06. 模型选择、成本与延迟

版本：v1.1
最后更新：2026-07-07
适用对象：需要为 LLM 应用、RAG、Agent、批处理、多模态和实时交互系统做模型选型、成本估算、延迟优化与模型路由的产品、研发、算法和架构同学

1. 为什么模型选择不是越强越好

很多团队刚做 AI 应用时，会下意识选择“最强模型”。

这在原型阶段没问题，因为它能降低调试复杂度。

但生产系统里，模型选择至少要同时平衡：

任务质量
单次成本
响应延迟
吞吐能力
上下文长度
结构化输出稳定性
工具调用稳定性
多模态能力
数据合规和部署区域
可用性、限流和供应商风险

OpenAI Model selection 官方文档在 2026-07-07 可访问的说明中，把模型选择概括为在 accuracy、latency、cost 之间做平衡。Anthropic 的模型选择文档也同样强调 capability、speed、cost 三个维度。

一句话理解：

模型选择不是找一个绝对最强模型，而是为每类任务找到最小足够、可评测、可回退、可持续付费的模型组合

2. 模型选择到底在选什么

你选的不是一个名字，而是一组工程能力。

维度	要问的问题
质量	对当前任务是否准确、稳定、少幻觉
推理	是否能处理多步推理、数学、代码、复杂判断
结构化输出	JSON / schema / function args 是否稳定
工具调用	是否能正确决定调用工具、填参数、处理失败
上下文	是否能容纳必要资料，长上下文质量是否稳定
多模态	是否需要图像、音频、视频、实时语音
延迟	P50、P95、首 token、总时长是否满足体验
成本	输入、输出、缓存、工具、批处理和重试成本
吞吐	RPM、TPM、并发、批任务队列能否撑住
合规	数据区域、日志、隐私、供应商政策是否满足
运维	是否有监控、回退、灰度、版本固定策略

模型选型文档应该描述这些能力，而不是只写“用某某大模型”。

3. 任务先分层，再选模型

不要按“产品”选模型，要按“任务节点”选模型。

一个知识库助手可能包含：

text

用户问题
 -> 意图分类
 -> 查询改写
 -> 检索
 -> rerank
 -> 答案生成
 -> 引用校验
 -> 风险审查
 -> 最终回复

这些节点不一定都要用同一个模型。

节点	常见模型策略
意图分类	小模型或规则优先
查询改写	小模型或中模型
rerank	专用 reranker 或中模型
答案生成	根据风险选中/大模型
引用校验	小模型 + 规则，或 judge 模型
风险审查	高召回优先，可用专用安全模型
最终润色	小模型即可，除非高风险

真正成熟的系统往往是模型组合，而不是单模型通吃。

4. 建立模型能力画像

模型选择应该沉淀成能力画像。

json

{
  "model": "example-large",
  "provider": "example-provider",
  "version": "2026-07",
  "context_window": "long",
  "modalities": ["text", "image"],
  "strengths": ["complex_reasoning", "code", "tool_calling"],
  "weaknesses": ["high_cost", "higher_latency"],
  "recommended_tasks": ["complex_qa", "code_review", "agent_planning"],
  "avoid_tasks": ["high_volume_simple_classification"],
  "eval": {
    "quality_score": 0.88,
    "json_valid_rate": 0.995,
    "tool_arg_valid_rate": 0.96,
    "hallucination_rate": 0.04
  },
  "runtime": {
    "p50_latency_ms": 1800,
    "p95_latency_ms": 5200,
    "avg_input_tokens": 2400,
    "avg_output_tokens": 650,
    "avg_cost_usd": 0.018
  }
}

画像的价值是：

给路由策略提供依据
给灰度和回退提供基线
给成本优化提供抓手
给模型升级提供对比标准

5. 选型前先定义任务 SLA

如果没有 SLA，模型选择就会变成主观争论。

建议先定义：

