当 LLM 撑到千亿参数，谁来撑住它？——一份 45 页综述讲清楚「云原生 + 分布式」如何把大模型做稳、做大、做便宜

  • 关联论文：2604.17227

你有没有遇到过这种场景：

  • 千卡训练集群利用率掉了 10%，电费 + 折旧足以拖垮一个中型项目；
  • 高 QPS 在线服务、长上下文生成、批量离线打分三种负载在同一集群里互相打架；
  • Kubernetes、Serverless、Edge、专用加速器、向量库、KV Cache 引擎各自为政，缺统一参考架构。

这三件事，是 2026 年所有做大模型的公司每天都在踩的坑。

但奇怪的是——学术界没有人给出一份系统回答。

直到 arXiv 2604.17227 出现：20 位系统领域学者（Minxian Xu、Kejiang Ye、Chengzhong Xu、Rajkumar Buyya 等）联合署名、45 页、5 张图，把「如何用云原生与分布式系统把 LLM 训练与推理做稳、做大、做便宜」系统梳理了一遍，并给出未来 2-5 年的研究路线图。

换句话说：这是 LLM Infra 领域第一份真正「全景视图」级别的综述。

为什么这件事值得大众关注

大多数搞算法的人以为「模型大 = 算力猛 = 工程上自然而然就跑得快」。真相恰恰相反——LLM 训练与推理对算力、显存、带宽、存储都提出了传统单机系统完全无法承受的要求，业界被三件事反复绊倒：

  1. 资源成本失控：千卡级训练集群一旦利用率掉 10%，电费与折旧就足以拖垮一个中型项目。
  2. 推理时延与吞吐矛盾：高 QPS 在线服务、长上下文生成、批量离线打分，三种负载在同一集群里互相打架。
  3. 平台碎片化：Kubernetes、Serverless、Edge、专用加速器、向量库、KV Cache 引擎各自为政，缺统一参考架构。

更尴尬的是，过去几年业界一直在「修修补补」——给 vLLM 加 PagedAttention、给 K8s 加 Volcano、给推理服务加 HPA——但没人给出一张全景图把这些工作组织起来。

这篇综述的核心贡献就是：用「工作负载 × 云原生能力」的二维矩阵，把所有相关研究重新组织。

这篇论文核心讲了什么

一张统一的二维矩阵

论文的组织方式非常值得借鉴：

+-------------------+      +-------------------+      +-------------------+
|   LLM Workload    | ---> | Cloud-native Stack| ---> |  Research Agenda  |
|  (train/infer)    |      |  (K8s/Serverless) |      |  (Open Problems)  |
+-------------------+      +-------------------+      +-------------------+
         |                          |                          |
         v                          v                          v
   Data Pipeline            Resource Manager           Standardization
   (ingest/ETL/vec)        (sched/autoscale)         (cross-cloud/cross-org)

第一维：工作负载分层（7 类）

把 LLM 生命周期拆成 7 类，每一类给出典型资源画像（GPU 显存、显存带宽、网卡吞吐、存储 IOPS、容错等级）：

  • 数据预处理、预训练、微调、在线推理、批量推理、Agent 工具调用、多模态推理

第二维：云原生栈映射（5 层）

把容器编排、微服务、Service Mesh、Serverless、Autoscaling、FinOps 一一对应到上面的负载，给出参考部署模式：

  • 预训练：K8s + Volcano/Slack Operator + RDMA 网络拓扑感知调度 + Checkpoint 到对象存储
  • 在线推理：Knative / KServe + HPA + KV Cache 共享层 + 主动预热
  • Agent 工具调用：Function-as-a-Service + 会话亲和性 + 向量库旁路缓存
  • Edge 推理：Cloud-Edge 协同推理，模型分层卸载（front layer 在端、back layer 在云）

七个横切关注点

论文另外抽出 7 个「跨工作负载」的横切关注点，这是 LLM Infra 工程师每天要面对的具体决策：

横切关注点 关键问题
Data Management 异构存储、冷热分层、向量化数据通路
Resource Optimization 异构 GPU 池化、碎片整理、能耗感知调度
Microservices 推理服务拆分、sidecar 化、RAG 工具独立部署
Autoscaling 基于 QPS / 基于 KV Cache 利用率 / 基于排队延迟的策略
Serverless 冷启动、Burst 流量、GPU 池化粒度
Hybrid Cloud-Edge 模型切分、缓存预置、断网续算
Quantum & Emerging 量子辅助优化、原型阶段

