模型选型避坑指南pdf

团队要定模型时，最容易出问题的不是选错一个名字，而是标准没对齐：有人看榜单，有人看演示效果，有人只问价格。等到上线才发现许可证不能商用、显存跑不动并发、换模型要重写一堆调用。这篇把选型前后该核对的环节按顺序列出来，每条都给出判断口径和去哪查当时的数据，方便你直接套成一份内部避坑文档。

团队定模型时翻车，通常不是名字选错，而是标准没对齐：有人看榜单，有人看演示效果，有人只关心单价。等上线才发现许可证不能商用、显存跑不动并发、换模型要重写一堆调用。真正该做的，是把选型前后要核对的环节按顺序列成清单。

这篇按八个环节拆，每条都给判断口径和去哪查当时的数据，你可以直接复制成一份内部文档。每个环节都写了「什么情况下不适用」，避免照搬别人的结论。全文不写具体数字，涉及价格、跑分、名次、版本的地方，一律给站内路径让你自己去核对当时的数值。

先冻结需求，再去看模型

选型最怕需求还在飘就先开榜单。先做一件事：把要模型干的活拆成三类——必须稳定交付的、可以容错的、只是试试水看效果的。只有前两类值得为选型花时间，第三类用顺手能跑的就够了。分类完之后，把硬约束白纸黑字写下来。

• 数据是否允许出内网：不允许的话，很多云端大模型直接出局，不用再比
• 语言要求：任务是否需要稳定的中文输出，是否需要中英混排
• 模态要求：只要文本，还是需要图片、语音、视频输入
• 输入长度：单次输入大概是几百字还是几万字，这直接决定候选范围
• 响应形态：要同步返回还是要异步批处理，是否接受排队延迟

榜单能看，但不能当结论

榜单测的是标准题目，你的任务往往在题目之外。正确用法是把榜单当筛选器，把自测当决策依据。做法是：先从榜单里挑出几个候选，再用自己业务的真实输入做小样测试，一般准备 50 到 100 条就够看出差异。

1. 固定评测口径提示词、温度、最大输出长度、是否开联网，全部固定成同一套，否则差异来自调用方式而不是模型本身。
2. 跑真实输入把线上抽样的真实请求脱敏后当测试集，别用自己编的漂亮例子，那只能证明你提示词写得好。
3. 人工盲评把几个模型的输出打乱顺序让人打分，避免看到模型名就自带偏见。
4. 记录放弃项写明哪个候选在哪类输入上明显不行，这比只写最终选了谁更有复用价值。

站内的榜单页和资料库可以帮你缩小范围，但要注意页面标注的样例规模、是否自评分、有没有可信度提示。这些页面的数字会变，以你查看当时为准。

许可证与合规先过一遍

许可证这块最容易被跳过，因为大家都默认开源就能随便用。实际上要分清几件事：权重能不能下载、下载了能不能商用、商用要不要署名、有没有调用量或用途限制。这四个问题分开问，答案经常不一样。

商用许可

是否允许把你的产品对外收费，很多权重是禁止或有限制的

署名要求

是否需要在使用处标注来源，这项常被漏掉导致后续返工

用途限制

是否禁止某些行业或场景，比如医疗、金融、自动化决策

再分发

你是否要把模型打包给客户，很多许可不允许这样做

数据不出内网的场景，要额外区分「权重可以下载」和「你可以合法部署」，两者不是一回事。拿不准就把待确认条件写进文档，让法务或负责人签字，别默认按开源处理。如果只是内部使用、不对外交付，这套流程可以简化，但仍要留一份书面记录。

按量、订阅、自建三种账分开算

成本不是比单价，而是比你的实际用量结构。同一个任务，用按量、订阅、自建三条路算出来的结果可能差很远，所以要分开建三个小表。重点是口径要对齐：按量看输入输出计费和上下文计费方式，订阅看额度上限和超限后的降速方式，自建看硬件、电、运维人力。

