AI Day 16
AI Day 16: LLM应用架构设计(1) — API Gateway / 路由 / 缓存 — 生产级LLM系统的骨架
LLM应用架构不是"调一个API"这么简单——它是一套从客户端请求到模型响应再到监控反馈的完整工程体系，包含网关(Gateway)、路由(Router)、缓存(Cache)、流式传输(Streaming)、可观测性(Observability)和成本控制(Cost Control)六大支柱。第一阶段学的是"每块砖是什么"，今天学的是"怎么把砖砌成承重墙"。
2026-04-17
APIModelSemanticStreamingObservabilityCostLiteLLMPortkeyLangFuse
日期：2026-04-17
阶段：第二阶段 — 工程实践 (Day 16-30)
标签：API Gateway Model Router Semantic Cache Streaming Observability Cost Control LiteLLM Portkey LangFuse
学习路径树
AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15) ✅
│ ├── Day 1: Transformer架构与LLM基础 ✅
│ ├── Day 2: 模型量化与本地部署 ✅
│ ├── Day 3: 训练过程深度：Pre-training / SFT / RLHF / DPO ✅
│ ├── Day 4: Prompt Engineering与上下文学习(ICL)原理 ✅
│ ├── Day 5: RAG架构：检索增强生成全链路 ✅
│ ├── Day 6: 向量数据库与Embedding模型 ✅
│ ├── Day 7: Fine-tuning实战：LoRA / QLoRA / Adapter ✅
│ ├── Day 8: 推理优化：vLLM / TensorRT-LLM / SGLang ✅
│ ├── Day 9: 长上下文技术：RoPE扩展 / Ring Attention ✅
│ ├── Day 10: 多模态模型：Vision-Language架构 ✅
│ ├── Day 11: Reasoning模型：CoT / o1 / R1 / Extended Thinking ✅
│ ├── Day 12: Agent框架：ReAct / Tool Use / Planning ✅
│ ├── Day 13: MCP协议与Tool生态 ✅
│ ├── Day 14: 模型评估：Benchmark / Arena / 安全评估 ✅
│ └── Day 15: 阶段复习与架构总结 ✅
│
├── 第二阶段：工程实践 (Day 16-30)
│ ├── Day 16: LLM应用架构设计(1) — API Gateway / 路由 / 缓存 ← 你在这里
│ ├── Day 17: Prompt管理与版本控制
│ ├── Day 18: 缓存与成本控制进阶
│ ├── Day 19: 可观测性与监控
│ ├── Day 20: 安全与合规
│ ├── Day 21-25: 生产级RAG系统（Chunking/Rerank/评估/迭代）
│ └── Day 26-30: Agent系统工程化（状态管理/错误恢复/成本控制）
│
├── 第三阶段：金融零售AI应用 (Day 31-42)
│ ├── Day 31-35: 金融AI（风控模型/智能投顾/合规/反欺诈）
│ ├── Day 36-40: 零售AI（推荐系统/智能客服/供应链预测/营销）
│ └── Day 41-42: CeFi x DeFi x AI融合架构
│
└── 第四阶段：面试冲刺 (Day 43-50)
├── Day 43-46: 系统设计面试（LLM平台/RAG/Agent/推荐）
├── Day 47-49: 产品/架构面试模拟
└── Day 50: 总结与作品集
核心概念
一句话定义
LLM应用架构不是"调一个API"这么简单——它是一套从客户端请求到模型响应再到监控反馈的完整工程体系，包含网关(Gateway)、路由(Router)、缓存(Cache)、流式传输(Streaming)、可观测性(Observability)和成本控制(Cost Control)六大支柱。第一阶段学的是"每块砖是什么"，今天学的是"怎么把砖砌成承重墙"。
金融类比
LLM应用架构 = 银行核心系统架构
传统银行的三层架构:
前台渠道层: 手机银行/网银/柜面/ATM → 统一接入网关
中台服务层: 账户/支付/风控/营销 → 服务路由 + 缓存 + 监控
后台核心层: 核心账务/清算/报表 → 核心处理引擎
LLM应用的三层架构:
接入层: Web/App/API/Agent → AI Gateway (鉴权/限流/日志)
编排层: Prompt管理/模型路由/缓存 → 智能中间件
模型层: GPT-4o/Claude/Qwen/本地模型 → LLM推理引擎
银行核心系统的工程经验 100% 适用于LLM系统:
┌──────────────────────────────────────────────────────────┐
│ 银行系统经验 → LLM系统对应 │
├──────────────────────────────────────────────────────────┤
│ 统一接入网关(ZUUL/Kong) → AI Gateway(Portkey/LiteLLM) │
│ 服务路由(灰度/AB) → 模型路由(按任务选模型) │
│ Redis缓存 → Semantic Cache(语义缓存) │
│ 限流熔断(Sentinel) → Token Rate Limiting │
│ 链路追踪(Zipkin/Jaeger) → LLM Traces(LangFuse) │
│ APM监控(Prometheus) → Token/延迟/质量三维监控 │
│ 灾备切换 → 模型Fallback(主模型→备模型) │
│ 交易流水(审计日志) → Prompt+Response审计日志 │
└──────────────────────────────────────────────────────────┘
本质相同: 都是在"不可100%信任的后端服务"前面加上
路由/缓存/限流/监控/容错 这五大中间件能力。
银行不信任单一清算通道（所以有灾备），
LLM不信任单一模型提供商（所以有Fallback）。
为什么Day 16是第二阶段的起点
第一阶段（Day 1-15）建立了"技术栈每一层是什么"的认知
第二阶段（Day 16-30）要解决"怎么把这些层组装成生产系统"
Day 16的定位:
→ 搭建LLM系统的"骨架"（Gateway/Router/Cache）
→ 后面的Day 17-20在这个骨架上加"肌肉"（Prompt管理/监控/安全）
→ Day 21-25在骨架上挂"器官"（RAG系统）
→ Day 26-30在骨架上装"大脑"（Agent系统）
今天不把骨架搭好，后面一切都是空中楼阁。
知识点1: LLM应用分层架构
1.1 完整架构图
┌─────────────────────────────────────────────────────────────────────┐
│ CLIENT LAYER │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Web App │ │ Mobile │ │ API调用方 │ │ Agent │ │
│ │ (React) │ │ (iOS/ │ │ (B2B) │ │ (自动化) │ │
│ │ │ │ Android)│ │ │ │ │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ │ │ │ │ │
│ └──────────────┴──────────────┴──────────────┘ │
│ │ │
│ HTTPS / WebSocket / SSE │
│ │ │
├──────────────────────────────┼───────────────────────────────────────┤
│ ┌─────▼─────┐ │
│ GATEWAY LAYER │ API │ ← 鉴权(API Key/JWT) │
│ │ Gateway │ ← 限流(Token Rate Limit) │
│ │ │ ← 日志(Request/Response Log) │
│ │ (Portkey/ │ ← 负载均衡 │
│ │ LiteLLM/ │ ← 输入校验 │
│ │ Kong+ │ ← 安全过滤(PII/Injection) │
│ │ Plugin) │ │
│ └─────┬─────┘ │
│ │ │
├──────────────────────────────┼───────────────────────────────────────┤
│ ┌─────▼─────┐ │
│ ROUTING LAYER │ Model │ ← 按任务复杂度选模型 │
│ │ Router │ ← 成本/延迟/质量权衡 │
│ │ │ ← Fallback链 (主→备→降级) │
│ └─────┬─────┘ │
│ │ │
├──────────────────────────────┼───────────────────────────────────────┤
│ ┌─────▼─────┐ │
│ CACHE LAYER │ Cache │ ← Exact Match (Redis) │
│ │ Manager │ ← Semantic Cache (向量相似) │
│ │ │ ← Prompt Cache (模型原生) │
│ └─────┬─────┘ │
│ │ │
│ Cache Miss │
│ │ │
├──────────────────────────────┼───────────────────────────────────────┤
│ ┌─────▼─────┐ │
│ PROMPT LAYER │ Prompt │ ← 模板引擎 │
│ │ Manager │ ← 变量注入 │
│ │ │ ← 版本控制 │
│ │ │ ← A/B测试 │
│ └─────┬─────┘ │
│ │ │
├──────────────────────────────┼───────────────────────────────────────┤
│ ┌─────▼─────┐ │
│ MODEL LAYER │ LLM │ ← OpenAI API │
│ │ Providers │ ← Anthropic API │
│ │ │ ← 本地vLLM │
│ │ │ ← Azure OpenAI │
│ │ │ ← AWS Bedrock │
│ └─────┬─────┘ │
│ │ │
├──────────────────────────────┼───────────────────────────────────────┤
│ ┌─────▼─────┐ │
│ OBSERVABILITY │ Monitor │ ← Token用量追踪 │
│ LAYER │ & Trace │ ← 延迟分布(P50/P95/P99) │
│ │ │ ← 质量评分 │
│ │ (LangFuse/│ ← 成本核算 │
│ │ Helicone)│ ← 告警 │
│ └───────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────┘
1.2 每层的核心职责
| 层 | 核心职责 | 关键指标 | 类比银行系统 |
|---|---|---|---|
| Gateway | 统一入口、鉴权、限流、安全过滤 | QPS、拒绝率、鉴权延迟 | 统一接入网关 |
| Router | 模型选择、Fallback、负载均衡 | 路由准确率、Fallback次数 | 交易路由(网联/银联) |
| Cache | 减少重复请求、降低成本和延迟 | 缓存命中率、节省的Token数 | Redis热数据缓存 |
| Prompt | 模板管理、版本控制、变量注入 | Prompt版本数、A/B测试命中率 | 交易报文模板管理 |
| Model | 实际调用LLM推理 | TTFT、Token/s、错误率 | 核心账务处理引擎 |
| Observe | 全链路监控、成本追踪、质量评估 | 日Token消耗、P95延迟、质量分 | APM+交易流水监控 |
1.3 为什么不能直接调API
"直接调API"的问题 = "银行直接连央行清算系统而不加中间件"
直接调API:
client → OpenAI API → response
问题1: 供应商锁定 → OpenAI限流了你就瘫了
问题2: 成本黑洞 → 没有缓存，相同问题每次都花钱
问题3: 无法追溯 → 出了问题不知道是哪个Prompt导致的
问题4: 安全裸奔 → 用户可以注入恶意Prompt
问题5: 浪费资源 → 简单问题也用最贵的模型
生产级架构:
client → Gateway → Router → Cache → Prompt → Model → Observe
解决1: Router支持多Provider，自动Fallback
解决2: Cache层命中率40-70%，直接省钱
解决3: Observe层全链路追踪每一次调用
解决4: Gateway层做输入过滤和PII脱敏
解决5: Router按复杂度选模型，简单任务用小模型
知识点2: AI Gateway设计
2.1 AI Gateway的核心能力
传统API Gateway (Kong/Nginx/Envoy):
→ 路由 / 限流 / 鉴权 / 日志 / 负载均衡
AI Gateway = 传统Gateway + LLM特有需求:
→ Token级别限流（不是按请求数，是按Token数）
→ 多模型统一接口（一个接口调任意模型）
→ 流式响应中继（SSE透传）
→ Prompt安全过滤（Injection检测）
→ 成本追踪（实时Token用量和费用）
→ 语义缓存（不是完全匹配，是语义相似也命中）
→ 模型Fallback（主模型超时自动切备用模型）
2.2 2025-2026主流AI Gateway方案
| 方案 | 类型 | 核心优势 | 适用场景 | 定价 |
|---|---|---|---|---|
| Portkey | SaaS+OSS | 最全面的AI Gateway，支持200+模型、语义缓存、Guardrails | 企业级生产环境 | 免费层+付费 |
| LiteLLM | OSS (Python) | OpenAI兼容格式统一100+模型，可自建 | 中小团队自建Gateway | 免费(OSS) |
| Cloudflare AI Gateway | SaaS | CDN集成、全球低延迟、缓存、分析 | 已用Cloudflare的团队 | 免费层+付费 |
| AWS Bedrock Gateway | Cloud原生 | 与AWS生态深度集成 | AWS重度用户 | 按量 |
| Kong + AI Plugin | OSS+插件 | 已有Kong的团队平滑升级 | 已有API Gateway基础设施 | Kong付费 |
| 自建 (FastAPI) | 自研 | 完全可控 | 特殊合规要求(金融/医疗) | 人力成本 |
2.3 OpenAI兼容API的重要性
为什么"OpenAI兼容API"成了事实标准？
OpenAI Chat Completions API格式:
POST /v1/chat/completions
{
"model": "gpt-4o",
"messages": [{"role": "user", "content": "Hello"}],
"temperature": 0.7,
"stream": true
}
2025年几乎所有模型都支持这个格式:
→ Anthropic Claude (通过LiteLLM转换)
→ Google Gemini (通过OpenRouter/LiteLLM)
→ DeepSeek (原生兼容)
→ Qwen/GLM (原生兼容)
→ 本地vLLM/Ollama (原生兼容)
好处:
1. 切换模型只改一个"model"参数，不改代码
2. 所有SDK/框架(LangChain/LlamaIndex)都原生支持
3. 测试时用便宜模型，上线用贵模型，零代码改动
金融类比: 就像银联定义了标准报文格式，
所有银行/商户接一次就能跑所有卡。
OpenAI格式 = AI领域的"银联标准"。
2.4 LiteLLM架构示例
LiteLLM: 最常用的开源AI Gateway (2025-2026)
核心能力:
→ 统一100+模型到OpenAI格式
→ 内置负载均衡和Fallback
→ Token级别限流
→ 成本追踪
→ 可作为Proxy Server独立部署
架构:
Client (任何OpenAI SDK)
│
▼
┌─────────────────┐
│ LiteLLM Proxy │ ← 独立部署的HTTP服务
│ (FastAPI) │
│ │
│ ┌───────────┐ │
│ │ Router │ │ ← 模型选择 + 负载均衡
│ └─────┬─────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │ Adapter │ │ ← 格式转换 (Claude/Gemini→OpenAI格式)
│ └─────┬─────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │ Budget │ │ ← Token预算管理
│ │ Manager │ │
│ └─────┬─────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │ Callbacks │ │ ← 监控回调 (LangFuse/Helicone)
│ └───────────┘ │
└────────┬────────┘
│
┌─────┴──────────────────┐
│ │ │
▼ ▼ ▼
OpenAI Anthropic 本地vLLM
GPT-4o Claude Qwen-72B
配置示例(litellm_config.yaml):
model_list:
- model_name: "gpt-4o" # 用户请求的模型名
litellm_params:
model: "gpt-4o" # 实际调用的模型
api_key: "sk-xxx"
- model_name: "gpt-4o" # 同一个名字可以配多个Provider
litellm_params:
model: "azure/gpt-4o" # Azure版本作为负载均衡
api_key: "azure-xxx"
- model_name: "claude-sonnet"
litellm_params:
model: "anthropic/claude-sonnet-4-20250514"
api_key: "sk-ant-xxx"
- model_name: "cheap-model" # 内部自定义名
litellm_params:
model: "deepseek/deepseek-chat"
api_key: "sk-ds-xxx"
router_settings:
routing_strategy: "least-busy" # 最空闲的实例优先
num_retries: 3 # 失败重试3次
fallbacks: # Fallback链
- model: "gpt-4o"
fallback: "claude-sonnet"
- model: "claude-sonnet"
fallback: "cheap-model"
2.5 Portkey: 企业级AI Gateway
Portkey的差异化能力(2025-2026最受关注的AI Gateway):
1. Guardrails (内容安全护栏)
→ 内置PII检测、Prompt Injection检测、内容过滤
→ 金融场景必备: 拦截含银行卡号/身份证号的请求
2. Virtual Keys (虚拟密钥)
→ 统一管理多个Provider的API Key
→ 不把真实Key暴露给开发者
3. Semantic Cache (语义缓存)
→ "如何转账"和"怎么转钱"命中同一缓存
→ 比Exact Match缓存命中率高3-5倍
4. Conditional Routing (条件路由)
→ 根据请求内容/用户标签/时间段选择不同模型
→ 例: VIP用户→Claude Opus, 普通用户→Sonnet
5. Reliability (可靠性)
→ 自动Fallback + 重试 + 超时控制
→ 99.99% uptime SLA
6. Analytics (分析)
→ 实时Token用量、成本、延迟Dashboard
→ 按用户/功能/模型维度拆分
知识点3: 智能路由
3.1 为什么需要智能路由
问题: 用一个模型处理所有请求 = 用大炮打蚊子 + 用BB弹打坦克
真实请求分布（典型的企业级LLM应用）:
┌──────────────────────────────────────────────┐
│ 简单请求 (60-70%) │
│ "帮我格式化这段JSON" │
│ "翻译这句话" │
│ "从这段文本提取日期" │
│ → 用Claude Haiku/GPT-4o-mini, 成本$0.001/请求│
├──────────────────────────────────────────────┤
│ 中等请求 (25-30%) │
│ "总结这篇5000字的报告" │
│ "写一封专业的客户邮件" │
│ "分析这个SQL查询的问题" │
│ → 用Claude Sonnet/GPT-4o, 成本$0.01/请求 │
├──────────────────────────────────────────────┤
│ 复杂请求 (5-10%) │
│ "设计一个分布式支付系统的架构" │
│ "分析这份金融报表的异常项" │
│ "写一个带错误处理的递归解析器" │
│ → 用Claude Opus/o3, 成本$0.10/请求 │
└──────────────────────────────────────────────┘
如果全用Opus:
100万请求/月 × $0.10 = $100,000/月
智能路由后:
70万简单 × $0.001 = $700
25万中等 × $0.01 = $2,500
5万复杂 × $0.10 = $5,000
总计 = $8,200/月
节省: 91.8% ← 这就是智能路由的价值
3.2 路由策略分类
┌────────────────────────────────────────────────────────────────┐
│ 模型路由策略矩阵 │
├──────────────┬──────────────────┬──────────────────────────────┤
│ 策略类型 │ 原理 │ 适用场景 │
├──────────────┼──────────────────┼──────────────────────────────┤
│ 基于规则 │ 预定义条件映射 │ 任务类型明确的场景 │
│ (Rule-based)│ if task == X │ "翻译"→小模型 │
│ │ → model_A │ "代码"→大模型 │
├──────────────┼──────────────────┼──────────────────────────────┤
│ 基于成本 │ 在质量阈值内 │ 成本敏感的高并发应用 │
│ (Cost-opt) │ 选最便宜的模型 │ 先试小模型，不行再升级 │
├──────────────┼──────────────────┼──────────────────────────────┤
│ 基于延迟 │ 选最快响应的 │ 实时对话/交互式应用 │
│ (Latency) │ 模型或实例 │ 用户不能等超过2秒 │
├──────────────┼──────────────────┼──────────────────────────────┤
│ 基于质量 │ 用Classifier │ 质量要求高的金融/医疗 │
│ (Quality) │ 判断所需质量级别 │ 宁可贵也不能错 │
├──────────────┼──────────────────┼──────────────────────────────┤
│ 混合策略 │ 成本+延迟+质量 │ 大多数生产系统 │
│ (Hybrid) │ 加权评分 │ 根据业务优先级调权重 │
├──────────────┼──────────────────┼──────────────────────────────┤
│ LLM自路由 │ 小模型判断任务 │ 前沿方案(2025-2026) │
│ (LLM-route) │ 复杂度后分发 │ Martian/Unify等平台 │
└──────────────┴──────────────────┴──────────────────────────────┘
3.3 级联路由 (Cascading Router)
级联路由: 先试便宜的，不行再试贵的（渐进式升级）
请求进入
│
▼
┌──────────────────┐
│ Step 1: │
│ 用 Haiku/Mini │ ← 最便宜，延迟最低
│ 尝试回答 │
└────────┬─────────┘
│
┌────▼────┐
│ 质量检查 │ ← 自动评估: 置信度/一致性/关键词检查
│ 通过？ │
└────┬────┘
Yes │ No
│ │
┌────▼┐ ┌▼───────────────┐
│返回 │ │ Step 2: │
│结果 │ │ 用 Sonnet/4o │ ← 中等成本
│ │ │ 重新回答 │
└──────┘ └────────┬───────┘
│
┌────▼────┐
│ 质量检查 │
│ 通过？ │
└────┬────┘
Yes │ No
│ │
┌────▼┐ ┌▼───────────────┐
│返回 │ │ Step 3: │
│结果 │ │ 用 Opus/o3 │ ← 最贵，质量最高
│ │ │ 最终回答 │
└──────┘ └────────────────┘
优点: 大部分请求在Step 1就返回了，平均成本极低
缺点: 延迟可能增加（最坏情况经过3次调用）
优化: 设超时阈值，如果Step 1在200ms内没有高置信答案就直接跳Step 2
金融类比: 就像银行的审批层级
→ 1万以下: 柜员直接批
→ 1-10万: 主管审批
→ 10万以上: 行长审批
大部分交易在第一级就处理了
3.4 基于分类器的路由
用一个轻量级分类器(或小模型)判断请求复杂度:
┌─────────────┐ ┌──────────────┐ ┌──────────────┐
│ 用户请求 │ ──► │ Classifier │ ──► │ 路由决策 │
│ │ │ (小模型/规则) │ │ → 选择目标模型│
└─────────────┘ └──────────────┘ └──────────────┘
Classifier的实现方式:
方式1: 关键词规则 (最简单)
if contains("翻译","translate") → haiku
if contains("代码","debug","架构") → opus
if token_count > 5000 → sonnet # 长输入用中等模型
方式2: 小模型分类 (更智能)
用Haiku/Mini对请求做分类:
system: "判断以下请求的复杂度: simple/medium/complex"
→ 成本约$0.0001/请求，可忽略
方式3: Embedding相似度 (最精准)
预定义各级别的示例Embedding
计算新请求的Embedding与各级别的相似度
选最近的级别 → 路由到对应模型
方式4: 专用路由模型 (2025前沿)
Martian、Unify等平台提供的专用路由模型
训练在大量(请求, 最优模型)对上
比规则更准确，比小模型分类更快
知识点4: 缓存策略
4.1 三层缓存架构
LLM应用的三层缓存（命中率和复杂度递增）:
Layer 1: Exact Match Cache (精确匹配)
┌──────────────┐
│ Redis/ │ key = hash(model + messages + params)
│ Memcached │ value = response
│ │ TTL = 1h - 24h
└──────────────┘
命中条件: 请求完全相同(字符级)
命中率: 10-30% (取决于应用类型)
延迟: <1ms
适用: FAQ/客服/重复性查询
Layer 2: Semantic Cache (语义缓存)
┌──────────────┐
│ Vector DB + │ 将请求Embedding后存入向量库
│ Redis │ 新请求Embedding后做相似度搜索
│ │ 相似度 > 阈值(如0.95) → 返回缓存
└──────────────┘
命中条件: 语义相似(不要求字面相同)
命中率: 30-60% (比精确匹配高很多)
延迟: 5-20ms (Embedding计算+向量搜索)
适用: 用户换不同说法问同一个问题
示例:
"ETH现在多少钱" vs "以太坊当前价格是多少" → 命中!
"如何申请信用卡" vs "办信用卡的流程" → 命中!
Layer 3: Prompt Cache (模型原生缓存)
┌──────────────┐
│ 模型Provider │ 缓存System Prompt和长前缀的KV Cache
│ 原生支持 │ 后续请求只计算新增部分
│ │ Claude: 自动缓存, 减少~90%输入Token
│ │ OpenAI: Cached Tokens半价
└──────────────┘
命中条件: Prompt前缀相同
节省: 输入Token成本降低50-90%
延迟: TTFT减少60-80%
适用: 所有带System Prompt的应用(几乎所有场景)
三层协同:
请求到达
│
▼
Exact Match → 命中? → Yes → 返回 (延迟<1ms, 成本$0)
│ No
▼
Semantic Cache → 命中? → Yes → 返回 (延迟~15ms, 成本≈$0)
│ No
▼
Prompt Cache → 减少输入Token → 调用模型 (延迟↓, 成本↓50-90%)
│
▼
模型返回 → 结果写入Exact + Semantic Cache
4.2 Semantic Cache深入
语义缓存的工作流程:
┌──────────┐ Embed ┌──────────┐ Search ┌──────────┐
│ 用户请求 │ ─────────► │ Embedding │ ──────────► │ Vector │
│ │ │ Model │ │ DB │
└──────────┘ └──────────┘ └────┬─────┘
│
相似度 > 0.95?
┌─────┴─────┐
│ Yes │ No
▼ ▼
┌──────────┐ ┌──────────┐
│ 返回缓存 │ │ 调用LLM │
│ 结果 │ │ 结果写入 │
│ │ │ 缓存 │
└──────────┘ └──────────┘
关键设计决策:
1. 相似度阈值选择
→ 0.90: 激进(高命中率，但可能返回不太精准的缓存)
→ 0.95: 平衡(推荐大多数场景)
→ 0.98: 保守(只在非常相似时才命中)
金融场景建议0.97+: "转账到招商银行"和"转账到工商银行"不能混
2. Embedding模型选择
→ 轻量: text-embedding-3-small (OpenAI), 成本低延迟低
→ 本地: all-MiniLM-L6-v2 (Sentence Transformers), 零API成本
→ 语义缓存不需要最好的Embedding，够用就行
3. 缓存失效策略
→ TTL: 固定时间过期（如1小时/24小时）
→ 事件驱动: 数据更新时主动清理相关缓存
→ LRU: 满了删最久未使用的
→ 金融数据建议短TTL（价格类5分钟，规则类24小时）
4.3 缓存命中率与成本节省
真实场景缓存效果估算:
场景: 金融智能客服，日均10万请求
Without Cache:
100,000请求 × 平均2000 Token × $0.003/1K Token = $600/天
月成本: $18,000
With 3-Layer Cache:
Exact Match命中: 20% → 20,000请求免费
Semantic Cache命中: 30% → 30,000请求免费
Prompt Cache节省: 剩余50,000请求的输入Token减少80%
实际调用模型: 50,000请求
Prompt Cache后Token成本: 50,000 × (400+2000×0.2) × $0.003/1K
≈ 50,000 × 800 × $0.003/1K = $120/天
月成本: $3,600
节省: $18,000 → $3,600 = 降低80%
缓存ROI计算:
缓存基础设施成本: Redis($50/月) + VectorDB($100/月) = $150/月
缓存节省: $14,400/月
ROI: 96x ← 缓存是LLM应用中ROI最高的优化
知识点5: 流式响应与用户体验
5.1 为什么Streaming是必须的
LLM的延迟特征和传统API完全不同:
传统API:
请求 → [处理100ms] → 完整响应
用户感知: "很快"
LLM非流式:
请求 → [等待5-30秒(生成全部Token)] → 完整响应
用户感知: "卡住了"，"是不是坏了"
LLM流式:
请求 → [200ms后第一个Token] → 逐Token流出 → 完成
用户感知: "正在思考，很流畅"
关键指标:
TTFT (Time To First Token): 第一个Token到达的时间
→ 用户体验的决定性指标
→ <500ms: 优秀
→ 500ms-2s: 可接受
→ >2s: 需要Loading动画
→ >5s: 用户可能放弃
TPS (Tokens Per Second): 每秒输出的Token数
→ 人类阅读速度约250词/分 ≈ 5 Token/s
→ >10 TPS用户感觉"很快"
→ <3 TPS用户感觉"一个字一个字蹦"
5.2 Streaming架构
两种Streaming协议:
方案1: Server-Sent Events (SSE) — 最主流
┌──────┐ HTTP POST ┌──────────┐ SSE ┌──────────┐
│Client│ ───────────────► │ Gateway │ ◄─────── │ LLM API │
│ │ ◄─────────────── │ (中继) │ ────────► │ │
└──────┘ SSE Stream └──────────┘ └──────────┘
数据格式:
data: {"choices":[{"delta":{"content":"你"}}]}
data: {"choices":[{"delta":{"content":"好"}}]}
data: {"choices":[{"delta":{"content":"，"}}]}
data: [DONE]
优点: HTTP协议，无需特殊基础设施，浏览器原生支持
缺点: 单向（服务端→客户端），不支持客户端中途发消息
方案2: WebSocket — Agent场景
┌──────┐ WebSocket ┌──────────┐
│Client│ ◄──────────────► │ Gateway │
└──────┘ 双向通信 └──────────┘
优点: 双向通信，客户端可随时中断/追加
缺点: 需要维护长连接，基础设施更复杂
适用: Agent场景（需要中途确认/追加指令）
2025-2026的共识:
→ 普通对话: SSE (简单够用)
→ Agent/协作: WebSocket (需要双向)
→ 绝大多数应用选SSE
5.3 TTFT优化策略
TTFT (Time To First Token) 优化:
┌───────────────────────────────────────────────────────────────┐
│ 优化手段 │ 效果 │ 适用场景 │
├────────────────────────────┼────────────┼───────────────────┤
│ Prompt Cache (模型原生) │ TTFT↓60-80%│ 固定System Prompt │
│ 更快的模型 (Haiku/Mini) │ TTFT↓70% │ 简单任务 │
│ 区域就近部署 │ TTFT↓30-50%│ 全球用户 │
│ Prompt压缩 (删冗余) │ TTFT↓20-40%│ Prompt过长时 │
│ 预热请求 (Keep-alive) │ TTFT↓10-20%│ 冷启动场景 │
│ 边缘缓存 (Cloudflare) │ TTFT→0 │ 高频重复请求 │
└───────────────────────────────────────────────────────────────┘
渐进式渲染(Progressive Rendering):
不是等全部输出完才处理，而是边输出边渲染
阶段1 (前100ms): 显示"思考中..."动画
阶段2 (TTFT到达): 开始逐字显示文本
阶段3 (Markdown检测): 检测到代码块/表格时切换渲染模式
阶段4 (完成): 显示"复制/重新生成"按钮
金融场景的特殊处理:
→ 数字出现时等整个数字完成再显示（避免"$1" → "$12" → "$123"闪烁）
→ 表格数据等完整行出来再渲染
→ 关键结论（如"审批通过/拒绝"）可以高亮显示
知识点6: 可观测性
6.1 LLM可观测性 vs 传统可观测性
传统微服务可观测性三支柱:
Logs → 发生了什么
Metrics → 系统表现如何
Traces → 请求经过了哪些服务
LLM可观测性需要额外维度:
Logs → 每次调用的Prompt + Response全文
Metrics → Token用量 + 成本 + 延迟 + 质量评分
Traces → 每次调用经过: Gateway → Router → Cache → Model → Post-process
Quality → 输出质量评估（传统系统没有这个维度）
┌─────────────────────────────────────────────────────────────┐
│ LLM可观测性四维矩阵 │
├──────────────┬──────────────────────────────────────────────┤
│ 维度 │ 关键指标 │
├──────────────┼──────────────────────────────────────────────┤
│ 性能 │ TTFT, TPS, P50/P95/P99延迟, 超时率 │
│ 成本 │ Token消耗(Input/Output), 日/月成本, 单请求成本│
│ 质量 │ Hallucination率, 用户满意度, 任务完成率 │
│ 可靠性 │ 错误率, Fallback触发率, 模型可用性 │
└──────────────┴──────────────────────────────────────────────┘
6.2 Traces和Spans
LLM Trace = 一次完整请求的全链路追踪
示例: 用户问"ETH现在什么价格？"
Trace ID: abc-123
├── Span 1: Gateway (2ms)
│ ├── 鉴权: API Key验证 ✓
│ ├── 限流检查: 未超限 ✓
│ └── 输入过滤: 安全 ✓
│
├── Span 2: Router (1ms)
│ ├── 任务分类: "简单查询"
│ └── 路由决策: → Haiku (最便宜)
│
├── Span 3: Cache Check (3ms)
│ ├── Exact Match: Miss
│ ├── Semantic Cache: Hit! (相似度0.97)
│ └── 缓存来源: "以太坊价格多少" (2分钟前)
│
├── Span 4: Response (0ms) ← 缓存命中，未调用模型
│ └── 返回缓存结果
│
└── Span 5: Logging (1ms)
├── Token: 0 (缓存命中)
├── 成本: $0
└── 总延迟: 7ms
如果Cache Miss，Span 3+4会变成:
├── Span 3: Cache Check (3ms)
│ ├── Exact Match: Miss
│ └── Semantic Cache: Miss
│
├── Span 4: Model Call (850ms)
│ ├── Provider: Anthropic
│ ├── Model: claude-haiku
│ ├── Input Tokens: 150
│ ├── Output Tokens: 80
│ ├── TTFT: 120ms
│ └── Cost: $0.00006
│
├── Span 5: Cache Write (2ms)
│ ├── 写入Exact Match Cache
│ └── 写入Semantic Cache (Embedding计算)
6.3 2025-2026主流LLM可观测性工具
| 工具 | 类型 | 核心能力 | 定价 | 适用 |
|---|---|---|---|---|
| LangFuse | OSS+Cloud | Trace/Prompt管理/评估/成本追踪 | 免费(OSS)/付费(Cloud) | 最推荐的开源方案 |
| LangSmith | SaaS | LangChain原生集成/Trace/评估/Dataset | 免费层+付费 | LangChain用户 |
| Helicone | SaaS | 一行代码接入/成本追踪/缓存/限流 | 免费层+付费 | 快速接入 |
| Arize Phoenix | OSS | Trace/Embedding可视化/LLM评估 | 免费(OSS) | 数据科学团队 |
| Portkey Analytics | SaaS | 内置在AI Gateway中/零额外集成 | 包含在Portkey中 | Portkey用户 |
| OpenTelemetry+ | OSS标准 | 用OTel标准接入LLM Trace | 免费 | 已有OTel基础设施 |
6.4 告警策略
LLM系统告警规则设计（参考金融交易监控经验）:
P0 - 立即响应 (电话/短信):
→ 所有模型Provider同时不可用(Fallback耗尽)
→ 错误率 > 20% (5分钟窗口)
→ 输出中包含PII/敏感信息泄露
P1 - 15分钟内响应 (IM/邮件):
→ 主模型不可用，已切Fallback
→ P95延迟 > 10秒 (5分钟窗口)
→ 日成本超预算150%
→ 缓存命中率骤降 > 50%
P2 - 1小时内查看 (Dashboard):
→ Token用量异常波动(环比+30%)
→ 特定Prompt版本的质量评分下降
→ 单用户Token消耗异常(可能被滥用)
P3 - 日报级别:
→ 成本趋势分析
→ 模型版本更新后质量变化
→ 缓存命中率周趋势
金融场景增加:
→ 合规相关输出被拦截次数 > 阈值 → P1
→ 审计日志写入失败 → P0 (合规要求)
知识点7: 成本控制
7.1 LLM成本构成
LLM应用的成本组成（按占比排序）:
┌─────────────────────────────────────────────────┐
│ 成本项 │ 典型占比 │ 可优化空间 │
├─────────────────┼──────────┼────────────────────┤
│ 模型API调用 │ 60-80% │ 高 (路由+缓存) │
│ Embedding计算 │ 5-15% │ 中 (本地化+缓存) │
│ 向量数据库 │ 5-10% │ 低 (相对固定) │
│ 基础设施 │ 5-10% │ 低 │
│ 可观测性工具 │ 2-5% │ 中 (采样) │
└─────────────────┴──────────┴────────────────────┘
→ 最大的杠杆在"模型API调用"上
→ 缓存+路由可以减少60-90%的调用成本
7.2 Token预算管理
Token预算系统 = 金融系统的交易限额管理
┌─────────────────────────────────────────────────────────┐
│ Token预算管理架构 │
├─────────────────────────────────────────────────────────┤
│ │
│ 全局预算: │
│ 月度上限: 10M Tokens ($3,000) │
│ 日均分配: 333K Tokens ($100) │
│ 实时余额: 查询当前已用/剩余 │
│ │
│ 团队/项目预算: │
│ 客服团队: 5M Tokens/月 │
│ 研发团队: 3M Tokens/月 │
│ 数据团队: 2M Tokens/月 │
│ │
│ 用户级别预算: │
│ 免费用户: 10K Tokens/天 │
│ 付费用户: 100K Tokens/天 │
│ 企业用户: 1M Tokens/天 │
│ │
│ 超限策略: │
│ 80%: 告警通知 │
│ 100%: 降级到更便宜的模型(不中断服务) │
│ 120%: 仅允许缓存命中(不调用模型) │
│ 150%: 返回"服务暂时不可用" │
│ │
│ 金融类比: 和信用卡额度管理一模一样 │
│ 预警 → 降额 → 临时额度 → 冻结 │
└─────────────────────────────────────────────────────────┘
7.3 Prompt压缩
Prompt过长 → Token消耗大 → 成本高 + 延迟高
Prompt压缩策略:
策略1: 删除冗余指令
Before (350 tokens):
"你是一个非常专业的、经验丰富的金融分析师助手。
你的回答应该总是非常准确、详细、全面的。
请注意，你的回答必须基于事实，不要编造信息。
如果你不确定，请明确说明你不确定。
回答时请使用中文。请用Markdown格式输出。"
After (80 tokens):
"角色:金融分析师。要求:准确、基于事实、不确定时说明。
格式:中文Markdown。"
节省: 77%
策略2: 示例压缩(Few-shot → Zero-shot + 格式说明)
Before: 给5个完整示例 (2000 tokens)
After: 给1个示例 + 格式说明 (400 tokens)
节省: 80%
策略3: 上下文窗口管理
对话历史只保留最近N轮 + 关键摘要
Before: 完整20轮对话 (8000 tokens)
After: 摘要(500 tokens) + 最近3轮(1500 tokens)
节省: 75%
策略4: 动态上下文(仅注入相关信息)
RAG检索结果不要全塞，根据相关性评分取Top K
Before: 塞10个chunk (5000 tokens)
After: 塞3个最相关chunk (1500 tokens)
节省: 70%
7.4 月度成本估算模型
LLM月度成本估算公式:
月成本 = 日请求数 × 30 × 平均Token × 有效Token单价
其中:
有效Token单价 = 模型单价 × (1 - 缓存命中率) × 路由节省系数
实际案例: 金融智能客服
基础参数:
日请求数: 50,000
平均输入Token: 800 (含System Prompt + 上下文)
平均输出Token: 300
无优化方案 (全用Claude Sonnet):
Input: 50,000 × 800 × $3/M × 30 = $3,600/月
Output: 50,000 × 300 × $15/M × 30 = $6,750/月
总计: $10,350/月
优化方案:
1. 智能路由 (60%用Haiku, 30%用Sonnet, 10%用Opus)
Haiku: 30,000 × (800×$0.25/M + 300×$1.25/M) = $17.25/天
Sonnet: 15,000 × (800×$3/M + 300×$15/M) = $103.5/天
Opus: 5,000 × (800×$15/M + 300×$75/M) = $172.5/天
路由后: $293.25/天 = $8,797.5/月 (↓15%)
2. 缓存 (命中率50%)
实际调用减半: $8,797.5 × 0.5 = $4,398.75/月 (↓57.5%)
3. Prompt Cache (输入Token↓80%)
Input成本再降80%: 约 $3,000/月 (↓71%)
4. Prompt压缩 (输入Token↓30%)
进一步压缩: 约 $2,400/月 (↓77%)
最终: $10,350 → $2,400 = 降低77%
基础设施额外成本:
LiteLLM/Portkey: $200/月
Redis (缓存): $50/月
LangFuse (监控): $100/月
总额外: $350/月
净节省: $10,350 - $2,400 - $350 = $7,600/月 = 73%
┌────────────────────────────────────────────────┐
│ 优化措施 │ 月成本 │ 降幅(vs无优化) │
├─────────────────┼──────────┼────────────────┤
│ 无优化 │ $10,350 │ - │
│ +智能路由 │ $8,797 │ ↓15% │
│ +缓存 │ $4,399 │ ↓57% │
│ +Prompt Cache │ $3,000 │ ↓71% │
│ +Prompt压缩 │ $2,400 │ ↓77% │
│ +基础设施成本 │ $2,750 │ ↓73%(净) │
└────────────────────────────────────────────────┘
7.5 多级模型策略的完整决策流
生产环境中的多级模型策略:
┌────────────────────────────────────────────────────────────┐
│ │
│ 请求到达 │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ 缓存层检查 │ → Hit → 返回 ($0, <5ms) │
│ └──────┬───────┘ │
│ │ Miss │
│ ▼ │
│ ┌──────────────┐ │
│ │ 路由分类器 │ ← 判断任务复杂度 │
│ └──────┬───────┘ │
│ ┌────┼────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 简单 中等 复杂 │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ Haiku Sonnet Opus │
│ $0.25 $3 $15 (per M Input Token) │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ │
│ │ 质量检查 │ ← 置信度评估 │
│ └──────┬───────┘ │
│ │ │
│ Pass │ Fail │
│ │ │ │
│ ▼ ▼ │
│ 返回 升级到更高级模型重试 │
│ 结果 (最多升级1次，避免无限循环) │
│ │
│ 整体效果: │
│ → 平均响应成本降低60-80% │
│ → 平均延迟降低40-60%(小模型更快) │
│ → 质量损失<5%(复杂任务仍用最强模型) │
│ │
└────────────────────────────────────────────────────────────┘
今日思考
思考1: LLM架构和传统金融系统架构的深层相似性
10年金融系统经验告诉我，LLM架构不是"全新的东西"，
而是"老问题在新场景的重现":
传统金融:
→ 多通道接入(柜面/ATM/网银) → 统一接入网关 → 路由 → 核心系统
→ 问题: 各通道格式不同、核心系统不能裸露、需要限流保护
LLM系统:
→ 多客户端(Web/App/API) → AI Gateway → 路由 → 模型服务
→ 问题: 各模型API不同、模型不能裸露、需要Token限流
架构模式完全一样:
1. 适配器模式: 统一不同后端的接口 (OpenAI兼容API)
2. 断路器模式: 后端故障时快速失败 (模型Fallback)
3. 分层缓存: 近端缓存→远端缓存→数据库 (Exact→Semantic→Model)
4. 限流降级: 超限时降级而非拒绝 (降级到更便宜的模型)
5. 审计日志: 每笔交易可追溯 (每次Prompt/Response可追溯)
核心洞察:
金融系统架构经验是LLM架构设计的"加速器"，不是"包袱"。
很多LLM团队在重新发明金融系统20年前就解决的问题。
比如"语义缓存"本质上就是金融系统里的"模糊匹配查重"(AML场景)。
思考2: 成本控制是PM最该关注的架构决策
技术团队往往痴迷于"用最好的模型"和"最酷的架构"，
但PM必须算成本账:
一个真实场景的决策过程:
需求: 金融报告自动生成
技术方案: 全用Claude Opus + RAG
月成本: $50,000
预算: $10,000
PM的架构介入点:
1. 拆解任务: 数据提取(简单) + 格式化(简单) + 分析(复杂)
2. 分层路由: 提取和格式化用Haiku，只有分析用Opus
3. 增加缓存: 同类报告的分析框架可缓存复用
4. Prompt优化: 精简System Prompt，减少无效Token
优化后月成本: $8,000 (目标预算内)
教训:
架构师/PM不关注成本 = 项目上线就亏钱
而大多数成本优化不需要牺牲质量，只需要"把对的模型用在对的地方"
思考3: 可观测性是从"能用"到"能信赖"的关键
金融系统最重要的不是"能跑"，而是"出了问题能查到原因"
同样，LLM系统的可观测性决定了:
→ 能否发现Hallucination? (质量监控)
→ 能否发现成本异常? (成本追踪)
→ 能否在出问题时5分钟定位原因? (Trace)
→ 能否向合规部门证明AI的决策过程? (审计日志)
金融监管的要求:
"每一笔交易必须可追溯、可审计、可复现"
LLM的对应要求:
"每一次AI输出必须可追溯(哪个Prompt/哪个模型/什么上下文)"
如果Day 16只记住一句话:
"没有可观测性的LLM系统，就像没有交易日志的银行系统——
能跑，但没人敢用它做真正重要的事。"
面试表达
面试题36: 如何设计一个生产级LLM应用的架构？
30秒版本:
生产级LLM架构分为六层：API Gateway统一接入和安全过滤，智能路由根据任务复杂度选择不同模型降低成本，三层缓存（精确匹配、语义缓存、Prompt Cache）将重复请求的成本降到零，Prompt管理层做版本控制和A/B测试，模型层对接多个Provider实现高可用，最后可观测性层用LangFuse做全链路追踪。这套架构可以在不牺牲质量的前提下，把成本降低70%以上。
2分钟版本:
我把LLM应用架构类比为银行核心系统——前台渠道层、中台服务层、后台核心层。
第一层是AI Gateway，类似银行的统一接入网关。用Portkey或LiteLLM统一多模型的API接口为OpenAI兼容格式，同时做鉴权、Token级限流、PII脱敏、Prompt注入检测。核心思想是不让模型层直接暴露。
第二层是智能路由，这是降本的关键。真实请求中60-70%是简单任务，只需要Haiku级别的模型。通过分类器或级联路由策略，把简单请求路由到便宜模型，复杂请求才用Opus/o3。实测可以降低60-80%的模型调用成本。
第三层是三级缓存——精确匹配缓存处理完全相同的请求，语义缓存处理意思相同但说法不同的请求（命中率可达30-60%），Prompt Cache利用模型原生能力减少重复前缀的计算。三层叠加可以把50%以上的请求在不调用模型的情况下返回。
第四层是可观测性，我认为这在金融场景尤其关键。用LangFuse做全链路Trace——每次调用的Prompt、Response、Token用量、延迟、成本全部记录。这不仅用于运维监控，更是合规审计的基础。
结合我的金融背景，这套架构的设计思路其实和银行核心系统的中间件架构完全一致——适配器模式统一接口、断路器模式做Fallback、分层缓存降成本、全链路追踪保合规。
面试题37: LLM系统如何做成本控制？
30秒版本:
LLM成本控制的核心是"四把刀"：第一刀是智能路由，60%的简单请求用便宜模型处理；第二刀是多层缓存，50%的请求直接返回缓存结果；第三刀是Prompt压缩，精简System Prompt和上下文减少Token消耗；第四刀是Token预算管理，给每个团队和用户设限额，超限降级而非中断。四刀下去，通常可以降低70%以上的成本。
学习资源
核心参考
| 资源 | 类型 | 说明 |
|---|---|---|
| LiteLLM文档 | 文档 | 最实用的AI Gateway开源方案 |
| Portkey文档 | 文档 | 企业级AI Gateway参考架构 |
| LangFuse文档 | 文档 | LLM可观测性最佳实践 |
| Cloudflare AI Gateway | 文档 | 边缘AI Gateway设计 |
| Helicone | 文档 | 一行代码接入的LLM监控 |
深入阅读
| 资源 | 类型 | 说明 |
|---|---|---|
| Not All Tokens Are Equal | 论文 | Token级路由的学术基础 |
| GPTCache | 开源项目 | 语义缓存实现参考 |
| OpenAI Prompt Caching | 文档 | OpenAI原生Prompt Cache |
| Anthropic Prompt Caching | 文档 | Claude原生Prompt Cache |
| Martian Model Router | 文档 | 基于ML的模型路由方案 |
实操建议
今日实操任务:
1. 本地部署LiteLLM Proxy，配置2个模型的负载均衡
2. 用Helicone或LangFuse接入监控，观察Trace
3. 实现一个简单的Exact Match Cache (用Redis)
4. 跑10个相同请求，验证缓存命中和成本节省
明日预告
Day 17: Prompt管理与版本控制
Day 16搭建了LLM系统的"骨架"(Gateway/Router/Cache)
Day 17在骨架上加"智能"(Prompt管理)
Day 17 核心内容预览:
1. Prompt Engineering的工程化
→ 从"随手写Prompt"到"Prompt即代码"
→ Prompt模板引擎(变量/条件/循环)
2. Prompt版本控制
→ Git管理Prompt还是用专用平台？
→ Prompt的CI/CD: 自动测试+自动部署
3. Prompt A/B测试
→ 怎么设计LLM的A/B测试？
→ 评估指标: 质量分/延迟/成本/用户满意度
4. Prompt Registry (Prompt注册中心)
→ LangFuse/PromptLayer/Humanloop
→ 金融类比: 和配置中心(Apollo/Nacos)一样
5. 安全Prompt设计
→ 防注入(Prompt Injection)
→ 防越狱(Jailbreak)
→ 金融场景的Prompt安全清单
准备：
→ 回顾Day 4的Prompt Engineering基础
→ 思考: 如果一个金融客服的Prompt需要频繁调整，
怎么做到"改Prompt不改代码、改了不出错"？
今日总结
┌────────────────────────────────────────────────────────────────┐
│ Day 16 核心收获 │
├────────────────────────────────────────────────────────────────┤
│ │
│ 1. LLM应用分层架构: 6层(Gateway/Router/Cache/Prompt/Model/ │
│ Observe)，每层职责清晰，和银行核心系统架构高度类似 │
│ │
│ 2. AI Gateway: LiteLLM/Portkey统一多模型接口 │
│ → OpenAI兼容API是事实标准("AI领域的银联") │
│ → 鉴权/限流/安全过滤/Fallback 四大核心能力 │
│ │
│ 3. 智能路由: 按任务复杂度路由到不同模型 │
│ → 60%简单请求用小模型，成本降低60-80% │
│ → 级联路由: 先试便宜的，不行再升级 │
│ │
│ 4. 三层缓存: Exact Match → Semantic Cache → Prompt Cache │
│ → 语义缓存命中率30-60%，是最被低估的优化 │
│ → 三层叠加可省50%+的模型调用 │
│ │
│ 5. 流式响应: SSE是主流，TTFT是用户体验决定性指标 │
│ → Prompt Cache可降低TTFT 60-80% │
│ │
│ 6. 可观测性: LangFuse/Helicone做全链路Trace │
│ → Token/延迟/质量/成本四维监控 │
│ → 金融场景的审计日志是合规硬要求 │
│ │
│ 7. 成本控制: 路由+缓存+Prompt压缩+预算管理 │
│ → 实测可降低70%+成本，ROI极高 │
│ → Token预算 = 金融系统的交易限额管理 │
│ │
│ 新增面试题: #36 生产级LLM架构设计, #37 LLM成本控制 │
│ 学习耗时：约 6 小时 │
│ 下一步：Day 17 Prompt管理与版本控制 │
│ │
└────────────────────────────────────────────────────────────────┘