一份未来 2-5 年的路线图

每章末尾都给出 3-5 条 open problems，这是研究生找课题最快的入口：

  1. 可观测性 + FinOps 一体化：把 token / GPU-hour / latency 一起入指标体系，按业务单元计费
  2. 跨云标准化：避开 vendor lock-in，KubeVirt 类技术让 VM 也能跑在 K8s 内
  3. Serverless GPU 池化：把 H100/A100 拆成 MIG slice 共享，进一步摊薄成本
  4. Green AI：能耗感知调度、PUE 优化、可再生电力调度
  5. Agent 时代的 Memory-aware Scheduling：考虑 KV Cache 亲和性、向量库命中率、会话复用

为什么这件事对 2026 年的 AI 工程至关重要

如果你是下面任一种角色，这篇综述几乎是必读：

  • Infra / 平台工程师：建立 LLM 平台的全景视图，避免技术选型遗漏
  • 系统方向研究生：找 open problem 最快的方式是读第 4 节路线图
  • 架构师 / 技术负责人：做技术选型、跨云规划、FinOps 决策时参考
  • Agent 平台建设者：关注 memory-aware scheduling，未来 agent 平台核心
  • 企业 CTO / VP Eng：向技术决策者汇报 LLM Infra 规划时，用论文的结构化框架增强说服力

它真正的价值不是「教你怎么部署」，而是「教你怎么想」——把零散的工程决策组织到同一张矩阵里，避免遗漏关键维度。

三处落地风险别踩

风险 1：综述 ≠ 参考实现

这是本文最重要的坑。综述给出的是设计空间框架（what to consider）和路线图方向（where to go），不是参考架构（how to implement）。例如「Serverless GPU 池化：把 H100/A100 拆成 MIG slice 共享」是一个方向性建议，不是可直接拿来用的 YAML。每个子方向的工程可行性必须单独论证。

风险 2：跨云 GPU 池化的网络拓扑依赖被低估

Serverless GPU 池化在跨 AZ（Availability Zone）场景下，RDMA/RoCE 网络带宽会显著低于单 AZ 内（跨 AZ 延迟通常 1-2ms，而单 AZ 内 NVLink/RoCE 可 <1μs），对大模型并行训练影响尤其大。论文把 MIG 切片共享列为降本路径，但没有强调 AZ 拓扑约束。工程建议：跨 AZ GPU 共享只适合批处理离线推理（延迟不敏感），在线推理服务的 GPU 池化应优先在单 AZ 内做 vertical 扩展。

风险 3：路线图的「2-5 年」时间线过于粗糙

不同子方向的成熟度差异极大——PagedAttention 已在生产广泛落地，而 Quantum AI 辅助优化仍处于原型阶段。把两者放在同一路线图上会给读者造成「它们同等接近」的错觉。不要按路线图顺序决定资源分配。

写在最后

这篇综述最有价值的，不是某一个具体技术，而是它给整个 LLM Infra 领域画了一张地图：

  • 7 类工作负载 × 5 层云原生栈——把所有相关研究放到同一坐标轴
  • 7 个横切关注点——给工程团队一份完整的选型 checklist
  • 1 份未来路线图——给研究者一份完整的研究议程

下次有人问你「我们到底应该用什么做 LLM 部署」，你只需要把对方的问题放到这张二维矩阵里——

「你的是什么工作负载？」 「你要的是在线推理还是离线批处理？」 「你能容忍跨 AZ 延迟吗？」 「你的成本敏感度是 token 级还是 GPU-hour 级？」

——四个问题就能让对方意识到自己遗漏了哪些维度。

LLM Infra 从 2026 年开始，不再是「各干各的」——而是有了同一张可对话的地图。