算的时候把重试、评测、内部试用这些额外调用量也算进去，很多人只算线上部分，最后账单和预估差一截。具体单价别凭记忆，到站内的成本计算工具和官方 API 页面用当时的数字套一遍。

• 按量：适合流量波动大、前期不确定的场景，先跑小流量再看曲线
• 订阅：适合用量稳定、能接受额度上限的团队，注意超限后的处理方式
• 自建：适合数据不出内网或用量极大且持续的团队，要把运维成本算进去
• 混合：核心走一条路，评测和兜底走另一条，这是很多小团队的实用解

显存、并发和延迟先做粗测

自建或本地部署的团队，显存是最常见的翻车点。常见错误是按「刚好能放下」选卡，结果一上并发就爆显存。正确做法是先按参数量乘量化档位估一个基础占用，再给上下文长度和并发留余量，一般不要贴着上限跑。

1. 估基础显存按模型参数量和量化档位估一个下限，这只是起点，不是结论。
2. 加上下文余量长输入比短输入更吃显存，按你真实的输入长度分布留余量，别只看平均值。
3. 压一轮并发在目标机器上用真实请求压测，观察并发上不去时是显存先满还是算力先到顶。
4. 记录临界点把「稳定支持多少并发」写成一张表，后面扩容和限流都靠它。

并发不是线性叠加的，长输入场景尤其明显。延迟也一样，别用单条请求的响应时间外推，要看你实际排队情况。站内的部署和算力规格页面能帮你按模型和卡型过一遍，再决定要不要换量化档位。

留回退路，避免被单一模型锁死

选型最大的隐性风险是锁死：接口调用散落在各处，模型名硬编码在很多文件里，一旦要换就得全局改。解决办法不复杂，在接口层做一层薄封装，把模型名、参数、提示词模板抽出来放配置里，换模型时只改配置不动业务代码。

同时至少准备一个降级方案。可以是同厂的低档模型、别家的同类模型，或者本地一个小模型兜底。降级不一定要效果一样好，能在主路挂掉时保证核心功能不中断就够。

把每个候选在你自己样例上的表现记成一张内部对照表，写清适用场景和不适用场景。这张表在人员交接和复盘时比任何文档都好用。

上线后怎么验证没选错

上线不是终点，而是验证的开始。选型对错要靠一段时间的运行数据说话，不是靠上线那天的感觉。建立一个小的回归样例集，每次换模型、升级版本或改提示词时都跑一遍，看输出有没有明显变化。

• 错误率：接口报错、格式错误的占比，先看趋势再看绝对值
• 超时比例：慢请求比例上升往往说明容量或模型变了
• 人工返工量：需要人重新处理的输出占比，这是最接近业务价值的指标
• 成本漂移：实际用量和重试量是否偏离预估

出现明显退化时，先查是模型变了、接口变了还是提示词被改了，按这个顺序排查，别急着整体推翻选型。很多所谓的选型问题，其实是某次改动引入的。要对比不同模型的运行时指标，可以到站内的测速工具看当时的延迟和稳定性表现。

把上面这些整理成一页选型文档

最后一步是把前面的核对结果落成一份固定结构的文档，让后来人能复核、能接手。结构不用花哨，六块就够：需求与硬约束、候选清单、评测结果、成本口径、风险与回退、结论与负责人。

1. 写需求与硬约束把冻结下来的那几项写清，特别是数据、语言、模态、长度四条。
2. 列候选与依据每个候选写为什么进候选、在哪看到的信息，注明站内路径方便核对当时的数字。
3. 附评测结果放自测样例的结果和人工盲评结论，写清评测口径。
4. 写成本口径注明按哪种方式算、包含哪些额外用量，数字来源指向站内页面。
5. 写风险与回退列出许可证待确认项、降级方案和切换步骤。
6. 写结论与负责人结论要有签字的人，未解决问题单独列一节，别混在正文里。

一份好的选型文档，大部分篇幅用来写「什么情况下这个结论不成立」，而不是写一堆肯定句。