第21章 成本、延迟、缓存与生产调优

"Fast, cheap, correct — pick three." —— LLM 时代对经典三元悖论的乐观改写

21.1 生产 RAG 的三元约束

每个 RAG 项目都要在三件事上取舍：

• 质量：答对率、faithfulness、用户满意度
• 延迟：TTFT、P50/P99、端到端响应时间
• 成本：LLM 调用、基础设施、运维人力

三者常常冲突：

• 想提质：加 rerank、加 Contextual Chunk、用更大 LLM → 延迟和成本 ↑
• 想降延迟：减 chunk、用小模型、删 rerank → 质量 ↓
• 想省成本：缓存狠、减 LLM 调用、用便宜 embedding → 质量可能 ↓

flowchart TB
    classDef q fill:#efe,stroke:#080
    classDef l fill:#def,stroke:#06c
    classDef c fill:#fed,stroke:#c60
    QUAL[质量]:::q <--> LAT[延迟]:::l
    QUAL <--> COST[成本]:::c
    LAT <--> COST

没有银弹——工程的工作是在业务场景下找到三者最佳平衡。本章讨论每个维度的主要杠杆和它们之间的相互影响。

21.2 延迟预算的分配

P99 = 2000ms 的对话场景典型分配（复习第 4 章）：

阶段	预算	优化方向
查询理解（含 rewrite）	150-300ms	规则优先 / 小模型 / 缓存
多路召回（并行）	80-150ms	索引调优 / 并行化
融合 + Rerank	200-400ms	batch / 小 reranker / 候选减少
Context pack	20-50ms	纯内存操作、几乎零
LLM 生成（TTFT 到完成）	800-1500ms	流式 / prompt cache / 并行工具
网关/日志/其他	100-200ms	保持精简

LLM 生成是主要延迟——60-80% 的总时间。优化顺序：先压 LLM、再压 rerank、最后搞 retrieval。不要先去优化 5ms 的 context pack——ROI 太低。

TTFT vs 端到端

对话体验更关注 TTFT（Time To First Token）——用户看到第一个字的时间。端到端完成可能 2s、但 TTFT < 800ms 感知就是"快"。开流式 + 优化前几步延迟、TTFT 能压到 400-600ms。

长尾延迟是真正的挑战

P50 1s 不代表不会慢——P99 可能 8s。长尾来源：

• GPU / API 偶发高延迟（抢占、网络抖动）
• Rerank 遇到长 chunk 超时
• LLM 某次采样运气差、生成超长

对策：

• 关键请求设 timeout + fallback（第 4 章降级链）
• 并行冗余调用（对关键 API 同时发两请求、取快的）
• 监控 P99 而不是 P50——优化 P99 才能改善用户感知

21.3 三层缓存

缓存是延迟和成本的双重杠杆。RAG 的三层缓存各有适用。

L1：Query-level 缓存

完整响应缓存。Key = hash(query + user_context + knowledge_version)。Value = 完整 JSON response。

• TTL：5-60 分钟
• 命中率：FAQ / 客服场景 30-50%、通用问答 2-5%
• 延迟收益：命中时从 2000ms 降到 < 10ms——跳过所有 LLM 和检索
• 成本收益：命中时零成本（除 Redis）

坑：包含用户信息的 response 不能跨用户共享缓存。Key 一定要包含 user_context hash。

L2：Embedding 缓存

query 和 chunk 的 embedding 去重。Key = hash(text + model_version)。

• TTL：永久或长 TTL（embedding 不变）
• 命中率：查询端 10-20%、离线索引端 50%+（增量场景）
• 延迟收益：命中时从 30-50ms 降到 < 2ms
• 成本收益：每次命中省一次 embedding 调用 ≈ $0.00005

对高频查询集中的场景特别有效。Redis 存 embedding 约 4KB/条、千万条约 40GB。

L3：Prompt Cache（2024 年后的大杠杆）

Anthropic、OpenAI 等都支持 prompt caching——让 LLM 的 input 里可 cache 的前缀只算部分费用。

• cacheable 前缀：system prompt + few-shot 示例 + 稳定 context（如 core memory）
• dynamic 后缀：query + 动态 retrieved chunks

[cacheable prefix]
system: 你是企业知识助手...
few-shot: 示例 1... 示例 2...
---
[dynamic]
context: {retrieved chunks}
query: {user query}

Anthropic 的 cacheable 部分成本降 90%（10% write + 10% read 价格）。典型 RAG 请求 input 60% 是 cacheable、省 50%+ 总 token 成本。

生产用法：

• system prompt + few-shot 标 cache_control: ephemeral
• 长期 cacheable（如整个专栏的 context）标 cache_control: persistent
• 动态部分（每次不同的 retrieved chunks）不标

prompt cache 的命中要求前缀 字节精确相同——注意 prompt 模板的稳定性，一个空格变化就 miss。

21.4 并发和吞吐

延迟只讲单次请求、不够。生产要回答"在高并发下还能撑住吗"。

QPS 和并发的关系

一个直觉：QPS = 并发数 / 平均延迟。P50 延迟 1s 时 100 QPS 意味着 100 个请求同时在跑。这对：

• LLM API 的并发上限（Anthropic / OpenAI 都有）
• 向量库的连接池
• GPU 显存（embedding / rerank 模型的 batch）
• Redis 的连接数和内存

都有直接压力。任一环节的并发上限低于业务 QPS、整条链路崩溃。

容量测试要点

压测时不只看均值——要看饱和曲线：

• 0-30% 容量：P99 和 P50 几乎一致——系统充裕
• 30-70% 容量：P99 开始升高 2-3 倍、但 P50 稳定
• 70-90% 容量：P99 急剧恶化、队列开始堆积
• > 90% 容量：P50 也崩、整体不可用

生产建议常态跑在 40-60% 容量——预留头部应对流量尖峰。上 80% 说明该扩容了、不是"还能再撑撑"。

水平 vs 垂直扩容

扩容两条路：

• 水平：加机器、加 worker 实例。容量线性增长、但要协调（如 LLM API key 配额分配）
• 垂直：单机升级（更大 GPU、更多内存）。简单直接、但有上限

RAG 的垂直扩容典型场景：embedding 服务从 A100 升 H100 一步吞吐翻倍。水平典型场景：在线检索服务加 pod、走 K8s HPA 按 QPS 自动伸缩。

组合用：检索服务水平扩、embedding/rerank 垂直扩——前者无状态好水平、后者模型加载重不宜频繁启动。

21.5 成本的主要来源

百万用户规模的 RAG 一年 LLM 成本可能百万美元级。拆分看：

成本项	典型占比	优化杠杆
LLM 生成	50-70%	prompt cache / 小模型 / 缓存
Embedding	10-20%	自托管 / 缓存 / 批处理
Rerank	5-15%	自托管 / 候选减少
向量库	5-10%	自托管 vs 云 / 压缩索引
基础设施	5-10%	优化之后再看

