适用场景与目标

适用场景：

• 客服机器人、FAQ 问答、知识库 RAG 等高重复度对话场景
• 混合复杂度的 AI 应用（部分简单查询不需要 GPT-4o 级别模型）
• 月度 LLM 账单超过 $1,000 且仍在增长的团队
• 需要在保持响应质量的前提下控制成本的 AI 产品

目标： 在不显著牺牲输出质量的前提下，将 LLM 推理成本降低 60-80%，具体手段是：

1. 语义缓存：对重复或相近的 query 复用缓存结果，避免重复调用
2. 模型路由：根据 query 复杂度自动分流到合适量级的模型

---

最小可行方案（MVP）步骤

第一步：建立基线测量（Day 1）

在优化之前，必须先知道钱花在哪里。用 instrumentation 包裹所有 LLM 调用：

import time
import json
from functools import wraps

def track_llm_call(model, input_tokens, output_tokens, latency_ms, cost):
    # 发送到你的指标系统 (Prometheus/Grafana/Custom)
    print(json.dumps({
        "model": model,
        "input_tokens": input_tokens,
        "output_tokens": output_tokens,
        "latency_ms": latency_ms,
        "cost_usd": cost,
        "timestamp": time.time()
    }))

def llm_with_tracking(client, model, prompt, ...):
    start = time.time()
    response = client.chat.completions.create(model=model, prompt=prompt)
    elapsed = (time.time() - start) * 1000
    input_t = count_tokens(prompt)
    output_t = count_tokens(response)
    cost = calculate_cost(model, input_t, output_t)
    track_llm_call(model, input_t, output_t, elapsed, cost)
    return response

关键指标要追踪：

• 每请求平均成本
• 各模型占比分布（GPT-4o / GPT-4o-mini / Claude Haiku 各消耗多少）
• Cache hit rate（当前大概率是 0）
• P99 延迟

---

第二步：实现语义缓存（Day 2-3）

语义缓存的核心逻辑：对 query 做 embedding，在向量数据库中找相似结果，命中则直接返回。

工具选型建议：

• 向量数据库：Redis（已有现成 Redis 场景最方便）或 Qdrant（轻量级）
• Embedding：text-embedding-3-small（OpenAI，便宜且质量够用）或 bge-m3

最小实现代码：

import redis
import openai

r = redis.Redis(host='localhost', port=6379, decode_responses=True)
client = openai.OpenAI()

def semantic_cache_get(query: str, threshold: float = 0.85) -> str | None:
    """查询语义缓存，返回命中结果或 None"""
    emb = client.embeddings.create(
        model="text-embedding-3-small",
        input=query
    ).data[0].embedding

    # 在 Redis 中做 ANN 搜索（或用 keys + scores 手动实现简单版）
    # 生产环境建议用 Redis Search 模块的 FT.SEARCH
    candidates = r.ft().search(query, vector=emb, vector_params={"threshold": threshold})
    if candidates:
        return candidates[0]["payload"]["response"]
    return None

def semantic_cache_set(query: str, response: str, ttl_hours: int = 24):
    """写入缓存"""
    emb = client.embeddings.create(
        model="text-embedding-3-small",
        input=query
    ).data[0].embedding
    r.json().set(f"cache:{hash(query)}", "$", {
        "query": query,
        "response": response,
        "embedding": emb,
        "created_at": time.time()
    }, expire=ttl_hours * 3600)

缓存命中率预期（参考值）：

场景	预期命中率
客服 FAQ	60-85%
RAG 文档问答	40-60%
开放域对话	10-20%
代码生成	15-30%

---

第三步：实现模型路由（Day 4-5）

根据 query 复杂度自动选择模型，而不是默认全用 GPT-4o。

路由策略：

ROUTING_RULES = {
    # 简单任务 → 小模型，省 10-15x 成本
    "gpt-4o-mini": {
        "max_tokens_output": 1024,
        "complexity_score": 0,  # 低于 5 分走这里
    },
    # 复杂任务 → 主力模型
    "gpt-4o": {
        "max_tokens_output": 4096,
        "complexity_score": 5,
    },
    # 最高要求任务
    "gpt-4o": {
        "max_tokens_output": 8192,
        "complexity_score": 8,
    }
}

def classify_complexity(query: str) -> int:
    """简单分类：基于关键词和 query 长度"""
    score = 0
    if len(query) > 500:
        score += 2
    if any(kw in query for kw in ["analyze", "compare", "evaluate", "design", "explain"]):
        score += 2
    if query.count("\n") > 3:
        score += 1
    return score

def route_model(query: str) -> str:
    score = classify_complexity(query)
    if score < 3:
        return "gpt-4o-mini"  # 便宜 15x，质量对简单任务够用
    elif score < 6:
        return "gpt-4o"
    else:
        return "gpt-4o"  # 复杂任务保持用大模型

各模型成本对比（2026-05 基准）：

