​ “大模型和小模型是从功能上来区分的，而不是参数上”

我们在工作的过程中，应该多多少少都遇到过这样的事情；那就是老板为了节省成本，然后找了一些不专业或者一些漏洞百出的工具给我们用；最后的结果就是成本没节约下来，然后还出了一大堆乱七八糟的事。

这可真的是羊肉没吃着，还惹了一身骚；成本没节约，最后还耽误时间，身心俱疲。

为什么不建议使用小模型？

首先声明一下，这里的小模型不是指参数体量小的模型，是指功能太差，无法满足业务场景的模型；更有甚者很多小企业老板会选择一些开源模型，自己部署，就为了省钱。

但他们却不知道，这里的“节省成本”并没有真正节省成本，反而大大地增加了成本。

使用小模型会面临着哪些问题？

使用小模型最大的问题就是，其性能不足，而且由于没有专业的团队维护，导致其会出现各种乱七八糟的问题。

以作者本人来说，公司最近的一个AIGC(AI生成内容)产品中，有一个文字生成视频的功能，这也是大模型应用中比较常见的一个功能。

然后使用的就是社区里的一个开源模型，而这种开源模型只能自己来部署，因此还专门买了算力机去部署。

而关于大模型的部署与运维，在前面的文章中也提到过，复杂性和工作量就不用细说了，感兴趣的可以查看文章​ ​关于大模型在企业生产环境中的独立部署问题​ ​。

关于这个文字生成视频的功能，说句实话，浪费了大量时间和精力开发的产品，效果真的是一言难尽；而且，这个模型使用的还不是传统的类似sora这种真正的视频生成模型，而更像是生成一张图片，然后增加了动态的效果。

而且，不只是模型本身的效果问题，也是为了节约成本选择的算力机并不是知名企业提供的算力，而是找的一个不知名企业的算力云机器，结果就是性能差的要死；跑在上面的服务经常莫名其妙的被杀掉，系统莫名其妙的重启。

而这就间接导致了各种各样的莫名其妙的问题，然后就需要浪费大量的时间和精力去排查；看到这里有些人可能会说，知道是算力机不稳定，肯定先查算力机啊？

但事实上问题出现的表象和算力机一点关系都没有，甚至你会怀疑是不是自己代码写的有问题，亦或者是不是某个中间件出问题了。

而这种乱七八糟，奇奇怪怪的问题不但耽误大量的时间和精力，最重要的是它会让我们特别的烦躁；本来简简单单就能解决的问题，然后中间出现一堆莫名其妙的bug，耽误进度，更影响心情。

最重要的一点是什么？

人的时间和精力都是有限的，当你把大量的时间和精力浪费在一些乱七八糟的事情之上后，你的核心业务就会受到影响。

首先，使用小模型带来的各种各样的问题，直接导致你本来有半年的时间开发核心功能，结果被奇奇怪怪的bug耽误了一大半时间；然后核心功能可能就会被做的乱七八糟的，甚至是匆匆忙忙的上线。

然后，技术人员就不得不花大量的时间去四处救火，最后形成恶性循环。

在前面的文章中作者曾说过，大模型+小模型是现在企业开发的主流模式；这里说的大模型+小模型是指性能足够的前提下，而不是说你随便找一个根本无法满足业务需求的模型，不但如此还要花费大量的时间去运维，这就更不值得了。

在基于大模型开发上层应用的过程中，除了大模型服务商之外，对绝大部分企业来说，使用第三方模型是最好的选择。

一个稳定的模型能够给你节省大量的时间和精力，这时你就有更多的时间把核心业务处理好，这也是为什么很多大企业会把一些非核心业务外包出去的原因之一。

原文链接：​ ​​ ​​