最近一段时间公司在搞AIGC领域的产品，虽然集成了很多第三方的大模型服务接口，但从节省成本的角度，公司也找了一部分具有相似效果的开源模型做独立部署。

但在做模型独立部署方面面对着各种各样的问题，而且环境极不稳定，因此就引发了关于大模型企业级应用中的环境部署和运维的问题。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

首先抛开成本问题从技术的角度来说，小公司独立部署大模型会很吃力，因为大模型部署是一个系统性的问题。涉及到算力，大模型，服务接口，并发问题等多个环节，设计到系统运维，镜像，监控，系统架构等多个方面。

企业独立部署大模型主要涉及哪些问题点？‍‍‍‍‍‍

首先最基础的就是算力问题，对大部分企业来说根本无力建属于自己的机房，面对着动辄几万甚至几十万的算力机，对大部分企业来说都无法承担。‍‍‍‍‍‍‍

因此，购买或租用一些云端算力机是一个比较好的选择，但云端算力机也只是一个一个独立的机器，在应用层面并没有提供自己集群部署和运维的能力。‍‍‍‍‍‍‍‍‍‍‍‍

当然，并不是说云计算做不到这一点，而是能做到这一点的云服务商机器的价格都比较贵；因此，对很多小微企业来说，都会选择一台或多台算力能够简单支持业务正常运营的机器，然后做人肉运维。‍‍‍

比如我们公司，就是购买了几台云端算力机，在上面部署几个模型，然后天天出问题，一个问题查一天。‍‍‍‍‍‍‍‍‍‍

从大模型的部署角度来看，部署大模型无非以下几种方式：‍‍‍‍‍‍‍‍

最简单的是一些小模型，单台机器就能够支撑其运算需求，这时在企业生产中只需要在多台机器上部署多个相同的模型，然后在入口做一个负载均衡就可以了。‍‍‍‍‍‍‍

但如果没有完整的运维系统，全靠人肉运维，这样会把运维和技术人员给累死。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

先说这种模式经常出现的一些问题，比如怎么检测大模型服务的健康状况？说白了就是怎么知道这些机器是否在正常运行？一台机器一台机器的看吗？

再有，如果某台机器出问题了，怎么快速定位到这台机器上？ 大模型的集群部署是否有自动健康检测系统？‍‍‍

我想很多企业都做不到这一点，一旦出问题只能靠技术人员慢慢排查；而这还不包括一些莫名其妙的问题。‍‍‍‍‍

比如说我自己，前几天遇到一个bug，AIGC的任务无法提交到大模型，本来以为任务无法提交是因为自己的模块有bug，然后查了一下午时间发现是因为算力机出问题导致业务端无法获取到算力机，然后间接导致任务无法提交。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

而如果是那种参数量和算力要求巨大的模型，单机部署就无法实现，只能依靠集群的并行计算能力，但换句话说能做到大模型集群并行计算的公司又有多少？ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

模型不同模块之间怎么部署，怎么监控，怎么解决它们的通讯问题，某些模块的算力瓶颈怎么解决？ 遇到高并发问题怎么解决？是使用异步通讯，还是使用消息队列做削峰处理？ 中间引入的异步通讯模块或消息队列中间件怎么保证稳定性？‍‍

最重要的是，在出现生产问题时怎么做到及时的响应，并快速恢复上线，把影响降到最小？而这些靠人工来做是不可能完成的，但大部分企业又没有能力构建完善的运维系统。

再有在大部分小微企业中，老板或者领导最看重的就是业务的开发进度，而不是系统运维的难度。业务开发时间被不断的压缩，各种业务bug已经让人不厌其烦，再加上模型服务的不稳定性，真的是让人崩溃。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

还有就是很多小公司为了省钱，前期也不肯找一个有能力，有经验的架构师做系统架构，很多小项目都是匆匆上马，开发人员素质不齐，导致大量的设计缺陷和业务漏洞，还包括一些项目管理混乱，简直就是群魔乱舞。‍

就拿作者自己的公司来说，采用的就是租用云算力服务商的算力机，把模型服务独立部署在云端；而为了提高扩展性，就通过调用云算力服务商的接口，根据业务压力动态进行扩容，也就是用镜像的方式启动多台相同环境的机器；然后业务端通过轮训或其它方式来进行动态选择算力机。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

然后为了解决可能存在的性能压力，因此就采用消息队列的方式做扩容；但由于业务时间紧，项目开发都是以完成功能为主，因此就导致整个扩容模块没有数据一致性处理，代码没注释，业务逻辑混乱，日志不全。‍‍‍‍‍‍‍‍‍‍

随便某个中间环节出问题，就只能从头开始排查，无法准确定位到问题产生的时间，地点和方式。‍‍‍

说了这么多，其实从根吧上来说还是很多小微企业的老板对整个技术没有一个完整的认识；大模型技术本身就极具复杂性，由于其庞大的算力需求就导致单机部署基本成为不可能。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

而集群化部署的复杂性又是不可想象的，因此其运维的难度与传统运维相比完全不可同日而语。‍‍‍‍‍‍‍‍

再加上需要把大模型与具体的业务相结合，而怎么设计大模型的服务接口，不但要保证功能性，还要保证稳定性和扩展性；而这就需要有着足够强大的业务理解和梳理能力，以及强大的接口抽象能力。‍‍‍‍‍‍‍‍‍‍

而以上种种，任何一个都不是普通人能轻易完成的任务。‍

因此从各方面来看对小企业来说，独立部署大模型都不是一个好的选择，表面上来看好像是节约了成本；但事实上不但大大增加了运维的难度和成本，最重要的是大大提高了系统的运行风险，导致整个系统风险不可控。‍‍‍‍‍

其次，大量的运维问题会占用技术和开发人员大量的时间；就比如说运维方面出了一个小问题，就很可能导致整个开发进度被耽误，开发人员会遇到各种各样莫名其妙的问题，而无从下手。‍‍‍‍‍‍‍‍‍‍‍

因此，选择一个三方模型虽然成本可能会高一点，但可以让你完全专注于自己的核心业务，减少系统性风险以及各种乱七八糟的问题。