一个生产级大模型应用通常怎么分层架构？

简化版

生产级大模型应用不能只有一个 prompt 和一次 API 调用，通常要分成入口层、编排层、模型网关、工具/RAG 层、状态存储、评测监控和安全治理层。这样才能把能力、成本、权限、质量和故障隔离开。

详细版

• 入口层负责鉴权、限流、参数校验和多端协议适配。
• 编排层负责 prompt 拼装、RAG、工具调用、多轮状态和降级策略。
• 模型网关负责多模型路由、重试、超时、成本统计和供应商隔离。
• 状态层保存会话、记忆、缓存、审计日志和业务上下文。
• LLMOps 的核心是把不可完全确定的模型能力纳入可观测、可评测、可回滚的工程体系。

完整版教学

记忆钩子：大模型应用不是“接口转发器”，而是“有模型参与的分布式业务系统”。

一、这题真正考什么

记忆钩子：大模型应用不是“接口转发器”，而是“有模型参与的分布式业务系统”。

生产级 LLM 应用至少分离入口鉴权、编排、模型网关、检索、工具执行、策略与观测。分层的目的不是画更多方框，而是让每个边界能独立限流、授权、版本化和回滚。

二、核心原理和工程边界

LLM 应用的复杂度来自两类不确定性：模型输出不确定，外部依赖不确定。分层架构的目的就是把这些不确定性分摊到不同模块里处理：入口层管用户和权限，编排层管任务流程，模型网关管模型选择，安全层管边界，监控层管质量反馈。

三、带数字的工程算例

假设一个客服助手每天 10 万次请求，平均每次 3000 input token、800 output token。如果没有模型网关，模型升级、限流、成本统计和故障切换都会散落在业务代码里；一旦供应商超时率从 1% 升到 8%，排查会非常困难。

请求总成本 = input_tokens * 输入单价 + output_tokens * 输出单价
可用性 = 1 - 失败请求数 / 总请求数
生产级链路 = API 入口 + 编排 + 模型网关 + 工具/RAG + 监控评测

四、典型链路怎么跑

可以把这类问题拆成下面的链路来理解：

用户/业务系统
    |
API 入口：鉴权、限流、参数校验
    |
编排层：Prompt、RAG、Tools、Memory
    |
模型网关：路由、重试、超时、成本
    |
后处理：格式校验、安全过滤、审计
    |
观测评测：日志、指标、Trace、反馈

五、方案对比和选择标准

层次	职责	常见失败
入口层	鉴权、限流、协议	越权、流量打爆
编排层	任务流和上下文	prompt 混乱、状态错
模型网关	模型访问和治理	重试风暴、成本失控
观测层	质量和稳定性闭环	线上问题不可解释

六、上线后最容易出问题的地方

• 把所有逻辑塞进一个 prompt，会让权限、成本和故障处理都失控。

• 模型供应商接口稳定不等于业务稳定，业务还要处理超时、降级和输出错误。

• 原始用户输入与检索内容都应标为不可信数据，不能跨过编排层直接获得工具执行权。

七、常见误区与追问

• 误区：大模型应用就是前端加一个聊天框。 真实链路还包含身份、状态、检索、工具、策略、监控和回滚，任一层失败都会影响结果。
• 误区：只要模型能力强，架构就可以简单。 强模型仍会超时、幻觉和被注入，系统必须管理外部状态、权限与副作用。
• 误区：模型网关只是转发 API。 网关还负责模型路由、配额、重试、版本、凭证隔离、统一观测和协议适配。
• 追问：为什么 LLM 应用需要单独的模型网关？ 它把供应商差异和凭证从业务层隔离，并集中实施限流、路由、降级与审计。
• 追问：如何设计一次请求的 trace？ 用同一 trace_id 串起 Prompt 版本、检索文档、工具调用、模型 usage、阶段耗时和最终反馈。
• 追问：模型升级应该放在哪一层控制？ 由网关或发布控制面按版本路由，业务只依赖能力契约，便于灰度和快速回滚。

八、加强记忆

按“入口、编排、模型、工具、状态、观测、安全”七个词记。面试时先画层次，再讲每层处理什么不确定性，最后用成本和故障例子落地。