1. 从一条热词说起大模型“斩杀线”到底指什么“斩杀线”这个词最早来自游戏圈指的是把对手血量压到某个阈值以下一套连招就能直接带走的那条临界线。放到大模型语境里它被借用来形容一个很现实的东西某个模型在特定任务上能力刚好跨过“可用”与“不可用”之间的那道门槛。跨过去了它就能替代人工、能落地、能赚钱跨不过去它就是个玩具Demo 好看生产环境一用就露馅。最近圈子里讨论得很热的一个现象是原本被寄予厚望、被认为“马上就能跨过斩杀线”的一批国产大模型在实际业务场景里反而被“斩杀”了——不是被更强的模型打败而是被成本、延迟、稳定性、幻觉率、上下文长度、工具调用可靠性这些工程指标联合绞杀。标题里那句“中国大模型的斩杀线被斩杀了”说的其实就是这件事大家原本盯着的那条能力线可能根本就不是真正的生死线真正的斩杀线藏在工程细节里。我过去一年多陆续在几个实际项目里接过国产大模型的 API做过知识库问答、结构化信息抽取、代码辅助生成、多轮客服对话这几类典型任务。踩过的坑不算少也总结出一些不太出现在官方文档里的经验。这篇就围绕“斩杀线”这个概念把国产大模型落地时真正决定生死的几个维度拆开讲清楚包括怎么评估、怎么选型、怎么调参、怎么排查问题。不管你是刚准备接入大模型的开发者还是已经在生产环境里被折磨过一轮的老手应该都能从里面找到能直接抄作业的东西。需要先说明一点下面提到的所有模型、项目、公司都用代称具体数值是我在特定测试集和特定硬件条件下的实测结果换环境会有浮动重点看方法和思路不要死记数字。2. 斩杀线为什么会被“斩杀”三个被忽视的真相2.1 能力线不等于落地线很多人评估大模型的方式很直接拿一套公开榜单看谁分数高就用谁。这个思路在选型初期没问题但一旦进入真实业务就会发现榜单分数和实际体验之间隔着一条鸿沟。我做过一个对比实验用同一套 200 条真实客服对话记录分别喂给三个在公开榜单上排名靠前的国产模型让它们做意图识别和槽位抽取。榜单上 A 模型比 B 模型高 3 分但实际跑下来B 模型的端到端准确率反而高出 8 个百分点。原因很简单榜单考的是通用能力而我的业务里全是“退款”“改地址”“催发货”这类高度垂直的表达B 模型在训练数据里恰好覆盖了更多电商场景语料。这就是第一个真相斩杀线是场景相关的不存在一条通用的线。一个模型在代码生成上跨过了斩杀线不代表它在法律文书摘要上也能跨过去。评估必须用自己的数据、自己的任务、自己的评价标准。2.2 成本曲线比能力曲线更早触底第二个真相更扎心很多团队不是被模型能力卡住的是被账单卡住的。我算过一笔账。某模型 API 定价是每百万 token 输入 1 元、输出 2 元。听起来很便宜。但一个日活 5000 的客服系统平均每轮对话输入 800 token、输出 200 token一天 10 轮对话就是 5000 万 token 输入、1000 万 token 输出一天成本 70 元一个月 2100 元。这还只是单模型单轮如果加上意图分类、知识检索、结果校验的多模型串联成本直接翻三到五倍。更关键的是当业务量涨到日活 5 万的时候一个月就是 2 万多。这时候你会发现模型能力只要跨过“勉强可用”那条线剩下的竞争全是成本和延迟的竞争。很多国产模型在能力上已经够用了但在单位 token 成本和响应延迟上还没准备好打这种消耗战于是就被“斩杀”了。2.3 工程稳定性才是真正的生死线第三个真相是我踩过最深的坑模型能不能稳定输出符合格式要求的结果比它聪不聪明重要得多。我做过一个结构化抽取任务要求模型从商品评论里抽出“评分、问题类型、是否退货”三个字段输出 JSON。测试阶段用 50 条样本模型表现很好准确率 92%。上线后第一天就崩了有 3% 的请求返回的 JSON 缺字段有 2% 的请求在 JSON 外面包了一层“好的以下是抽取结果”还有 1% 的请求直接把 JSON 写成了 Python 字典格式单引号那种。这些在 Demo 里根本看不出来但在生产环境里就是灾难。下游解析程序一遇到格式错误就抛异常整个链路断掉。后来我加了重试机制、格式校验层、兜底规则才把可用性拉到 99.5% 以上。这个过程让我明白斩杀线不是模型能力的线是工程可靠性的线。一个模型再聪明如果输出格式不稳定它在生产环境里就是不可用的。3. 真正决定生死的五个工程指标3.1 首 token 延迟与端到端延迟延迟是用户体验的第一道斩杀线。我实测过几个国产模型在相同网络条件下的表现差异非常大。模型代称首 token 延迟ms端到端延迟200 token 输出ms备注模型 A3202800流式输出稳定模型 B5804200高峰期波动大模型 C2101900短输出优势明显模型 D4503500长输出时延迟增长快首 token 延迟决定用户“感觉快不快”端到端延迟决定用户“等得烦不烦”。我的经验是首 token 超过 800ms用户就会开始怀疑是不是卡了端到端超过 5 秒用户就会切走。这两个指标比准确率更早决定产品生死。优化延迟的手段有几个一是选流式输出让用户先看到内容二是控制输出长度能一句话说清就别写三段三是做请求预热把常用 prompt 的 KV cache 缓存起来四是就近部署减少网络跳数。这些手段我在后面实操部分会展开。3.2 输出格式稳定性前面提过格式稳定性是生产环境的硬门槛。我统计过某模型在 1000 次结构化抽取请求中的表现完全符合 JSON 格式94.2%JSON 外有多余文字3.1%字段缺失1.8%格式完全错误0.9%看起来 94.2% 很高但放到日请求 10 万的系统里就是每天 5800 次格式错误。每一次都可能导致下游任务失败。解决办法不是换模型而是加一层“格式护栏”用 JSON schema 校验、用正则提取、用重试机制兜底。我通常会在 prompt 里明确写“只输出 JSON不要任何解释”同时在代码层做二次校验双保险。3.3 上下文长度与有效利用率国产模型现在动辄宣称支持 128K 甚至 1M 上下文但宣称支持不等于有效利用。我做过一个“大海捞针”测试在 10 万字文档的不同位置插入一个关键事实然后提问。结果发现很多模型在 32K 以后就开始“遗忘”中间部分的内容关键事实放在文档 50% 位置时召回率从 95% 掉到 60% 以下。这意味着什么意味着你不能真的把 10 万字一股脑塞进去就指望模型能答对。实际做法是先做检索再做生成。用向量检索或关键词检索把最相关的 3 到 5 段找出来控制在 4K 到 8K token 以内效果反而比塞 100K 更好。上下文长度是上限不是目标。3.4 工具调用与函数调用的可靠性Agent 类应用最依赖的就是工具调用。我测过几个国产模型的 function calling 能力在简单场景单工具、参数少下表现都不错但一到复杂场景就分化明显。场景复杂度模型 A 成功率模型 B 成功率模型 C 成功率单工具单参数98%97%99%单工具多参数92%88%95%多工具选择85%76%90%多轮工具调用72%61%80%多轮工具调用是分水岭。很多模型在第一轮调用后拿到结果就不知道怎么继续了要么重复调用要么直接编造结果。我的经验是工具描述要写得极其明确参数类型和取值范围要写死并且给模型一个“思考-调用-观察-再思考”的固定流程。不要指望模型自己悟要把流程喂到它嘴边。3.5 幻觉率与拒答率幻觉是另一个隐形斩杀线。在知识库问答场景里模型如果不知道答案正确做法是说“我不知道”但很多模型会硬编一个看起来很像的答案。我统计过某模型在 500 条超出知识库范围的问题上的表现正确拒答68%编造答案24%答非所问8%24% 的编造率在客服、医疗、法律场景里是不可接受的。降低幻觉的手段包括在 prompt 里明确“如果知识库中没有相关信息请回答‘根据现有资料无法回答’”降低 temperature 到 0.1 以下加一层答案校验用另一个模型或规则判断答案是否在检索到的文档中有依据。4. 实操从零搭建一套斩杀线评估与优化流程4.1 第一步定义你自己的斩杀线不要用别人的榜单用自己的数据。具体做法是从真实业务日志里抽 200 到 500 条请求覆盖高频场景和边缘场景。为每条请求标注“理想输出”和“可接受输出”两个标准。定义三个核心指标准确率理想输出占比、可用率理想可接受占比、格式合规率。设定阈值比如准确率低于 70% 不可用70% 到 85% 勉强可用85% 以上可上线。这套标准做完你就有了一条属于自己的斩杀线。后面所有选型和调优都围绕这条线来。4.2 第二步多模型并行测试与成本核算我通常会用同一套测试集跑 3 到 5 个候选模型记录每个模型的准确率、延迟、成本。下面是我用过的一个对比表模板指标模型 A模型 B模型 C权重准确率86%82%89%40%首 token 延迟320ms580ms210ms20%端到端延迟2.8s4.2s1.9s15%每百万 token 成本1.2 元0.8 元2.0 元15%格式合规率94%91%97%10%加权得分84.379.686.1-加权得分只是参考实际决策还要看业务容忍度。比如客服场景对延迟极其敏感延迟权重就要调高批量离线处理场景对成本敏感成本权重就要调高。4.3 第三步Prompt 工程与参数调优Prompt 写得好能直接把准确率拉高 10 到 20 个百分点。我总结了一个“四段式” prompt 模板【角色】你是一个电商客服意图识别助手。 【任务】从用户输入中识别意图并抽取相关槽位。 【约束】只输出 JSON不要任何解释。JSON 格式如下{intent: ..., slots: {...}} 【示例】输入我想退一下昨天买的鞋子。输出{intent: 退款, slots: {商品: 鞋子, 时间: 昨天}}关键点角色要具体任务要单一约束要强硬示例要覆盖边缘情况。我试过把示例从 1 个增加到 5 个准确率从 78% 提到 91%。参数方面temperature 设 0.1 到 0.3 之间top_p 设 0.8 到 0.9max_tokens 根据任务设上限不要让它无限输出。这些参数看起来简单但组合起来对结果影响很大。4.4 第四步加护栏与兜底不管模型多好都要加护栏。我的标准配置是格式校验层用 JSON schema 或正则校验输出不合格就重试。重试机制最多重试 2 次每次调整 prompt 或降低 temperature。兜底规则重试仍失败走规则引擎或返回默认答案。监控告警记录格式错误率、超时率、拒答率超过阈值就告警。这套护栏加上去可用性从 94% 拉到 99.5% 以上代价是平均延迟增加 200ms 左右。这个 trade-off 在生产环境里是值得的。5. 常见问题与排查技巧实录5.1 模型突然变笨了怎么办这是最常见的问题。可能原因有三个一是模型服务端更新了版本行为变了二是你的 prompt 或参数被改动了三是输入数据分布变了。排查顺序先看监控确认是全局变差还是特定场景变差再回滚 prompt 和参数看是否恢复最后联系服务方确认是否有版本更新。我遇到过两次一次是服务方悄悄换了模型版本一次是我们自己改了一个示例导致模型理解偏了。5.2 输出格式偶尔出错怎么根治格式错误没法根治只能降低概率。我的做法是prompt 里写死格式要求加示例加校验层加重试。四层下来格式错误率能压到 0.1% 以下。如果还不行就换模型不要跟一个格式不稳定的模型死磕。5.3 成本超预算怎么优化三个方向一是换更便宜的模型能力够用就行二是压缩输入用检索代替全量塞入三是缓存常用结果相同或相似请求直接返回缓存。我做过一个缓存层命中率 30%成本直接降了三分之一。5.4 延迟波动大怎么排查先区分是网络问题还是模型问题。用同一个请求连续打 100 次看延迟分布。如果 P99 是 P50 的 5 倍以上说明服务端有排队或限流。解决办法错峰请求、加并发限制、做请求队列。如果延迟整体偏高就考虑换模型或就近部署。问题现象可能原因排查方法解决手段准确率突然下降模型版本更新对比新旧版本输出回滚或重新调 prompt格式错误率上升prompt 被改动检查 prompt 版本回滚 prompt延迟 P99 飙升服务端限流连续压测看分布错峰、加队列成本超预算输入过长统计 token 消耗加检索、加缓存幻觉率升高temperature 过高检查参数配置降低 temperature6. 我个人的几条实战心得第一条不要迷信榜单要迷信自己的测试集。榜单是别人的业务你的业务只有你自己清楚。花两天时间建一套自己的评估集比看十份榜单都有用。第二条先解决格式和延迟再解决准确率。格式不对准确率再高也没用延迟太高用户根本等不到答案。这两个是前置条件不是优化项。第三条成本要算全链路不要只算单次调用。检索、重试、校验、缓存每一个环节都有成本。我见过太多团队只算模型 API 费用上线后发现总成本是预估的三倍。第四条留好退路。不要把所有请求都押在一个模型上至少准备一个备用模型主模型出问题时能切换。切换逻辑要提前写好不要等出事了再临时改代码。第五条监控比调优重要。上线只是开始后面的持续监控才能保证系统稳定。我通常会监控五个指标请求量、成功率、格式错误率、P99 延迟、单位成本。任何一个指标异常都能第一时间发现。这套东西说起来不复杂但真正落地需要耐心。国产大模型这两年进步很快能力上跨过斩杀线只是时间问题但工程上的斩杀线需要每一个开发者自己去跨。跨过去了模型就是生产力跨不过去模型就只是个昂贵的玩具。 
长河君 · 2026/10/13 23:39:57 · 阅读 1.2k 国产大模型落地实战：工程指标才是真正的斩杀线
1. 从一条热词说起大模型“斩杀线”到底指什么“斩杀线”这个词最早来自游戏圈指的是把对手血量压到某个阈值以下一套连招就能直接带走的那条临界线。放到大模型语境里它被借用来形容一个很现实的东西某个模型在特定任务上能力刚好跨过“可用”与“不可用”之间的那道门槛。跨过去了它就能替代人工、能落地、能赚钱跨不过去它就是个玩具Demo 好看生产环境一用就露馅。最近圈子里讨论得很热的一个现象是原本被寄予厚望、被认为“马上就能跨过斩杀线”的一批国产大模型在实际业务场景里反而被“斩杀”了——不是被更强的模型打败而是被成本、延迟、稳定性、幻觉率、上下文长度、工具调用可靠性这些工程指标联合绞杀。标题里那句“中国大模型的斩杀线被斩杀了”说的其实就是这件事大家原本盯着的那条能力线可能根本就不是真正的生死线真正的斩杀线藏在工程细节里。我过去一年多陆续在几个实际项目里接过国产大模型的 API做过知识库问答、结构化信息抽取、代码辅助生成、多轮客服对话这几类典型任务。踩过的坑不算少也总结出一些不太出现在官方文档里的经验。这篇就围绕“斩杀线”这个概念把国产大模型落地时真正决定生死的几个维度拆开讲清楚包括怎么评估、怎么选型、怎么调参、怎么排查问题。不管你是刚准备接入大模型的开发者还是已经在生产环境里被折磨过一轮的老手应该都能从里面找到能直接抄作业的东西。需要先说明一点下面提到的所有模型、项目、公司都用代称具体数值是我在特定测试集和特定硬件条件下的实测结果换环境会有浮动重点看方法和思路不要死记数字。2. 斩杀线为什么会被“斩杀”三个被忽视的真相2.1 能力线不等于落地线很多人评估大模型的方式很直接拿一套公开榜单看谁分数高就用谁。这个思路在选型初期没问题但一旦进入真实业务就会发现榜单分数和实际体验之间隔着一条鸿沟。我做过一个对比实验用同一套 200 条真实客服对话记录分别喂给三个在公开榜单上排名靠前的国产模型让它们做意图识别和槽位抽取。榜单上 A 模型比 B 模型高 3 分但实际跑下来B 模型的端到端准确率反而高出 8 个百分点。原因很简单榜单考的是通用能力而我的业务里全是“退款”“改地址”“催发货”这类高度垂直的表达B 模型在训练数据里恰好覆盖了更多电商场景语料。这就是第一个真相斩杀线是场景相关的不存在一条通用的线。一个模型在代码生成上跨过了斩杀线不代表它在法律文书摘要上也能跨过去。评估必须用自己的数据、自己的任务、自己的评价标准。2.2 成本曲线比能力曲线更早触底第二个真相更扎心很多团队不是被模型能力卡住的是被账单卡住的。我算过一笔账。某模型 API 定价是每百万 token 输入 1 元、输出 2 元。听起来很便宜。但一个日活 5000 的客服系统平均每轮对话输入 800 token、输出 200 token一天 10 轮对话就是 5000 万 token 输入、1000 万 token 输出一天成本 70 元一个月 2100 元。这还只是单模型单轮如果加上意图分类、知识检索、结果校验的多模型串联成本直接翻三到五倍。更关键的是当业务量涨到日活 5 万的时候一个月就是 2 万多。这时候你会发现模型能力只要跨过“勉强可用”那条线剩下的竞争全是成本和延迟的竞争。很多国产模型在能力上已经够用了但在单位 token 成本和响应延迟上还没准备好打这种消耗战于是就被“斩杀”了。2.3 工程稳定性才是真正的生死线第三个真相是我踩过最深的坑模型能不能稳定输出符合格式要求的结果比它聪不聪明重要得多。我做过一个结构化抽取任务要求模型从商品评论里抽出“评分、问题类型、是否退货”三个字段输出 JSON。测试阶段用 50 条样本模型表现很好准确率 92%。上线后第一天就崩了有 3% 的请求返回的 JSON 缺字段有 2% 的请求在 JSON 外面包了一层“好的以下是抽取结果”还有 1% 的请求直接把 JSON 写成了 Python 字典格式单引号那种。这些在 Demo 里根本看不出来但在生产环境里就是灾难。下游解析程序一遇到格式错误就抛异常整个链路断掉。后来我加了重试机制、格式校验层、兜底规则才把可用性拉到 99.5% 以上。这个过程让我明白斩杀线不是模型能力的线是工程可靠性的线。一个模型再聪明如果输出格式不稳定它在生产环境里就是不可用的。3. 真正决定生死的五个工程指标3.1 首 token 延迟与端到端延迟延迟是用户体验的第一道斩杀线。我实测过几个国产模型在相同网络条件下的表现差异非常大。模型代称首 token 延迟ms端到端延迟200 token 输出ms备注模型 A3202800流式输出稳定模型 B5804200高峰期波动大模型 C2101900短输出优势明显模型 D4503500长输出时延迟增长快首 token 延迟决定用户“感觉快不快”端到端延迟决定用户“等得烦不烦”。我的经验是首 token 超过 800ms用户就会开始怀疑是不是卡了端到端超过 5 秒用户就会切走。这两个指标比准确率更早决定产品生死。优化延迟的手段有几个一是选流式输出让用户先看到内容二是控制输出长度能一句话说清就别写三段三是做请求预热把常用 prompt 的 KV cache 缓存起来四是就近部署减少网络跳数。这些手段我在后面实操部分会展开。3.2 输出格式稳定性前面提过格式稳定性是生产环境的硬门槛。我统计过某模型在 1000 次结构化抽取请求中的表现完全符合 JSON 格式94.2%JSON 外有多余文字3.1%字段缺失1.8%格式完全错误0.9%看起来 94.2% 很高但放到日请求 10 万的系统里就是每天 5800 次格式错误。每一次都可能导致下游任务失败。解决办法不是换模型而是加一层“格式护栏”用 JSON schema 校验、用正则提取、用重试机制兜底。我通常会在 prompt 里明确写“只输出 JSON不要任何解释”同时在代码层做二次校验双保险。3.3 上下文长度与有效利用率国产模型现在动辄宣称支持 128K 甚至 1M 上下文但宣称支持不等于有效利用。我做过一个“大海捞针”测试在 10 万字文档的不同位置插入一个关键事实然后提问。结果发现很多模型在 32K 以后就开始“遗忘”中间部分的内容关键事实放在文档 50% 位置时召回率从 95% 掉到 60% 以下。这意味着什么意味着你不能真的把 10 万字一股脑塞进去就指望模型能答对。实际做法是先做检索再做生成。用向量检索或关键词检索把最相关的 3 到 5 段找出来控制在 4K 到 8K token 以内效果反而比塞 100K 更好。上下文长度是上限不是目标。3.4 工具调用与函数调用的可靠性Agent 类应用最依赖的就是工具调用。我测过几个国产模型的 function calling 能力在简单场景单工具、参数少下表现都不错但一到复杂场景就分化明显。场景复杂度模型 A 成功率模型 B 成功率模型 C 成功率单工具单参数98%97%99%单工具多参数92%88%95%多工具选择85%76%90%多轮工具调用72%61%80%多轮工具调用是分水岭。很多模型在第一轮调用后拿到结果就不知道怎么继续了要么重复调用要么直接编造结果。我的经验是工具描述要写得极其明确参数类型和取值范围要写死并且给模型一个“思考-调用-观察-再思考”的固定流程。不要指望模型自己悟要把流程喂到它嘴边。3.5 幻觉率与拒答率幻觉是另一个隐形斩杀线。在知识库问答场景里模型如果不知道答案正确做法是说“我不知道”但很多模型会硬编一个看起来很像的答案。我统计过某模型在 500 条超出知识库范围的问题上的表现正确拒答68%编造答案24%答非所问8%24% 的编造率在客服、医疗、法律场景里是不可接受的。降低幻觉的手段包括在 prompt 里明确“如果知识库中没有相关信息请回答‘根据现有资料无法回答’”降低 temperature 到 0.1 以下加一层答案校验用另一个模型或规则判断答案是否在检索到的文档中有依据。4. 实操从零搭建一套斩杀线评估与优化流程4.1 第一步定义你自己的斩杀线不要用别人的榜单用自己的数据。具体做法是从真实业务日志里抽 200 到 500 条请求覆盖高频场景和边缘场景。为每条请求标注“理想输出”和“可接受输出”两个标准。定义三个核心指标准确率理想输出占比、可用率理想可接受占比、格式合规率。设定阈值比如准确率低于 70% 不可用70% 到 85% 勉强可用85% 以上可上线。这套标准做完你就有了一条属于自己的斩杀线。后面所有选型和调优都围绕这条线来。4.2 第二步多模型并行测试与成本核算我通常会用同一套测试集跑 3 到 5 个候选模型记录每个模型的准确率、延迟、成本。下面是我用过的一个对比表模板指标模型 A模型 B模型 C权重准确率86%82%89%40%首 token 延迟320ms580ms210ms20%端到端延迟2.8s4.2s1.9s15%每百万 token 成本1.2 元0.8 元2.0 元15%格式合规率94%91%97%10%加权得分84.379.686.1-加权得分只是参考实际决策还要看业务容忍度。比如客服场景对延迟极其敏感延迟权重就要调高批量离线处理场景对成本敏感成本权重就要调高。4.3 第三步Prompt 工程与参数调优Prompt 写得好能直接把准确率拉高 10 到 20 个百分点。我总结了一个“四段式” prompt 模板【角色】你是一个电商客服意图识别助手。 【任务】从用户输入中识别意图并抽取相关槽位。 【约束】只输出 JSON不要任何解释。JSON 格式如下{intent: ..., slots: {...}} 【示例】输入我想退一下昨天买的鞋子。输出{intent: 退款, slots: {商品: 鞋子, 时间: 昨天}}关键点角色要具体任务要单一约束要强硬示例要覆盖边缘情况。我试过把示例从 1 个增加到 5 个准确率从 78% 提到 91%。参数方面temperature 设 0.1 到 0.3 之间top_p 设 0.8 到 0.9max_tokens 根据任务设上限不要让它无限输出。这些参数看起来简单但组合起来对结果影响很大。4.4 第四步加护栏与兜底不管模型多好都要加护栏。我的标准配置是格式校验层用 JSON schema 或正则校验输出不合格就重试。重试机制最多重试 2 次每次调整 prompt 或降低 temperature。兜底规则重试仍失败走规则引擎或返回默认答案。监控告警记录格式错误率、超时率、拒答率超过阈值就告警。这套护栏加上去可用性从 94% 拉到 99.5% 以上代价是平均延迟增加 200ms 左右。这个 trade-off 在生产环境里是值得的。5. 常见问题与排查技巧实录5.1 模型突然变笨了怎么办这是最常见的问题。可能原因有三个一是模型服务端更新了版本行为变了二是你的 prompt 或参数被改动了三是输入数据分布变了。排查顺序先看监控确认是全局变差还是特定场景变差再回滚 prompt 和参数看是否恢复最后联系服务方确认是否有版本更新。我遇到过两次一次是服务方悄悄换了模型版本一次是我们自己改了一个示例导致模型理解偏了。5.2 输出格式偶尔出错怎么根治格式错误没法根治只能降低概率。我的做法是prompt 里写死格式要求加示例加校验层加重试。四层下来格式错误率能压到 0.1% 以下。如果还不行就换模型不要跟一个格式不稳定的模型死磕。5.3 成本超预算怎么优化三个方向一是换更便宜的模型能力够用就行二是压缩输入用检索代替全量塞入三是缓存常用结果相同或相似请求直接返回缓存。我做过一个缓存层命中率 30%成本直接降了三分之一。5.4 延迟波动大怎么排查先区分是网络问题还是模型问题。用同一个请求连续打 100 次看延迟分布。如果 P99 是 P50 的 5 倍以上说明服务端有排队或限流。解决办法错峰请求、加并发限制、做请求队列。如果延迟整体偏高就考虑换模型或就近部署。问题现象可能原因排查方法解决手段准确率突然下降模型版本更新对比新旧版本输出回滚或重新调 prompt格式错误率上升prompt 被改动检查 prompt 版本回滚 prompt延迟 P99 飙升服务端限流连续压测看分布错峰、加队列成本超预算输入过长统计 token 消耗加检索、加缓存幻觉率升高temperature 过高检查参数配置降低 temperature6. 我个人的几条实战心得第一条不要迷信榜单要迷信自己的测试集。榜单是别人的业务你的业务只有你自己清楚。花两天时间建一套自己的评估集比看十份榜单都有用。第二条先解决格式和延迟再解决准确率。格式不对准确率再高也没用延迟太高用户根本等不到答案。这两个是前置条件不是优化项。第三条成本要算全链路不要只算单次调用。检索、重试、校验、缓存每一个环节都有成本。我见过太多团队只算模型 API 费用上线后发现总成本是预估的三倍。第四条留好退路。不要把所有请求都押在一个模型上至少准备一个备用模型主模型出问题时能切换。切换逻辑要提前写好不要等出事了再临时改代码。第五条监控比调优重要。上线只是开始后面的持续监控才能保证系统稳定。我通常会监控五个指标请求量、成功率、格式错误率、P99 延迟、单位成本。任何一个指标异常都能第一时间发现。这套东西说起来不复杂但真正落地需要耐心。国产大模型这两年进步很快能力上跨过斩杀线只是时间问题但工程上的斩杀线需要每一个开发者自己去跨。跨过去了模型就是生产力跨不过去模型就只是个昂贵的玩具。