什么项目适合用大模型？

最近看到越来越多的项目开始用大模型，我自己也做了一些评估。到底什么项目适合用大模型？以下做一些总结。

我认为，核心有两点：显性调用成本和隐性纠错成本。两笔账算完之后，对于项目是不是该用大模型，就有一个更加清晰的判断了。

第一笔账：显性调用成本（也就是token）

这是最直观的，我们按主流闭源模型的API价格算，输入输出加一起，每百万token大概在几十元到几百元人民币这个区间。

我们来做个压力测试，假设你有一个客服场景，日均活跃用户1万人，每人来回对话5轮，每轮平均消耗1500个token。一天就是7500万token。按每百万40元算，一天三千，一年接近110万，还只是纯API调用费，没算联网搜索等附加费用。

那如果换开源模型自己部署呢？一张H100按云厂商报价，每小时大概40元。跑一个70B级别的模型，至少得4张卡打底，每小时硬成本160元往上。一年跑下来，光GPU就得小150万。

还有就是吞吐量的问题。如果业务并发高，模型推理慢，为了维持同样的吞吐量，就得成倍堆显卡，想要维持并发能力，就得成倍地买卡，这笔钱也是不小的。

所以第一道决策门槛简单粗暴：你的业务日均请求量，乘以单次token消耗，再乘上365。 如果这个数字太高，等于是你给大模型打工了。

第二笔账：隐性纠错成本（也就是幻觉税）

大模型有时候会一本正经地胡说八道。

根据Vectara HHEM的数据，在新闻摘要这类相对可控的任务中，头部模型的幻觉率不到1.5%。但如果换个场景，比如6月刚发布的PhantomBench基准测试，用6万多个“不存在但听起来像真的”概念去考21个模型，部分模型的幻觉率高达86.7%。

也就是说，幻觉率不是一个固定的数字，而是取决于你让模型干什么活。一旦涉及知识边界探测等需要“知道自己的无知”的任务，前沿模型也会频繁翻车。

有些错误不是当场能发现的。比如生成合同条款里的模糊表述，或者代码里的逻辑后门，这种问题纠错成本可能会很高。

第二道门槛是：你的业务容错率，必须高于模型当前的基准幻觉率。 如果业务场景要求准确率 99.9% 以上，可能更好的选择是直接放弃纯大模型方案。强行上的话，纠错投入会反超调用成本，做到最后你发现养了很多复核员。

结论

适合用大模型的，是那种单次产出高价值，而且错了修改成本不是很高（或者可以让大模型自己验证修改）的活，比如代码生成、文档摘要、初稿写作、客服工单分类等等。

而不适合的，是那种高频低价值、容错率低的事，比如精密工业质检等等。

该省的钱，咱一分都不多烧。该拿的效果，咱一分都不少拿。