LLM 生成占大头——prompt caching 是最大单点杠杆。

LLM 选型的成本影响

2026 年主流 LLM 价格（近似）：

模型	Input / 1M tokens	Output / 1M tokens
Claude Haiku 4.5	$1	$5
Claude Sonnet 4.6	$3	$15
Claude Opus 4.7	$15	$75
GPT-5-mini	$1.5	$6
GPT-5	$5	$20
DeepSeek V3	$0.1	$1
Qwen3-Max	$0.3	$1.5

一次 RAG 请求典型 3000 input + 500 output tokens。用 Sonnet 成本 $0.016、用 Haiku 成本 $0.004——4 倍差距。质量可能差 5-10 点。

模型分层策略

一套 RAG 里不同环节用不同模型：

• Query rewrite：Haiku（任务简单）
• Rerank：专用 reranker（bge-reranker）
• Generation：Sonnet（质量主战场）
• Judge / faithfulness：另一个 Sonnet（独立评估）
• Memory extraction：Haiku（批处理不急）

只在真正需要大模型的阶段用大模型、其他用小模型——整体成本可能降 40-60%。

21.6 Batch 处理

离线索引的成本大头是 embedding 和 rerank——batch 处理能让 GPU 利用率从 20% 拉到 80%、吞吐 5-10 倍。

动态 batch

• 队列积累 0-20ms、batch 满 32/64 就 flush
• batch 内尽量选长度相近的（避免 padding 浪费）
• GPU 空闲时强制 flush（不累计太久）

批 embedding API

OpenAI 的 embedding API 支持 batch API——24 小时异步处理、价格 50% 折扣。适合离线全量索引。

# OpenAI batch API 伪代码
batch = client.files.create(file=upload_file, purpose="batch")
job = client.batches.create(
    input_file_id=batch.id,
    endpoint="/v1/embeddings",
    completion_window="24h",
)
# 24 小时后拉结果

大批量一次索引（几千万 chunk）用 batch API 能省一半钱。Anthropic 和 Google 也有类似机制。

21.7 模型选型的成本/质量权衡

具体到业务、小模型 vs 大模型要实测：

场景	小模型够用	必须大模型
FAQ 问答	✓ Haiku	-
合同分析	-	✓ Sonnet/Opus
代码生成	部分够	复杂需 Sonnet
数据提取	✓ Haiku	-
多步推理	-	✓ Opus

实操：先用大模型验证可行、再尝试用小模型看是否保质。反过来（先小模型、质量差再换大）容易让小模型误被判死。

离线蒸馏

用大模型生成高质量数据、训练小模型在这些数据上逼近大模型——离线训一次、在线用小模型。适合量大的稳定任务（如 query rewrite）。

21.8 向量库的成本

向量库的成本按索引大小、QPS、托管方式变化大。

自托管 vs 云

第 11 章的成本对比：

• 自托管 Qdrant 1 节点 + 1 备份：~$3300/月（含 0.2 FTE 运维）
• Pinecone 类似规模：~$1500/月
• pgvector on RDS：~$310/月

中小规模 pgvector 性价比极高——够用、简单、便宜。大规模（> 千万向量）性能不够时再升级。

索引压缩

IVF-PQ 把向量从 4KB/条压到 32 bytes——128× 压缩。1 亿向量从 400GB 降到 3.2GB，内存成本从十几万降到几千。质量略降、用 re-rank 补回来。

冷数据下沉

长期不命中的 chunk 移冷存储，节省内存：

• 热数据：HNSW in-memory（30 天内命中过）
• 冷数据：磁盘 IVF-PQ
• 归档：S3 + 按需重激活

典型分层能降 60% 内存成本。

21.9 Rerank 的成本优化

Rerank 每次请求都跑、量大成本可观。优化方向：

• 候选减少：从 top-100 精排到 top-50 → top-20。延迟 -50%、精度几乎不变
• 模型分层：先用 small rerank 快速过、大 rerank 只精排 top-20
• 自托管：bge-reranker-v2-m3 自托管比 Cohere API 便宜 5-10 倍
• 缓存：(query_hash, chunk_id) → score 缓存。命中率按场景 10-30%

这些单独可能不起眼、叠加起来 rerank 成本能降 60-80%。

21.10 一次完整请求的成本账

具体算一笔账。某企业 RAG 的典型单次请求：

请求流程：
1. Query rewrite (Haiku):  300 input + 80 output
   = 300 * $1/1M + 80 * $5/1M = $0.0007
   
2. Dense embedding (自托管 bge):  0 API 成本（GPU 成本分摊 $0.0001）

3. Hybrid retrieval + Rerank:  bge-reranker 自托管 ≈ $0.0002

4. Generation (Sonnet):  3000 input + 500 output
   = 3000 * $3/1M + 500 * $15/1M = $0.0165

5. Faithfulness check (Haiku offline 10% sampling):  
   分摊 = 0.1 * (2000 * $1/1M + 100 * $5/1M) = $0.00025

6. 向量库 + 网关 + 日志:  $0.0002 分摊

单次请求合计: ~$0.018

加 prompt cache 后

system prompt (200 tokens) + few-shot (400 tokens) 标 cacheable：

Sonnet input:
- cacheable prefix: 600 tokens * $3 * 10% = $0.00018 (write 初次) 或 $0.00018 (read 后续，几乎相同)
- dynamic suffix: 2400 tokens * $3 = $0.0072
- output: 500 * $15 = $0.0075

Generation 从 $0.0165 降到 $0.0149  (-10%)

prompt cache 对长 cacheable prefix 省更多——如果 prefix 占 50%，可省 40%+。

成本优化 ROI 图

flowchart LR
    classDef high fill:#efe,stroke:#080
    classDef mid fill:#def,stroke:#06c
    classDef low fill:#fed,stroke:#c60
    START[优化起点] --> O1[1. prompt cache]:::high
    O1 -->|-40% 成本| O2[2. 模型分层]:::high
    O2 -->|-20%| O3[3. query/embedding cache]:::mid
    O3 -->|-10%| O4[4. batch 处理]:::mid
    O4 -->|-5%| O5[5. rerank 自托管]:::low
    O5 -->|-3%| END[优化终点]

规模经济

100 万请求/天的 RAG：

• 无优化：$18000/天、$540 万/年
• prompt cache + 小模型分层 + rerank 自托管：约 $8000/天、$240 万/年
• 激进优化（重度缓存 + small LLM for 简单问题）：约 $4000/天、$120 万/年

工程投入 100 万200 万美元（研发 + 运维）就能撬动 200 万400 万/年节省——成本优化的 ROI 极高。

21.11 质量-成本-延迟的迭代思路

生产 RAG 的优化不是一次性的、是持续迭代。建议的节奏：

阶段 1：跑通（1-2 周）

• 用默认参数（bge-m3 embedding、bge-reranker、Sonnet）
• 目标：答对率 > 50%、延迟 < 3s
• 不优化成本、先证明 feasibility

