网易游戏如何在Kubernetes上实现30秒的大语言模型冷启动

来源: Cloud Native Computing Foundation
作者: 廖海峰，网易游戏高级基础设施工程师 和 张翔，网易游戏AI基础设施负责人
发布时间: 2026/5/21 19:00:00
原文链接: https://www.cncf.io/blog/2026/05/21/how-netease-games-achieved-30-second-llm-cold-starts-on-kubernetes/

---

发布于2026年5月21日，作者：NetEase Games（网易游戏）高级基础设施工程师 Haifeng Liao 与 网易游戏 AI 基础设施负责人 Xiang Zhang

本文重点介绍的 CNCF 项目

](https://www.cncf.io/projects/kubernetes “Go to Kubernetes”)

在网易游戏，我们通过生产环境中的大语言模型（LLM）推理学到了一个惨痛教训：弹性计算只有在数据能同样快速移动时才有用。

“弹性计算只有在数据能同样快速移动时才有用。”

从纸面上看，无服务器 GPU 基础设施似乎非常适合推理工作负载。游戏流量具有突发性，各游戏标题和一天中不同时段的峰值各异，为每一个可能的峰值预留 GPU 容量成本高昂。但当我们开始跨区域扩展 LLM 服务时，另一个瓶颈出现了。真正的问题不在于调度容器，而在于加载模型数据。

对于 70B 类模型，从远程存储将数百 GB 的权重拉取到推理节点可能需要数十分钟。这抹杀了自动扩缩的价值。在一个典型工作负载中，模型加载时间从跨区域直连存储访问时的 42 分钟，缩短到基于传统 Alluxio 缓存时的 14 分钟，再到我们启用 Fluid 的预取工作流后的 3 分钟。这一差异将无服务器推理从架构构想变成了我们可以实际运行的东西。

我们的 AI 平台 Tmax 运行在 Kubernetes 之上，支持完整的机器学习生命周期，从基于 Notebook 的开发到训练和推理部署。随着游戏相关场景（包括智能 NPC、内容生成和内部 AI 服务）中 LLM 使用量的增长，三个运维问题变得紧密关联。

首先，GPU 资源稀缺且异构。不同的工作负载需要不同的显卡类型、内存大小和扩缩模式。为满足每个团队的高峰需求而保持足够的 GPU 容量在线是低效的。

其次，推理流量并不均匀。某些游戏标题在晚上达到峰值，其他则在白天。一些工作负载是对延迟敏感的在线推理；其他则是批处理作业或微调任务。静态配置导致了利用率下降和浪费增加。

第三，无服务器冷启动被模型加载所主导。即使计算资源快速可用，模型的数据路径仍然很慢。结果是系统成本高昂，仍然无法及时响应流量峰值。

这就是“Day 2”运维变得有趣的地方。问题不再是“如何部署推理服务”，而是“如何跨区域和命名空间长期保持模型访问的快速、一致和可管理”。

为什么我们不直接运行 Alluxio

我们需要的是 Kubernetes 原生的方式来定义数据集、预热它们、挂载到工作负载中，并在命名空间之间安全共享。同时还需要运行时层能够与应用程序行为同步扩展。

这种更高层次的抽象是选择 Fluid（云原生计算基金会 CNCF 孵化项目）的主要原因。使用 Fluid，运维单元不再只是一个缓存集群，而是一个数据集和运行时。这种配置更符合平台团队实际管理模型服务基础设施的方式。

Fluid：为 Alluxio 添加操作性控制

维度

直接运行 Alluxio 面临的挑战

Fluid 增加的功能

与 Kubernetes 集成

Alluxio Master 和 Worker 集群必须单独部署和管理，与 Kubernetes 原生的生命周期和调度行为对齐程度有限。

Fluid 实现了运行时自动化部署和生命周期管理，通过 HPA/KEDA 等机制支持缓存弹性，并通过数据感知调度更容易地将计算放置与缓存数据对齐。

LLM 推理特定优化

通用缓存改善了访问时间，但加载大模型仍需自定义预热逻辑和额外的运维工作。

Fluid 提供了预取工作流，支持定时、事件驱动和主动预热。它还让我们能够针对特定框架的访问行为进行优化，包括 vLLM 和 SGLang 风格的模型加载模式，并在部署后适当时缩小缓存。

数据抽象与运行时解耦

直接部署模型使运维更紧密地绑定到单个缓存实现，增加了长期演进的难度。

Fluid 将数据集抽象与运行时层分离。这让我们能够保持稳定的运维模型，同时保留随时间切换运行时的选项，例如 Alluxio、JindoCache 或 JuiceFS。

跨团队隔离与共享

多团队共享需要更多手动命名空间、配额和配置设计，尤其是在必须安全复用通用基础模型时。

Fluid 支持数据集级别的逻辑隔离和跨命名空间共享，访问控制与原生 Kubernetes 机制对齐。

支持异构计算环境

在不同环境（如 Serverless 容器）中部署和管理相同的数据访问模型更加困难，通常需要额外的集成工作。

Fluid 同时支持基于 CSI 和 Sidecar 的访问模式。基于 Webhook 的 Sidecar 注入减少了跨环境使用相同模型加载路径时所需的应用程序端更改量。

此外，Fluid 还让我们更容易实现以下几种常见模式：

• 启动前预取，使推理 Pod 在运行时无需承担完全的冷启动代价。
• 调度扩容和预热，适用于具有可预测流量窗口的工作负载。
• 跨命名空间模型共享，通用基础模型无需被每个团队重复缓存。

最后一点的实际影响超出了我们的预期。在多租户平台中，重复缓存同一模型会浪费内存并产生版本管理开销。Fluid 让我们能够在单个命名空间中维护共享模型，并通过引用而非重复运行时堆栈的方式将其暴露给应用团队。

生产环境中的变化

结果并非小幅调优改进，而是从根本上改变了弹性推理在实践中的可行性。

在早期的基准测试路径中，模型加载时间从跨区域直连的 42 分钟，缩短到使用传统缓存层的 14 分钟，再到启用基于 Fluid 的预取后的 3 分钟。经过进一步的生产调优，两个模型推理服务的启动时间缩减至约一分钟，某些情况下甚至低于 30 秒。

延迟的大幅降低带来了相应的成本缩减，使我们在低谷期能更激进地扩展 GPU 资源。

缓存共享模式也减少了浪费。过去每个命名空间需要分别缓存相同的基础模型，现在我们只需预热一次，就可让多个服务共用。这降低了缓存内存开销，并简化了平台团队的运维工作。

同样重要的是，分布式缓存帮助吸收了启动突发流量。当大量推理 Pod 同时启动时，平台不再把全部压力直接推给后端存储路径。

一种实用的选择框架

对我们而言，比较的焦点并不是 “Fluid 与 Alluxio 作为竞品” 之间的取舍，而是在解决一个窄领域问题与解决运维问题之间的选择。

如果需求只是在远程存储前方加一个缓存，直接运行 Alluxio 可能就够了。如果需求是在 Kubernetes 上长期运行大语言模型推理——包括预加载、共享、自动扩缩和多租户控制——那么更高层级的数据编排模型就显得至关重要。

“问题从来不只是模型文件存放在哪里。真正的挑战是如何让它们快速、可预测且经济地用于生产推理。”

这在我们案例中体现出了差别。问题从来不只是模型文件存放在哪里。真正的挑战是如何让它们快速、可预测且经济地用于生产推理。