AI 成本优化 — 省 token 的工程化栈

这个 pack 包含什么

月度 OpenAI 账单跨过五位数那天，每个工程师突然都对缓存有了观点。这个 pack 是无聊但有用的有序剧本，真正能动账单：先观测再优化、先缓存再路由、先路由再压缩、先压缩再微调。多数把五层都走完的团队能省 10–50%，用户感觉不到 — 上限只在客服 / FAQ（高缓存命中）和大批量分类（小模型微调）这类场景出现，不适用于全新的 agent 推理任务，那种要小心。

按这个顺序装 — 先观测、最后才微调

# 第一层：观测（动手改之前先做这层）
tokrepo install tokencost                                  # 离线价格模型
tokrepo install litellm-cost-tracking                      # 实时按项目看板

# 第二层：缓存（重复场景下 ROI 最高、风险最低）
tokrepo install helicone-cache                             # 一行接入响应缓存
# 或: tokrepo install cloudflare-ai-gateway                # 边缘缓存 + 分析，免费档

# 第三层：路由（先走便宜，安全升级）
tokrepo install litellm-proxy                              # 自部署、BYOK
# 或: tokrepo install openrouter-unified-api               # 托管、一个 key 接 300+ 模型
tokrepo install manifest-smart-router                      # 上面再套语义路由

# 第四层：压缩（前三层做出基线再上）
tokrepo install llmlingua                                  # prompt 压缩 2–20×

# 第五层：微调（最后的手段 — 真烧工程师时间）
tokrepo install fireworks-fine-tune                        # 给那一个窄任务在 Llama 上做 LoRA

顺序比选型更重要。跳着来要么浪费工程师时间去微调一个原本 $0.50/MTok 缓存就能替的模型，要么默默把质量压下去而你都归因不了 — 因为你从来没插桩过基线。不光鲜的真相：最大省钱来自第二层（缓存）和第三层（路由），不是看起来更高级的第五层。

第一层 — 观测

把 TokenCost 当库装上，每个 PR 都能在 staging 打印改动前后的 token 数。生产装 LiteLLM Proxy（开成本追踪）或 Portkey，每条调用都有按项目 / 用户 / 模型拆分的账本。在你能精确到两位有效数字回答「一次用户会话花多少钱」之前，不要进第二层。

第二层 — 缓存

Helicone 一个 proxy header 就能开精确匹配缓存，加 embedding 相似度还能开语义缓存。Cloudflare AI Gateway 在边缘做同样的事，有免费档、默认 24 小时缓存。客服机器人、FAQ、检索问答、幂等分类场景，30–70% 命中率是常见的。Agent 规划循环和创意生成不是，别硬上。

第三层 — 路由

LiteLLM Proxy 是自部署默认款 — 一个 OpenAI 兼容 URL 映射到 Anthropic / Bedrock / Vertex / OpenAI，外加 fallback 链和按 key 预算。OpenRouter 是不想自部署时的托管版。在两者之上再加一层 Manifest，它给 prompt 分类、先丢便宜模型、置信度低才升前沿。Portkey 在网关层加企业功能（SSO / 审计 / 虚拟 key / guardrails）。

第四层 — 压缩

LLMLingua 按 token 重要度评分把 prompt 压到 20×。质量损失完全看任务类型：摘要、抽取、分类基本无感；数学、代码生成、复杂推理就很危险。上线前必须对着 eval 套件 A/B。把压缩比当预算看，不是目标。

第五层 — 微调

在 Llama 上跑 Fireworks 无服务 LoRA，大约 30 分钟训练就能把前沿模型替换在一个窄高频任务上。值得做的条件：≥1 万条标注或 LLM 生成的样本、任务稳定（不是 prompt 还在每周改）、单这个任务上前沿模型账单足够大、能 cover 工程时间。低量端点不要为了省 5% 去微调。

它们怎么拼起来

client app
   │
   ▼