阶段 2：质量（2-4 周）

• 改 chunk / 加 hybrid / 微调 rerank
• 目标：答对率 > 75%、基本成型
• 成本延迟次要、允许 10-30% 膨胀

阶段 3：降成本（2-4 周）

• prompt cache / 模型分层 / 缓存 / 批处理
• 目标：成本降 50-70%、质量不退化
• 延迟可以略升

阶段 4：降延迟（持续）

• 并行化 / rerank 轻量化 / 流式
• 目标：P99 < 2s
• 常态持续优化

顺序错了会浪费。阶段 2 没做先降成本、质量上不去；阶段 3 没做先降延迟、优化 ROI 低。

21.12 P99 长尾的对抗：请求冗余和超时

生产 RAG 的 P99 延迟常是 P50 的 4-8 倍——LLM / 外部 API 的尾部延迟难以预测。几个对抗策略：

策略 1：并行冗余请求

对关键 API（LLM 生成、Rerank）同时发两个请求、取先回来的那个。成本加倍、p99 降 50%+。适合：

• 关键路径（而非 batch 提取）
• 外部 API（不是自己服务——自己服务不如扩容）
• 成本不敏感（冗余请求翻倍成本）

策略 2：激进超时 + Fallback

• 主请求：期望 800ms、超时 1500ms
• Fallback：小模型或缓存、立即返回
• 用户体验：99% 的请求看不出降级、1% 的请求看到简短回答

实现：asyncio.wait_for(llm_call, timeout=1.5) 捕获超时走 fallback。

策略 3：speculative decoding

某些 LLM 服务（vLLM、Triton）支持 speculative decoding——用小模型先猜 draft、大模型快速验证。一次推理速度可能 1.5-2 倍。对自托管 RAG 显著。API 侧很少暴露该功能。

策略 4：分段输出

不等完整答案、先把确定部分流式发出。用户看到"正在思考..." → "企业版 SSO 定价..." → "每年 20000 元"。TTFT 低、感知流畅。哪怕完整答案总延迟不变。

长尾监控

把 P99 / P99.9 放在看板上主要位置、和 P50 同等对待。长尾恶化通常是事故前兆——某个下游服务 degraded、先在长尾显现、再影响 P50。

21.13 Rate limit 管理

外部 API 都有 rate limit——OpenAI / Anthropic 按 tenant 或 API key 限 tokens/min 和 requests/min。RAG 高 QPS 下触碰限制会 429 错误。

应对策略

• 配额充裕采购：关键 API 申请企业级 tier、额度 × 10
• 客户端 rate limiter：自己限、比被服务端 429 体面（token bucket + burst）
• 多 key 轮询：企业账号能申请多个 key、轮流用分散压力
• 全局 vs per-user：用户级限流防单用户抢光所有额度
• 优雅降级：被限后切到 fallback（缓存、小模型、静态回复）

监控

必看：

• rate_limit_error_rate：429 错误率（应 < 0.1%）
• tokens_used_per_min：实时使用量 / 配额
• retry_rate：重试比例

接近配额 80% 时告警、采购要提前——等到 100% 用户都受影响了。

21.14 成本监控

生产 RAG 的成本看板要有：

• 单次请求成本分布：P50 / P99、按 segment 分
• 总成本趋势：按天、按 component（LLM / embedding / rerank）拆
• cache 命中率：query / embedding / prompt cache 各自
• 模型用量 per category：Sonnet 被用了多少次、都是什么请求
• 异常成本：单次请求 > 2x 平均的 case 清单

每周看一次、每月做一次预算 review。无监控的项目成本能悄悄翻 3 倍。

21.15 常见反模式

• 反模式 1：默认大模型干所有事。Query rewrite / 抽取 都用 Sonnet——浪费。用 Haiku 绰绰有余
• 反模式 2：cache key 加时间戳。"加个时间戳防陈旧"——每次 key 不同、cache 永不命中。用内容 hash + knowledge_version
• 反模式 3：并发数拉满。上来就 1000 并发请求 LLM API——被 rate limit 爆炸。渐进式、有队列
• 反模式 4：只看均值成本。均值 $0.02 但 p99 $0.5——少数复杂请求吃掉一大半预算。长尾要单独看
• 反模式 5：优化 5% 的部分。context pack 优化半天省了 5ms——LLM 生成那边 1500ms 没动。ROI 算错了

21.16 FinOps 视角：从请求成本到单位经济学

前面几节都在谈 "单次请求成本"——但单次请求成本低不代表生意健康。真正决定项目能否持续的是单位经济学（unit economics）：每个用户、每个付费订阅、每个成功回答对应的成本。

三层单位指标

flowchart TB
    classDef raw fill:#fed,stroke:#c60
    classDef biz fill:#def,stroke:#06c
    classDef sla fill:#efe,stroke:#080
    R1[cost per request<br/>$0.018]:::raw
    R2[cost per successful answer<br/>cost / answer_quality]:::biz
    R3[cost per MAU<br/>月活用户单位成本]:::biz
    R4[cost / revenue ratio<br/>占收入百分比]:::sla
    R1 --> R2 --> R3 --> R4

• Cost per request：工程视角、容易测
• Cost per successful answer：业务视角、失败的回答花的钱是浪费、应该用成功率折算
• Cost per MAU / DAU：产品视角、决定商业模式能否跑通
• Cost / ARR ratio：财务视角、决定毛利率

一个常见陷阱：成本优化只看 cost per request、把 LLM 换成小模型降了 40% 成本、但答对率从 85% 掉到 70%——cost per successful answer 反而上升了（$0.018 / 0.85 = $0.021 → $0.011 / 0.70 = $0.016，看起来降了但考虑到失败答案用户会重问一次、实际更贵）。

成本归因的粒度

仅仅看总成本不够。按维度拆才能发现可优化点：

• 按用户类型：免费用户 vs 付费用户的成本对比、免费吃了太多资源是商业模式问题
• 按 query 类型：FAQ 类 vs 复杂推理类的成本比、定价应反映这个差异
• 按时间段：峰值时段 vs 平时、错峰调度能不能省
• 按 feature：搜索 vs 摘要 vs 对话、哪个 feature 毛利率最高

典型的 "2% 用户吃 50% 成本" 分布在 RAG 里非常常见——找出这 2% 要么限流要么加价、杠杆极大。

什么时候应该"加钱升级"

前面章节都在谈降本，但不是所有场景都应该压成本。三种情况应该反向投钱：

• 合规/法律/医疗场景：答错的代价远大于单次成本差——不要为了省 $0.01 从 Opus 换 Haiku
• 关键决策场景：CEO 每天用来辅助决策的 AI 助手——一次好答案价值 $1000、不在意每次多 $0.05
• 品牌时刻：新用户首次使用、客诉解决等——用最好的模型确保体验、留存 > 成本

工程师本能是降本、产品决策要求懂得在哪些场景应该花更多。

成本优化的止损点