指标	示例
质量目标	答案正确率 >= 90%，引用支持率 >= 95%
延迟目标	P95 总响应 <= 5 秒
成本目标	单次平均成本 <= 0.02 美元
可用性目标	月可用性 >= 99.9%
安全目标	高风险误放率 <= 0.5%
结构化目标	JSON 解析成功率 >= 99.5%
工具目标	工具参数合法率 >= 98%

模型是否合适，要看它是否满足这些约束。

6. 成本由哪些部分组成

不要只看模型单价。

真实成本通常包括：

text

总成本 =
  输入 token 成本
  + 输出 token 成本
  + cached input 成本
  + reasoning / thinking token 成本
  + 工具调用成本
  + 检索 / 向量库 / rerank 成本
  + 图片 / 音频 / 视频成本
  + 批处理 / 优先级 / 区域处理成本
  + 重试成本
  + 日志、存储、评测和观测成本

OpenAI Pricing 页面在 2026-07-07 可访问的说明中按每百万 token 标注输入、cached input、输出等价格，同时还列出实时音频、图像、视频和 web search 等工具价格。

这说明：

成本不只是“文本模型单价”。
工具、多模态、优先级和数据区域也会改变账单。

7. 单次请求成本估算

7.1 基础公式

text

request_cost =
  input_tokens / 1_000_000 * input_price
  + cached_input_tokens / 1_000_000 * cached_input_price
  + output_tokens / 1_000_000 * output_price
  + tool_cost

如果模型或供应商有 thinking token、audio token、image token、regional uplift，也要单独加进去。

7.2 示例

假设：

输入 8,000 tokens
其中 5,000 tokens 命中缓存
输出 700 tokens
输入价 $2 / 1M
缓存输入价 $0.2 / 1M
输出价 $10 / 1M

text

成本 =
  3,000 / 1,000,000 * 2
  + 5,000 / 1,000,000 * 0.2
  + 700 / 1,000,000 * 10
= 0.006 + 0.001 + 0.007
= 0.014 美元

注意：

这个示例只是演示计算方式。
真实价格必须以上线当天官方 pricing 页面为准。

7.3 为什么输出 token 很重要

很多模型的输出 token 单价高于输入 token。

所以“让模型多解释一点”会明显抬高成本和延迟。

优化输出通常包括：

限制最大长度
让模型先给结论
只在需要时展开
用结构化字段替代大段解释
对内部链路使用短输出

8. 延迟由哪些部分组成

用户看到的延迟不是模型延迟本身。

text

总延迟 =
  客户端网络
  + 网关 / 鉴权
  + 排队等待
  + 输入预处理
  + 模型 prefill
  + 首 token 生成
  + 输出 token 生成
  + 工具调用
  + 后处理 / 审核 / 引用校验
  + 前端渲染

OpenAI Latency optimization 文档强调，延迟优化适用于从细粒度 workflow 到端到端聊天机器人的多类场景。生产系统要看整条链路，而不是只看模型响应。

8.1 首 token 延迟与总延迟

指标	含义	适合关注
TTFT	time to first token，首 token 时间	聊天、实时交互
Total latency	完整响应结束时间	结构化任务、报告生成
P95 / P99	高分位延迟	SLA、告警
Tokens/sec	输出速度	长文本生成
Tool latency	工具调用耗时	Agent、RAG、业务查询

实时产品更看 TTFT 和打断体验。

批处理更看吞吐和总完成时间。

8.2 延迟常见瓶颈

瓶颈	解决方向
输入过长	压缩上下文、检索替代全量拼接
输出过长	限制长度、先摘要后展开
模型太慢	换更快模型、分层路由
工具太慢	并行调用、缓存、预取、超时降级
多轮调用太多	合并节点、减少 reviewer、限制 loop
队列等待	提升限额、优先级处理、削峰填谷
前端体验差	流式输出、骨架屏、分阶段结果

