上个月一个做传统制造业信息化的朋友问我："我们准备上 AI，到底该选哪个模型？"

我停了几秒，发现这个问题我答不上来——不是我不知道有哪些模型，是这个问题本身就不成立。企业选模型从来不是挑一个最强的名字挂上去，而是给每一类任务配一个合适的档位。问"选哪个"，等于问"我家该买哪辆车"，却没说自己是要拉货、跑长途，还是接送孩子。

这是《企业AI落地实战》系列第二篇。上一篇聊启动前该问的五个问题，这一篇聊钱真正花起来之后，模型该怎么选。

选模型最容易犯的错，其实是被单价牵着走

大部分人看模型，第一眼看的是价格表：输入多少钱、输出多少钱、缓存读多少钱。

这些数不是没用，但它们太像菜单上的单价了。你点菜时觉得每道都不贵，结账才发现服务费、酒水、临时加菜全来了。

模型也一样。有些新模型把缓存读取价格降下来了，听起来是利好；但如果它为了拿到更高质量，实际多花了几倍推理 token、生成了更长的中间步骤、给了更啰嗦的答案，那点单价优势就被吃干净了。

我见过一组挺有意思的公开评测：同一个高思考模型，在某个智能指数上分数比上一代更高，但单任务消耗的 token 也更多；换到另一类偏工程的任务上，又是成本下降、分数上升。两个结果不打架，它们说的是同一件事——决定账单的是任务形态，不是发布文案。

所以我现在看模型成本，会先问一句：这个任务跑一次真实活儿，到底烧多少？模型省不省钱，要按交付算，不能按 token 单价算。

同一个模型，不同档位不是一个成本结构

第二个容易被忽略的地方：同一个模型，档位不同，成本结构完全不同。

现在不少模型提供 low、medium、high、extra high、max effort 这类思考档位。听上去像油门踏板，实际上更像不同工种。

我看过两组对照：一个浏览器里的小游戏任务，最高档跑了一小时、成本接近 19 美元，但结果完整——赛道能跑、碰撞有效、计时正常；中高档更快，二十多分钟、13 美元出头，但细节粗糙。另一个网站设计任务，最高档 51 分钟、17 美元，页面完整度最好；低一档 8 分钟、4 美元，结构接近但完成度弱一截。

差了四倍的钱，买的是不是四倍的产出？这要看你的任务属于哪种。

我的分法是三层。

改文案、整理资料、轻量代码修改这类活，用低中档，你人工扫一遍再加局部运行就能验收。

单文件复杂实现、清晰 bug 修复、长文深度写作，上高档，配测试和 diff 复查。

跨模块重构、疑难调试、长期 Agent 任务，才轮到最高档，而且必须配完整测试、可观察日志和人工验收。

最高档应该默认禁用，它是事故处理档，不是日常档。只有当任务满足"失败会浪费你半小时以上人工""要跨五个以上文件或系统边界""输出必须一次接近可交付""错误测试抓不到""中高档跑过一轮明确卡在推理深度上"这五条里的两条，才值得开。

别不好意思降档。成熟的用法不是"我用最强模型"，是知道什么时候不该用它。

小模型真的只能干杂活吗？

过去两年，"大模型当老师、小模型当学生"这个说法很流行。到今年，这个故事不够用了。

蒸馏这条路已经走过三代：第一代学答案，把老师的输入输出成对拿去训练学生；第二代学推理链，让学生看到完整的拆解、校验、纠错过程；第三代干脆把推演能力内化到参数里，不再每次在线空耗一堆思考 token。

说白了就一句话：把昂贵的智能变成便宜的智能，把推理成本从"每次使用时在线计算"挪到"训练阶段一次性沉淀"。

效果也很实在。现在市面上有 30B 级别的开放模型，专门为本地 Agent 工作流设计，单张消费级显卡、一台 Mac 或普通 PC 就能跑完整任务——不用联网、不用按 token 计费。

但有个反直觉的结论值得记住：老师越强，学生不一定越好。两者之间有个容量差距，千亿级老师的抽象方式，参数量有限的小模型在表征空间上根本接不住，学到最后反而震荡、饱和。就像让一个刚上三年级的孩子直接听顶级科学家推前沿物理，不是老师讲得差，是学生接不住。

放到企业里就是：高频、稳定、格式固定的活，可以下沉到小模型甚至本地跑，成本能压掉一大截；但那些需要跨域判断、疑难分析的活，本地那点能力确实低一档，还是得交给云端大模型。