成本优化不是无止境的——几个信号说明该停：

• 进一步优化会伤质量：再降 LLM 层级或模型大小、答对率开始下降
• ROI 倒挂：花 2 人月工程优化省 $500/月——工程师时间本身更贵
• 复杂度爆炸：优化引入的缓存/分层/降级路径超过了核心业务逻辑、可维护性崩塌
• 绝对值已经很小：单次请求 $0.005 以下、再降也没多少钱

"还能再优化 5%"不值得。工程产能应该转到质量提升或新 feature——那里的 ROI 高得多。

单位经济学驱动的路线图

好的 RAG 成本策略按这个顺序：

1. 先算清 unit economics：知道现在每 MAU 多少成本、和收入比
2. 找异常成本：归因分析、发现那 2% 超重用户或那类超贵 query
3. targeted 优化：对准异常点优化、不做地毯式优化
4. 监控止损：每次优化后看业务指标、不好就回滚
5. 到一定点之后停：资源转投提质或新 feature

这套路径比"挨个优化每个组件"高效得多。

预算分配的经验法则

成熟 RAG 项目的一个粗略分配：

支出类别	占 RAG 总支出
LLM 生成（模型 API 或自托管 GPU）	50-65%
Embedding + Vector DB	10-20%
Rerank + 辅助模型	5-15%
基础设施（网关 / 日志 / 监控）	5-10%
工程人力（分摊）	10-15%
评估 / Gold set 维护	2-5%

偏离这个分布太远的项目通常有结构性问题——比如工程人力占 40% 说明自动化不够、或 evaluation 占 20% 说明 gold set 维护太重。

21.17 成本回归测试与自动化优化 pipeline

前 16 节讲的都是"如何优化"——但一个被忽略的角度：优化后的成本会悄悄回退。Prompt 模板改了一行、context 多塞了两个 chunk、某个 prompt cache 的前缀改动让命中率降了——单次改动省钱的迭代很多、但每周某处不经意的改动也在消耗这些收益。没有回归机制、半年后你会发现"钱也没省下来"。

成本回归的几种隐形来源

flowchart TB
    classDef src fill:#fed,stroke:#c60
    classDef effect fill:#fdd,stroke:#c00
    S1[Prompt 模板修改]:::src --> E1[cache miss 率上升]:::effect
    S2[top-k 默认值调大]:::src --> E2[token 成本 +30%]:::effect
    S3[模型版本静默升级]:::src --> E3[定价涨 1.5-3×]:::effect
    S4[对话历史累积]:::src --> E4[context 逐日膨胀]:::effect
    S5[新 feature 上线]:::src --> E5[单请求叠加 3 次 LLM]:::effect
    S6[Rerank 候选扩大]:::src --> E6[GPU 成本翻倍]:::effect

这六类每一类都在生产里反复出现——不是"谁故意浪费"、是正常迭代的副作用。不加监控就是温水煮青蛙。

CI 里加成本 check

参考软件工程的性能回归测试——成本回归测试应该在 CI 阶段就跑。典型检查：

def test_cost_regression():
    fixture = load_fixture("typical_requests_100.json")
    total_input_tokens = 0
    total_output_tokens = 0
    for req in fixture:
        result = rag.process(req)
        total_input_tokens += result.trace.input_tokens
        total_output_tokens += result.trace.output_tokens

    # 基线 (上次 release 时记录)
    baseline_input = 198000
    baseline_output = 53000

    # 允许 5% 回归
    assert total_input_tokens < baseline_input * 1.05, \
        f"input token 回归 {total_input_tokens}/{baseline_input}"
    assert total_output_tokens < baseline_output * 1.05, \
        f"output token 回归 {total_output_tokens}/{baseline_output}"

基线随版本滚动更新——每次有意的成本改动后重新录制基线。意外的回归被 CI 挡在上线前——成本作为一等质量指标而非事后审计。

生产观察的异常检测

CI 只能防已知的、生产观察要防未知的。自动化异常检测：

• 滑动窗口对比：今天的平均成本 / 上周同一天的平均成本、偏差 > 20% 告警
• 租户级异常：某租户成本突增（可能是新上线 feature、可能是滥用）
• Feature 级拆分：搜索 / 摘要 / 对话三个 feature 各自的成本趋势独立看
• cache 命中率漂移：命中率下降 10%+ → 很可能 prompt 前缀不稳定、cache miss 飙升

这些告警的触发时机比每月 review 早、止损效果更好。

自动化扩缩容策略

成本优化不仅是减少单次请求成本、也是让资源利用率高。自动化扩缩容的基本政策：

• 按 QPS 自动伸缩：检索服务根据 QPS 维持 40-60% 利用率、高峰扩容、低谷缩容
• GPU 池按任务弹性：embedding 批任务在夜间用 spot 实例（便宜 3-5×）、白天在线用 on-demand
• 按业务 SLA 分层：核心业务用预留容量（低单价）、新 feature 用按量计费（灵活）
• 关键路径冗余：P0 服务至少 2 个可用区、防单点故障导致流量转移引发成本爆增

扩缩容策略和成本直接挂钩——配错就是浪费或事故。

时段定价与批处理窗口

云供应商和 LLM API 的时段定价策略差异大：

• OpenAI / Anthropic 的 batch API：非实时任务承诺 24 小时内完成、价格 50% 折扣
• AWS / GCP Spot 实例：比 on-demand 便宜 70-90%、可能被中断
• 电价低谷：自建 GPU 集群在电费低谷时段跑大 batch（夜间）

RAG 离线任务（索引全量重建、gold set 评估、memory 提取）都可以用这些便宜窗口。典型做法：

任务分类调度:
- 紧急（RAG 在线查询）    → 主区域 on-demand GPU 实时
- 日常（增量索引）        → 主区域 on-demand 队列、白天处理
- 批量（全量重建、评估）  → 夜间 spot + batch API、next-day 完成
- 实验（A/B 评估、微调） → 任意时段 spot、可中断重启

这四层分类对应的成本差距可能 5-10×——大规模项目省的钱不是小数目。

持续优化飞轮

成本优化不是"一次项目"、是持续过程。飞轮的四个环节：

flowchart LR
    classDef phase fill:#def,stroke:#06c
    M[监控看板]:::phase --> A[异常归因]:::phase
    A --> O[制定优化]:::phase
    O --> D[灰度上线]:::phase
    D --> M

• 监控：每日、每周的成本面板持续刷
• 归因：成本异常时定位是哪个 feature / 租户 / 时段
• 优化：针对性措施（调 top-k、换模型、加 cache）
• 灰度上线：带 CI cost check 和 shadow 验证

一个成熟 RAG 团队每季度都在跑这个飞轮、累积几年成本可能降 60-80%。

常见反模式

• CI 只跑质量不跑成本：性能在 CI 查、成本在财务部查——两者不同步
• 大改动才 review 成本：小改动累积成大问题、半年才发现
• 成本归因不到 feature 粒度：只看总成本、不知道哪个新功能吃掉了预算
• 优化项目结束即忘：做完一轮优化团队散了、没人维护监控——半年回归

