面向高效可扩展大模型的云原生与分布式系统：一份研究路线图

关联论文：2604.17227
作者：flyP
更新：2026-07-08

一句话结论

本文是一份由 Minxian Xu、Kejiang Ye、Chengzhong Xu、Rajkumar Buyya 等 20 位系统领域学者联合署名的 45 页综述，系统盘点"如何用云原生与分布式系统把 LLM 训练与推理做稳、做大、做便宜"，并给出未来 2-5 年的研究路线图。

解决什么真问题

LLM 的训练与推理对算力、显存、带宽、存储都提出了传统单机系统无法承受的要求，业界被三件事反复绊倒：

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

论文没有再发一个新模型，而是把这些痛点按"云原生 + 分布式"视角重新组织成可对照的设计空间，让研究者、平台工程师、Infra 负责人能用同一张图讨论问题。

核心方法：研究路线图与分层方法论

论文采用经典的"问题域 → 技术栈 → 开放问题 → 路线图"四段式综述结构。整体可抽象为：

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

1. 工作负载分层

把 LLM 生命周期拆成：数据预处理、预训练、微调、在线推理、批量推理、Agent 工具调用、多模态推理七类；每一类给出典型资源画像（GPU 显存、显存带宽、网卡吞吐、存储 IOPS、容错等级）。

2. 云原生栈映射

把容器编排、微服务、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 在云)。

3. 关键技术横切

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

4. 研究路线图（论文原文要点）

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

关键实验与数据

本文是 survey / 研究路线图，没有单一 SOTA 数字，论文用 5 张图 + 45 页文字梳理对比表。要点式呈现：

引用 100+ 篇近三年 LLM + 分布式系统工作，涵盖 Megatron、DeepSpeed、vLLM、SGLang、Ray、KubeRay、KServe、Volcano 等代表性系统。
对 autoscaling、scheduling、serverless inference 三类问题分别给出 量化对比表：典型延迟、QPS、GPU 利用率范围。
讨论 KubeVirt 等技术时给出 真实生产案例（具体公司名以原文为准）。
用一个统一的"研究成熟度坐标"（横轴：研究热度，纵轴：工业落地深度）把 12 个子方向放到四象限。

原文未明确给出"在哪个标准 benchmark 上跑分"——综述类论文的价值在结构化与判断，不在单一 SOTA。

亮点

作者组合强：Buyya 团队 + 多位系统顶会资深作者，文献覆盖密度高。
视角统一：不堆砌论文，而是按"工作负载 × 云原生能力"二维矩阵组织。
路线图落地：每章末尾都给出 3-5 条 open problems，研究生可直接选课题。
涵盖新兴话题：Quantum、Federated、Edge、Serverless 一并讨论，避免"只谈 K8s"。
强调 FinOps 与 Green AI：把成本与能耗从工程问题升格为研究问题。

局限

概念性偏多，工程代码偏少：对 KubeVirt、Serverless GPU 池化只给出概念性建议，缺可直接复现的 YAML / Operator。
Agent 内存调度是新方向，论证略薄：对 KV Cache 跨节点共享、向量库命中感知调度的讨论仍以未来工作为主。
未深入模型并行拓扑：对 3D / 4D 并行、序列并行、专家并行的网络拓扑约束讨论有限。
缺统一基准：不同系统的对比口径不一致，工程上仍需自己跑分验证。
时间窗 2024-2026 中段，2026 下半年的新动向（如 SGLang PD 分离、Speculative Decoding 大规模落地）覆盖不全。

对工程落地的启发

平台选型：可以拿文中的"工作负载 → 云原生能力"矩阵做内部技术雷达。
FinOps 上车：把 GPU-hour、token、KV Cache 利用率放进同一块 Grafana，论文提供了指标分层思路。
Serverless GPU 池化：MIG 切片 + 配额调度是降低单 token 成本的有效路径。
混合云-边缘：模型切分 + KV Cache 预置是 agent-on-device 的关键。
跨云迁移：KubeVirt + GitOps 可显著降低大集群迁移风险。

与同方向工作的关系

与 vLLM / SGLang 类推理引擎互补：本文讨论"引擎之上"的服务化、调度、成本问题。
与 Ray / KubeRay 等分布式框架互补：本文给出云原生层最佳实践。
与 PagedAttention / FlashAttention 类内核优化互补：本文把它们当作"系统调度的输入信号"。
与 AIBrix、KServe、Anyscale 等平台互补：本文提供选择与组合依据。

适合谁读

Infra / 平台工程师：建立 LLM 平台的全景视图。
系统方向研究生：找 open problem 最快的方式是读第 4 节路线图。
架构师 / 技术负责人：做技术选型、跨云规划、FinOps 决策时参考。
Agent 平台建设者：关注第 4 章的 memory-aware scheduling，未来 agent 平台核心。

不确定处

文中引用的具体生产案例公司名与数字未在 abstract 给出，细节以正文为准。
"5 张图 + 45 页"为 arXiv 元信息，正文章节编号与具体图表内容以论文 HTML 版为准。
路线图中"2-5 年"为推断，原文未明确给出时间表。

工程落地与核查（Jay）

事实核查

