模型选型报告模板

做选型最怕的不是选错，是讲不清为什么选它——嘴上说得明白，落到文档就只剩几段跑分截图和一句「综合体验更好」，评审一追问成本、并发、许可证就卡壳。这篇给一份可以直接抄进文档的报告骨架：每一节该写什么、哪些数字要去站内哪一页现场取、什么情况下这套模板不适用。

做选型最怕的不是选错，是讲不清为什么选它。嘴上说得明白，落到文档就只剩几段跑分截图和一句「综合体验更好」，评审一追问成本、并发、许可证就卡壳。把报告写成一份能自查的清单，比把结论写得漂亮更有用。

下面这份骨架可以直接抄进你的技术文档：先定结论页再倒推正文，评测口径写成可复现的对照，成本按三种口径分开算，最后把许可证和回退方案钉死在文档里。每节都标了该去站内哪一页取当时的数字。什么情况下这套模板不适用，也会在对应小节说清楚。

报告骨架：先定结论页，再倒推正文

很多人写报告的毛病是从背景介绍开始铺，铺到第八页才说推荐谁。评审的耐心在前两页就用完了。正确做法是先写结论页，写不出来就说明你自己还没想清楚，此时应该回去砍需求，而不是继续凑对比表。

• 结论页只放三件事：推荐哪个方案、替代方案是什么、什么条件下这个结论会失效；这三句写完再动笔写后面，能省掉一半返工
• 正文按「需求边界 → 候选清单 → 评测口径 → 成本与容量 → 风险与回退」排，评审的阅读顺序和这个一致，别把成本塞在附录里
• 候选清单控制在三到五个；超过五个说明需求没收敛，先回去砍需求，而不是继续加对比表的行数
• 结论页要写清适用范围，比如「适用于内网部署、日调用量中等、对首字延迟敏感的问答场景」，写不出这句说明还没想清
• 每节末尾留一行「本节待确认项」，把没定的事显式挂出来，比藏在正文里被追问强

判断标准很简单：把报告给一个完全没参与选型的同事看，他能在一分钟内说出你推荐什么、为什么、什么情况下不推荐。说不出来就是骨架没搭好，跟内容深浅无关。

评测口径：把主观感受换成可复现的对照

公开榜单能帮你缩小候选范围，但代替不了内部评测。你业务里最高频的两三类输入，才是真正决定体验的东西。建议自建一小批真实任务样本当内部评测集，样本来源写进报告，方便评审判断代表性。

1. 建内部评测集从真实工单、日志或客服记录里抽一批任务，覆盖最高频的两三类输入，脱敏后固定下来。样本数量够跑出趋势就行，关键是要固定，后面每次换模型都用同一批。
2. 统一跑同一套样本每个候选跑完全相同的输入和参数，别给某个模型开小灶。记录成功、失败、勉强能用三档，不要只给一个平均分。
3. 贴原文片段失败样本要附上输入和输出的原文片段，这是评审最看的部分。只写「准确率偏低」没人能判断，贴出三条真实错例比一个分数有说服力。
4. 分两次测延迟一次在空闲时段测基线，一次在接近真实并发下测。空闲基线可以先用 接口测速（/tools/speed-test） 这类页面量出来，作为报告里的参照口径。

什么情况下这套口径不成立：样本量太小、任务类型单一、或者业务本身还在频繁变更需求，这时评测结论只能当参考不能当依据。报告里要老实写上这句，否则评审误以为结论很硬。

成本与容量：按量、按订阅、按卡三种口径别混着算

成本段最容易出错的地方是把不同计费口径堆在一张表里比大小。按量调用、按订阅、自建租卡是三种完全不同的成本结构，混着算必然得出错误结论。正确做法是分三块写，每块注明数据来源和取数口径，具体数字一律去站内页面取当时的数。

容量段别只写「支持高并发」。要把假设写出来：单卡能撑多少并发、显存算不算得下、要不要多机、峰值怎么扛。按 几张卡够用（/compute/sizing） 那套算法走一遍，把每个输入假设标在表里，评审才能复算。

按量调用和自建租卡不要只比单价，冷启动、限流、弹性扩缩的代价要折进同一张表。另外一定要写出成本随规模变化的拐点：调用量涨到什么量级，结论可能从租卡反转到按量，或者反过来。这个拐点比当前报价更有决策价值。

什么情况下这套成本口径不适用：业务量波动极大、或者未来半年内用量根本无法估，这时应该改用「按峰值预留 + 弹性补充」的写法，而不是硬套一套平均成本。

风险与回退：把许可证和迁移成本提前写进文档

风险和成本不一样，它不是估算题，是确认题。许可证、合规、数据出境这些事只有「已确认」和「没确认」两种状态，别写成「风险可控」这种模糊表述。逐条列状态，待确认项写明谁负责核实、什么时候给结论。

• 许可证单独一节：模型权重许可、商用边界、数据出境、是否需要备案，逐条标「已确认 / 待确认 / 不适用」
• 待确认项必须写责任人和核实方式，不能只写「后续跟进」
• 集成风险写清依赖了什么：接口协议是否兼容、有没有绑定特定平台、向量库和重排模型换掉要改多少代码
• 回退方案具体到动作：什么信号触发、退到哪个备选、切换影响多少用户、数据要不要重跑
• 接口或权重兼容性拿不准时，先做一次小规模验证再把结论写进报告

回退方案的写法有个实用技巧：把它写成「触发条件 → 动作 → 验证」三列。触发条件要可观测，比如错误率、延迟、成本偏离；动作要可执行，比如切回备选接口或降级到小模型；验证要能说明切换成功没有。模型换代后的验证与回退清单可以参照 部署测算（/models/deploy） 的测算口径。

什么情况下不需要写得这么重：如果只是内部试验、不涉及对外服务、随时可以下线，回退方案可以简化成一句「保留现有方案不动」。但只要涉及线上流量或对外承诺，这张表就必须完整。

选型报告的价值不在结论多漂亮，而在别人能照着你的假设复算出同样的结论。