成本纪律和代码纪律同等重要——工程团队对成本的掌控能力决定了项目商业模式能否长期成立。

21.18 多租户成本归因与计费设计

前 17 节的成本讨论默认整体视角——RAG 系统每月花多少钱、怎么优化。SaaS 级 RAG 产品还有一个维度：每个租户各自花多少。这个问题不解决、公司层面整体成本控制了、单租户成本仍可能爆炸——某个大客户每月吃掉 30% 资源但只付了 10% 订阅费。多租户成本归因和计费设计是 SaaS RAG 的商业命脉。

为什么 per-tenant 成本必算

典型 SaaS RAG 的租户成本分布规律：

flowchart TB
    classDef heavy fill:#fdd,stroke:#c00
    classDef mid fill:#fed,stroke:#c60
    classDef light fill:#dfd,stroke:#080
    T[所有租户]
    T --> T1[头部 2% 租户<br/>吃掉 40-60% 成本]:::heavy
    T --> T2[中部 20% 租户<br/>吃 30% 成本]:::mid
    T --> T3[长尾 78% 租户<br/>吃 10% 成本]:::light

这个"2/20/78 法则"在企业 RAG 里极其普遍。头部大客户：

• 知识库大（百万 chunk）→ 向量库内存贵
• 活跃用户多（日均千 query）→ LLM 成本高
• 功能用全（hybrid + rerank + memory + agent）→ 全链路贵

如果定价一刀切、头部客户的毛利可能为负——不知道这件事的 SaaS 早晚亏死。

归因到租户的工程挑战

per-tenant 成本归因的核心是每次请求的成本能追溯到租户：

成本项	归因难度	方法
LLM 调用	低	trace 里记 tokens + tenant_id
Embedding 调用	低	同上
向量库存储	中	chunk 数 × 维度 × 单价、按 tenant 聚合
向量库查询 QPS	中	query 数 × 平均延迟占用、按 tenant
GPU 推理	中	rerank / embedding 调用次数
基础设施	高	按 tenant 使用量比例分摊
研发 / 运营	最难	按 ARR 比例分摊

低难度项直接从 trace 拿、中高难度项按比例分摊——大致准确 > 精确但未实现。

Trace-based cost accounting

生产 RAG 的每条请求 trace 加成本字段：

{
  "request_id": "req-abc123",
  "tenant_id": "tenant-acme",
  "user_id": "u-456",
  "timestamp": "2026-04-25T10:00:00Z",
  "cost_breakdown": {
    "llm_input_tokens": 3200,
    "llm_output_tokens": 520,
    "llm_model": "sonnet-4.6",
    "llm_cost_usd": 0.0176,
    "embedding_calls": 1,
    "embedding_cost_usd": 0.00005,
    "rerank_calls": 50,
    "rerank_cost_usd": 0.0002,
    "vector_db_ops": 3,
    "vector_db_cost_usd": 0.00001,
    "total_cost_usd": 0.01786
  }
}

总成本按 tenant_id 聚合、每月出账单。定价和真实成本对比、亏本的租户要重新谈判。

存储类成本的分摊

LLM / embedding 是"按次"成本、向量库 / GPU 是"按占用"成本——后者的 per-tenant 归因更麻烦：

• 向量库存储：每租户 chunk 数 × 每 chunk 存储成本（含 replica + index overhead）
• GPU 推理：按每租户的调用次数 / 总次数 × GPU 月费
• 网关和日志：按流量比例（请求数 + bytes）

这些用 Prometheus metric 采集、月末汇总。精确不到个位数但误差 < 10% 足够商业决策用。

计费模式的三种选型

SaaS RAG 的计费模式：

• 固定订阅：$X/月、不限用量。简单、但必须按最贵用户定价（否则亏）。低使用用户觉得贵
• 按量计费：按 query 数 / token 数付费。灵活但用户预算不可控——怕被"超量炸"
• 混合（tier + overage）：$X/月包含 N 个 query、超出按 $Y/query。主流选择

典型混合定价：

Tier	月费	包含	超量
Starter	$99	1000 queries	$0.10/query
Pro	$499	10000 queries	$0.05/query
Enterprise	定制	无限	定制

定价要预留毛利——每 query 的收入要高于成本 × 2-3（覆盖研发 / 支持 / 坏账）。

限流 + 配额的工程实现

光计费不限流、用户可能一次刷爆配额：

• tier 级别 rate limit：Starter 10 QPS、Pro 100 QPS、Enterprise 无限
• 月度配额：按合约 quota 用完就暂停（或降级到弱模型）、避免 overage 无限增长
• 成本告警：单租户当月成本超 quota 80% → 发邮件预警、超 100% → 暂停服务
• Fair use 约束：明确 "单 query 最多 X token"、避免被 prompt injection 式滥用

这些措施是商业安全网——没有就是在给客户送钱。

成本可视化 per tenant

成本看板必备 per-tenant 视图：

• tenant cost leaderboard：按月成本排序、头部一眼见
• cost per query by tenant：哪些租户单位成本异常高
• 成本构成拆解：每租户 LLM / 向量库 / rerank 的占比、找异常
• 成本 vs 订阅收入：红色高亮亏本租户
• 月度 trend：按租户的成本趋势、突增找原因

这些看板不是技术同学看的——是产品 + 销售 + 财务看的、决定定价策略、续约谈判、客户成功策略。

Bad tenant 的处理

发现某租户"严重亏本"后的处理方式：

• 谈判涨价：续约时按真实成本调整定价
• 技术限流：加强该租户的 quota、降成本
• 迁移低成本 tier：企业版用户改用按量计费、减浪费
• 功能降级：该租户关掉某些昂贵 feature（如 Agent Memory）
• 最后手段：不续约 / 升价到他离开

技术和商业配合——纯技术优化解不了"定价错了"的根本问题。

成本归因的反模式

• 总成本看一次、分租户从不看：头部亏损在均值里被掩盖
• 计费数据和成本数据脱节：财务只看定价、工程只看成本、中间没人对齐
• 不 log 每次请求的成本字段：月末汇总时要从各个系统抓、数据对不上
• 定价静态多年不调：模型降价、你没降、客户长期觉得贵；或成本涨了、你没涨、亏死
• 超量告警只给工程：应该直接给销售和客户、让他们提前应对

多租户成本纪律是商业护城河

认真做 per-tenant cost accounting 的 SaaS 会发现：20% 的客户要涨价、20% 的客户要留住（毛利好）、剩下的按规矩续约。这种细颗粒度的成本认知、让定价持续合理、毛利持续健康——是长期商业护城河。不做的公司最终会被"头部客户不涨价、中部客户不续约"慢慢卷死。

21.19 LLM 自托管 vs API 的 TCO 决策

