外观
LLM应用架构设计：从API调用到生产级AI应用的7个关键决策
把一个 LLM 应用从 Demo 推到生产，中间隔着的不是模型调参，而是一整层工程架构。Demo 阶段「一行 API 调用搞定一切」的写法，上线后会以各种姿势翻车：某模型供应商抖动半小时，全站功能瘫痪；用户并发一上来，账单超出预算三倍；出了坏回答，日志里只有一句模糊的 prompt，完全无法复盘。这篇文章梳理从 API 调用到生产级 AI 应用的关键架构决策。
第一道分水岭：别让业务直连模型
生产架构的第一个决策是在业务代码与模型之间加一层 AI 网关（或自建 Model Service 层），统一收口所有模型调用。这层承担四件事：多供应商路由（主模型超时自动切备模型）、密钥与配额管理、请求日志埋点、以及按业务方的限流。业务代码只面对内部接口，模型可换、策略可调：
typescript
// 业务侧只依赖内部 service，不感知具体供应商
const result = await modelService.chat({
scene: "order-summary", // 场景标识：路由/限流/计费都按场景维度
messages,
fallback: ["gpt-main", "glm-backup"] // 主备模型依次降级
});scene 这个看似不起眼的字段，是后续成本核算与质量分析的锚点——没有场景标识的调用日志，在排查时几乎等于废纸。
上下文组装：提示词的版本管理
生产环境的提示词不是一段文案，而是由系统提示、业务上下文（用户信息、RAG 片段）、历史对话三部分动态拼装的。架构上要做两个决定：其一，提示词模板入配置中心或独立仓库，支持版本化与灰度，改提示词和改代码走同样的评审流程；其二，上下文组装独立成模块，带 token 预算控制——历史对话超限时按策略裁剪（保首轮结论 + 最近 N 轮），而不是简单截断导致前后矛盾。
流式输出：体验问题本质是架构问题
长回答不做流式，用户面对白屏十几秒就会流失。生产级做法是全链路流式：模型侧用 SSE 流式接口，服务端透传 token 流，前端逐字渲染。容易忽略的是流式场景下的错误处理——输出到一半才失败，不能假装无事发生，至少要向用户输出「生成中断」的明确提示，并支持一键重试。
typescript
// 服务端：流式透传 + 异常时的显式中止事件
const stream = await modelService.chatStream({ scene: "chat", messages });
for await (const chunk of stream) {
res.write(`data: ${JSON.stringify(chunk)}\n\n`);
}
res.write("data: {\"type\":\"done\"}\n\n"); // 结束标记必须显式可观测性：三件套缺一不可
LLM 应用的可观测性有三件套：调用日志（场景、模型、token 数、耗时、结果摘要）、质量抽评（每日抽样人工或用强模型评审弱模型的输出打分）、坏例回流（用户点踩的内容自动入库，成为回归测试集）。三者合起来回答两个问题：钱花在哪了、质量坏在哪了。缺了任何一件，迭代都只能靠感觉。
成本与降级：预算前置的设计
成本控制要在架构期做三件事：按场景设 token 预算与限流（聊天场景限单次输入 4k token）；分级用模——摘要、分类这类简单任务用小模型，复杂推理才走旗舰模型，成本常见能降一个数量级；缓存生效——确定性任务（固定文档的摘要）按输入哈希缓存结果。降级预案同样前置：模型全面不可用时，功能是「静默降级为传统规则实现」还是「明确告知暂不可用」，要在设计期选好，不要等到故障时拍脑袋。
实践清单
- 模型调用全部收口到网关层，业务代码不感知供应商。
- 所有调用带场景标识，日志、限流、计费都按场景管理。
- 提示词模板版本化，上下文组装独立模块并带 token 预算。
- 长文本任务全链路流式，异常时输出显式中止事件。
- 可观测性三件套（日志、抽评、坏例回流）先于功能上线。
- 分级用模 + 缓存 + 降级预案，成本与可用性设计前置。
从 API 调用到生产级应用，本质是把「对模型的单次请求」升级为「对不确定性的系统化管理」。模型能力会持续升值，但这套架构层的功力，才是 AI 应用工程师的护城河。
免责声明
本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。