9. Token 不是字符，必须精确计算

OpenAI Token Counting 文档在 2026-07-07 可访问的说明中提到，token counting 可以在发送请求前估算输入 token，用于优化 prompt、估算成本、按大小路由请求，并避免图片和文件等输入的字符估算误差。

这对模型选择很关键。

不要用：

text

字符数 / 4

作为生产级成本估算。

应该记录：

input_tokens
cached_input_tokens
output_tokens
reasoning_tokens
image_tokens
audio_tokens
tool_schema_tokens
system_prompt_tokens
retrieved_context_tokens

9.1 为什么工具 schema 也会烧 token

工具定义、JSON Schema、few-shot 示例、系统规则，都会进入模型输入。

Agent 项目里，工具很多时，工具说明本身可能成为大头。

优化方式：

工具按需加载
tool search / lazy loading
合并重复 schema
精简工具描述
不把无关工具暴露给当前节点

10. Prompt caching 是重要成本杠杆

OpenAI Prompt Caching 文档在 2026-07-07 可访问的说明中提到，prompt caching 可降低延迟和输入 token 成本，并且对近期模型自动启用。文档也说明，缓存命中依赖相同前缀，因此静态内容应放在 prompt 前部，动态变量放在后部。

Anthropic Rate Limits 文档也强调，prompt caching 可以让重复内容如系统指令、大上下文文档、工具定义、对话历史获得更高有效吞吐。

10.1 什么适合缓存

适合：

稳定系统提示词
长工具定义
大段固定背景资料
固定 few-shot 示例
固定政策说明
长上下文文档

不适合：

每次都变化的用户输入
当前时间、随机 ID、临时字段
会话里频繁变动的状态

10.2 如何提升缓存命中

建议：

text

稳定系统规则
 -> 稳定工具定义
 -> 稳定示例
 -> 稳定背景资料
 -> 动态用户输入
 -> 动态检索片段

不要把时间戳、用户 ID、随机数放在 prompt 前缀里。

10.3 缓存不是万能

注意：

缓存不减少输出 token 成本。
缓存不替代上下文压缩。
缓存命中依赖请求形态稳定。
缓存策略可能受数据保留、区域和供应商政策影响。

11. 批处理、Flex、Priority 和实时链路

不同工作负载需要不同消费模式。

模式	适合场景	取舍
标准实时请求	普通在线交互	简单直接
streaming	聊天、长回复、实时反馈	改善体感，但不一定缩短总时长
batch	离线批量、日报、离线标注	成本更低，但不适合实时
flex / spot 类模式	可延迟任务	成本低，延迟和可用性不稳定
priority	高 SLA 任务	成本高，延迟更稳
realtime	语音、低延迟交互	成本和并发治理更复杂

选型时不要只问模型本身，也要问请求模式。

12. 限流和吞吐是选型的一部分

模型再便宜，如果限流扛不住，也不能用于生产高峰。

OpenAI Rate Limits 文档说明，限流会按 RPM、RPD、TPM、TPD、IPM、音频分钟等指标约束，并且可能按模型、组织、项目和共享模型族生效。

Anthropic Rate Limits 文档也说明，不同模型分别有速率限制，同时缓存可以帮助提升有效吞吐。

12.1 需要关注的限流指标

指标	含义
RPM	每分钟请求数
TPM	每分钟 token 数
RPD	每日请求数
TPD	每日 token 数
并发	同时运行请求数
Batch queue	批处理队列 token 或任务上限
Audio minutes	音频模型分钟数限制

12.2 限流对架构的影响

如果触碰限流，需要考虑：

请求排队
用户级配额
租户级配额
高低优先级队列
批处理转离线
多模型分流
多区域或多供应商容灾
降级到小模型

限流不是上线后才处理的问题。

它应该进入选型表。

13. 不同任务的模型选型建议

13.1 分类与路由

关注：

稳定性
低成本
低延迟
枚举输出合法率

