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

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

本章要点

• RAG 生产的三个硬约束：成本 / 延迟 / 质量——没法全部最大、但能找到业务甜点
• 三层缓存：query 级（完整响应）、embedding 级（去重）、prompt cache（LLM 前缀）
• prompt caching 能把输入 token 成本降 90%——2024 年后最大单点优化杠杆
• 延迟预算要分阶段精打细算——每一跳都有削减空间
• 成本优化的 ROI 顺序：prompt caching → 模型分层 → 缓存 → 批处理

21.1 生产 RAG 的三元约束

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

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

三者常常冲突：

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

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

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 图

规模经济

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）：每个用户、每个付费订阅、每个成功回答对应的成本。

三层单位指标

• 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 的前缀改动让命中率降了——单次改动省钱的迭代很多、但每周某处不经意的改动也在消耗这些收益。没有回归机制、半年后你会发现"钱也没省下来"。

成本回归的几种隐形来源

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

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×——大规模项目省的钱不是小数目。

持续优化飞轮

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

• 监控：每日、每周的成本面板持续刷
• 归因：成本异常时定位是哪个 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 的租户成本分布规律：

这个"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 自托管的详细决策框架。

两种路线的性能特征

两者不是简单"便宜 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/月。

规模拐点

把两种模型放一起对比：

拐点大约在 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 用量预测与容量规划

前面几节讲了当前的成本和容量怎么算——但生产规划还需要回答：下季度 / 下年的用量会怎样、成本会是多少、容量要买多少？没有预测、要么容量不足（用户挤爆）、要么容量浪费（付了没用的钱）。这节把 RAG 的用量预测和容量规划讲清楚、让预算和部署决策有依据。

为什么要做预测

预测的终极价值：把不可预测的 cost spike 变成可控的 cost curve。

预测的三种方法

方法 A：基于历史趋势

过去 3-6 月的 QPS / 成本数据、用时间序列模型（ARIMA / Prophet）外推：

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)

适合：成长曲线稳定的项目（月增长 5-10%）

方法 B：Seasonal 模式

识别周 / 月 / 季度的周期性：

• 工作日 vs 周末：QPS 差 3-5 倍（企业 B2B 产品）
• 工作时段 vs 凌晨：10× 差
• 季度促销（双十一 / 黑五）：日常的 5-10×
• 财报季 / 招聘季：特定行业的高峰

把这些 pattern 加进模型——不只预测"均值"、还预测"什么时候会高"。

方法 C：Event-driven

重大事件打破历史趋势：

• 产品发布：上线新 feature、用量跃升
• 营销活动：推广导致 QPS 10×
• 客户签约大客户：单一 tenant 的量翻倍
• 竞品事件：竞品出问题、流量转移过来

这些用户告诉你而不是从数据里算——要跨团队预测、和产品 / 市场 / 销售对齐。

容量分段规划

预测出 "未来 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（手动启用、应对极端）

分段而不是"一刀切"——日常不浪费、极端能扛。

弹性扩容的 buffer

K8s HPA 扩容不是瞬间的——有延迟：

• 触发阈值（QPS 到 80%）→ 起新 pod
• Pod 启动（包括 warmup）：30-120s
• 这段时间内 QPS 继续涨——可能击穿

所以 buffer 要领先流量增长：

• HPA 阈值 70% 而不是 90%——给扩容留时间
• Min replicas 设相对宽：baseline QPS 的 1.5×
• 预扩容：预测到高峰的 30 分钟前、手动扩

这套 buffer 让扩容不落后于流量。

成本预测的不确定性

预测数字有不确定性——要给范围不是单一数：

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

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

向上级老板报预算时、给 range 更专业——拍死一个数、最后实际差太远、信誉受损。

基础设施的采购策略

基于预测、采购策略：

• 基础容量：Reserved Instances / 年度承诺——低价、但死板
• 增长部分：On-demand——灵活、按量
• 峰值 burst：Spot / preemptible——最便宜、但可能被抢

典型组合：60% reserved + 30% on-demand + 10% spot — 平衡成本和灵活度。