声明	核查结论	备注
本文是 survey，无单一 SOTA 数字	✅ 正确，综述性质	不存在实验数字需要核查
引用 100+ 篇近三年工作	✅ 定性声明，合理	数量级核查需正文计数
涵盖 Megatron、DeepSpeed、vLLM、SGLang 等代表性系统	✅ 与摘要描述一致	不代表这些系统被深人分析
对 autoscaling、scheduling、serverless inference 给出量化对比表	✅ 综述框架描述	具体数字以正文为准
具体公司名 / 数字以正文为准	✅ 符合综述论文特征	abstract 确实不载具体公司名
"5 张图 + 45 页"为 arXiv 元信息	✅ 正确	正文章节编号以 HTML 版为准
路线图 "2-5 年" 为推断，原文未明确	✅ 正确	原文未声称精确时间线
2026H2 新动向（SGLang PD 分离、Speculative Decoding）覆盖不全	✅ 局限性正确描述	时间窗局限是综述固有局限

存疑项：所有量化对比表（autoscaling 典型延迟 / QPS / GPU 利用率范围）来自正文而非 abstract，解读者无法独立核实具体数字。若工程选型需要精确数字，必须查阅正文对应表格。

可读性精修

「研究成熟度坐标」被描述为「横轴研究热度、纵轴工业落地深度把 12 个子方向放到四象限」——这是对综述图的结构化解读，原文是否严格用四象限（每个象限有等宽坐标轴）来呈现，需对照正文插图确认；
「Agent 内存调度」在原文中被标注为「新方向，论证略薄」，解读将这一局限如实传达，无夸大；
「Memory-aware Scheduling」（考虑 KV Cache 亲和性、向量库命中率）被列为路线图第 5 点，是前瞻性描述而非已验证技术，工程团队不应将其视为当前可用方案；
论文的组织方式被描述为「工作负载 × 云原生能力二维矩阵」，实际正文是否严格按此矩阵排布需核实——但这一框架描述与论文标题和摘要一致，属于合理提炼。

工程落地关键坑

1. 综述 ≠ 参考实现，工程落地必须自行验证

这是本文最重要的坑。本文给出的是设计空间框架（what to consider）和路线图方向（where to go），不是参考架构（how to implement）。例如「Serverless GPU 池化：把 H100/A100 拆成 MIG slice 共享」是一个方向性建议，不是可直接拿来用的 YAML。具体实现需要自己评估 MIG 分片调度、GPU 内存隔离、CUDA 上下文切换开销等工程细节。工程建议：把本文当作技术雷达和议题清单，而不是解决方案集。每个子方向的工程可行性需要单独论证。

2. FinOps 指标分层框架需要定制化落地

论文提出把「token / GPU-hour / latency 放进同一块 Grafana」，这是一个原则性建议，但具体指标的采集方式、聚合粒度、可视化 dashboard 的实际 schema 需要自己设计。不同云厂商的计费模型差异很大（Reserved vs Spot vs On-demand），混在一起做统一 FinOps dashboard 的工作量可能被低估。工程建议：先用论文的指标分层思路做一个最小可行的三仪表板（GPU 利用率、Token 吞吐、每 Token 成本），验证ROI之后再扩展到完整 FinOps 体系。

3. KubeVirt 迁移方案的实际复杂度被低估

KubeVirt 让 VM 运行在 K8s 内，听起来可以避免重写，但实际迁移涉及：现有 VM 的镜像容器化、网络策略重新配置（K8s NetworkPolicy vs 传统安全组）、存储 PersistentVolumeClaim 映射、StatefulSet vs Deployment 选型。这些都不是「GitOps + KubeVirt 就能解决」的问题。工程建议：KubeVirt 迁移方案在评估阶段要先做 POC（选 3-5 个非关键 VM），确认迁移路径可行后再规划大规模迁移。

4. 跨云 GPU 池化的网络拓扑依赖被低估

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

5. "工作负载 → 云原生能力"映射矩阵的实操性有限

矩阵给出的是方向性对应（如「预训练 → K8s + Volcano + RDMA」），但没有给出容量规划数字（如千卡训练需要多少带宽、哪个 Kubernetes Operator 的调度效率最优）。工程建议：以本文的矩阵作为技术选型的 checklist，而不是容量规划的直接依据；容量数字要从具体系统的 benchmark 报告（如 vLLM / SGLang 的官方 benchmark）中找。

6. 路线图的「2-5 年」时间线过于粗糙

不同子方向的成熟度差异极大——例如 PagedAttention 已在生产广泛落地，而 Quantum AI 辅助优化仍处于原型阶段。把两者放在同一路线图上会给读者造成「它们同等接近」的错觉。工程建议：按本文的四象限（研究热度 × 落地深度）做自己的优先级排序，而非按路线图顺序决定资源分配。

实际系统怎么用

适合把本文作为参考的场景： - 建立 LLM 平台技术全景视图，避免技术选型遗漏 - 向技术决策者（CTO / VP Eng）汇报 LLM Infra 规划时，用论文的结构化框架增强说服力 - 系统方向研究生找 open problem，按路线图第 4 节逐条评估可行性 - Agent 平台建设者关注 memory-aware scheduling 的前沿动态

不适合直接落地的场景： - 需要可直接复现的 YAML / Helm Chart（本文不提供） - 需要精确容量规划数字（从 benchmark 报告而非综述中获取） - 需要评估某项技术的生产就绪状态（需要独立调研当前版本和社区成熟度） - 2026H2 后的最新进展（SGLang PD 分离、Speculative Decoding 大规模落地）——这部分是本文的时间盲区，需要单独追踪