推荐：

小模型优先
强 schema
少输出 token
用评测集验证边界

不建议：

一上来用最大模型
让模型输出长解释
类别边界不清就换模型

13.2 信息抽取

关注：

字段完整性
JSON 合法率
缺失字段处理
证据保留

推荐：

结构化输出
后端 schema 校验
对复杂长文先切片再抽取
对高风险字段人工复核

13.3 RAG 问答

关注：

答案 groundedness
引用准确率
上下文处理能力
拒答能力

推荐：

检索和 rerank 先做好
答案生成用中/大模型
引用校验可用小模型或规则
高风险问题升级更强模型或人工

13.4 代码任务

关注：

代码理解
多文件上下文
工具调用
测试修复能力

推荐：

复杂代码修改用代码能力强的模型
简单格式化、解释、分类可用小模型
必须结合测试和静态检查

13.5 Agent 规划

关注：

任务分解
工具选择
停止条件
失败恢复

推荐：

planner 可以用更强模型
executor 节点按任务选模型
reviewer 不一定要最大模型，但要稳定
给 loop 设置成本和步数上限

13.6 实时语音

关注：

TTFT
音频延迟
打断体验
VAD
工具调用期间的等待体验

推荐：

使用 realtime / audio 专用模型
能异步的工具异步
给用户即时反馈
控制长上下文和长回复

14. 模型路由：生产系统的常态

模型路由就是根据请求特征选择模型。

text

请求
 -> 任务识别
 -> 风险判断
 -> 成本和延迟约束
 -> 模型选择
 -> 回退策略

14.1 常见路由维度

维度	示例
任务类型	分类、问答、代码、语音、图片
难度	简单、中等、复杂
风险	普通、高风险、需要人工
上下文长度	短上下文、长上下文
用户等级	免费、付费、企业
SLA	普通、优先、后台
成本预算	低成本、质量优先
工具需求	无工具、只读工具、写入工具

14.2 简单路由规则示例

json

{
  "rules": [
    {
      "if": "task_type in ['classification', 'simple_extract'] and risk == 'low'",
      "model": "small-fast"
    },
    {
      "if": "task_type == 'rag_answer' and evidence_score >= 0.8",
      "model": "medium"
    },
    {
      "if": "risk == 'high' or complexity == 'high'",
      "model": "large-reasoning"
    },
    {
      "if": "latency_sla_ms < 1500",
      "model": "fast-mini"
    }
  ],
  "fallback": "medium"
}

14.3 路由评测指标

指标	含义
route_accuracy	是否选到正确模型
unnecessary_large_model_rate	过度使用大模型比例
escalation_success_rate	小模型失败后升级是否成功
cost_saved	相比全量大模型节省多少
quality_delta	路由后质量损失多少
latency_delta	路由后延迟变化

不要只看省钱。

如果路由让高风险任务质量下降，就不合格。

15. 模型回退和降级

生产系统必须设计回退。

触发条件：

模型不可用
供应商故障
超时
限流
成本超过阈值
输出格式不合法
安全审查失败
质量评测低于阈值

15.1 回退类型

类型	示例
同供应商小模型	大模型超时降级到 mini
同供应商强模型	小模型低置信升级到强模型
跨供应商	OpenAI 不可用时切到 Anthropic / Gemini
离线处理	实时失败转后台任务
人工介入	高风险任务转人工
拒答	证据不足或安全风险过高

15.2 回退后要记录什么

原模型
回退模型
回退原因
质量是否下降
成本是否变化
延迟是否超 SLA
用户是否感知

16. 评测：不要凭感觉选模型

OpenAI Evaluation best practices 文档明确反对 vibe-based evals，也强调 eval 流程应包含目标、数据集、指标、运行比较和持续评估。

模型选择至少要有一个小型评测集。

16.1 评测集结构

json