全 on-demand 贵 30-50%、全 reserved 风险高（用不完浪费）。

预算 review 节奏

预测不是一次——持续 review：

• 周度 review：实际 vs 预测、差距 > 20% 触发调整
• 月度 review：下月预测更新、容量规划调整
• 季度 review：和财务对齐、下季预算
• 年度 review：长期战略对齐、多年预算

每次 review 里、基于最新数据更新模型——不是拿 6 个月前的预测当准。

成本的季节性

RAG 成本有几种季节性：

• 业务周期：新产品发布、销售旺季
• 竞品事件：竞品出事、流量涌入
• 宏观因素：经济周期、行业趋势
• 定价变化：云厂商 / LLM 厂商涨价或降价

每种因素都要关注——某些完全不可控（经济、定价）、要做 sensitivity 分析（如果涨价 10%、成本变化多少）。

成本优化的 pipeline

每次发现实际成本偏高、要有标准流程：

每个事件走完这个 pipeline、团队的"成本优化经验"就积累起来——下次同类问题快速响应。

预算的组织对齐

工程团队的预算不是工程一家定——跨团队：

• 产品：承诺用量（DAU 增长）
• 销售：新大客户上线
• 财务：总预算盘子
• 法务：合规增加的成本

工程做预测、给这些方对齐、得到一致的预算承诺。各做各的数字、最后对不上——典型大公司病。

极端场景的应对

规划要考虑极端但可能的场景：

• 竞品挂一天：流量突涨 5×、能扛吗
• 核心客户上线：单客户 QPS 翻倍
• 云厂商限流：现有配额被削减、怎么办
• 黑天鹅（LLM 厂商涨价 50% / 被封）：备用方案

每个场景写进 runbook——不是"应急时再想"、是事前想好。

预测的误差来源

预测常见误差：

• 用户增长不线性：有 S 曲线、病毒传播等非线性
• 用量分布变化：用户使用深度变（原来每天 5 query、现在 20 query）
• 架构改变影响：上线新 feature、成本结构变
• 竞品 / 市场事件：不可预测

接受误差是常态——定期校准是关键。

预测工具的投资

是否值得投资专门的 forecasting 工具：

• 小项目（< 1 QPS）：不需要、凭经验
• 中项目（1-100 QPS）：用 Prophet / 简单时间序列
• 大项目（100+ QPS）：专门 forecasting 团队 / 工具
• 超大（1000+ QPS）：可能自研、和业务指标深度结合

投入和规模匹配——小项目上专业预测工具是过度工程。

预测的长期价值

做好预测的团队、相对没做的团队：

• 预算偏差：±10% vs ±50%
• 扩容延迟：提前 30 天 vs 事到临头
• 成本优化：持续小步 vs 偶尔大跃进
• 和老板关系：可预测 vs 惊喜

可预测性本身就是价值——让组织能依赖 RAG 团队做规划、不是看天吃饭。

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

成本控制讲的是钱——但 AI 系统的真实代价还包括能耗和碳排放。一次 LLM 调用的电耗、是一次 Web search 的 100-1000 倍。RAG 服务百万用户、月碳排放可能等于一个小镇——这是 2026 年企业 AI 必须面对的话题。这节给 RAG 的可持续性视角——和成本管理并列的另一维度。

为什么要关注

不是"未来的事"——2026 年已是企业 AI 必答题。

RAG 的能耗来源

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

LLM 是大头——和成本结构一致。

量化方法

每次请求的碳排放估算：

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——不是微不足道。

减排措施

措施 1：模型分层（§21.7）

• Haiku 比 Sonnet 能耗少 5×
• 简单任务用小模型、省电

措施 2：Caching（§21.3）

• Cache 命中 = 几乎不耗电
• 推荐至少 30% cache 命中

措施 3：Prompt 压缩（ch16 §16.17）

• Token 减半 = 能耗减半
• LongLLMLingua 等技术

措施 4：自托管 + 高效硬件

• H100 比 A100 能效高 30-50%
• 自托管能选最优硬件

措施 5：选对厂商 / 区域

