被问到该选哪个大模型的次数我记不清了。问的人有做客服系统的有做知识库问答的有想给内部流程加个助手的还有打算把模型接进审核管线的。大多数人一上来就甩我一张排行榜截图问我是不是选排第一的那个就行。我的回答通常不是是或者否而是反问他一句你拿自己的真实业务数据测过吗没有的话榜单再高也是别人眼里的优秀。这些年我在项目里踩过的坑让我养成了一个习惯——选大模型我会逐条过这 5 件事业务效果、成本、有效上下文、延迟并发、工具链稳定性。这五关过完才轮到排名说话。1. 第一件事拿业务数据实测别让榜单替你拍板1.1 为什么榜单分数在真实业务里经常失灵排行榜上的分数看着客观其实至少有三个问题绕不开。第一是训练数据污染。测评集的题目可能在训练阶段就被模型见过了分数自然虚高。这不一定是厂商作弊更多是互联网上的内容早就混进了训练语料模型哪怕没见过原题也见过高度相似的表达。第二是数据分布不一致。榜单测的是通用任务比如百科问答、数学推理、代码生成这些任务跟你业务里的真实输入根本不是一回事。你做的是短文本工单分类或者需要从聊天记录里抽取结构化字段那测评集里一万道题都和你无关。第三是刷分驱动。模型厂商都知道分数会被拿来当卖点于是会针对公开评测集做额外优化。这个现象在开源生态里更明显有些模型论文里的指标很漂亮拉下来一跑业务数据就现原形。所以我的结论是榜单可以看但只能用来圈定候选名单不能用来做最终决策。1.2 自己搭评测集从历史数据里抽 50 个样本就够起步很多团队一听说要做模型评测第一反应是要搞几千条数据的测试集然后这个项目就卡死在等数据上了。我的经验是先抽 50 条真实样本就够用了重要的是样本结构和评分标准而不是数量。具体做法是这样。先从你历史业务数据里抽样本——比如过往的客服会话、工单记录、已经标注过的样本、线上日志里真实用户的提问。抽的时候注意覆盖几个维度常见场景至少占一半疑难场景占三成边界和异常输入留两成。如果你不知道疑难场景是什么样的就翻一下历史工单里那些被转给人工处理的记录那里面藏着最典型的问题。抽完之后每条样本配一个参考答案。这个步骤不能偷懒参考答案可以是人工写好的标准回复也可以是从历史记录里挑选的出彩答复。没有参考答案后面打分就全靠主观拍脑袋评测结果没法对齐。1.3 评分维度要拆开看总分会掩盖问题给模型结果打分时最忌讳只打一个总分。总分高不代表适合因为你不知道它是在哪个维度上拿的分。我把评分拆成几个独立维度每个维度单独打分再加权汇总。评分维度考察内容常见问题内容正确性事实、逻辑、业务规则是否准确一本正经地编造数据完整性该覆盖的要点是否都覆盖了只回答一半漏掉关键约束格式合规性是否按要求的 JSON、表格、模板输出字段名乱飘、多出解释性文字指令遵循度是否严格遵守 prompt 里的限制词不让用保险字样它偏要提风格匹配度语气、用词是否符合业务预期过于正式或过于随意这五个维度里正确性和指令遵循度是我最看重的。前者决定了系统靠不靠谱后者决定了你写的 prompt 能不能生效。如果格式合规性这一项连续多条不达标那这个模型接进生产链路之前就要打一个大大的问号。1.4 分数之外还要拆解失败模式评测结果出来之后不要只盯着正确率这个数字我会把错误结果批量拉出来做一次聚类看看它稳定地栽在哪里。这一步给的信息比总分值钱得多。举个例子。某次我在给一个信息抽取项目选模型两个候选模型总分差不多但错误模式完全不同。模型 A 的错集中在长文本输入上超过 2000 字就开始丢字段模型 B 的错集中在歧义表达上遇到张三欠李四 500 元这种句子会分不清谁是债权人。知道了这个差异决策就清楚了——我的业务场景里长文本占大多数那模型 A 直接出局哪怕它总分略高。错误模式会直接告诉你这个模型上线之后会在哪些场景给你惹麻烦以及你需要准备多少兜底逻辑。2. 第二件事把成本账从单价算到单次任务2.1 输入输出计价的不对称性看 API 定价时很多人只扫一眼百万 token 多少钱就完事了这是最容易踩的坑。多数商用模型是输入和输出分开计价的而且输出 token 的价格往往是输入的三到五倍。原因不难理解输出 token 是模型实时逐字生成的推理过程中每个输出 token 都要占据完整的算力时间而输入 token 主要是并行处理计算成本相对低。所以厂商把输出定得贵是有物理原因在里面的。但如果你只看输入单价成本估算能偏出好几倍。2.2 单次任务成本公式我算成本从来不问单价多少只问单次任务多少钱。公式很简单单次任务成本 平均输入 token 数 × 输入单价 平均输出 token 数 × 输出单价÷ 1,000,000举一个具体的例子。假设某家商用 API 的定价是输入每百万 token 10 元输出每百万 token 30 元。你做的是一个知识库问答应用每次请求要携带系统提示词、检索到的若干段资料、以及前几轮对话历史加起来大约 6000 个输入 token模型平均返回 400 个输出 token。那单次成本就是6000 × 10 ÷ 1,000,000 400 × 30 ÷ 1,000,000 0.06 0.012 0.072 元如果一天有 5 万次请求光模型调用就是 3600 元一个月就超过十万。很多团队方案评审时觉得挺便宜上线后看到账单才反应过来就是没算这笔单次任务账。2.3 长上下文带来的成本放大效应对话型应用还有一笔容易被忽略的隐性成本每一轮新请求都要把完整的对话历史重新发给模型。一个用户聊了 20 轮假设历史累积到 1 万个 token那他在第 20 轮的请求本身就带着 1 万个输入 token而不是像你想象的那样只问一句新的。按上面的价格算1 万个输入 token 就是 0.1 元加上输出一个长期对话会话跑下来成本可能是首轮对话的十几倍。这个放大效应对很多高频客服类场景是致命的。所以我做成本评估时会专门算带历史的长会话场景占总流量多少这个比例直接决定要不要上上下文压缩、要不要做会话摘要。2.4 私有化部署的临界点什么时候该自建成本话题绕不开开源模型和私有化部署。我的判断标准很简单当请求量足够大或者数据敏感度不允许外发时才考虑自建。自建的成本要算全不只是显卡的钱。硬件上一张好点的推理显卡价格不菲要跑一个性能接近商用入门水平的开源模型通常需要两张卡组一台机器运行成本上电费和机器折旧每个月都是固定的人力成本更不可忽视模型部署、推理框架调优、显存管理、负载均衡、版本升级这些都需要人维护不是下载个权重就能甩手不管的。我见过不少团队为了省 API 费用自建结果工程师连续三周在调显存溢出和推理速度算下来人天成本早就超过 API 费用了。所以自建这件事要把时间线拉到一年算总拥有成本而不是只看单次调用差价。3. 第三件事有效上下文长度参数表上的数字要打折扣3.1 能塞进去和记得住是两回事模型标称支持 128K 上下文这个数字说的是输入序列最长能到 128K token意思是塞得进去。但塞得进去不等于它每个位置都记得住。我在实测中发现很多模型在处理长上下文时中间位置的信息质量明显下降这种行为在学术上叫位置偏差。类比一下一个人一次能读一百页资料但读到最后他很可能已经忘了第 40 页写了什么。大模型也是这样——注意力资源的分配并不均匀开头和结尾的内容更容易被记住中间的内容容易被忽略。3.2 大海捞针测试的局限网上流传的大海捞针测试做法是把一句关键信息藏在一大段无关文本中间然后问模型能不能找出来。它能测出一个模型的基础检索能力但它的局限也很明显这测的是找到这句话不是理解整段内容。你实际业务里不会有那么多捞针场景。更多时候是让模型分析一份长文档、总结一堆聊天记录、或者按照一份几十页的规范做判断这些任务要求在整段上下文中都保持理解不是定位一句话就能搞定的。所以大海捞针过了不代表长上下文能力就合格。3.3 长对话的遗忘和位置偏差多轮对话场景里还有另一个问题随着轮次增加早期轮次里的关键信息会被挤出注意力范围。即使所有内容都还在上下文窗口内模型回复时可能已经默认忘记了用户开场时提的需求。我测试时遇到过很典型的例子开场用户说我只想看 6 月之后的订单聊了十几轮之后模型已经开始推荐 3 月的订单了而且它没有意识到前后矛盾。这种问题在用户体感上非常糟糕而且很难通过简单的 prompt 约束解决。3.4 自己设计上下文压测量出有效长度我给团队的建议是别信宣传上的最大值自己压一遍。方法不复杂准备一份你业务里真实会出现的长文档比如操作手册、聊天记录、历史报告从中挑出十个散落在不同位置的关键细节然后分别用 8K、16K、32K、64K 的填充长度把文档撑大每个长度跑二十遍统计关键细节的回答准确率。填到某个长度后准确率明显掉到及格线以下那个位置就是有效上下文的边界。我最近一次给某个长文档分析场景做压测标称 128K 的模型在 32K 之后就开始漏细节最后我们按 32K 来规划系统设计给上层加了检索模块而不是把所有内容都硬塞给模型。4. 第四件事延迟、吞吐和并发上线前必须亲自压一遍4.1 平均延迟会骗人要盯 p95 和 p99模型本身的能力再强如果上线以后转圈圈用户一样会弃用。延迟指标里平均值是最会骗人的。p95 或者 p99 才是你真正需要关心的数字因为最慢的那批请求才是用户真实感受到的体验。同一个模型可能平均延迟 1.2 秒看起来不错但 p95 是 4 秒p99 直接到了 8 秒。这意味着 5% 的请求要等四秒以上1% 的请求要等八秒。对一个在线交互场景来说这个尾延迟完全是不可接受的。4.2 首 token 延迟和流式输出比总耗时更影响体感评估延迟时我会拆成两个阶段来看从请求发出到模型返回第一个 token 的时间首 token 延迟以及后续生成速度。为什么这么拆因为现在主流应用都做流式输出用户看到第一个字在动就会觉得系统在工作。有的模型总耗时差不多但首 token 特别慢用户盯着屏幕干等一两秒才看到字符出现体验极差。有的模型首 token 快后面生成速度慢用户能看到文字一行行冒出来虽然总耗时更长但体感反而更好。所以压测的时候这两个指标要分开记录。4.3 并发压测的做法和三根曲线单请求测出来的数据不能代表生产环境。同一个模型在只有一个请求时可能很快但 50 个请求同时进来就会出现排队、超时、甚至直接报错。我做并发压测的方法比较朴素根据业务预估高峰期 QPS准备一到两倍的压测量级用脚本同时发起请求记录三组数据延迟分布并发上升后p50、p95、p99 分别恶化到多少吞吐上限每秒能稳定处理多少请求超过这个数之后延迟曲线开始陡峭上升错误率高并发下请求失败的占比很多无状态 API 在过载时会选择直接拒绝这个压测一定要在真实网络环境里做不要在本地连测试环境模拟因为公网网关、限流策略、服务端排队统统都是变量。你测出来的结果直接决定了上线之后要不要加限流、要不要做超时重试、要不要买更大的并发配额。4.4 三种部署形态下的延迟差异同一个模型换一种部署形态延迟表现可能完全不同。公有 API 的好处是零运维但它在高峰期可能出现共享资源争抢托管式私有部署在延迟稳定性上好一些代价是费用更高完全自建则可以把延迟压到最低但要自己处理扩容和故障。我的建议是先明确你的延迟目标是秒级可用还是毫秒级可用。客服助手、知识库问答这类场景三秒内出结果基本没问题但如果是高频调用、嵌在用户操作链路里的功能比如输入联想、实时审核那 p95 必须控制在 1 秒以内这时就应该优先考虑私有部署形态。5. 第五件事工具调用和结构化输出的稳定性决定能不能长成系统5.1 函数调用质量是智能体架构的地基如果你的目标不只是聊天而是让模型去调用工具、操作业务系统那函数调用能力就是绕不开的一关。模型在什么情况下决定调用哪个函数、参数提取得准不准、会不会在不需要调工具时强行调用这些细节直接决定你的智能体流程能不能跑通。我拿真实场景测函数调用时会准备一组业务函数比如查库存、查订单、发通知然后构造一批需要调用工具才能回答的任务。重点看三类错误该调用的没调用导致答非所问参数从文本里提错比如把收货人当成下单人不需要调用时强行调用凭空造出一个工具结果。这三个错误只要有一个比例偏高这个模型做智能体应用就很难受。5.2 JSON 输出稳定性和 schema 遵循能力另一个容易被忽略的是结构化输出的稳定性。做系统集成时我们经常需要模型输出一段 JSON然后交给下游程序处理。如果模型输出的字段名时准时不准、偶尔夹带解释性文字、甚至把 JSON 写坏你的解析层就要花大量精力去兜底。我的测试方法是给模型一张明确的字段清单让它按给定 schema 输出连续跑 100 条统计三个指标合法 JSON 的比例、字段名和类型完全匹配的比例、完全无多余内容的比例。这三个比例如果低于 95%接进生产环境前就要三思。现在有些平台会提供约束解码能力能在语法层面保证输出是合法 JSON但它只能保证格式不能保证语义正确该做的校验一步都不能省。5.3 生态成熟度微调、部署和周边工具的配套单点能力再强配套跟不上也很难落地。我会重点看模型周边生态的成熟度能不能在主流推理加速框架里跑起来、有没有现成的量化方案来压缩显存、社区里有没有人踩过坑并留下解决方案、出问题的时候能不能快速找到资料。开源模型的好处是你可以自己调整比如做低秩微调来适配特定域或者用量化把大模型塞进更小的显存。商用闭源模型的好处是省心但如果你想做深度定制它就像一个黑盒你只能通过 prompt 去调。这两种模式没有绝对的好坏取决于你的团队有没有对应的人才和时间。5.4 版本迭代风险今天能用的能力明天还在吗大模型领域变化快选型时还得考虑版本迭代的稳定性。商用模型可能会调整定价、下线旧版本、或者悄悄改变某个接口的行为这些变化对你的生产系统可能是破坏性的。开源模型也可能因为社区转向、维护者停更导致你依赖的版本得不到安全修复。我选商用模型时会专门确认是否支持版本固定以及变更通知的周期选开源模型时会关注项目的活跃度和发布节奏。做技术的都知道技术选型一旦定下来迁移成本是很高的这方面的风险控制越早考虑越主动。6. 附赠一条红线安全合规和数据边界要提前查清楚6.1 数据流向输入、输出和日志去了哪里前面五件事都过关后还有一条红线是安全合规。很多人等到数据要出省、要过审的时候才想起来查那时已经晚了。选型阶段就应该搞清楚你发送给模型的文本会存储在哪里、存储多长时间、厂商会不会拿你的数据做模型训练、是否支持申请关闭数据留存。这些信息通常在服务条款和数据协议里写着要逐条核对。如果条款写得不清晰宁可请对方给个书面确认也不要稀里糊涂上线。我见过有团队因为没查清楚日志留存策略闭眼让数据在外部流转了几周后来合规审计时才发现问题整个项目被叫停返工。6.2 数据脱敏和权限控制就算厂商承诺数据不留存我仍然建议在上层加一道脱敏。凡是发给模型的文本先过一遍敏感信息识别把身份证号、手机号、地址、银行卡号这类直接替换成脱敏占位符返回结果里也要做一次反向审查防止模型把不该出现的原始敏感信息带回来。这不是不信任厂商而是把安全边界控制在自己手里。模型服务只是一个组件它永远不该成为你数据安全的信任根。权限控制同样重要谁有权限调用哪个模型、能不能传外部数据、调用配额是多少这些都应该纳入你现有的权限管理体系而不是单独放开一个口子。6.3 部署选项和合规清单最后给一张简单的核查清单可以直接拿去做选型时的一轮问答核查项要问的问题风险等级数据去向输入输出是否会被记录、存储多久高训练复用你的数据会不会被用于模型训练能否关闭高传输链路是否全程加密、是否走专线或私有通道中日志权限能不能主动查询、导出、删除日志记录中部署边界是否支持专属实例、私有网络或本地化部署高这张表逐项过完能帮你把合规风险从上线后爆发提前到选型时规避。数据边界这件事永远是越早确认成本越低。最后说一个我在真实项目里的体会。去年有个团队让我帮他们选一个做对话摘要的模型对方一开始笃定榜单第一准没错我坚持按这五件事过了一遍业务实测发现它在口语化聊天记录上漏要点成本核算发现他们的高并发场景会把预算烧穿长上下文压测在 16K 附近就开始丢细节。后来换了一个按照真实场景评测通过的方案上线后稳定性好得多。从那次以后我更加确定选大模型这件事没有标准答案只有适不适合你的业务、你的成本结构、你的数据边界。把这五件事逐条过完你听到的就不是别人的推荐而是自己拿真实数据得出来的结论。