在前面的千万不要为了节约成本而选择小模型，特别是开源模型这篇文章中，简单说明了为什么尽量不要选择小模型，然后文章下面有些评论，可能觉得作者说的都是废话，或者模型不好直接换就行了。

但事实上作者认为这些都是站在纯粹的技术角度或者说把企业级应用想的太简单了。‍‍‍‍‍‍‍‍‍‍‍‍

很多技术人员都习惯站在技术的角度来考虑问题，认为某项技术不好换一个就好了；又或者因为某些原因导致某些东西不能用。比如说，有些政府单位或银行保险部门还在使用xp系统和jsp做开发。

所以很多人就认为政府单位的系统很拉垮，或者自己公司的技术经理脑子有问题，选的都是什么架构和技术栈；包括作者自己在前两年也是这种想法。‍‍

但随着工作经验的增加，以及看待问题角度的改变，现在发现一个项目真的没那么容易给做起来，做好；它会受到多个方面的影响，由于各种各样的原因可能会导致想的是一回事，做的是另一回事。‍‍‍‍‍‍‍‍‍‍‍‍‍

友情提示一下，看这篇文章首先要抛开技术至上的理念，要从企业运营，产品，成本，技术等多个角度来看待问题。‍‍‍‍‍

现在从实际案例的角度来思考问题，假如某一天你和朋友合伙开公司，然后想做一款基于大模型的产品；然后由于初创企业，资金和人力都有限，无法直接配备完善的企业架构，比如说项目经理，产品经理，技术负责人，再加上其它的行政，财务等等。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

可能很多时候都需要一人扮演多个角色，又是项目经理，又是技术经理，同时还需要负责企业的正常运营。‍‍‍‍‍‍‍‍‍‍‍‍‍‍

现在假如你是技术经理，让你负责这款大模型应用的技术架构，以及业务实现；这时你应该怎么做？ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍

前期的需要采集与分析，以及产品经理把需求产品化的过程就不说了；现在产品经理直接给你一份产品的详细设计方案，然后让你基于这个方案做一个技术评估，以及一个能落地的技术方案。这时你需要处理哪些问题？‍‍‍‍‍‍‍‍

首先，你要评估这个产品在技术上是否可行，也就是说依靠现有的技术能力能否实现产品的功能；然后在技术可行的前提下，怎么设计系统架构，不同的功能模块怎么拆分；这时你考虑的不仅仅只是技术的实现问题上；还同时需要考虑后续的功能升级，产品上线之后的稳定性，当前自己团队的技术实力。‍‍‍‍‍‍‍‍‍

前端技术栈的选择，后端技术栈的选择，各种中间件的选择；然后是否会有安全性问题，合规性问题，保密性问题，行业要求，政府规章问题等等。‍‍‍‍‍‍‍‍‍‍

等这些问题都搞定之后，再来说关于大模型的选择，毕竟做的就是基于大模型的上层应用。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

关于大模型的选择一般有以下几种情况：‍

自己开发大模型，这种对创业公司来说基本可以放弃，除非你就是想做大模型服务‍‍‍‍‍‍‍‍‍‍‍‍‍

使用第三方模型，这又有几种情况，是使用一些大模型服务商提供的大模型接口，还是搞几个开源模型。‍‍‍‍‍‍‍

选择大模型服务商的模型，需要考虑几个个问题，你这个应用是否有保密性要求；比如数据不能上传到第三方模型服务；只能放在本地， 这时大模型服务商就可以直接抛弃了，只能选择开源模型本地部署。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

其次，开源模型服务商的接口价格问题；比如有些接口调一次几毛钱就没了；而在开发测试阶段，每天都要花几百块钱甚至几千块钱的接口调用费；这还不包括上线之后可能面临的大量用户调用带来的巨大成本。

因为一般情况下，产品上线前期很难赚到钱，这时就需要公司的资金做支持。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

