模型选型
给智能体选基座模型是在性能、成本、速度、部署方式之间做权衡，而不是挑「最大最强」。
八个考量维度
| 维度 | 要看什么 |
|---|---|
| 性能与能力 | 不同模型擅长的任务不同——有的长于逻辑推理和代码生成，有的在创意写作或多语言翻译上更强。可参考公开基准榜（如 LMSys Chatbot Arena Leaderboard） |
| 成本 | 闭源模型算 API 调用费（按 Token 计费）；开源模型算本地部署的硬件（GPU、内存）与运维。结构细节见下 |
| 速度（延迟） | 要分 TTFT 和 TPOT 两个指标看，结构细节见下 |
| 上下文窗口 | 一次性可处理的 Token 上限。要理解长文档、分析代码库、维持长期对话记忆的智能体，需要大窗口（128K Token 或更高） |
| 部署方式 | API 最简单，但数据要发给第三方且受服务商条款约束；本地部署能保证数据隐私和自主可控，但对技术与硬件要求高 |
| 生态与工具链 | 主流模型的社区支持、教程、微调工具、兼容框架（LangChain、LlamaIndex、Hugging Face Transformers）更成熟，遇到问题更容易找到解法 |
| 可微调性与定制化 | 处理特定领域数据或任务时，微调能力关键。开源模型在这方面的调整余地更大 |
| 安全性与伦理 | 看模型在偏见、毒性、幻觉方面的表现，以及服务方在模型安全上的投入。面向公众或涉及敏感信息的应用不能忽略 |
维度之间存在硬冲突，不可能全占：
- 大窗口 + 高能力 → 高延迟、低成本不可兼得
- 本地部署换来自主可控 → 代价是放弃前沿模型的绝对能力
- 追求最大并发 → 显存被 KV Cache 吃掉，反过来限制了能选的窗口大小
最后那条是本地部署最容易算漏的一笔：「权重放得下」不等于「跑得起来」，要权重 + KV Cache 一起放得下才算。长上下文下 KV 能占掉总显存的 50%–80%。
成本不是一个数，是一张结构表
按 Token 计费听起来简单，但输入和输出、缓存命中和未命中，单价完全不同：
| 项 | 相对基准 |
|---|---|
| 输入 token | 基准 |
| 输出 token | 通常显著高于输入 |
| 写入缓存（5 分钟 TTL） | 1.25× |
| 写入缓存（1 小时 TTL） | 2× |
| 读取缓存 | 0.1× |
（价格结构详见 Context Engineering）
这张表对选型的直接含义：如果工作负载是长前缀 + 多轮（agent、代码助手、长文档问答），缓存能把输入成本压到 1/10——这时候**「支持 Prompt Cache」本身就是一个选型加分项**，两个能力相近的模型可能因为这一条差出一个量级的成本。
反过来，如果工作负载是一次性短请求（缓存永远用不上），那缓存能力就没有价值。
还有一条容易忽略的：工具定义会随每一轮重复发送。工具多到上百个时，单次预加载 5–7 万 token，并且每轮重发一次——这个固定开销在你的成本结构里可能比实际推理还大。
按 Token 计费听起来简单，但每一项的单价完全不同。
输入 token ██ 1×（基准）
输出 token ████████████ 通常显著高于输入
读取缓存 █▏ 0.1×
写入缓存（5 分钟 TTL） ███ 1.25×
写入缓存（1 小时 TTL） ████ 2×
对选型的直接含义，看工作负载的形状
长前缀 + 多轮（agent、代码助手、长文档问答）
└─ 缓存把输入成本压到 1/10 ──▶ 「支持 Prompt Cache」本身是选型加分项，
两个能力相近的模型可能因为这一条差出一个量级
一次性短请求
└─ 缓存永远用不上，这条能力没有价值
还有一笔容易被忽略的固定开销：工具定义随每一轮重复发送
工具多到上百个时，单次预加载 5–7 万 token，并且每轮重发一次
──▶ 这个固定开销在某类负载里可能比实际推理还大延迟要拆成两个指标
「模型快不快」是一个不完整的问题。推理分两个阶段，瓶颈完全不同（详见 KV Cache 与推理优化）：
| 指标 | 对应阶段 | 受什么影响 |
|---|---|---|
| TTFT（首 token 延迟） | Prefill | prompt 长度、算力；计算受限 |
| TPOT（每输出 token 延迟） | Decode | 显存带宽、并发数 |
两者的用户感知完全不同：
- 交互式对话 → TTFT 主导体感（用户等的是「它开始说话」）
- 长文生成 → TPOT 主导体感（一旦开始流式输出，用户在意的是流得顺不顺）
所以「哪个模型快」这个问题得先回答「我的场景在意 TTFT 还是 TPOT」。 一个 TTFT 很低但 TPOT 平庸的模型适合客服；反过来适合长文生成。
推理分两个阶段，瓶颈不同，用户感知也不同。
┌── Prefill ─────────────────┬── Decode ──────────────────────────┐
│ 一次算完整个 prompt │ 一个 token 接一个 token 地生成 │
│ 计算受限（算力） │ 显存带宽受限 │
│ 对应指标：TTFT │ 对应指标：TPOT │
│ 随 prompt 长度上升 │ 随并发数上升 │
└──────────────┬─────────────┴──────────────────┬────────────────┘
│ │
▼ ▼
交互式对话：TTFT 主导体感 长文生成：TPOT 主导体感
（用户等的是「它开始说话」） （用户在意的是流得顺不顺）
所以「哪个模型快」这个问题得先回答「我的场景在意哪一段」
TTFT 很低、TPOT 平庸 ──▶ 适合客服这类短问答
反过来 ──▶ 适合长文生成API 与本地部署的取舍
这是最容易含糊过去、实际最致命的一个维度：
| API | 本地部署 | |
|---|---|---|
| 上手 | 一个 key 就能跑 | 需要 GPU、环境、运维 |
| 数据 | 要发给第三方，受服务商条款约束 | 不出本机 |
| 能力上限 | 能用到当前最强模型 | 受显存与开源模型能力限制 |
| 成本结构 | 按 Token 线性增长，用多少付多少 | 前期硬件投入 + 固定运维 |
| 并发能力 | 由服务商承担 | 由你的显存决定（权重 + KV） |
| 可定制 | 基本只能靠提示与少量微调接口 | 可完整微调、量化、裁剪 |
用敏感数据、要离线运行、或要精细控成本时，本地部署是必选项而不是加分项。
但要把代价算全：本地部署的成本曲线是阶梯的（够用就一直够用），API 的成本曲线是线性的。所以判据是调用量——量小的时候 API 便宜得多，量大到一定程度本地方案才回本。「自建更省」这个结论只在足够高的调用量下成立。
两种部署方式的成本曲线形状不同，判据落在调用量上。
API 调用费 ──── 线性：用多少付多少
30 万次请求的账单就是 3 万次的 10 倍
本地部署 ──── 阶梯：一次性硬件投入 + 固定运维
GPU 买回来之后，1 万次和 10 万次请求的成本几乎一样
两者有一个交叉点，位置由调用量决定
低于交叉点 ──▶ API 便宜得多
高于交叉点 ──▶ 本地方案才回本
──▶ 「自建更省」这个结论只在足够高的调用量下成立
叠加在成本之上的两条硬约束（不进账本，但会直接否掉方案）
数据不能出域 / 要离线运行 ──▶ 本地部署是必选项，不参与成本比较
并发上限 ──▶ 权重 + KV Cache 一起放得下，才算「跑得起来」
长上下文下 KV 能占总显存的 50%–80%与前面几篇的判据衔接
选型时有三处容易被忽略的连锁关系：
一、能力涌现决定了能力下限（06-缩放法则）。复杂自主决策与规划这类能力只有跨过规模阈值才存在，小模型上再怎么调提示也补不出来——所以「先选够大的模型」是这类任务的前提，不是优化项。
但结合那条 Mirage 争议，判据要写准：可以用阈值做初步筛选（多步推理、规划在 10B–100B 量级开始可靠出现），最终要按自己的任务实测——因为「阈值」本身是度量相关的。
二、幻觉的缓解手段大部分在应用侧（07-模型幻觉）。如果架构上已经接了 RAG 和外部工具，选型时对「模型自身事实准确性」的依赖就可以降低，可以把权重更多给成本和延迟。
这是「架构换选型自由度」的一个具体例子：先决定要接什么护栏，再决定能容忍多弱的模型。
三、评测要用自己的任务分布（LLM Evaluation 与反馈闭环）。公开基准测的是代理任务，基准分与生产表现之间的差距通常很大。而且基准会污染、会老化——SWE-bench Verified 已于 2026 年 2 月被 OpenAI 弃用就是例子。
一条可操作的选型流程
把上面拆开的东西收成一个顺序：
1. 先定约束（数据能不能出去、要不要离线、调用量级）
│
▼
2. 写自己的 golden set：20–50 条真实问题 + 标注答案
│
▼
3. 用可以算出的确定性指标粗筛候选（工具调用精确匹配、schema 校验、代码执行）
│ └── 关键分水岭：能把一部分评测变成确定性检查，
│ 选型就快得多，也可靠得多
▼
4. 只对开放式质量部分上 LLM judge（并且先校准）
│
▼
5. 同时测成本与延迟，并把「每任务成本」「每任务工具调用数」一起报
│
▼
6. 按有意义的切片看结果，不要只看聚合分第三步是关键分水岭：能把一部分评测变成确定性检查，选型就快得多也可靠得多。
闭源与开源两条线
闭源模型提供开箱即用的 API，通常代表当前技术前沿；开源模型在透明度与自主性上更彻底，允许本地部署与定制微调。
模型清单迭代极快，具体版本和性能数据随时间失效，这里不列。 选型时按上面八个维度现场评估，比记住某个榜单更有用。
相关
- KV Cache 与推理优化 —— 本地部署的显存与并发约束
- 06-缩放法则 —— 能力下限，以及「阈值」该怎么用
- 07-模型幻觉 —— 幻觉缓解手段决定了你能容忍多弱的模型
- Context Engineering —— 成本结构里的缓存那一块
- LLM Evaluation 与反馈闭环 —— 用自己的任务分布评测
- 04-采样参数 —— 模型定了之后调怎么取词
- 05-文本分词与子词算法：BPE、WordPiece 与 Unigram —— 上下文窗口与 API 成本都按 Token 算，估算前要懂分词
参考
- 《Hello-Agents》第三章 §3.2.3、§3.2.4
- 见 Context Engineering 及其参考
- 见 KV Cache 与推理优化 及其参考
- 见 LLM Evaluation 与反馈闭环 及其参考
YJ