{
  "id": "case-001",
  "task_type": "rag_answer",
  "input": "企业版开票后还能退款吗？",
  "expected_behavior": "必须基于政策回答，不足时拒答",
  "must_have": ["人工审批"],
  "must_not_have": ["直接承诺退款"],
  "risk": "medium",
  "tags": ["refund", "policy", "rag"]
}

16.2 评测维度

维度	检查内容
任务质量	正确率、召回率、人工评分
忠实性	是否基于证据
结构化	JSON 合法率、字段完整率
工具调用	调用正确率、参数合法率
安全	越权、注入、敏感信息
延迟	P50、P95、P99
成本	平均成本、P95 成本
稳定性	多次运行波动

16.3 模型对比表

模型	质量	P95 延迟	平均成本	JSON 合法率	工具参数合法率	结论
small-fast	82%	900ms	$	99.2%	94%	适合简单节点
medium	89%	1800ms	$$	99.5%	96%	默认模型
large-reasoning	94%	5200ms	$$$$	99.4%	97%	高风险/复杂任务

不要只按平均值选。

上线更关心：

P95/P99
长尾失败
高风险样例
成本峰值

17. 线上监控指标

上线后要记录：

json

{
  "request_id": "req_001",
  "task_type": "rag_answer",
  "route": "medium",
  "model": "example-medium",
  "input_tokens": 3200,
  "cached_input_tokens": 1800,
  "output_tokens": 420,
  "reasoning_tokens": 0,
  "tool_calls": 2,
  "ttft_ms": 620,
  "total_latency_ms": 3100,
  "estimated_cost_usd": 0.012,
  "fallback_used": false,
  "quality_signal": "thumbs_up"
}

17.1 必看指标

指标	用途
cost_per_request	单请求成本
cost_per_task_type	哪类任务最贵
cost_per_success	完成一次成功任务的成本
input_tokens / output_tokens	成本结构
cache_hit_rate	缓存是否有效
P50/P95/P99 latency	体验和 SLA
timeout_rate	延迟失控
retry_rate	隐性成本
large_model_ratio	大模型使用比例
fallback_rate	稳定性
quality_by_model	各模型质量

17.2 告警建议

触发告警：

单小时成本超过基线 2 倍
P95 延迟连续 15 分钟超阈值
大模型路由比例异常升高
缓存命中率突然下降
输出 token 均值异常上升
retry_rate 或 timeout_rate 上升
高风险任务被路由到低能力模型

18. 常见优化杠杆

18.1 减少输入 token

压缩系统提示词
删除重复规则
减少 few-shot
只放相关工具
RAG 只放高分证据
历史会话摘要化
图片裁剪和降采样

18.2 减少输出 token

先短答，再按需展开
设置最大输出长度
结构化输出
内部链路不写解释
报告类任务分段生成

18.3 减少请求次数

合并可合并步骤
用规则替代简单模型调用
分类器路由减少大模型调用
减少无效 reviewer
限制 Agent loop

18.4 提升缓存

固定 prompt 前缀
稳定工具定义顺序
静态内容前置
动态内容后置
监控 cache_hit_rate

18.5 分层路由

简单任务小模型
默认任务中模型
高风险复杂任务大模型
失败再升级

19. 场景案例

19.1 客服分诊

需求：

高频
低延迟
成本敏感
类别固定

选型：

小模型 + schema
高风险投诉升级中模型
无法判断转人工

指标：

分类准确率
高风险召回率
平均成本
P95 延迟

19.2 企业知识库问答

需求：

正确引用
能拒答
上下文较长

选型：

查询改写小模型
检索 + rerank
答案生成中模型
高风险制度/财务问题升级大模型或人工

指标：

引用支持率
context recall
unsupported claim rate
单次 token 成本

19.3 代码审查

需求：

多文件上下文
bug 发现能力
低误报

选型：

复杂 PR 用代码能力强模型
简单 diff summary 用中小模型
结合测试和静态检查