延伸阅读 - 论文：arXiv 2604.17227（Cloud-native and Distributed Systems for LLM：研究路线图，20 位作者，45 页） - 同方向工作：vLLM / SGLang（推理引擎代表）、Ray / KubeRay（分布式框架代表）、PagedAttention / FlashAttention（内核优化代表）、AIBrix / KServe / Anyscale（平台代表） - 工程起点：论文第 3 节「云原生栈映射」+ 第 4 节「研究路线图」是两份最值钱的清单 - 延伸阅读：KubeVirt + GitOps（跨云迁移路径）、MIG slice（Serverless GPU 池化路径）、Volcano + RDMA（千卡训练调度路径）

三个标题变体

  1. 当 LLM 撑到千亿参数，谁来撑住它？——一份 45 页综述讲清楚「云原生 + 分布式」如何把大模型做稳、做大、做便宜
  2. 20 位系统领域学者联合署名、45 页论文、5 张图：LLM Infra 领域第一份「全景视图」级别的研究路线图
  3. 别再各干各的了！这篇综述把 LLM Infra 的所有零散工作拉到同一张地图上：工作负载 × 云原生能力

小红书风格卡片文案（可直接发布）

🏗️ LLM 撑到千亿参数，谁来撑住它？

不是算法瓶颈 ⚠️，是基础设施瓶颈！

arXiv 2604.17227 给了答案 📄： 20 位系统领域学者（Minxian Xu、Kejiang Ye、Buyya 等） 45 页 + 5 张图 + 7 类工作负载 + 5 层云原生栈 ✨

画了一张二维矩阵地图 🗺️：

🔹 横轴（7 类工作负载）： - 数据预处理 / 预训练 / 微调 - 在线推理 / 批量推理 / Agent 工具调用 / 多模态推理

🔹 纵轴（5 层云原生栈）： - 容器编排 / 微服务 / Service Mesh - Serverless / Autoscaling / FinOps

关键洞察 💡：

  • 预训练：K8s + Volcano + RDMA + Checkpoint 到对象存储
  • 在线推理：Knative / KServe + HPA + KV Cache 共享层
  • Agent 工具调用：FaaS + 会话亲和性 + 向量库旁路缓存
  • Edge 推理：模型分层卸载（front 在端、back 在云）

7 个横切关注点 🛠️（LLM Infra 工程师必看）： 1️⃣ Data Management（异构存储 + 向量化数据通路） 2️⃣ Resource Optimization（异构 GPU 池化 + 能耗感知调度） 3️⃣ Microservices（推理服务拆分 + sidecar 化） 4️⃣ Autoscaling（QPS / KV Cache / 排队延迟 三种策略） 5️⃣ Serverless（冷启动 + GPU 池化粒度） 6️⃣ Hybrid Cloud-Edge（模型切分 + 缓存预置） 7️⃣ Quantum & Emerging（量子辅助优化）

未来 2-5 年路线图 🔮： - 可观测性 + FinOps 一体化 - 跨云标准化（KubeVirt） - Serverless GPU 池化（MIG slice） - Green AI（能耗感知调度） - Agent 时代的 Memory-aware Scheduling

工程落地点 🛠️：

1️⃣ 把矩阵当 checklist——评估内部 LLM 平台时按 7×5 矩阵过一遍，避免遗漏 2️⃣ FinOps 上车——把 GPU-hour / token / latency 放进同一块 Grafana 3️⃣ Serverless GPU 池化——MIG slice + 配额调度是降低单 token 成本的有效路径 4️⃣ 混合云-边缘——模型切分 + KV Cache 预置是 agent-on-device 的关键 5️⃣ 跨云迁移——KubeVirt + GitOps 可显著降低大集群迁移风险

⚠️ 必须警惕的边界： - 综述不提供参考实现，工程可行性必须独立论证 - KubeVirt 迁移涉及镜像容器化、网络策略、存储映射等多个隐藏复杂度 - 跨 AZ GPU 池化网络拓扑依赖被低估（延迟 1-2ms vs NVLink <1μs） - 矩阵给出的是方向性对应，无容量规划数字（要从 benchmark 报告找） - 路线图「2-5 年」时间线过于粗糙，不同子方向成熟度差异极大 - 2026H2 新动向（SGLang PD 分离、Speculative Decoding 大规模落地）覆盖不全

📎 论文 ID：2604.17227

💬 评论区聊聊：你做 LLM Infra 时最头疼的是哪一层？K8s 调度？推理优化？还是 FinOps？🤔