第 11 章 — 平台与编排层

《LLM Primer VI: Scaling AI Systems》章节走读的第十一篇。这一章要说的是:平台的选择不是关于功能,而是关于哪一种运营模型贴合团队现有的 ops 文化。

这一章为什么存在

Engine 把一个模型包在一块 GPU 上,产 token。这就是它完整的岗位描述。一旦生产需要两个副本挂在负载均衡后、或者两个不同的 engine 在同一个 endpoint 下、或者一条 embed→retrieve→rerank→generate 流水线当一次逻辑调用、或者一份不让一个租户饿死另一个的配额系统、或者一个 autoscaler 随队列深度上升加副本,engine 就没答案了。第 11 章走 2026 年占主导做这份工作的四个平台 —— Ray Serve、KServe、BentoML、Triton Inference Server —— 并主张它们之间的选择是关于团队 ops 文化契合度的问题,不是功能问题。

11.1 Ray Serve 是 Python 优先;KServe 是 Kubernetes 优先

Ray Serve 是那种"如果我永远不用离开 Python 就能组合、扩展、部署一条模型流水线,一个 serving 框架会长成什么样"的答案。答案就是 Python 类当作 actor 用装饰器标记出来,用 Python 函数调用把它们连起来,由 Ray 运行时来复制、放置、autoscaling。Deployment 靠调用彼此的方法来组成流水线;流水线是 Python、可观测性是 Python、ops 故事也是 Python。当同一个集群本来就在跑 Ray 训练时,它就是自然选择。KServe 起点相反:Kubernetes 优先、供应商中立、声明式。KServe 的 InferenceService 是一份 CRD,捕获权重在哪儿、什么运行时提供服务、autoscaling 该怎么表现。平台通过 Knative 把 pod 接上做 scale-to-zero,通过 Istio 做流量路由,再暴露一个稳定的 HTTP endpoint。取舍是表达力 —— KServe 里流水线组合比 Ray Serve 更被 YAML 主导 —— 换来的是可移植性和标准化。

11.2 BentoML 做打包;Triton 给异构模型做批处理

BentoML 站第三种立场:平台的主要分工是把模型 + 代码 + 依赖变成一个一致的产物 —— 一份 Bento —— 并且把这份产物往任何地方(Kubernetes、Lambda、Cloud Run、裸 VM)部署变成一条命令。它对模型 serving 层的意思,相当于 Docker 镜像对一般应用的意思。写作体验是 FastAPI 形状的 Python;部署故事是"产物优先"那个动作。最贴合的场景是小 ops 摊子、以及想要从"Python 类"到"能到处跑的部署 endpoint"路径最短的团队。Triton Inference Server 是历史上在 NVIDIA 阵营 serving 里占主导的那种企业级动态批处理。它并肩托管 TensorFlow、PyTorch、ONNX、TensorRT、TensorRT-LLM、Python 后端,对非 LLM 工作负载(推荐、分类、embedding)应用它的动态 batcher,对 LLM 通过 TensorRT-LLM 后端应用 continuous batching 调度。最贴合的场景是异构工作负载或已经深度绑定 NVIDIA 的团队。

11.3 四种选择按 ops 文化契合度切开

四个平台切得很干净。重心是 Python 和 Ray → Ray Serve。重心是 Kubernetes、声明式清单、多云可移植、多租户隔离 → KServe。ops 摊子小、想要从类到 endpoint 路径最短 → BentoML。异构工作负载或 NVIDIA 优先的组织 → Triton。它们在组织层面并非互斥:大公司里常见的模式是 Triton 用于最高流量的生产 LLM、Ray Serve 用于组合多个模型调用的 RAG 和 agent 流水线、KServe 作为强制多租户的伞、BentoML 存在于开发者环境里。挑选时的一个有用练习是:列出团队绝对需要的三个运营性质和绝对可以没有的三个,然后按这份清单给平台排序。别去挑那种"什么都支持"的 —— 每一个平台把自己的核心做得好、外围做得差,核心和你的必需项重叠的那个就是团队日常运营会舒服的那个。

第 11 章为下面铺了什么

Engine 和平台的边界,在"复制单位就是一个 pod 拥有 GPU 节点上一个模型"时是干净的。一旦我们尊重第 1 章那个事实 —— prefill 和 decode 是互相冲突的工作负载 —— 那条边界就不再干净。第 12 章把它们拆到不同 GPU 池,靠网络交换 KV cache,并用 Kubernetes 原语来表达这次拆分 —— LeaderWorkerSet、Grove 的 PodCliqueSet、KAI Scheduler 的拓扑感知。平台层是让这次拆分可运营的东西;平台层也是让这次拆分本身可表达的原因。

下一章 — 第 12 章:拆分部署与 Kubernetes。把 prefill 和 decode 拆成不同类型的 pod,以及表达这次拆分的 Kubernetes 原语。