大模型运行开发环节中干流架构形式

“架构是灵敏多变的，切勿钻牛角尖”

但大模型在工程化落地中依然面临着很多疑问，比如说老本疑问，技术疑问，以及才干疑问，毕竟大模型并不是万能的，某些模型只管在某些方面表现较强，但并不是无所不能的。

因此，该怎样处置这个疑问呢？

这时 通用大模型+多个垂直小模型的处置打算就产生了。

大模型+多个小模型

大家看到大模型+多个小模型，会不会就以为大模型就是参数量庞大的模型，多个小模型就是参数量较小的模型？

其实这里说的大模型+多个小模型并不是从咱们传统意义从技术角度了解的模型，而是从业务角度上的模型。

这里的大模型指的是你们公司关键业务依赖的模型，比如一家做AIGC业务的企业，它的大模型必需是以生成业务为主；但生成式范畴那么大，无法能有一家公司能保养如此多的模型，必需是以一两个业务方向为主，其它的为辅。

比如说一家公司做AI音乐生成业务，但假设它还想做视频处置和文字处置的业务，这时它或者就没有那么多资金，技术和期间来保养如此多的模型。

而多个垂直小模型也并不是说必定是体量小的模型，而是那种非关键业务的模型；或者是自己保养的小模型，也或者是调用第三方的大模型服务。

大模型+小模型的性能形式细分来说还有很多实用场景，比如下面说的主业务模型+边缘业务模型；再比如，一特性能弱小的视频生成模型+多个不同格调的垂下小模型，经过大+小的形式来处置不同场景的疑问，以及浪费企业老本。

不论是学习还是实践的企业运行，千万要明确没有人能做处置一切的疑问，也没有人能实现一切的义务，因此协作才是最好的选用，而大模型+垂直小模型的形式就是最好的协作表现——协作共赢。

团体或企业只有要关注于自身的外围业务，而不用把期间和精神糜费在一些自己基本有力实现的义务上，这就是要做报答率最高，最有性价比的事件。

很多人都青睐做一条龙，集研发，消费，开售为一体，但对大局部中小企业来说成为产业链条上的一环或者是更好的选用。

而在往年上半年，360CEO周鸿祎也不止一次性的提过，不要过火谋求大模型的才干和性能，经常使用多特性能弱小的垂直小模型或者会比一个大模型做的更好，更强。

前面可以说是经常使用大模型+多个小模型的好处，那么经常使用这种打算有没有什么坏处呢？

凡事都有两面性，经常使用大模型+小模型只管能带来很多好处但雷同也面临着很多疑问。

只管很多时刻因为业务的多元性造成咱们不得不经常使用多个模型，但经常使用多个模型最大的疑问就是要适配不同的模型，每个模型都有其不同的输入和输入，而且不同模型的才干不一而足。

咱们要在兼容不同模型的基础之上，还要同时统筹多种模型的复杂性和稳固性。

就相似于传统业务系统架构中，因为业务须要或其它要素造成咱们不得不引入一些两边件，但有过名目阅历的人应该都知道，每引入一个两边件都会给名目带来一些不确定的潜在危险。

万一两边件不稳固怎样办，万一两边件宕机了怎样办等等，怎样做容错处置等。

总之，没有原封不动的架构，也没有白璧无瑕的系统，咱们须要依据实践状况基本不同的业务场景，选用适合的处置打算，而不是想着靠一个架构处置一切疑问。

最后，最最最关键的事就是，面对疑问必定要灵敏多变，切记无法钻牛角尖。

原文链接：​ ​​ ​​