• Google Cloud 主打 carbon-neutral
• 北欧 / 加拿大区域电网更绿
• 中国宁夏 / 内蒙古的数据中心电力清洁度高

每措施单独效果一般、组合总碳排降 50-70%。

透明的报告

向客户 / 投资者 / 监管报告：

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

ESG 报告级——披露是最低要求。

法规趋势

2025-2027 年 AI 可持续性法规：

• EU AI Act：高风险 AI 系统披露能耗
• 加州 SB-XXX：大模型披露训练 / 推理碳
• 中国双碳目标：科技公司减排压力
• GRI / SASB 标准：自愿报告框架

走在法规前面比被罚划算——尤其上市公司。

用户可见的可持续性

某些产品给用户展示"绿色 AI"：

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

让用户有意识——可能改变使用习惯（不滥用 AI）。

不是所有产品适合——消费级有空间、企业 SaaS 没必要。

自托管 vs API 的可持续性

• API：厂商处理 infra、可能有公开 carbon report
• 自托管：完全自控、能选最绿的电网

谁更绿——看具体厂商和你自己。Google Cloud 的 carbon-neutral 优势对 API 用户。自托管在水电富集地（贵州 / 四川）也很绿。

端到端 vs 单点优化

降排放 holistic 思考：

• 减少不必要 query
• 提高 cache 命中
• 用更小模型 when possible
• 选绿色 infrastructure
• Offset 残余

单点优化效果有限——系统视角看才大。

业务和可持续的平衡

不能为了减排牺牲业务：

• "用最小模型" → 答错率升、商业损失
• "完全靠 cache" → 用户体验差
• "限制使用次数" → 用户跑

可持续要和业务质量平衡——不是"减到 0"、是"合理减"。

投资 ROI

可持续性的 ROI：

• 直接：降耗 = 降本（省电费）
• 间接：合规 + 品牌 + 客户偏好

投入：

• 量化能耗：1-2 人月
• 优化措施：和成本优化重合
• 报告：每季度 1-2 人天

收益：

• 潜在客户的 ESG 偏好
• 监管合规
• 长期降本

Carbon offset 的争议

买 carbon credit 抵消排放——有争议：

• 支持：市场机制、能减排
• 反对：很多 offset 不真实、绿色洗白

主流意见：先减排、剩余的再 offset——不能只 offset 不减排。

数据中心选址

如果用云：

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

按需求选区域——同公司不同区域碳强度差几倍。

模型大小和能耗的关系

不严格线性：

• LLM 7B → 70B：能耗 ×10、质量 ×1.5（边际递减）
• LLM 70B → 400B：能耗 ×6、质量 ×1.1（更递减）

大模型不是 always 划算——能力 / 能耗的边际收益快速降低。

长期愿景

理想：

• 完全可再生能源驱动的 AI
• 模型本身能效高（小但聪明）
• 每个 query 都"绿色"
• 透明可审计

2030+ 的 AI 应该是这样——今天朝这方向走。

团队的角色

可持续性不是"环保部门的事"——RAG 工程师能做：

• 测量自己服务的能耗
• 优化时考虑能效（不只看延迟成本）
• 文档化减排成果
• 和合规 / 销售配合做 ESG 报告

每个工程师都能贡献——总和才大。

给小团队的建议

不是大公司就不能做：

• 选绿色云区域（举手之劳）
• Cache 命中（本来就要做）
• 小模型 first（成本驱动）
• Track 基本指标（一个 dashboard）

小投入小收益——总比不做强。

这只是开始

AI 可持续性是新兴话题——2024 年才进入主流讨论。本节给的是 starting point——未来几年会有：

• 更精确的测量方法
• 更绿的硬件 / 软件
• 更严的法规
• 更高的客户期望

跟进这个方向、别落后。

和 ch21 整章成本话题的关系

成本和可持续性90% 重叠：

• 减排措施 = 降本措施
• 量化方法相似
• 监控 dashboard 共用

但视角不同——成本是钱、可持续是环境。两者并行考虑、互相强化。

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 章的所有机制汇总到一个完整项目落地。