模型	Input $/1M tokens	Output $/1M tokens	适用场景
GPT-4o	$2.5	$10	复杂推理、创作
GPT-4o-mini	$0.15	$0.6	简单问答、分类
Claude Haiku	$0.8	$4	快速响应

---

第四步：整合 Pipeline 并测试（Day 6-7）

def ask(query: str) -> str:
    # 1. 先查缓存
    cached = semantic_cache_get(query)
    if cached:
        return cached

    # 2. 缓存未命中，路由选择模型
    model = route_model(query)

    # 3. 调用 LLM
    response = call_llm(model, query)

    # 4. 写缓存（异步，避免拖慢响应）
    threading.Thread(target=semantic_cache_set, args=(query, response)).start()

    return response

上线前必须验证：

• 缓存命中率 > 30%（否则缓存收益不明显）
• 路由准确率：随机抽样 100 条 query，验证高复杂度 query 确实路由到了大模型
• 质量回归测试：对比优化前后的输出质量（人工或自动化评估）

---

常见坑与规避清单

坑 1：缓存 key 设计不合理

问题： 直接用完整 query 作为 key，导致完全匹配的请求极少。

规避： 使用 embedding + 余弦相似度，阈值设置在 0.85-0.90。低于 0.85 说明语义差异过大，不适合复用。

坑 2：缓存没有设置 TTL

问题： 缓存永不失效，FAQ 更新后用户仍得到旧答案。

规避： 根据业务特性设置 TTL（FAQ 类 → 1-24h；知识库 → 7 天），并提供主动失效接口。

坑 3：路由规则太粗糙

问题： 简单用 query 长度判断复杂度，把复杂问题错误路由到小模型，导致输出质量差。

规避： 先用小模型跑一遍，看是否能满意，再逐步收紧路由阈值。或者用 two-stage 分类：先用 fast model 做意图识别，再决定用哪个模型处理。

坑 4：缓存穿透（Cache Penetration）

问题： 大量不重复的 query 每次都穿透到 LLM，缓存完全没用。

规避： 对无法缓存的 query（embedding similarity < threshold）做短路保护，直接调用 LLM，不要反复查缓存。

坑 5：没有监控 cache hit rate

问题： 缓存上线了但不知道效果如何，无法持续优化。

规避： 在 tracking 系统中增加 cache_hit 字段，每周 review 命中率变化。

坑 6：忽视了 Embedding 成本

问题： embedding 调用虽然便宜，但高频场景下也可能成为成本瓶颈。

规避： 对 query 做 caching（短期 TTL），避免每次都重新 embedding 相同 query。

---

成本/性能/维护权衡

成本对比（以 50 万请求/月为基准）

方案	月成本	年成本	说明
全 GPT-4o（无优化）	~$18,000	~$216,000	假设每请求 1500 tokens
语义缓存（60% 命中）	~$7,200	~$86,400	缓存命中部分成本降到接近 0
缓存 + 路由（简单→mini）	~$3,600	~$43,200	综合优化后
缓存 + 路由 + Batch（适合后台任务）	~$2,000	~$24,000	非实时任务走 Batch API（50% 折扣）

ROI 结论： 每月 $18,000 → $3,600，节省约 $14,400/月，年省约 $17 万。

性能影响

• 缓存命中：延迟降低 90%+（从 ~2s 降到 <50ms）
• 模型路由到 mini：延迟降低 60%+（小模型推理更快）
• 整体 P99 延迟：预期从 3000ms 降到 800-1200ms

维护成本

组件	维护难度	说明
语义缓存	低	Redis/Qdrant 稳定，做好 TTL 即可
模型路由	低	规则简单，每季度 review 阈值即可
Embedding 服务	中	如果用 OpenAI API 则无需自维护
监控/指标	中	需要建立 dashboard 和告警

---

一周内可执行行动清单

Day 1：

• 在现有 LLM 调用层加入 instrumentation，追踪每请求成本
• 导出至少一周的历史数据，确认 top cost 终端

Day 2-3（核心实施）：

• 选择向量数据库（Redis 或 Qdrant）
• 实现语义缓存 MVP（缓存 + 查询逻辑）
• 用历史 query 做离线测试，确认命中率

Day 4-5（路由实施）：

• 实现 query 复杂度分类器
• 配置路由规则，先让 >80% 的明显简单 query 走 mini 模型
• 端到端联调，确保 pipeline 无断点

Day 6-7（验证上线）：

• 上线灰度（10% 流量），监控 cache hit rate 和质量
• 对比优化前后延迟和成本，确认达标后全量
• 搭建监控 dashboard（cache hit rate / 模型分布 / 成本趋势）

Bonus（进阶）：

• 对非实时任务接入 Batch API（50% 折扣）
• 引入 prompt compression（压缩 system prompt 30-50%）

---

一句话总结： LLM 推理成本优化的本质是”让贵的模型只处理真正需要它的任务”。语义缓存解决重复问题，模型路由解决匹配问题，两者结合是 2026 年生产环境 AI 成本控制的标配能力。