指标：

bug recall
false positive rate
review latency
developer accepted rate

19.4 实时语音客服

需求：

首 token / 首音频低延迟
可打断
可调用工具

选型：

realtime / audio 模型
工具查询异步化
长任务转文本或人工

指标：

首音频延迟
打断成功率
平均通话成本
工具等待时间

20. 供应商和模型版本治理

20.1 固定版本，不要盲目 latest

Google Gemini Models 文档区分 Stable、Preview、Latest、Experimental，并说明 production app 通常应使用 specific stable model；latest alias 会随新版本热切换。

这个原则很重要：

生产系统应尽量固定模型版本。
预览模型要标注风险。
latest alias 更适合实验，不适合关键链路。

20.2 供应商风险

需要考虑：

服务可用性
限流政策
价格变化
数据区域
合规条款
模型退役
输出风格变化
工具调用行为变化

20.3 模型升级流程

建议：

固定旧模型 baseline。
用同一评测集跑新模型。
比较质量、成本、延迟、安全。
影子流量验证。
小流量灰度。
保留回退。
更新模型画像和路由规则。

21. 一个可执行的选型流程

21.1 第一步：任务分解

列出所有模型节点。

text

router
query_rewrite
answer_generation
citation_check
summary
reviewer

21.2 第二步：定义每个节点 SLA

包括：

质量阈值
延迟阈值
成本阈值
结构化输出要求
安全要求

21.3 第三步：选候选模型

每个节点至少比较：

低成本模型
默认模型
高质量模型

21.4 第四步：跑离线评测

评估：

质量
延迟
成本
稳定性
安全

21.5 第五步：设计路由和回退

不要只选一个赢家。

要设计：

默认模型
升级模型
降级模型
超时策略
限流策略
人工兜底

21.6 第六步：上线监控

上线后持续看：

质量
成本
延迟
路由分布
回退原因
供应商状态

22. 常见误区

22.1 只看排行榜

排行榜不等于你的业务场景。

同一个模型在摘要、代码、RAG、工具调用、结构化输出上的表现可能完全不同。

22.2 只看平均成本

平均成本掩盖长尾。

更应该看：

P95 成本
高风险任务成本
失败重试成本
工具循环成本

22.3 只看平均延迟

用户投诉通常来自 P95/P99。

必须看长尾延迟。

22.4 把长上下文当万能解法

长上下文能容纳更多资料，但不保证模型能稳定使用所有资料。

长上下文还会增加成本、延迟和噪声。

22.5 不做版本固定

生产系统盲目使用 latest，可能因为模型热切换导致行为变化。

22.6 不记录路由原因

如果不知道为什么选了某个模型，就很难复盘质量和成本问题。

23. 推荐搭配阅读

24. 落地检查清单

是否按任务节点选模型，而不是全系统只选一个模型？
是否定义质量、成本、延迟、结构化输出和安全 SLA？
是否有模型能力画像？
是否用真实样例评测，而不是凭感觉选型？
是否记录 input_tokens、cached_input_tokens、output_tokens、tool_calls？
是否计算 P50、P95、P99 延迟？
是否按任务类型统计成本？
是否设计模型路由和回退？
是否监控大模型使用比例？
是否固定生产模型版本？
是否有模型升级灰度流程？
是否针对限流设计队列、降级或批处理？
是否验证 prompt caching 是否命中？
是否把工具调用和多模态成本算进总成本？

25. 推荐资源

以下资源在 2026-07-07 检查时可访问。价格和模型列表变化很快，生产上线前必须重新检查官方页面。

26. 2026 年模型选型补充：别只选模型名，还要选处理模式

到 2026 年，很多团队已经不是“不会选模型”，而是“只会选模型名，不会选处理模式”。真正影响成本和体验的，往往还有下面这些维度：

26.1 同一个模型，不同处理模式的成本和体验可能完全不同

一个任务可以是：