§21.5 说 LLM 生成占 RAG 成本 50-70%——这是大头。§22.16 泛泛讨论了 buy vs build。LLM 的 self-host 决策值得专门展开——因为它有 GPU 硬件、吞吐 / 延迟特性、模型选择等独特考量、不能用通用 TCO 框架套。很多团队在"API 太贵了要自托管"的想法上拍脑袋、没算清 TCO——最后要么失望（比 API 还贵）、要么走回头路。这节给出 LLM 自托管的详细决策框架。

两种路线的性能特征

flowchart LR
    classDef api fill:#dfd,stroke:#080
    classDef self fill:#fed,stroke:#c60
    API[商用 API<br/>Claude/GPT/Gemini]:::api
    API --> A1[起步即开箱即用]
    API --> A2[按 token 计费]
    API --> A3[模型自动升级]
    API --> A4[厂商锁定]
    SELF[自托管]:::self
    SELF --> S1[前期投入大]
    SELF --> S2[按 GPU 固定成本]
    SELF --> S3[完全控制]
    SELF --> S4[运维负担重]

两者不是简单"便宜 vs 贵"——是使用模型 vs 运营模型两种完全不同的商业关系。

成本模型：API

API 成本 = QPS × avg_tokens_per_request × price_per_token

典型规模示例:
- 100 QPS
- 每请求 3000 input + 500 output tokens
- Sonnet 定价: $3/1M input + $15/1M output

月成本 = 100 QPS × 86400 s/day × 30 天 × (3000 × $3 + 500 × $15) / 1M
      = 2.6 亿请求 × 0.0165 / 请求
      ≈ $430 万/月

100 QPS 是中大型 RAG 规模——$400 万/月让人想自托管。

成本模型：自托管

自托管的主要成本：

• GPU 硬件：A100 / H100 的采购 or 按时租用
• 运维：DevOps 人力 + 监控栈
• 模型本身：开源免费、微调 / 训练有成本
• 故障修复：出事自己排查、没有 SLA 兜底

假设用 8 × H100 自托管 Llama-70B（相当于 Sonnet 级）：

- 8 × H100 (按时租): $30/h × 8 × 720h = $172800/月
- 运维: 0.5 FTE × $300K/年 / 12 = $12500/月
- 监控栈 / 网络: $2000/月

月固定成本: $187000

这 $187000 的月成本可以服务多少 QPS？

• H100 跑 Llama-70B 的典型吞吐：~50 token/s per GPU
• 8 × H100 并发：~400 token/s total
• 每请求 3500 tokens → ~0.11 请求/s per GPU cluster
• 单一 cluster：~10 QPS max

吞吐上不去——多 cluster 才行。50 QPS 需要 5 个 cluster = $935000/月。

规模拐点

把两种模型放一起对比：

flowchart LR
    classDef api fill:#dfd,stroke:#080
    classDef self fill:#fed,stroke:#c60
    QPS1[10 QPS<br/>API $43K/月<br/>自托管 $187K/月]:::api
    QPS2[50 QPS<br/>API $215K/月<br/>自托管 $935K/月]:::api
    QPS3[100 QPS<br/>API $430K/月<br/>自托管 $1.87M/月]:::api
    QPS4[500 QPS<br/>API $2.15M/月<br/>自托管 $1.87M/月]:::self
    QPS5[1000 QPS<br/>API $4.3M/月<br/>自托管 $2M/月]:::self

拐点大约在 500-800 QPS——低于此 API 更便宜、高于此自托管开始省钱。实际数字因模型和场景不同而异、但这个量级是对的。

多数 RAG 项目 QPS 远低于这个拐点——自托管 LLM 不划算。只有超大规模应用（日活千万级）才到这个门槛。

隐性成本

拐点只考虑了显性成本——自托管的隐性成本常被低估：

• 模型升级跟不上：开源模型落后 API 3-6 个月、质量差距影响用户体验
• 微调维护：有 fine-tune 时、新 base 模型出后要重新微调
• 故障响应：API 挂了是厂商的事、自托管挂了是你的事
• 初期磨合：第一次部署到稳定运行、6-12 月团队调试期
• 机会成本：运维 LLM 占 ML 工程师精力、少做产品优化

这些加进去、实际拐点可能推迟到 1000+ QPS。

混合策略

不是"非此即彼"——混合策略最常见：

• API 主路径：关键业务 / 复杂任务用 Claude / GPT——保证质量
• 自托管辅助：简单任务（分类、摘要、抽取）用自托管小模型——省钱
• 离线任务全自托管：索引 pipeline 的 embedding / summary、自托管 GPU 批处理——高性价比
• cold fallback：API 挂了切自托管——可用性提升

典型组合：

def pick_llm(task_type, priority):
    if task_type == "generation" and priority == "high":
        return claude_api  # 质量最重要
    if task_type == "classification":
        return self_hosted_small  # 简单任务用小模型
    if task_type == "offline_summary":
        return self_hosted_batch  # 离线批处理
    return claude_api_haiku  # 默认

这种混合让总成本降 40-70%、同时保留关键场景的质量。

决策 checklist

自托管 LLM 前逐项检查：

• 规模达标：QPS > 500 持续 6 个月、不是短期促销
• 团队能力：有 2+ 名懂 LLM serving（vLLM / TensorRT）的工程师
• 预算：前期 3 个月磨合期、愿意多花 30-50%
• 模型能力可接受：开源模型（Llama、Qwen）的能力够用——质量差距不致命
• 运维基础设施：GPU 采购 / 租用渠道、K8s 集群、监控栈就绪
• 长期战略：不是为了"省钱"、是因为数据隐私 / 定制化等硬需求
• 退路：发现不行时能切回 API、不被沉没成本绑定

少 2 项不过关 → 再等等、别自托管。

自托管的真实成本优势场景

有些场景自托管 ROI 高、不止是规模：

• 数据强隐私要求：金融 / 医疗 / 政务、数据不能出境或不能过第三方 API——自托管是唯一选项
• 极度定制：需要深度微调 base 模型、超出商用 API 的 fine-tune API 能做的
• 超高 QPS 单任务：同一 prompt 模板千万级 QPS——商用 API 的 rate limit 够不上
• 已有 GPU 集群：公司 ML 其他任务已经买了 GPU、复用几乎免费

这些场景下即使 QPS < 500、自托管也值。

半自托管：LLM gateway

近年流行半自托管——用商用 API 作后端、自己做 gateway：

• 自己维护 prompt cache、多模型路由、A/B 测试逻辑
• 底层调 Claude / GPT / Gemini 等多厂商
• 和厂商谈企业协议拿折扣

成本比纯 API 低 20-40%、运维负担远低于自托管模型——对大多数生产 RAG 是甜点。

什么时候重新评估

决定不是一次性的——每年重新评估：

• API 降价了吗？（过去两年降了 70%）
• 开源模型进步了吗？（质量差距缩小 → 自托管 ROI 升）
• 业务规模变了吗？（大幅涨 / 降）
• 团队能力变了吗？（招到 LLM serving 专家后门槛降）

