大模型应用部署运维要关注哪些工程问题？

简化版

大模型应用部署运维要关注容量、延迟、并发、限流、超时、重试、密钥管理、版本发布、日志脱敏、依赖降级和 SLA。即使用第三方模型 API，也要把它当作外部高成本、强依赖、可能波动的服务来治理。

详细版

• 容量规划要看 QPS、并发会话、平均 token、长尾 token 和流式连接时长。
• 限流要按用户、租户、模型、工具和预算多维度控制。
• 重试必须有退避和上限，避免供应商抖动时放大故障。
• 密钥和模型配置要走安全配置管理，不能写死在前端或日志里。
• 运维目标包括稳定性、成本、质量和合规，而不只是服务在线。

完整版教学

记忆钩子：用了外部模型 API 也不是“免运维”，只是把模型训练运维换成了应用可靠性运维。

一、这题真正考什么

记忆钩子：用了外部模型 API 也不是“免运维”，只是把模型训练运维换成了应用可靠性运维。

运行时治理要把模型供应商当作有配额、尾延迟和故障模式的外部依赖。容量估算使用到达率乘平均占用时间，并分别考虑非流式请求、长连接与工具阶段。

二、核心原理和工程边界

LLM 应用的运行时资源和传统接口不同：请求持续时间更长，输出 token 不确定，流式连接占用更久，模型供应商可能限流，工具调用又引入外部依赖。部署运维要围绕容量、依赖、发布和安全四条线设计。

容量模型必须把排队时间、连接存活时间和供应商配额分开计算，因为扩容应用实例并不能突破上游 RPM/TPM。发布单元也不只是镜像，还应绑定模型、Prompt、工具 schema 与限流配置，确保一次回滚能恢复完整行为。

三、带数字的工程算例

假设峰值 200 QPS，平均请求持续 8 秒，服务端同时挂起连接约 1600 个。若每个请求还可能调用 2 个外部工具，线程池、连接池、队列和超时都要按峰值设计，否则模型没慢，应用自己先堵住。

并发连接数 ≈ QPS * 平均请求时长
容量余量 = 峰值需求 * 安全系数
SLA 失败 = 应用错误 + 模型错误 + 工具错误 + 网络错误

四、典型链路怎么跑

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

流量进入网关
   |
鉴权和限流
   |
任务队列和并发控制
   |
模型/工具调用
   |
超时重试和降级
   |
日志监控和告警
   |
版本回滚

五、方案对比和选择标准

问题	传统接口	LLM 应用
延迟	通常较短稳定	生成长度导致波动大
成本	机器资源为主	token 和外部 API 显著
发布	代码版本为主	prompt、模型、索引都算版本
安全	接口权限	还要防 prompt 注入和数据泄露

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

• 不要在前端暴露模型 API key，所有模型调用都应走服务端代理或网关。

• 重试没有幂等和退避时，故障时会同时放大成本和延迟。

• 重试必须带全链路截止时间、指数退避和幂等键；超过预算后应降级而不是继续放大拥塞。

七、常见误区与追问

• 误区：调用云模型 API 就不用做容量规划。 仍受账号配额、并发连接、速率限制和下游连接池约束，突发流量会排队或被 429。
• 误区：失败重试次数越多越可靠。 无界重试会形成重试风暴并重复有副作用的工具调用，必须限定次数、总时限和幂等语义。
• 误区：只要服务 200 就代表用户体验正常。 空答案、截断、首 token 过慢和工具失败都可能以 200 返回，应监控语义成功与阶段延迟。
• 追问：如何估算流式请求并发？ 用请求到达率乘连接平均存活时间估算 Little 定律并发，再为 P95 输出长度和突发流量留余量。
• 追问：模型供应商限流时如何降级？ 先排队与限流，再路由兼容备用模型；必要时缩短非关键上下文或返回可解释的稍后重试。
• 追问：LLM 应用的 SLA 应包含哪些指标？ 至少包含可用率、TTFT、TPOT、端到端成功率、工具成功率、质量红线和成本上限。

八、加强记忆

按“容量、限流、超时、重试、密钥、发布、监控”七项检查。LLM 应用部署的难点，是把长连接、高成本和不确定输出放进可靠系统里。