同步请求
流式输出
background mode
batch
flex processing
priority processing
realtime 语音链路

这些模式会直接影响：

用户等待时间
是否占用前台 SLA
是否能接受排队和延迟
单位成本是否下降
是否适合评测、离线处理或高价值在线流量

所以生产里真正要记录的不是只有 model_name，还要记录 processing_mode。

26.2 Prompt caching 已经不是“可选优化”，而是选型输入

如果系统 prompt、工具定义、固定背景资料和 few-shot 很长，那么你最终要比的就不只是模型单价，还要比：

cached_input_tokens 占比
prompt_cache_key 设计是否稳定
动态内容是不是被错误地放到了前缀里
缓存命中率下降时，成本和延迟会不会突然抬升

在这类系统里，“更便宜的模型”未必比“缓存命中率更高的调用方式”更省钱。

26.3 任务级成本要和成功率绑定，不能只看 request 级均值

真正该看的往往是：

cost_per_success
cost_per_resolved_case
cost_per_approved_action
p95_cost_per_task_type

如果一个模型便宜，但需要更多重试、更多人工接管、更多升级路由，它在任务级口径上可能反而更贵。

26.4 版本固定和升级评测要进入默认流程

模型迭代很快，所以上线时要优先固定具体版本，而不是长期依赖 latest 语义。更稳的做法是：

固定当前生产版本。
用同一套 eval、同一套路由规则对新版本做横向比较。
先影子流量，再小流量灰度，再正式切换。
保留旧版本回退策略和兼容期。

这一步经常被忽略，但它直接决定你后面的“模型升级”会不会变成线上事故。

27. 最后总结

模型选择是工程问题，不是排行榜问题。

一套成熟的模型选型体系，应该能回答：

哪类任务用哪个模型？
为什么不用更强或更便宜的模型？
单次请求真实成本是多少？
P95/P99 延迟是否满足 SLA？
模型失败后怎么回退？
模型升级前后质量是否可证？
当前路由是否过度使用高成本模型？

如果这些问题回答不了，说明模型选择还停留在“试试看”的阶段。

真正可生产化的做法，是用评测、画像、路由、回退和监控把模型选择变成可持续演进的系统能力。

06. 模型选择、成本与延迟 ​

1. 为什么模型选择不是越强越好 ​

2. 模型选择到底在选什么 ​

3. 任务先分层，再选模型 ​

4. 建立模型能力画像 ​

5. 选型前先定义任务 SLA ​

6. 成本由哪些部分组成 ​

7. 单次请求成本估算 ​

7.1 基础公式 ​

7.2 示例 ​

7.3 为什么输出 token 很重要 ​

8. 延迟由哪些部分组成 ​

8.1 首 token 延迟与总延迟 ​

8.2 延迟常见瓶颈 ​

9. Token 不是字符，必须精确计算 ​

9.1 为什么工具 schema 也会烧 token ​

10. Prompt caching 是重要成本杠杆 ​

10.1 什么适合缓存 ​

10.2 如何提升缓存命中 ​

10.3 缓存不是万能 ​

11. 批处理、Flex、Priority 和实时链路 ​

12. 限流和吞吐是选型的一部分 ​

12.1 需要关注的限流指标 ​

12.2 限流对架构的影响 ​

13. 不同任务的模型选型建议 ​

13.1 分类与路由 ​

13.2 信息抽取 ​

13.3 RAG 问答 ​

13.4 代码任务 ​

13.5 Agent 规划 ​

13.6 实时语音 ​

14. 模型路由：生产系统的常态 ​

14.1 常见路由维度 ​

14.2 简单路由规则示例 ​

14.3 路由评测指标 ​

15. 模型回退和降级 ​

15.1 回退类型 ​

15.2 回退后要记录什么 ​

16. 评测：不要凭感觉选模型 ​

16.1 评测集结构 ​

16.2 评测维度 ​