如果无法承担巨大的资金成本，这时只能退而求其次去选择一些价格便宜，但性能可能并没有那么好的模型服务商。‍‍‍‍‍‍‍‍‍‍‍

这时，你觉得模型不好用，直接换一个就行了，有这么容易吗？ 虽然从技术的角度来说换一个模型很简单，也就是换一个接口而已。‍‍‍‍‍‍

再有，关于大模型本地部署的问题，大模型本地部署需要大量的算力，而算力问题怎么解决？ ‍‍

是自己买GPU组建机房，还是租用云算力服务？

自己组建机房就需要有专业的团队来负责机房的稳定运营和功能升级；租用云算力服务就需要面临巨大的资金压力；这时应该怎么选择？ ‍‍‍

一般情况下，选择云算力服务肯定会比自己组建机房成本要低的多；因此租用云算力服务是一个比较好的选择。‍‍‍

ok，现在云算力服务租下来了，要本地部署大模型；这时选择什么样的大模型做本地部署？ ‍‍‍‍‍‍‍‍‍‍‍‍

是选择功能垂直化的小模型，还是选择参数量巨大的强大开源模型？‍‍

选择参数量巨大的强大开源模型就意味着单台算力机无法支持大模型的稳定运行，这时就需要采用多台算力机并行计算的方式来实现；但大模型由于其体量巨大，而且运行过程中需要面临各种各样的问题。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

因此，人力运维就很难完成，因此就需要有完整的自动化运维系统；这个系统哪里来？自己开发，还是购买第三方的系统？ 第三方系统能满足你的全部需求吗？ 如果不能该怎么办？ ‍‍‍‍‍‍‍‍

还有，如果选择功能垂直的小模型，可以进行单机部署，但你这单机模型的运维怎么搞？ 全部靠人工吗？ ‍‍‍‍‍‍‍‍‍‍‍‍

如果是前期开发测试阶段，由于规模不大靠人力还能扛的住；但上线之后呢？如果面临每天几万，甚至几十万的访问量，单台机器能扛的住吗？

如果不行，大模型集群部署该怎么搞？ 是简单的多买几台机器然后把模型复制过去就行了吗？ ‍‍‍‍‍

怎么保证某台机器突然挂掉导致业务系统受影响，怎么做到不同机器之间的主动切换？ ‍‍‍‍‍

由于节假日或者某些原因导致系统压力突然增大，怎么在最快的情况下让系统自动扩容，应对流量洪峰。‍‍

当然，看到这里可能有人会说我们初创企业没有那么大的流量，这些都是有些规模的企业才需要考虑的问题。‍‍‍‍

虽然话是这么说，但即使是小企业在产品上线之后，只要产品不是特别差，每天的用户量也会有一部分吧？ 哪怕只需要三五台，甚至十来台机器部署大模型，而且还有保证业务的稳定运行，这时全靠人力运维，技术人员会有多累？能坚持的住吗？ 并且还要负责新功能的开发和测试。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

本地部署大模型就需要面临着巨大的运维成本，技术成本和算力成本；使用第三方模型就需要面临着巨大的接口调用成本；这还是在没考虑各种意外情况的理想状态下。‍‍‍‍‍‍‍‍‍

而且，你引入的技术种类越多，也就意味着你的技术成本越高；可能某些技术还需要重新学习。这也意味着上线之后面临的风险就越大；毕竟无法保证新技术带来的稳定性。‍‍‍‍‍‍‍‍‍‍

或者你会说，我们公司不缺钱，这些服务直接买就行了；那对于有钞能力的企业，作者只能留下羡慕的泪水。‍‍‍‍‍

总之，对企业级应用来说，它不是学习用的demo，这个不好换那个；再换之前你需要考虑技术，资金，稳定性，风险等多个角度去考虑问题。‍‍‍‍‍‍‍‍‍

所以，如果说你是技术负责人，你会怎么做？怎么平衡技术，成本，风险，以及各种各样的问题？