每年 Q1 做一次、和年度预算配套——保持决策动态调整。

最终建议

多数 2026 年的 RAG 项目：

• 规模 < 500 QPS：用 API + gateway、稳定快速
• 规模 > 1000 QPS：认真评估自托管、从部分任务开始试
• 合规敏感：自托管 + 国内 LLM（如 DeepSeek / Qwen）
• 研究 / 实验：API 优先、快速迭代

不要盲目自托管、也不要盲目 API——数清账、选对路。

21.20 用量预测与容量规划

前面几节讲的是当前成本和容量怎么算，生产规划还要回答另一个问题：下季度、下一年的用量会怎样，成本多少，容量买多少。没有预测的结果只有两种——容量不足被挤爆，或者容量浪费花冤枉钱。

flowchart TB
    classDef bad fill:#fdd,stroke:#c00
    classDef ok fill:#dfd,stroke:#080
    P[不做预测]:::bad --> P1[促销时容量不够]:::bad
    P --> P2[低谷时过度采购]:::bad
    P --> P3[预算预估常 off ±50%]:::bad
    G[做预测]:::ok
    G --> G1[提前扩容]:::ok
    G --> G2[spot 实例省钱]:::ok
    G --> G3[预算准确 ±10%]:::ok

预测的价值可以概括成一句：把不可预测的 cost spike 变成可控的 cost curve。

三种预测方法

基于历史趋势最直接，拿过去三到六个月的 QPS 和成本数据做时间序列外推，适合月增长稳定在 5–10% 的项目：

from prophet import Prophet

df = historical_qps_data  # ts, qps
model = Prophet(seasonality_mode='multiplicative')
model.fit(df)

future = model.make_future_dataframe(periods=90)  # 预测 90 天
forecast = model.predict(future)

周期性模式要单独识别，因为它决定的不是均值而是「什么时候会高」：企业 B2B 产品工作日与周末能差 3–5 倍，工作时段与凌晨差一个数量级，双十一、黑五这类促销是日常的 5–10 倍，财报季和招聘季对特定行业也有明显影响。

事件驱动的部分则完全算不出来——产品发布带来的用量跃升、营销活动导致的十倍 QPS、签下大客户后单一租户翻倍、竞品出故障导致流量转移。这些只能靠产品、市场、销售提前告诉你，所以预测本身必须是跨团队的动作，不是工程闷头跑模型。

预测有误差是常态，主要来自四处：用户增长常常不是线性而是 S 曲线；用量分布会变（原来每天 5 条 query 的用户变成 20 条）；上线新 feature 会改变成本结构；市场和竞品事件本就不可预测。所以关键不是追求准，而是定期校准——周度比对实际与预测（差距超 20% 就调整）、月度更新下月预测和容量规划、季度和财务对齐预算、年度做长期战略对齐。每次 review 都要用最新数据重训模型，而不是拿半年前的预测当准。

从预测到容量

有了未来 90 天的 QPS 轨迹，容量要分段配而不是一刀切：

目标 SLA: P99 < 2s、99.9% 可用

预测 QPS 范围:
  P50: 50 QPS（日常）
  P95: 150 QPS（高峰）
  P99.9: 400 QPS（黑五级）

容量配置:
  基础 baseline: 60 QPS 容量（稍高于 P50）
  自动扩容上限: 200 QPS（覆盖 P95 + buffer）
  burst 预案: 450 QPS（手动启用、应对极端）

这里有个容易踩的坑：K8s HPA 扩容不是瞬时的。从触发阈值到新 pod 起来并完成 warmup 要 30–120 秒，而这段时间里 QPS 还在涨，可能直接击穿。所以 buffer 必须领先于流量——HPA 阈值设 70% 而不是 90%、min replicas 设成 baseline QPS 的 1.5 倍、预判到高峰时提前半小时手动扩。

采购策略同样分层：基础容量用 Reserved Instances 或年度承诺换低价，增长部分用 on-demand 保持灵活，峰值 burst 用 spot 或 preemptible 拿最低价。典型配比是 60% reserved + 30% on-demand + 10% spot——全 on-demand 会贵 30–50%，全 reserved 则承担用不完的风险。

规划时还要把极端但可能发生的场景写进 runbook，而不是等出事再想：竞品挂一天导致流量涨 5 倍扛不扛得住、核心客户上线让单租户 QPS 翻倍、云厂商削减现有配额、以及 LLM 厂商大幅涨价或断供时的备用方案。

报预算：给范围，而不是一个数

预测数字带不确定性，对外沟通时要给区间：

2026 Q3 RAG 基础设施成本预测:
  Best case: $120K（用量低 + 优化到位）
  Base case: $180K（预期轨迹）
  Worst case: $300K（用量暴涨 + 紧急扩容）

建议预留: $240K（Base × 1.3）

拍死一个数、最后实际差出一大截，损失的是后续所有预测的可信度。除了用量本身，还有几类完全不可控的因素要做敏感性分析——经济周期、行业趋势、以及云厂商和 LLM 厂商的涨价降价（如果单价涨 10%，总成本变多少）。

预算也不是工程一家的事：产品承诺 DAU 增长，销售提供新大客户的上线节奏，财务给出总盘子，法务说明合规带来的额外成本。工程做预测、拿去和这几方对齐，最终得到一致的预算承诺——各做各的数字、最后对不上，是典型的大公司病。

实际成本超出预测时要有标准流程，让每次异常都沉淀成经验：

flowchart LR
    classDef step fill:#def,stroke:#06c
    S1[成本异常告警]:::step --> S2[归因分析]:::step
    S2 --> S3[定位具体原因]:::step
    S3 --> S4[制定优化计划]:::step
    S4 --> S5[A/B 上线]:::step
    S5 --> S6[持续监控]:::step

最后是投入要匹配规模：QPS 不到 1 的项目凭经验就行，1–100 QPS 用 Prophet 一类的简单时间序列，100 QPS 以上值得配专门的工具和人，1000 QPS 以上才谈得上自研并与业务指标深度耦合。小项目上专业预测工具属于过度工程。

21.21 RAG 的能耗与可持续性：碳足迹的工程视角

成本控制讲的是钱，但 AI 系统的真实代价还包括能耗和碳排放。一次 LLM 调用的电耗是一次 Web search 的 100–1000 倍；一个服务百万用户的 RAG，月碳排放可能相当于一个小镇。

这一节值得读的工程理由不是环保口号，而是它和整章其余部分 90% 重叠：减排措施就是降本措施（模型分层、缓存、prompt 压缩，下面每一条都指回本章前面的小节），量化方法相似，监控 dashboard 共用。区别只在视角——成本是钱，可持续是环境；两者并行考虑会互相强化。

驱动力也不只有理想主义：ESG 报告要求上市公司披露，B2B 客户开始在采购问卷里问碳排放，EU AI Act 等法规正在把高风险 AI 系统的能耗披露写进条文，而降耗本身直接降电费。

