模型选型
跑分榜第一名每月都在换，但你的业务场景不会变。这一章把选型拆成一套能落地的方法：看清各家模型的真实差异，用决策树和打分表收敛候选，最后靠自己的 eval 集做裁决。
先泼一盆冷水：跑分会过时
打开任何一个模型榜单，你都能看到密密麻麻的分数：MMLU、HumanEval、GPQA、SWE-bench……每个新模型发布都自称"SOTA"。但如果你照着跑分选型，大概率会踩坑，原因有三个：
- 基准会饱和：MMLU 这类老榜单，头部模型普遍刷到 85+，分数差异已经小于评测噪声
- 基准会污染：公开榜单的题目很可能已经进了训练数据，高分不代表泛化能力
- 基准不代表你的场景：模型在 GSM8K 上拿 95 分，不意味着它能把你的客服工单分类做对
那 LMArena（原 Chatbot Arena）这种真人盲测投票榜呢？它比静态基准更接近真实体验，值得参考，但它衡量的是"普通用户在开放闲聊中的主观偏好"，和你的"结构化抽取准确率""代码补丁一次通过率"依然是两回事。
所以这一章的目标不是告诉你"哪个模型最强"——这个问题每个月答案都不一样——而是给你一套什么时候都适用的选型方法。先说结论：
记住这个漏斗，后面的内容都是围绕它展开。
闭源三巨头：性格与关键规格
闭源模型三巨头就像三个性格迥异的同事，没有全能选手，只有擅长领域。下面提到的上下文窗口、价格档位都是当前这一代的量级参考，以官方页面为准、随时会变——关注结构，别背数字。
GPT 系列（OpenAI） 生态最成熟、工具链最全的"六边形战士"。Function Calling、结构化输出（Structured Outputs）、多模态能力都是业界最早稳定的，文档、社区方案、第三方集成到处都是。产品梯队很清晰：旗舰档负责质量上限，mini 档负责日常主力，把"贵但强"和"便宜够用"都覆盖了。上下文窗口主流档位在 12.8 万 token 量级，部分新成员已上探到百万 token 量级。如果你的团队第一次接 LLM，GPT 是踩坑最少的起点。
Claude 系列（Anthropic） 长上下文处理和代码能力是招牌：写代码、改代码、读大型代码库这类任务上口碑极好，Claude Code 能在编程 Agent 领域成为标杆不是偶然。另外在"遵循复杂指令、不瞎发挥"这件事上一直很稳，适合对输出格式和边界要求严格的场景。产品线是 Haiku（轻量）/ Sonnet（甜点档，多数业务的性价比最优解）/ Opus（旗舰）三档，上下文 20 万 token 量级，部分型号提供百万 token 的 beta 档位。
Gemini 系列（Google） 超长上下文（百万 token 量级起步，是其主打卖点）和原生多模态是差异化优势。要往模型里塞整本书、几小时的视频、几百页的财报，Gemini 是最顺手的选择。背靠 Google 基建，大吞吐场景下的成本往往也有竞争力，Flash 档打的就是"快且便宜"。
一张速查表（再次提醒：数字以官方为准、会变动）：
| 模型族 | 上下文量级 | 价格档（相对） | 招牌场景 |
|---|---|---|---|
| GPT 系列 | 12.8 万 ~ 百万 token | 旗舰贵，mini 便宜 | 生态集成、通用全能 |
| Claude 系列 | 20 万（beta 百万） token | 中高，Haiku 便宜 | 代码、Agent、严格指令遵循 |
| Gemini 系列 | 百万 token 量级 | 相对便宜 | 超长文档、视频、多模态 |
注意，以上"性格"描述的是这一代模型的倾向，半年后可能完全洗牌。这也是为什么你需要的是方法而不是结论。
开源模型：规格、架构与许可证
过去两年开源模型进步飞快，在很多场景已经是第一选择而非"买不起闭源的平替"。先纠正一个用词：这些模型严格说叫开放权重（open weights）——你能下载权重自己跑，但训练数据和配方不一定公开，许可证也各有不同，和 OSI 定义的"开源软件"不是一回事。
DeepSeek 以极致的训练效率著称。DeepSeek-V3 的技术报告里有两个值得记住的工程亮点：
- MoE（混合专家）：总参数 671B，但每次推理只激活约 37B——像一家有几百个专家的公司，每个工单只转给相关的几个专家处理。用激活参数的算力，买到了总参数的容量
- MLA（多头潜在注意力）：把注意力计算中的 KV Cache 压缩成低秩的潜在向量，显存占用大幅下降——这直接关系到长上下文推理的成本
再加上训练只用了约 278.8 万 H800 GPU 小时（按当时租金折合约 558 万美元，远低于头部实验室的量级），DeepSeek 把"能力 vs 成本"的权衡整个往前推了一档。推理模型 R1 把思维链能力打成了白菜价，官方还蒸馏出一批基于 Qwen/Llama 底座的小尺寸推理模型，权重可商用。API 定价极其激进，自建方案（vLLM、SGLang）也非常成熟。
Qwen（阿里） 开源阵营里综合实力最全面的一族：从 0.5B 的端侧模型到数百 B 的旗舰，尺寸梯队完整；多语言能力尤其强，中文场景表现一流；绝大多数型号采用 Apache 2.0 许可证（商用友好、几乎无附加限制），衍生微调模型生态极其繁荣——开源社区大量的领域微调模型都以 Qwen 为底座。想做私有化部署，Qwen 通常是第一个要试的。
Llama（Meta） 开放权重阵营的"老大哥"，历史最久、生态最广——几乎所有推理框架、量化工具、微调库都优先适配 Llama。但要特别注意它的许可证：Llama Community License 不是常规开源协议，里面有几条真实影响商用的条款，最知名的是"月活跃用户超过 7 亿的公司需向 Meta 单独申请许可"（对绝大多数公司无影响，但体现了许可证里确实埋着限制），此外对"用 Llama 的输出改进其他模型"也有约束。接 Llama 之前，让法务扫一眼许可证是标准动作。
还有两个贯穿开源世界的概念，后面会反复用到：
- 量化（Quantization）：把权重从 FP16 压到 FP8/INT4，显存需求砍掉一半甚至四分之三，代价是轻微的质量损失。自建部署的必修课
- 蒸馏（Distillation）：用大模型的输出当教材训练小模型，让小模型在特定能力上逼近大模型。DeepSeek-R1 的蒸馏小模型、各家的 mini 档，本质都是这个思路
开源的真正价值不在"免费"，而在控制权：权重在你手里，你可以微调、量化、部署在自己的机器上，数据不出内网，也不用担心服务商某天涨价或下线模型。
能力 × 成本 × 延迟：把三角坐实
选型本质上是在三个轴上找最优解，这三个轴互相打架：
能力：模型回答正确、有用的程度。最直观的感受，但最难用单一数字衡量——它在代码任务和文案任务上的排名可能完全不同。
成本：按 token 计费，但有三个细节常被忽略：
- 输入输出分开算，输出 token 通常比输入贵 3~5 倍。一个"读 1000 字写 100 字"的摘要任务和一个"读 100 字写 2000 字"的创作任务，成本结构完全不同
- 提示词缓存（prompt caching）：系统提示词、 few-shot 示例这些重复前缀命中缓存后价格大幅下降，设计 prompt 时把不变的部分放前面
- 成本 = 单价 × 用量 × 重试率：便宜模型如果格式错误率高、需要重试，总账可能更贵
- 能异步就走批量：对延迟不敏感的任务（夜间数据标注、离线摘要），各家都提供 Batch 类接口，价格通常是实时调用的一半左右。这类任务走批量，等于什么都没做就打了五折
一个最小可用的成本估算函数：
def monthly_cost(price_in: float, price_out: float, # 每百万 token 价格
calls_per_day: int,
avg_in: int, avg_out: int,
retry_rate: float = 0.05) -> float:
"""估算月成本（元），把重试和输入/输出价差算进去"""
calls = calls_per_day * 30 * (1 + retry_rate)
return calls * (avg_in * price_in + avg_out * price_out) / 1_000_000
# 客服工单分类：每天 5 万单，输入约 300 token，输出约 20 token
print(monthly_cost(2, 8, 50_000, 300, 20)) # 输入便宜、输出贵的模型在这类任务上很划算
延迟：拆成两个指标看——首 token 时间（TTFT，用户按下回车到看到第一个字的等待）和解码速度（字往外蹦的快慢）。聊天产品对 TTFT 敏感（等 3 秒用户就烦了），批处理任务（夜间跑数据标注）则完全不在乎延迟、只看成本。调用 API 时还要留意供应商的 TPM/RPM 限额（每分钟 token 数/请求数），大促流量打满限额被限流，比模型贵更致命。
经验法则：
- 面向用户的实时交互：延迟第一，能力够用就行
- 离线批处理：成本第一，延迟随便
- 代码生成、医疗、金融这类出错代价高的场景：能力第一，前两者让步
还有一招叫模型路由：不用一个模型打天下，而是简单问题丢给小模型、难问题丢给大模型。路由可以简单到一条规则（"问题长度 < 50 字走 mini"），也可以用一个分类小模型判断难度。实践中 80% 的请求用小模型就能解决，成本直接砍一个数量级。举个具体例子：一个智能客服里，"查物流""改地址"这类高频简单意图走轻量模型，只有"投诉升级""复杂退款计算"才转给旗舰模型——用户感知不到差别，账单立刻感知得到。注意路由器本身也会判错，把错误分流的代价估进总账，别把路由当成零成本的免费午餐。
什么时候该微调
选定模型之后，下一个问题通常是："效果还差口气，要不要微调？"先别急着答，因为微调只是三种改造手段之一，而且往往是最后才该用的那个。三者的分工：
- 提示词（Prompt）改行为：告诉模型"你是谁、按什么格式答、什么不许做"。零数据门槛，改完立刻生效，成本几乎为零
- RAG 补知识：模型不知道的、会过时的、你私有的信息（产品文档、内部规章、今天的库存），走检索注入上下文。知识可以随时更新，改文档就行，不用重新训练
- 微调（Fine-tuning）改能力与风格：让模型把某种行为"长进骨子里"——稳定的输出格式、统一的语气风格、领域术语的正确使用，或者把大模型的能力压缩进小模型
一个简单的决策顺序：先写提示词，不够再加 RAG，最后才考虑微调。三者的门槛差着数量级：提示词是分钟级、零数据；RAG 需要一套检索基建（向量库、chunking 策略、召回评估）；微调（通常指 SFT，监督微调）需要几百到几千条高质量的"输入→理想输出"样本，数据质量直接决定成败——500 条精心标注的样本，胜过 5 万条爬虫洗出来的脏数据。成本上，API 厂商的托管微调按训练 token 收费、训练后按微调模型推理计费（通常比基础模型贵）；开源自建则可以自己跑，但GPU 时间和调参人力要算进去。
微调真正值回票价的场景有四个：
- 输出格式固化：要求严格 JSON、特定表结构，提示词写了三页还是会偶发翻车——微调能把格式可靠性推到接近 100%
- 风格一致性：品牌文案、客服口吻，靠提示词每次都要带一大段示例，微调后一个短提示词就能稳定复现
- 领域术语：医疗、法律、芯片行业的黑话，通用模型经常张冠李戴，用领域语料微调能显著纠正
- 小模型替代大模型降本：结合前面说的蒸馏思路——用大模型生成教材、微调小模型，让便宜的小模型在窄任务上达到大模型九成水准，推理成本砍掉一个数量级
最后是一个必须点名的常见误区：用微调给模型"灌知识"。"把公司 wiki 微调进去，模型就什么都懂了"——这是错觉。微调学到的是统计上的行为模式，不是可查询的数据库：灌进去的知识会随时间过时（改知识要重新训练），模型记不清的部分会理直气壮地幻觉，而且你无法追问它"这条答案是哪来的"。知识的归 RAG，行为的归微调，这条边界划错，后面全是坑。
工程上还有个小知识：如今绝大多数微调用的是 LoRA 这类参数高效方法——冻结原模型权重，只训练一小撮低秩的"补丁"矩阵，显存需求降一个数量级，训练完可以把补丁合并回底座或按需热插拔。除非你有特殊理由，别碰全量微调。
可操作的选型流程（加深版）
把开头的漏斗展开成四步。
第 1 步：写清楚场景 别写"我们要用 AI"，要写"我们要把客服工单从 12 个类目里自动分类，允许 5% 错误率，每天 5 万条，P95 延迟 2 秒内"。场景越具体，后面的评测越有针对性。
第 2 步：列出硬约束，走决策树 硬约束是一票否决项。按这个顺序问自己：
约束一摆，候选列表往往直接从几十个缩到三五个。
第 3 步：用打分表收敛到 2~3 个候选 挑代表时覆盖三种定位：一个闭源旗舰（质量上限）+ 一个闭源轻量或开源 API（性价比）+ 一个可私有化的开源模型（合规兜底）。然后用加权打分表把"拍脑袋"变成"算出来"：
| 维度 | 权重 | 候选 A（闭源旗舰） | 候选 B（轻量 API） | 候选 C（开源自建） |
|---|---|---|---|---|
| 实测准确率 | 40% | 9 | 7 | 8 |
| 单请求成本 | 25% | 4 | 9 | 7 |
| 延迟/限额 | 20% | 6 | 9 | 8 |
| 合规与可控性 | 15% | 5 | 5 | 10 |
权重按你的业务定：客服机器人可以把成本权重拉到 40%，代码助手则把准确率拉到 60%。表里的"实测准确率"一栏必须来自下一步的 eval，而不是跑分榜。
第 4 步：用自己的 eval 集实测 这是最关键也最被忽视的一步，展开讲方法论。
数据集构造：从真实业务数据里分层抽样 100~200 条——别只用"典型样本"，要刻意混入边界 case、脏数据、曾经出过错的历史 badcase（这些才是模型分层的试金石）。每条样本人工标注期望输出。样本要保密、定期更新，防止泄漏进训练数据后失效。
评分标准（rubric）：能程序化判定的（分类、JSON 格式、数值抽取）直接写断言；开放性输出用 LLM-as-Judge，但 rubric 必须有锚点，例如：
0 分：答非所问，或包含事实性错误
1 分：方向正确但遗漏关键信息 / 格式不符合要求
2 分：完整、正确、可直接交付
用 Judge 时注意两个坑：位置偏差（对比两个答案时，模型倾向偏爱排在前面的，解决方法是交换顺序各评一次取平均）和自我偏爱（尽量不用被测模型自家当裁判）。
统计显著性：这是最多人栽跟头的地方。100 条样本上，75% 和 79% 的准确率差异在统计上说明不了什么——粗略估算，100 个样本的 95% 置信区间宽达 ±9% 左右。两个模型差不到 5~10 个百分点时，要么加样本量，要么用配对 bootstrap（对同一批样本上两模型的逐条差异做重采样）判断差异是否稳定。别拿着 2% 的差距跟老板宣布"A 模型更好"。
工程化落地：把 eval 脚本接进 CI——每次换模型、改提示词、升级模型版本，都自动跑一遍 eval 集，分数掉了就报警。同时在线上留一个采样管道，定期把真实流量（脱敏后）回流到 eval 集里，防止数据漂移让 eval 集悄悄失效。eval 集不是一次性资产，是需要持续饲养的"看门狗"。
一个最小可用的 eval 脚本：
import json
from openai import OpenAI
client = OpenAI()
# 自己的 eval 集：真实业务样本 + 人工标注的期望答案
with open("eval_set.jsonl") as f:
cases = [json.loads(line) for line in f]
def run_eval(model: str) -> float:
scores = []
for case in cases:
resp = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": case["input"]}],
temperature=0,
)
output = resp.choices[0].message.content
# 简单场景可以直接比对；复杂场景换成 LLM-as-Judge 按 rubric 打分
scores.append(1.0 if case["expected"] in output else 0.0)
return sum(scores) / len(scores)
for model in ["gpt-5-mini", "claude-haiku", "deepseek-chat"]:
print(model, f"{run_eval(model):.1%}")
要点不在代码本身，而在于：eval 集必须来自你的真实数据，评判标准必须反映你的业务目标。公开跑分是别人的考试，这才是你自己的考试。
私有化部署与合规：一笔真实的成本账
有些场景，"选哪个模型"之前先有一个更硬的问题："能不能把数据发给第三方 API？"触发私有化部署的典型情况：
- 金融、医疗、政务等行业，监管明确要求数据不出域
- 处理的数据涉及商业机密（未公开财报、源代码、客户名单）
- 对服务可用性有硬性 SLA 要求，不能依赖外部 API 的稳定性
关于自建 vs API 的争论，正反两方都有道理：
正方（自建划算）：权重免费，量大之后单位成本远低于 API 按 token 计费；开源模型迭代快，半年内就能用上社区最新成果；数据完全可控，还能做深度微调，这是 API 给不了的。
反方（API 划算）：自建的隐性成本常被低估——GPU 采购或租赁只是首付，真实账单里还有：推理框架（vLLM / SGLang）的调优人力、量化（FP8/INT4 能把显存需求砍一半以上，但需要验证质量损失）、并发扩容与容灾、7×24 运维值班，以及一个最容易被忽略的项——GPU 利用率。业务量有波峰波谷，按峰值买的卡大部分时间在空转；而 API 是按用量付费，天然 100%"利用率"。
一个简单的算账方式：日均 token 量 × 一年的 API 费用 vs GPU 年化成本 + 运维人力 + 利用率折扣。量小的场景，私有化通常不划算；量大且合规刚性的场景，私有化反而是唯一解。还有个折中方案值得知道：云上专属部署（各大云厂商都提供开源模型的托管推理），数据逻辑隔离，省了自建机房，代价是比纯 API 贵、比自建便宜。
常见误区
- 拿跑分当选型结论：再强调一遍——榜单第一不等于你的场景第一。基准分数是筛选候选的起点，不是终点
- 只看单价不看用量：单价便宜 30%，但提示词更长或重试率更高，总账可能更贵。算总成本，别算单价
- 忽略限额（TPM/RPM）：压测时不打满生产流量，上线当天被限流才知道疼
- 一个模型打天下：没有路由意识，所有请求都走最贵最强的模型，账单会非常难看
- 锁死单一供应商：把模型调用抽象成一层接口（比如统一走 OpenAI 兼容协议），换模型只改一个参数。半年后你会感谢自己
- eval 集建完就不管了：业务在变、数据分布在漂移，eval 集也要定期补充新样本，否则它会和公开榜单一样失效
术语表
| 名词 | 定义 | 一句话直觉 | 常见混淆 |
|---|---|---|---|
| MoE（混合专家） | 模型内部拆成多个"专家"子网络，每次推理只激活其中一小部分 | 几百个专家的公司，工单只转给相关的几个 | 总参数大 ≠ 每次推理都贵，看的是激活参数 |
| RAG（检索增强生成） | 先从知识库检索相关文档，塞进上下文再让模型作答 | 开卷考试：书随便换，不用重背 | 和微调不是替代关系——知识归 RAG，行为归微调，划错边界两边都翻车 |
| MLA（多头潜在注意力） | DeepSeek 提出的注意力变体，把 KV Cache 压成低秩潜在向量 | 给注意力的"备忘录"做无损感压缩 | 不是量化，是架构层面的设计 |
| KV Cache | 推理时缓存历史 token 的注意力中间结果，避免重复计算 | 模型的"短期记忆草稿纸" | 它吃显存，是长上下文成本的主要来源，不是模型权重本身 |
| 量化（Quantization） | 把权重从高精度（FP16）压到低精度（FP8/INT4） | 高清图转标清，省空间、轻微糊 | 省的是显存和带宽，不等于让模型变笨很多——但要用 eval 验证损失 |
| 蒸馏（Distillation） | 用大模型的输出当教材训练小模型 | 名师出高徒，徒弟只学到一部分但很便宜 | 蒸馏版小模型 ≠ 大模型本身，能力只在特定维度逼近 |
| SFT（监督微调） | 用"输入→理想输出"样本对模型做继续训练，固化行为与风格 | 给通才模型上岗前培训班 | 微调改的是行为模式，不是可查询的知识库——灌知识请走 RAG |
| LoRA | 冻结原权重、只训练低秩"补丁"矩阵的参数高效微调方法 | 不重装系统，只打个可插拔的补丁 | 效果接近全量微调但成本天差地别；全量微调如今是少数派选择 |
| 开放权重（Open Weights） | 公开模型权重供下载自用，但训练细节和许可各有差异 | "给你编译好的程序，但不一定给源代码" | ≠ OSI 定义的开源；Llama 协议里藏着商用限制 |
| 上下文窗口 | 模型单次能看到的最大 token 数（输入+输出） | 模型的"工作记忆"容量 | 标称 100 万 ≠ 全长都好用，长上下文中段的信息容易被"忽略" |
| TTFT | Time To First Token，从发请求到收到第一个 token 的耗时 | 按下回车到开始蹦字的等待 | 只衡量"开头快"，总耗时还取决于解码速度和输出长度 |
| TPM / RPM | 供应商限流：每分钟 token 数 / 每分钟请求数 | 水管的粗细和龙头开关次数 | 不是模型能力指标，但会直接决定你线上会不会被限流 |
| LMArena | 基于真人盲测投票的模型对战榜（原 Chatbot Arena） | 模型的"全民好感度投票" | 衡量开放对话主观偏好，不代表你业务任务的准确率 |
| LLM-as-Judge | 用另一个大模型当裁判给输出打分 | 请一位不知疲倦的阅卷老师 | 有位置偏差和自我偏爱，rubric 没锚点就是让它自由发挥 |
| 模型路由 | 按请求难度/类型把流量分发给不同模型 | 分诊台：小病社区医院，大病三甲 | 路由本身判错的代价要算进总账，不是免费午餐 |
参考材料
- DeepSeek-V3 Technical Report — MoE + MLA 架构细节与训练成本账本，理解"能力 vs 成本"权衡的绝佳案例
- Qwen2.5 Technical Report — 开源阵营最全面模型族的技术报告
- The Llama 3 Herd of Models — Meta 的开放权重旗舰论文
- Llama Community License — 商用前必读的许可证原文，注意月活红线与输出使用限制
- LMArena — 真人盲测对战榜，比静态基准更接近真实体验
- Your AI Product Needs Evals — Hamel Husain 的经典博客，讲透为什么"自己的 eval 集"才是选型的终极依据
小结
模型选型没有标准答案，只有标准流程：从场景出发，用约束和打分表筛候选，靠自己的 eval 集做最终裁决。 跑分榜用来看候选、不用来做决定；开源模型是主力选项而不是备胎，但要看清许可证；能力、成本、延迟的权衡没有银弹，模型路由能帮你三头兼顾；自建 vs API 没有信仰之争，只有一笔要算全（含利用率和人力）的成本账。最后记住：模型半年一换代，你建的 eval 集和抽象好的调用层，才是真正不会过时的资产。