大模型应用部署运维要关注哪些工程问题？
简化版
大模型应用部署运维要关注容量、延迟、并发、限流、超时、重试、密钥管理、版本发布、日志脱敏、依赖降级和 SLA。即使用第三方模型 API，也要把它当作外部高成本、强依赖、可能波动的服务来治理。
详细版
- 容量规划要看 QPS、并发会话、平均 token、长尾 token 和流式连接时长。
- 限流要按用户、租户、模型、工具和预算多维度控制。
- 重试必须有退避和上限，避免供应商抖动时放大故障。
- 密钥和模型配置要走安全配置管理，不能写死在前端或日志里。
- 运维目标包括稳定性、成本、质量和合规，而不只是服务在线。
完整版教学
记忆钩子：用了外部模型 API 也不是“免运维”，只是把模型训练运维换成了应用可靠性运维。
一、这题真正考什么
记忆钩子：用了外部模型 API 也不是“免运维”，只是把模型训练运维换成了应用可靠性运维。
面试官真正想看的是你有没有生产工程视角：能不能把模型能力、业务流程、用户体验、成本和风险放在同一张图里思考。回答时不要只停留在工具名，而要讲出边界、链路和验收方式。
二、核心原理和工程边界
LLM 应用的运行时资源和传统接口不同：请求持续时间更长，输出 token 不确定，流式连接占用更久，模型供应商可能限流，工具调用又引入外部依赖。部署运维要围绕容量、依赖、发布和安全四条线设计。
LLMOps 的难点在于模型行为不是传统函数调用，输入稍变、模型版本稍变、上下文稍变，都可能让输出分布变化。因此工程系统必须把“可变的模型行为”包进“可管理的发布、监控和回滚流程”。
三、带数字的工程算例
假设峰值 200 QPS，平均请求持续 8 秒，服务端同时挂起连接约 1600 个。若每个请求还可能调用 2 个外部工具，线程池、连接池、队列和超时都要按峰值设计，否则模型没慢，应用自己先堵住。
这个算例的作用不是追求精确到小数，而是帮助你在面试中建立量级感。只要能估出 token、并发、延迟、成本或错误率的数量级，你的回答就会从概念题变成工程题。
并发连接数 ≈ QPS * 平均请求时长
容量余量 = 峰值需求 * 安全系数
SLA 失败 = 应用错误 + 模型错误 + 工具错误 + 网络错误四、典型链路怎么跑
可以把这类问题拆成下面的链路来理解：
流量进入网关
|
鉴权和限流
|
任务队列和并发控制
|
模型/工具调用
|
超时重试和降级
|
日志监控和告警
|
版本回滚链路图的价值在于暴露责任边界：哪一步做权限，哪一步算成本，哪一步可重试，哪一步必须审计。面试时能画出链路，通常就能自然回答故障排查和系统设计追问。
五、方案对比和选择标准
| 问题 | 传统接口 | LLM 应用 |
|---|---|---|
| 延迟 | 通常较短稳定 | 生成长度导致波动大 |
| 成本 | 机器资源为主 | token 和外部 API 显著 |
| 发布 | 代码版本为主 | prompt、模型、索引都算版本 |
| 安全 | 接口权限 | 还要防 prompt 注入和数据泄露 |
选择方案时要先说评估维度，再说取舍。LLMOps 面试很看重这种思维，因为真实系统没有银弹，只有在质量、成本、延迟、安全和维护成本之间做平衡。
六、上线后最容易出问题的地方
- 不要在前端暴露模型 API key，所有模型调用都应走服务端代理或网关。
- 重试没有幂等和退避时，故障时会同时放大成本和延迟。
- 只在少量 demo 上验证会低估风险，真实流量中的长尾输入、权限组合和外部依赖更复杂。
- 没有版本记录时，线上问题很难复现；prompt、模型、知识库、工具和配置都要纳入发布记录。
七、常见误区与追问
- 误区：调用云模型 API 就不用做容量规划。 要补充适用条件、失败模式和工程兜底，避免把局部经验讲成绝对规律。
- 误区：失败重试次数越多越可靠。 要补充适用条件、失败模式和工程兜底，避免把局部经验讲成绝对规律。
- 误区：只要服务 200 就代表用户体验正常。 要补充适用条件、失败模式和工程兜底，避免把局部经验讲成绝对规律。
- 追问：如何估算流式请求并发？ 先给判断标准，再从数据、链路、权限、监控或评测角度说明落地方案。
- 追问：模型供应商限流时如何降级？ 先给判断标准，再从数据、链路、权限、监控或评测角度说明落地方案。
- 追问：LLM 应用的 SLA 应包含哪些指标？ 先给判断标准，再从数据、链路、权限、监控或评测角度说明落地方案。
八、加强记忆
按“容量、限流、超时、重试、密钥、发布、监控”七项检查。LLM 应用部署的难点，是把长连接、高成本和不确定输出放进可靠系统里。
复习 LLMOps 题时，可以固定用“目标、链路、预算、风险、观测、回滚”六步组织答案。这样既能回答原理，也能自然延伸到生产系统设计。