“大模型和小模型是从配置过去辨别的，而不是参数上”
咱们在上班的环节中，应该多多少少都遇到过这样的事情；那就是老板为了节俭老本，而后找了一些不专业或许一些破绽百出的工具给咱们用；最后的结果就是老本没浪费上去，而后还出了一大堆乌七八糟的事。
这可真的是羊肉没吃着，还惹了一身骚；老本没浪费，最后还耽误期间，身心俱疲。
为什么不倡导经常使用小模型？
首先申明一下，这里的小模型不是指参数体量小的模型，是指配置太差，不可满足业务场景的模型；更有甚者很多小企业老板会选用一些开源模型，自己部署，就为了省钱。
但他们却不知道，这里的“节俭老本”并没有真正节俭老本，反而大大地参与了老本。
经常使用小模型会面临着哪些疑问？
经常使用小模型最大的疑问就是，其性能无余，而且由于没有专业的团队保养，造成其会产生各种乌七八糟的疑问。
以作者自己来说，公司最近的一个AIGC(AI生成内容)产品中，有一个文字生成视频的配置，这也是大模型运行中比拟经常出现的一个配置。
而后经常使用的就是社区里的一个开源模型，而这种开源模型只能自己来部署，因此还专门买了算力机去部署。
而对于大模型的部署与运维，在前面的文章中也提到过，复杂性和上班量就不用细说了，感兴味的可以检查文章 对于大模型在企业消费环境中的独立部署疑问 。
对于这个文字生成视频的配置，说句瞎话，糜费了少量期间和精神开发的产品，成果然的是一言难尽；而且，这个模型经常使用的还不是传统的相似sora这种真正的视频生成模型，而更像是生成一张图片，而后参与了灵活的成果。
而且，不仅是模型自身的成果疑问，也是为了浪费老本选用的算力机并不是出名企业提供的算力，而是找的一个不出名企业的算力云机器，结果就是性能差的要死；跑在下面的服务经常莫明其妙的被杀掉，系统莫明其妙的重启。
而这就直接造成了各种各样的莫明其妙的疑问，而后就须要糜费少量的期间和精神去排查；看到这里有些人或许会说，知道是算力机不稳固，必需先查算力机啊？
但理想上疑问产生的表象和算力机一点相关都没有，甚至你会疑心是不是自己代码写的有疑问，亦或许是不是某个两边件出疑问了。
而这种乌七八糟，奇奇异怪的疑问岂但耽误少量的期间和精神，最关键的是它会让咱们特意的焦躁；原本简便捷单就能处置的疑问，而后两边产生一堆莫明其妙的bug，耽误进展，更影响心境。
最关键的一点是什么？
人的期间和精神都是有限的，当你把少量的期间和精神糜费在一些乌七八糟的事情之上后，你的**业务就会遭到影响。
首先，经常使用小模型带来的各种各样的疑问，直接造成你原本有半年的期间开发**配置，结果被奇奇异怪的bug耽误了一大半期间；而后**配置或许就会被做的乌七八糟的，甚至是匆匆忙忙的上线。
而后，技术人员就不得不花少量的期间去到处救火，最后构成恶性循环。
在前面的文章中作者曾说过，大模型+小模型是如今企业开发的干流形式；这里说的大模型+小模型是指性能足够的前提下，而不是说你随意找一个基本不可满足业务需求的模型，岂但如此还要破费少量的期间去运维，这就更不值得了。
在基于大模型开发下层运行的环节中，除了大模型服务商之外，对绝大局部企业来说，经常使用第三方模型是最好的选用。
一个稳固的模型能够给你节俭少量的期间和精神，这时你就有更多的期间把**业务处置好，这也是为什么很多大企业会把一些非**业务外包进来的要素之一。
原文链接：