Part VIII 部署与基础设施¶
本部分目标¶
Part VIII 讨论 Agent 平台从“能够运行”进入“能够稳定交付”以后必须建立的基础设施边界。四章形成一条连续生产链：GPU 调度负责把算力变成可承诺资源，模型服务负责把权重变成稳定 API，LLM 网关负责把模型调用变成受治理入口，GitOps/IaC 负责把这些状态变成可复现的生产环境。
这四层不能互相替代。GPU 还有空闲，不代表某个模型能立即扩容；模型 Service Ready，不代表当前租户有权调用；网关能够路由，不代表生产配置已经经过受控 Promotion。只有算力、服务、调用治理和交付证据同时成立，Agent 平台的基础设施才真正闭环。
本部分章节¶
| 章 | 主题 | 核心问题 |
|---|---|---|
| 第43章 GPU 调度与 Kubernetes | 节点池、队列、Gang、配额、弹性 | 高价值任务怎样按 SLO 获得 GPU |
| 第44章 模型部署 | KServe、Runtime、Revision、Canary、回滚 | 模型怎样变成稳定、可升级的 API |
| 第45章 LLM 网关与多租户 | 身份、路由、配额、fallback、缓存 | 每次模型调用怎样被统一治理 |
| 第46章 GitOps、IaC 与边缘推理 | Terraform、Helm、ArgoCD、Promotion、Edge OTA | 生产状态怎样可复现、可审计、可回退 |
四个贯穿全 Part 的生产承诺¶
算力承诺回答“这类任务能否在约定时间拿到合适 GPU”；模型服务承诺回答“上层是否只依赖稳定服务名和接口”；调用治理承诺回答“谁能调用什么模型、花多少、失败时怎么降级”；交付承诺回答“谁改了什么、何时进入哪个环境、如何恢复上一稳定状态”。
这四个承诺相互依赖。第43章的节点池容量会影响第44章的模型副本，第44章的服务健康会影响第45章的路由与 fallback，第45章的租户和模型策略最终由第46章进入生产。Part VII 的 Trace、成本和 SLO 则贯穿这条链路，为每一层提供运行证据。
阅读建议¶
架构师建议顺序阅读第43–46章，重点看职责边界和跨层契约。应用开发者可以重点读第44、45章，理解为什么业务代码不能直连 Pod 或供应商 API。平台负责人、SRE 与 FinOps 应重点关注第43、45、46章，因为 GPU 配额、模型路由和变更治理最终都会落到资源承诺、成本和业务连续性。
本部分的重点不是教读者堆一套 Kubernetes 工具链，而是说明算力、模型、入口和交付怎样组成一套可运营的生产系统。