┌──────────────┐    cache hit  ┌────────────┐
│ Helicone /   │──────────────▶│ cached     │
│ Cloudflare   │               │ response   │
│ AI Gateway   │               └────────────┘
└──────┬───────┘ cache miss
       │
       ▼
┌──────────────────┐  classify  ┌─────────────────┐
│ Manifest router  │───────────▶│ cheap model     │
│（语义）          │            │ (Llama / Haiku) │
└──────┬───────────┘            └─────────────────┘
       │ 置信度低 / 升级
       ▼
┌─────────────────┐  可选      ┌──────────────┐
│ LiteLLM /       │───────────▶│ LLMLingua    │
│ OpenRouter /    │ 压缩        │ 先压一道     │
│ Portkey 网关    │            └──────┬───────┘
└──────┬──────────┘                   │
       │                              │
       ▼                              ▼
  前沿模型 (Opus / GPT-4 / Gemini Ultra)
       │
       ▼
LiteLLM 成本账本 + TokenCost 对账

取舍（实话部分）

• 缓存命中 vs 新鲜度 — 客服机器人 70% 命中是赚到，股价助手 70% 命中是事故。TTL 按路由设、不要全局设。FAQ 默认 24 小时合适，时效任何敏感的都不行。
• 路由延迟开销 — 语义路由会在真正调用前加 50–200 ms（embedding + 分类）。聊天里看不见，流式语音 agent 里看得见。前后都测端到端 p95。
• 压缩的质量损失 — LLMLingua 5× 在摘要上几乎免费，20× 在抽取里开始丢事实。压缩上线必须配 held-out eval set，不能只看几条抽样。
• 便宜模型路由错 — 把数学题路由到 Haiku 因为路由器以为是「简单问答」是一种静默回退，一周后用户抱怨「答错」才会浮上来。把路由决策跟 trace 一起记，每周复查置信度最低的那一档。
• 微调锁定 — 在 Llama 3.1 70B 上的 LoRA 是你的、能搬走；闭源模型上的微调不是。基座挑稳了再开。
• 观测本身也不免费 — 自部署 Langfuse / LiteLLM 成本看板要基建；托管 Helicone / Portkey 每调用一点费用。盈亏平衡通常在每月 100 万调用左右 — 这之下，免费档够用。

常见踩坑

• 没观测就优化 — 工程师「GPT-4 太贵」就开始微调模型，从没插桩过真正的花费 top 端点。十次有八次账单被一个功能占大头、不是整个产品。先装第一层。
• 不小心把鉴权 / 私密内容缓存了 — 只按 prompt 文本做 key 的语义缓存会很愉快地把用户 A 的医疗对话回给用户 B，只要他们问得相近 embedding 就对上。缓存 key 必须带 user / tenant / 鉴权上下文。
• 错任务路由到错模型 — Tool 调用、JSON 模式结构化输出在很多便宜模型上会崩。上线前用真实生产流量分布跑路由分类器、不要用合成 benchmark。
• 把「省 token」当「省钱」 — 大多数提供商输入 token 比输出 token 便宜 3–5 倍。压缩 8k 输入而模型输出本来就 200 token 的场景，省下的比表面比例小得多。盯美元、不要盯 token。
• 把成本优化当一次性事 — 提供商价格按月变、便宜新模型按季度出。每季度重跑路由 benchmark，不然你会在 2026 年的硬件上付 2024 年的价。
• 跳过 compression / 路由的 eval 闸门 — 第三到第五层每次改动都必须挂在 eval 套件后面（golden set / LLM-as-judge / 生产影子流量）。「省 20% token、掉 4% 准确率」很少是你想要的交易。

跟这些 pack 搭配

这个 pack 是成本层。配 Agent Observability + Tracing 做调试侧 — 没法归因到 span 的花费、就没法优化。配 LLM Eval & Guardrails 让每次路由 / 压缩改动都挂在质量门后面。配 Vector DB + RAG — 如果你的 prompt 是被检索上下文撑长的，最便宜的 token 就是不发的那条。