算力与资源供给
获取 GPU 容量、节点池，以及与服务引擎保持兼容的驱动和 CUDA 栈。
AI推理指南
基础设施与运维
让模型持续对外提供服务所需的一切：平台组件、安全交付模型变更的运维规范、突发负载下的扩缩容、跨区域与跨云运行，以及把多个模型组合成一个产品。
推理基础设施包含什么
服务层
推理引擎，加上前置网关：鉴权、配额、路由、后端之间的故障转移。
编排与扩缩容
把模型调度到硬件上、自动扩缩容策略、在多个工作负载之间动态分配资源。
版本管理与模型注册表
哪个模型、哪份权重、哪版提示词和配置正运行在哪里；能回答这个问题，是安全变更的前提。
安全
对调用和模型产物的访问控制、提示词与输出的保护、谁改了什么的审计。
成本管理
按工作负载和按功能核算的服务成本；可用的杠杆是模型选择、硬件匹配、批处理、路由和扩缩容策略。
InferenceOps：安全交付模型变更
用对待代码部署同样的严格程度来对待模型部署的运维实践，并针对“失败表现为行为异常而不只是崩溃”的产物做了调整：
- 发布流水线： 标准化的部署流程，在流量进入之前完成发布前验证（质量回归套件、延迟与 token 速率检查）。
- 渐进式发布： 用灰度发布或蓝绿发布在真实流量上把候选版本与线上版本做对比，并把自动回滚接到对比结果上。
- 容错： 带预算的重试、超时、熔断和过载丢弃，让单个劣化的模型或服务商不至于引发连锁故障。
- 治理： 带生命周期状态、责任人、审计轨迹和合规元数据的注册表；从请求回溯到模型版本的部署可追溯性。
- 成本卫生： 闲置 GPU 检测与利用率复盘；没用上的预留容量是最无声的烧钱方式。
快速扩缩容与冷启动问题
推理流量是突发的，而 GPU 分钟数在两个方向上都很贵：过量预配浪费钱，预配不足则会丢请求。对 LLM 来说，弹性扩缩容比经典的自动扩缩容更难，原因有两个：
冷启动很慢
一个新副本要依次付出三笔开销：申请 GPU 实例、拉取庞大的容器镜像，以及把几十 GB 的权重从存储加载进显存。缓解手段针对每个阶段：预热池、镜像缓存与瘦身、把权重放在高速本地存储或并行流式加载。缩容到零能省下闲置成本，但会把完整的冷启动加到第一个请求头上；这要按工作负载逐个决定。
显而易见的指标会误导人
对于受 GPU 约束的服务，CPU 利用率说明不了什么；而上报的 GPU 利用率可能看起来很高，芯片却没干多少有用的活。应改用需求侧信号来扩缩容：队列深度、在途并发数和请求速率，并与引擎实际达到的批大小关联起来看。
分布式、多区域与多云
- 分布式推理 横跨两个尺度：把一个模型分片到多张 GPU 和多个节点上（张量并行、流水线并行和专家并行，见 服务优化），以及把一组副本分布到多个可用区和集群上，配合感知状态的调度、健康检查和故障恢复。
- 团队为什么走向多区域或多云： GPU 稀缺、不同服务商与区域之间的价格差异、用户延迟、故障转移、数据驻留法规（GDPR 这类约束会把部分数据钉死在特定司法辖区），以及避免被单一厂商锁定。
- 需要付出什么： 把模型产物复制到每个服务地点附近、具备容量感知与合规感知路由的全局负载均衡、自动故障转移，以及带按地点成本归因的统一可观测性。
- 账单： 跨区域流量要付出实打实的延迟和出网费用，每多接一朵云，运维面就成倍扩大。默认集中部署；只有有明确理由时才分散。
多模型流水线
生产环境中的功能很少只用一个模型。检索增强的回答会串起嵌入模型、检索器、通常还有重排序器、生成器和安全检查；文档 AI 会串起 OCR、版面分析、分类和摘要；多模态助手还要加上各模态的编码器。当各阶段对能力的要求不同、适配的硬件不同、扩缩容行为也不同时，把专用模型组合起来会胜过一个大一统模型。
- 拓扑结构：串行阶段、带合并的并行扇出，以及两者之间的条件路由。
- 各阶段独立扩缩容、独立放置；一个小分类器不需要和生成器同一档次的 GPU。
- 在整张图上明确分配延迟预算，并保持各阶段接口稳定；每个阶段的失败模式都必须可观测，否则排障就只能靠猜。
- 这与流水线并行（把一个模型拆成多个阶段）和智能体循环（由模型驱动的动态控制流）都不同；流水线的图是由应用固定下来的。
自建还是采购：如实核算成本
自建推理基础设施要承担一批很少出现在第一版预算里的成本：在稀缺市场上采购 GPU、手工搭建并调优的自动扩缩容与并发控制、平台自带但自建栈必须自己实现的优化功能（前缀缓存、分离式部署）、面向 GPU 的可观测性，以及引擎、框架和驱动版本必须同步推进的依赖跑步机。再加上应用层的胶水代码（前后处理、连接器、每个模型各自的流式输出与缓存行为），以及运转这一切所需的稀缺而昂贵的人才。把这笔持续的工程成本，与平台费用以及团队因此没能去做别的事的机会成本放在一起权衡；正确答案随规模而变，用量增长之后要重新评估。