别在同一个会话里塞两种任务

这几年我见过最普遍的浪费，是把写方案和审合同塞进同一个对话框。

两件事的上下文互相干扰，模型越聊越拧巴——前面刚用写报告的调性铺垫了一大段，后面审合同就开始替甲方说好话。

真正要分开的是三件事：能力路由、交接协议、质检点。

能力路由是给每个环节挑模型：检索用一个、分析用一个、生成用一个、校对再用一个。降本的关键不是换更便宜的模型，而是让贵的别再干杂活——起标题、写摘要、压缩上下文这些活，便宜的快模型完全够用。

交接协议是上游给下游的输出格式。我踩过这个坑：上游写了一大段散文，下游根本没法接手，只能重新理解一遍。后来改成固定结构——结论、证据、待核项分节，数字后面标来源，不确定的地方写"待核"而不是硬编一个。

质检点是关键环节上的一次交叉检查。写和审用不同的模型、不同的人设，盲区才暴露得出来。同一个模型写完再自己审，很难跳出自己的思维惯性。

混合部署怎么落地？

回到开头那个问题：企业到底怎么选。我给的是一个拆解流程，不是名单。

第一问，这个环节要什么能力？笼统说"强"没有用，得拆成具体的：需要数学和复杂推理，需要中文长文表达，需要创意发散，还是只需要速度。不同能力对应不同的候选，这是路由的起点。

第二问，哪个模型最适合？以你自己任务的实测为准，别看广告。有个两分钟就能做的测试：同一段中文文本分别丢给两三个候选模型，看谁的断句、术语、语气更自然，各自的"性格"立刻就能看出来。

第三问，交接格式是什么？这一步最容易被跳过，也最常出错。谁交给谁、什么格式、带哪些字段，写清楚。

行业里已经有人把它做成产品了。海外云厂商的推理路由器靠"简单请求走轻模型"，实测把推理成本砍掉了 40% 到 60%；也有开源项目专门做智能体任务的模型路由。

落到具体协作，三种模式够用了。

串行接力适合有风险的内容：模型 A 起草，模型 B 扮演挑剔的编辑只挑逻辑漏洞和数据存疑处，模型 C 定稿。并行对比适合重要决策：同一任务丢给两三个模型各自出稿，你来择优或合并。分工流水线适合有固定环节的日常产出：检索、分析、生成、校对各管一段。

有三条边界得先说清楚。简单任务、一次性提问，单模型就够，别为了"多模型"而多模型，切换本身有成本。两个模型给出相同答案不等于正确，它们可能用了相似的训练数据，关键事实还得靠程序或官方来源核。敏感资料别散到多家服务商，涉及保密内容就用单一可信来源或本地部署。

模型的账，要按交付算，不是按 token 单价算

前面说的都是方法，最后落到钱。我建议企业看四个数，而不是一张价格表。

单任务总 token：完成一次真实任务用掉多少输入、缓存、推理和输出，这是账单主体。

首次可用率：第一次结果能不能直接进入验收，这个数决定返工成本。

修复轮数：需要几轮提示才能修到可交付，它直接吃掉总时长，还顺手把上下文撑肥。

验证成本：你要花多少人工、测试、截图去确认它没乱来。模型越强，坑藏得越深，这一项越不能省。

四个数一起看，结论常常反转：很多"便宜模型"贵在返工，很多"昂贵模型"只在高风险任务上才划算。

有个年营收十几亿的软件公司公开过他们的账：一天烧一百多亿 token，全年从 72 亿涨到单日百亿量级。他们的管法挺务实——个人有个人额度，团队有团队预算，专项有专项预算；有一部分额度就是允许你浪费的，超了自己充值或者走审批。他们 CIO 有句话我印象很深：企业本质上是个理性的决策组织，哪怕一开始被焦虑裹挟，事后还是会追问产出。

企业要的从来不是最聪明的模型，是可预测的成本。私有化还是 API，本地还是云端，取决于你的任务分布——高频稳定的活下沉，疑难判断上云，中间用路由和协议连起来。

选型不是挑最强，是给每类任务配合适的档位

回到那位做信息化的朋友。我最后跟他说的是：先别挑模型，先把自己公司要干的活列十件出来，标上哪件高频、哪件出错代价大、哪件必须人签字，然后我们再谈用哪个模型跑哪件。

说到底，模型选型不是一道品牌选择题，是一道分账题。

混合部署听着复杂，拆开就是三句话：简单活给便宜模型，难活给贵模型，交接处立规矩、关键处留质检。