能耗从哪儿来，怎么算

典型的能耗分布和成本结构几乎一致——LLM 推理是绝对大头：

能耗占比（典型）:
- LLM 推理（GPU）   60-70%
- Embedding（GPU）  10-15%
- 向量库内存 / 磁盘  5-10%
- Rerank（GPU）     5-10%
- 网关 / 应用层      < 5%
- 数据中心 PUE 损耗  20-40% overhead

单次请求的碳排放可以按 token 估算。下面这段是量级估算而非精确测量——真实数字取决于具体模型、硬件代次和电网结构：

def estimate_co2_per_request(request_trace):
    # 1. LLM 推理
    llm_kwh = (request_trace.input_tokens + request_trace.output_tokens) * 0.000003
    # ~3 micro-kWh per token、按主流模型估

    # 2. Embedding 推理
    embed_kwh = request_trace.embed_calls * 0.0001

    # 3. 向量检索
    retrieve_kwh = 0.00001  # 微小

    # 4. PUE overhead (数据中心)
    total_kwh = (llm_kwh + embed_kwh + retrieve_kwh) * 1.5  # PUE

    # 5. 转 CO2（区域电网混合）
    grid_factor = 0.5  # kg CO2 / kWh、看国家
    co2_kg = total_kwh * grid_factor

    return co2_kg

百万请求/天的服务，年碳排约数十到数百吨 CO2——不是可以忽略的量级。

有一条曲线值得单独记住：模型大小与能耗不是线性关系，而且边际收益衰减很快。7B → 70B，能耗约 ×10 而质量约 ×1.5；70B → 400B，能耗再 ×6 而质量只 ×1.1。所以「上更大的模型」在能耗账上往往是最差的一笔投资——这也正是 §21.7 模型选型那条成本/质量权衡的另一面。

五条减排措施

每一条单独看效果一般，组合起来总碳排可降 50–70%。前三条本来就是本章讲过的降本手段：

措施 1：模型分层（§21.7）。Haiku 一类的小模型比 Sonnet 一类能耗少约 5 倍，简单任务不必用大模型。

措施 2：缓存（§21.3）。cache 命中几乎不耗电，建议至少做到 30% 命中率。

措施 3：prompt 压缩（ch16 §16.17）。token 减半即能耗减半，LongLLMLingua 等技术都属于这一类。

措施 4：自托管 + 高效硬件。H100 比 A100 能效高 30–50%，自托管的好处是能自己选硬件代次。

措施 5：选对厂商与区域。同一家云的不同区域，碳强度能差几倍：

• AWS：us-west-2（俄勒冈）水电、eu-north-1（欧洲）风电
• GCP：europe-north1（芬兰）、asia-northeast1
• Azure：West Europe
• 阿里云：宁夏（光伏）、贵州（水电）

自托管与用 API 在这件事上各有各的路径：API 厂商替你处理基础设施，有些会公开 carbon report；自托管则是完全自控，能挑最绿的电网。

报告、合规与 offset

对外披露是最低要求，一份 ESG 报告级的季度报告大致长这样：

RAG Service Carbon Report 2026 Q1
================================
Total requests: 30M
Total kWh: 12,000
Total CO2 (kg): 6,000

Breakdown:
- LLM inference: 65%
- Embedding: 12%
- Other: 23%

Mitigation:
- Cache hit rate: 35%
- Renewable energy %: 40%
- vs Q4 2025: -15% per request

Offset purchased: 6,000 kg credits
Net CO2: 0

2025–2027 年的法规方向：EU AI Act 要求高风险 AI 系统披露能耗；加州相关法案要求大模型披露训练/推理碳；中国的双碳目标给科技公司持续的减排压力；GRI / SASB 则提供自愿报告框架。对上市公司而言，走在法规前面比被罚划算。

报告里那行 offset 需要一句提醒：买 carbon credit 抵消排放是有争议的做法。支持者认为市场机制确实能推动减排，反对者指出很多 offset 项目并不真实、等同绿色洗白。主流意见是先减排、剩余部分再 offset，不能只 offset 不减排。

投入产出上，这件事的账相当好算：量化能耗大约 1–2 人月，优化措施与成本优化高度重合（等于顺带做了），报告每季度 1–2 人天。收益是省下的电费、监管合规，以及潜在客户的 ESG 偏好。

边界：不要为减排牺牲业务

这一节最容易被读歪的地方是把减排当成单一目标。下面三条都是错的：

• 「一律用最小模型」→ 答错率上升，商业损失远大于省下的电费
• 「完全靠 cache」→ 用户体验变差
• 「限制使用次数」→ 用户流失

可持续要和业务质量平衡，目标不是减到 0，而是合理地减。

还有一个产品层面的选择：要不要把碳足迹展示给用户。

🌱 这条答案的环境足迹：
- 能耗：0.5 Wh
- CO2：0.25 g
- 等效 1 个 Google 搜索的 50 倍

这种展示能让用户对「用一次 AI 的代价」有概念，可能改变滥用习惯。但它不是普适的——消费级产品有发挥空间，企业 SaaS 基本没必要，在后者那里它只会变成噪音。

最后是落地的门槛问题。小团队常以为这是大公司才做得起的事，其实入门四件事几乎零成本：选绿色云区域（改个 region）、把 cache 命中率做上去（本来就要做）、小模型优先（成本驱动，本来就要做）、拉一个 dashboard 跟踪基本指标。RAG 工程师能贡献的也正是这几件——测量自己服务的能耗、优化时把能效和延迟成本一起看、把减排成果记录下来供合规与销售做 ESG 报告。

21.22 跨专栏关联：LLM 推理成本和 serving

《vLLM 推理内核深度解析》讨论过 PagedAttention、continuous batching 等技术——这些都是 LLM serving 侧的成本优化。RAG 侧的 prompt cache 和 serving 侧的 KV cache 有精神同构——都是"复用计算过的结果"。

对自托管 LLM 的 RAG 项目、学习 vLLM / TensorRT-LLM 等 serving 框架的优化技术直接降成本——比纯应用层优化收益大。

21.23 本章小结

1. RAG 的三元约束（质量/延迟/成本）不可能全部最大、业务场景决定甜点
2. prompt caching 是 2024 年后最大单点优化杠杆——cacheable prefix 省 90% 成本
3. 三层缓存：query / embedding / prompt cache 各司其职
4. 模型分层：不同环节用不同模型、总成本降 40-60%
5. 成本大头是 LLM 生成——优化顺序：prompt cache → 模型分层 → 缓存 → 批处理
6. 延迟预算分阶段精打细算——先压大头（LLM）、再压小头（context pack）
7. 优化节奏：跑通 → 质量 → 降成本 → 降延迟——顺序错了 ROI 低
8. 成本监控不可少——均值 + 长尾都要看

下一章是本专栏最后一章——从零构建一个生产级 RAG 系统——把前 21 章的所有机制汇总到一个完整项目落地。