AI System Design：生产级 LLM 应用架构

面试常问「设计一个 ChatGPT」，工作中更常遇到「把 LLM 接进我们产品并扛住流量」。两件事的内核是一样的：从一个 API 调用，长成一个系统。

这篇按模块讲清楚，一个像样的 LLM 应用架构都有哪些层。

一个最小可用的架构

用户
 → API 网关（鉴权、限流）
 → 应用层（编排逻辑）
    ├─ 缓存层（命中直接返回）
    ├─ 检索层（RAG：向量库 + 重排）
    ├─ 模型层（主模型 + 备用模型）
    └─ 后处理（过滤、格式化）
 → 监控 / 日志（贯穿全程）

下面逐层说为什么需要。

检索层（RAG）

如果应用要基于私有知识回答，就需要 RAG：把文档向量化存进向量库，查询时检索相关片段喂给模型。这一层的工程量经常被低估——分块策略、检索召回、重排，每一步都影响最终质量。框架选型可参考 LlamaIndex vs LangChain，向量库选型看 Qdrant vs Chroma。

缓存层

LLM 调用又慢又贵，缓存是性价比最高的优化。两种：

精确缓存：相同问题直接返回上次结果。

语义缓存：意思相近的问题也命中（用向量相似度判断）。

高频问题缓存命中率上去后，成本和延迟都能砍一大块。

模型层与降级

别死绑一个模型。设计成可切换的网关，主模型挂了能自动切备用。这部分单独成篇讲过，见 LLM Fallback 降级策略。

成本上还有个常用技巧：模型分级路由——简单问题走便宜的小模型，复杂问题才上 GPT-4o 这种贵的。能省不少钱。

限流与并发

LLM API 有速率限制，你的应用也得有。否则一波流量进来，要么把你自己的额度打爆，要么把下游模型打到 429。网关层做令牌桶限流，超出的排队或快速失败。

后处理

模型输出不能直接信：

安全过滤：防注入、防有害输出，见 AI 安全防御。

格式校验：要 JSON 就校验是不是合法 JSON，不对就重试或修复。

敏感信息脱敏：输出里别带出不该有的数据。

监控（最容易省略，最不该省略）

每次调用记录：延迟、token、成本、命中的模型、用户反馈。没有这些，线上质量下滑你根本无感。LLM 应用的监控维度和传统服务不同，详见 LangSmith vs Langfuse。

面试 / 设计时的取舍点

被问到设计题，体现深度的是这些权衡：

维度取舍

延迟 vs 质量流式输出改善体感；小模型快但差 成本 vs 质量分级路由、缓存压成本 实时 vs 准确RAG 实时检索 vs 预计算 自建 vs API数据敏感自托管，否则用 API 省心

小结

LLM 应用架构的核心，不是「怎么调模型」，是「怎么在质量、成本、延迟、可靠性之间做平衡」。检索、缓存、降级、限流、监控——这几层搭齐了，你才有一个能上生产的系统，而不只是一个 demo。