1.背景
随着 ChatGpt 展现的惊人能力，各种大模型也逐渐进入人们研究使用的范围。虽然开源社区各种努力，但是研究和使用大模型并没有那么方便。首先大模型是 GPU 密集型任务，对 GPU 的算力，显存等要求都很高，而目前市面上 GPU 短缺，价格相对较高，使得很多公司或者研究者处于巧妇难为无米之炊的境界，就算购得之后，由于线上调用量少，也没办法完全利用，浪费了算力。其次大模型的部署运维高可用区别于传统应用，这也要求公司必须具备这样的人才，而当前处于大模型刚刚爆发时期，相关人才数量较少，不大能满足社会需求。
应对上述问题的最佳方案就算大模型的 Paas化。企业将大模型使用的整个生命周期托管给云厂商，云厂商通过专业的技术团队运维大模型，同时通过优秀的调度算法能力，充分利用显卡资源，降低大模型使用的成本。
那一个大模型的 Paas平台要有哪些功能呢？ 下面我们通过分析大模型业务相关的场景，以及大模型 Paas 平台的运营过程来梳理出相关功能点。
2.大模型相关业务场景分析
2.1 大模型用户侧的业务场景
大体来说，一个和大模型相关的业务基本涉及下面几步。 第一是算法团队训练模型，第二是运维团队部署模型，第三是工程团队基于模型做业务开发，然后上线业务，后续算法团队根据实际结果持续优化模型。
算法训练一种是从 0 到 1 这种，由于这种资金成本和时间成本都很高，除了极个别大公司很少会这样做。另外一种是基于现有模型进行微调，应该是很多公司大多数的选择。即使是微调模型，对资源的要求也是很高的，而且随着业务的发展，资源使用具有一段时间用量高，一段时间用量低的特点。所以很多公司还是会选择云计算这种弹性资源。微调的时候，算法团队会先选择一个合适的业界常见的大模型，然后自行收集或者采购一些和自己业务行业相关的数据，进行微调，微调后需要一些设计好的案列进行微调效果的验证。如果验证的效果不好，可能需要修改模型参数，或者调整数据集，重新进行训练。循环往复直到达标。当模型达标的时候，就交给运维和技术团队。
运维团队接收到大模型后，需要根据大模型对资源的要求，采购相关机器资源，然后部署相关依赖的软件资源，最后部署大模型，同时还需要结合业务特点考虑模型的弹性调度，模型的高可用建设，模型的 CICD 流程等。
技术团队拿到运维团队提供的模型接口地址和算法团队提供的模型调用的 API 文档之后，根据自身的业务特征设计技术方案，编写业务代码，同时需要考虑一些非业务上的问题，如大模型普遍响应较慢，如何做好交互，如果大模型偶发超时，或者不可用，业务侧如何降低对业务的影响等。同时模型升级迭代的时候，如何保障业务对外的一致性，平滑升级等。
最后还需要从成本的角度去考虑，模型运行需要了多少资源，产生了多少费用，以及各个环境的资源消耗，方便后续降本增效。
2.2 大模型运营侧场景
当我们把大模型进行 Paas 化改造后，那么就需要一个团队运营这个 Paas 平台，那么这个团队在 Paas 平台中涉及不同角色，所以需要提供不同能力。
算法需要将世面上常见的大模型进行适配然后推送给技术同学，技术同学需要为大模型提供相关的技术访问文档，用列等。然后将大模型转交给运营同学，运营同学根据大模型的特点，为大模型提供插图，宣传语等一系统营销相关信息，最终提交审核后发布大模型到基础模型模块（模型广场）。
系统需要提供功能一个方面是系统运行的各项监控和预警，帮助运维同学快速发现系统问题。另外也需要提供各种预案工具，能在系统出现问题的时候技术和运维同学通过这些工具快速解决问题。
安全需要保障大模型的输出不能出现涉及法律，政治等相关触犯国家法律法规，违背各个国家和地区伦理道德的言论。
平台需要提供功能供财务同学去统计，审计，分析每个客户的花费，每个资源的使用情况，收支利润等和财务相关的各种功能。
3大模型Paas平台功能设计
3.1大模型用户侧功能设计
我们通过上述分析了大模型各个角色使用大模型的业务场景，那么我们的大模型 Paas 平台对客户侧业务可以按照这些角色使用的功能进行设计。
训练模块
这个模块围绕训练的生命周期展开，训练的原料 （数据，源码，环境），训练的过程（训练任务），训练的产物 （训练结果）展开。
- 数据管理
可能需要包含数据集的新增，修改，删除，导入，导出，标注等功能。
- 训练源码
需要实现源码的新增，删除，版本管理等功能。
- 训练任务
需要包含任务的新增，任务的修改，任务的删除。另外每个任务可以运行多次，每次对应的任务执行详情。如果设计功能更加丰富，还可以考虑定时调度等。
- 任务执行详情
任务执行详情主要分为两块，一块是任务运行时相关的功能，如运行时的日志，事件，性能监控，登录运行机器等。另外一块是运行后的结果，如产生的大模型的验证，发布，运行总结报告等。
模型管理
提供模型的创建，修改，版本管理，删除等功能。
提供公开的能力，让模型能在模型社区分享传播。
部署模块
围绕模型部署的生命周期展开，部署的原料，部署的设备，部署的过程，部署的结果。
- 部署单
提供一个模型部署所需要选择的各项参数，如模型，集群类型等，选择后 创建部署单。部署单内可以启动，终止部署过程，查看部署日志，排除部署问题等。
- 部署管理
可以查看已经创建的部署单。
推理服务模块
- 服务管理
提供已经部署成功的服务的释放，重启，运行日志的查看，机器资源的查看监控等。查看部署历史，回滚模型等。
- 调用管理
调用管理提供用户调用接口（SDK） 所需要的密钥，参数等功能，密钥的有效期，密钥的替换等功能。
- SDK 模型
提供各种语言版本的 SDK，相关 SDK 的版本，使用方法文档，在线测试等功能。
- 调用监控模块
提供各个接口的监控，包括 QPS，RT，调用量，成功错误率等模块。
成本模块
- 使用明细
提供给客户使什么时间用了什么资源，用了多久，产生了多少用量等功能。
- 费用明细
基于使用明细，通过单价或计价规则，给客户提供费用明细及计算过程。
- 费用总计
提供总费用。
3.2 大模型运营侧功能设计
运维
- 设备管理
管理各种GPU 集群，实现集群的创建，裁撤，扩缩容，添加和删除资源等。
- 监控告警
对各个集群及各种硬件资源进行各种指标的采集，同时提供告警规则设置，告警接收确认，临时关闭等。
- 预案处置
针对常见的问题形成处置工具，当问题发生时候，可以借助工具快速解决。
模型管理
- 基础模型上线
模型上线是一个涉及算法，技术，运营，运维，安全等多个角色的业务流程。所以需要设计一个流程来推动整个过程。
- 模型升级
模型升级和上线类似也是涉及多个角色的流程，需要相关的流程串联起来。
- 模型下线
模型下线涉及如何和客户交互告知，运维从服务集群下线等流程功能，甚至需要从法律方面考虑流程的合规性，不是简单的删除模型，也需要一个完整的流程串联起来。
安全运营
- 安全规则
安全人员可以录入，修改，删除，相关敏感词规则。同时需要提供规则校验的能力，方便安全人员测试。
运营模块
提供模型热度排行榜，提供模型广场模型的顺序等。
财务模块
提供基于客户角度的财务明细，账单，数据最终汇聚到专业的财务系统。
提供基于资源的财务明细，账单，数据最终汇聚到专业的财务系统。
4 总结
本文是自己通过思考大模型使用的整个过程，分析得出的一些结论和看法。希望向大家展示一下，如何对于你不熟悉的领域，如何快速分析和熟悉这个领域。既我们需要首先分析这个业务会涉及哪些参与方，然后这个业务服务的客户是谁，客户的利益，使用场景是什么，然后我方应该怎么设计业务流程满足客户的利益和自身的利益呢。最后由于还没实际参与过相关系统的研发和建设，所以部分结论可能有误，希望指正批评。