16.3 模型对比表 ​

17. 线上监控指标 ​

17.1 必看指标 ​

17.2 告警建议 ​

18. 常见优化杠杆 ​

18.1 减少输入 token ​

18.2 减少输出 token ​

18.3 减少请求次数 ​

18.4 提升缓存 ​

18.5 分层路由 ​

19. 场景案例 ​

19.1 客服分诊 ​

19.2 企业知识库问答 ​

19.3 代码审查 ​

19.4 实时语音客服 ​

20. 供应商和模型版本治理 ​

20.1 固定版本，不要盲目 latest ​

20.2 供应商风险 ​

20.3 模型升级流程 ​

21. 一个可执行的选型流程 ​

21.1 第一步：任务分解 ​

21.2 第二步：定义每个节点 SLA ​

21.3 第三步：选候选模型 ​

21.4 第四步：跑离线评测 ​

21.5 第五步：设计路由和回退 ​

21.6 第六步：上线监控 ​

22. 常见误区 ​

22.1 只看排行榜 ​

22.2 只看平均成本 ​

22.3 只看平均延迟 ​

22.4 把长上下文当万能解法 ​

22.5 不做版本固定 ​

22.6 不记录路由原因 ​

23. 推荐搭配阅读 ​

24. 落地检查清单 ​

25. 推荐资源 ​

OpenAI ​

Anthropic ​

Google Gemini ​

06. 模型选择、成本与延迟

1. 为什么模型选择不是越强越好

2. 模型选择到底在选什么

3. 任务先分层，再选模型

4. 建立模型能力画像

5. 选型前先定义任务 SLA

6. 成本由哪些部分组成

7. 单次请求成本估算

7.1 基础公式

7.2 示例

7.3 为什么输出 token 很重要

8. 延迟由哪些部分组成

8.1 首 token 延迟与总延迟

8.2 延迟常见瓶颈

9. Token 不是字符，必须精确计算

9.1 为什么工具 schema 也会烧 token

10. Prompt caching 是重要成本杠杆

10.1 什么适合缓存

10.2 如何提升缓存命中

10.3 缓存不是万能

11. 批处理、Flex、Priority 和实时链路

12. 限流和吞吐是选型的一部分

12.1 需要关注的限流指标

12.2 限流对架构的影响

13. 不同任务的模型选型建议

13.1 分类与路由

13.2 信息抽取

13.3 RAG 问答

13.4 代码任务

13.5 Agent 规划

13.6 实时语音

14. 模型路由：生产系统的常态

14.1 常见路由维度

14.2 简单路由规则示例

14.3 路由评测指标

15. 模型回退和降级

15.1 回退类型

15.2 回退后要记录什么

16. 评测：不要凭感觉选模型

16.1 评测集结构

16.2 评测维度

16.3 模型对比表

17. 线上监控指标

17.1 必看指标

17.2 告警建议

18. 常见优化杠杆

18.1 减少输入 token

18.2 减少输出 token

18.3 减少请求次数

18.4 提升缓存

18.5 分层路由

19. 场景案例

19.1 客服分诊

19.2 企业知识库问答

19.3 代码审查

19.4 实时语音客服

20. 供应商和模型版本治理

20.1 固定版本，不要盲目 latest

20.2 供应商风险

20.3 模型升级流程

21. 一个可执行的选型流程

21.1 第一步：任务分解

21.2 第二步：定义每个节点 SLA

21.3 第三步：选候选模型

21.4 第四步：跑离线评测

21.5 第五步：设计路由和回退

21.6 第六步：上线监控

22. 常见误区

22.1 只看排行榜

22.2 只看平均成本

22.3 只看平均延迟

22.4 把长上下文当万能解法

22.5 不做版本固定

22.6 不记录路由原因

23. 推荐搭配阅读

24. 落地检查清单

25. 推荐资源

OpenAI

Anthropic

Google Gemini