網易游戲 Tmax 平臺實踐：基于 Fluid 的云原生 AI 大模型推理加速架構

作者 | 廖海峰，張翔

背景：游戲行業智能化浪潮下的

基礎設施不斷演進

作為中國領先的游戲研發與運營公司，網易游戲旗下擁有《夢幻西游》《大話西游》《蛋仔派對》等國民級游戲產品，以及游戲資產交易平臺“藏寶閣”等重要服務生態。隨著游戲產品矩陣的不斷擴大和用戶體驗需求的持續升級，網易游戲需要處理的數據類型和業務場景日益復雜多樣。

而大模型正深刻改變游戲行業。在 NPC 智能化、自動化劇情生成、角色動作捕捉及游戲資產生成等場景，特別是 RPG 與社交類游戲中，大模型已成為核心競爭力。為了更好地通過生成式 AI 支持業務發展，網易游戲打造了面向云原生的Tmax AI 機器學習平臺，提供靈活的資源調度、高效的 AI 開發效率與易托管的 AI 服務。

Tmax 平臺構建于 Kubernetes 之上，整合了 Kubeflow、自研調度器及 CubeFS 文件管理系統，支持從 Jupyter 交互式開發到分布式訓練、再到模型推理部署的全鏈路 AI 生命周期管理。然而，隨著大模型推理業務規模爆發，平臺在資源彈性、數據訪問效率與多地域協同方面面臨嚴峻挑戰。

挑戰：大模型推理服務的

“不可能三角”

在構建推理服務時，我們面臨著成本、效率與彈性的多重制約：

1. GPU 資源的稀缺性與異構性

受限于供應鏈，高端 GPU 資源稀缺且價格昂貴，且存量資源卡型復雜（異構混部）。這要求平臺必須實現分鐘級彈性伸縮，絕不能按業務峰值長期空置資源。

2. 業務峰值差異導致的資源浪費

不同游戲業務的推理負載呈現顯著差異：

• 時段分布不均：不同游戲業務的流量高峰分布在一天中的不同時段（如晚間游戲高峰、白天辦公工具使用高峰）

• 資源需求異構：實時推理、批量處理、模型微調等場景對 GPU 類型、顯存、網絡的要求各不相同

• 按峰值預留的低效性：為每個業務單獨預留峰值資源會導致整體利用率低下，資源浪費顯著

按峰值疊加滿足所有業務將導致資源浪費率高達 60% 以上。

3. Serverless 冷啟動的致命延遲

雖然阿里云 ACS Serverless 容器理論上能解決彈性問題，但大模型加載成為致命瓶頸。從遠程存儲拉取一個 70B 模型（約 140GB+）到 GPU 顯存通常耗時 10-15 分鐘，這完全抵消了 Serverless 的彈性優勢。

4. 多地域存儲管理復雜度和計算資源的碎片化

• 跨地域管理難題：GPU 資源分布在多個地域，但模型數據需要高效同步和統一管理。

• 存儲性能瓶頸：大模型文件（通常 70-500GB）從遠端存儲加載到 GPU 節點速度慢，成為推理延遲的主要因素。

• 多環境運行時支持：需要同時管理 IDC 物理機、云上 ECS 實例和 Serverless 容器服務等多種計算資源中的存儲訪問。要求存儲抽象必須具備跨集群、跨云廠商的一致訪問接口。

方案選型：為何選擇

Fluid+AlluxioRuntime？

針對大模型推理的多地域部署的緩存加速需求，直覺上直接部署 Alluxio 集群比較簡單。在技術選型過程中，我們深入評估了直接使用 Alluxio 與基于 Fluid 構建完整解決方案兩種路徑。

二者抽象層級與架構定位的根本差異

· Alluxio：本質是分布式緩存引擎，提供內存級數據訪問能力，核心價值在于作為計算與存儲間的虛擬化層，提供統一命名空間與緩存加速。

· Fluid：是基于 Kubernetes 及 Alluxio 等底層系統的云原生數據編排平臺，以數據集為中心進行抽象，深度集成于 Kubernetes 生態。

這種抽象層級的差異決定了二者解決不同層次的問題。

最終我們選擇 Fluid 而非直接使用 Alluxio，是基于以下多個維度的綜合考量：

選擇 Fluid 的綜合考量：

分析結論

對于我們的大模型推理場景，選擇 Fluid 而非直接使用 Alluxio，是基于以下核心判斷：

1. 抽象匹配：Fluid 的"數據集"抽象更貼近 AI 應用的數據使用模式，而 Alluxio 的"文件系統"抽象更底層。

2. 運維簡化：封裝 Alluxio 的運維復雜性，提供了 Kubernetes 原生的管理體驗。

3. 場景優化：針對 AI/ML 場景進行了專門優化，直接解決了大模型加載的關鍵痛點。

4. 生態集成：作為 CNCF 孵化項目，Fluid 與云原生生態的集成深度和未來兼容性更好。

5. 長期投資：多 Runtime 架構避免了對單一技術的依賴，為未來技術演進留出空間。

落地實踐：聲明式數據基礎設施

基于 Fluid 的云原生抽象能力，我們構建了“計算 - 緩存 - 存儲”三層解耦架構：

1. 底層存儲：CubeFS/OSS 存儲原始模型權重。

2. 加速層：Fluid + AlluxioRuntime 構建分布式緩存層，跨地域提供統一訪問接口。

3. 計算層：Kubernetes 集群（含 Serverless 容器）運行推理服務，通過 PVC 掛載數據。

架構設計

關鍵配置實踐

1. 自動預熱機制

針對 DeepSeek-R1 等超大模型，啟用了 Fluid 的應用預取功能，大幅縮短冷啟動時間。

  file-prefetcher.fluid.io/file-list: "pvc://llm-model/"

2. 智能彈性：GitOps 與定時伸縮

針對游戲業務明顯的早晚高峰特征，我們結合CronHorizontalPodAutoscaler與 FluidDataLoad實現了全自動化的“潮汐式”管理：

• 高峰前：自動擴容緩存節點，并觸發模型數據預熱。

• 低峰后：自動縮容緩存節點，釋放資源。

     targetSize: 20

使用定時預熱

  - path: /path/to/warmup # 指定了需要預熱的后端存儲系統路徑。

3. 跨 namespace 的緩存共享

在 Tmax 平臺中，存在“公共模型倉庫”與“多業務項目組”并存的場景。如果每個項目組（Namespace）都單獨部署一套 Dataset 和 Runtime，將導致：

1. 存儲冗余：同一個 DeepSeek-V3 模型在集群中被重復緩存多次。

2. 內存浪費：多套分布式緩存系統占用大量內存資源。

3. 管理混亂：模型版本更新需要通知所有項目組手動同步。

Fluid 提供了跨 Namespace 共享（Cross-Namespace Referencing） 能力，完美解決了這一痛點。

• Model-Hub Namespace：由平臺管理員維護，部署AlluxioRuntime和Dataset負責對接底層存儲并進行數據預熱。

• Game-Project Namespace：分配給各游戲項目組，無需部署 Runtime，只需創建一個引用型的 Dataset 指向 Hub 中的數據集

管理員在public-services命名空間發布模型：

      name: model-root

授權業務組在game-team-a命名空間引用：

    name: deepseek-mount

收益

• 一次預熱，全員加速：模型只需在公共空間加載一次，所有授權的業務組即可通過本地網絡訪問，無需重復下載。

• 資源節省：緩存層內存占用降低 60%-80%（取決于共享比例）。

• 極速啟動：新開服的游戲業務無需等待模型下載，直接掛載公共緩存，實現秒級啟動。

性能與成本收益

經過超過一年的生產環境運行，Fluid + AlluxioRuntime 的組合不僅解決了技術層面的 I/O 瓶頸，更為網易游戲帶來了顯著的業務價值。以下是我們在性能加速、成本節約、高并發穩定性等方面的具體收益細節：

1. 性能維度：12 倍啟動加速，讓 Serverless 真正落地

在大模型 Serverless 彈性場景中，“冷啟動速度”直接決定了方案的可行性。

• 加載耗時大幅縮短：以 DeepSeek V3/R1 等大參數模型為例，通過對比實測：

• • 基線（跨地域直連 CubeFS）：受限于網絡帶寬與長鏈路延遲，平均耗時 36 分鐘。

  • 優化一階段（傳統 Alluxio）：部署緩存后縮短至 14 分鐘，但仍受限于元數據同步和預熱效率。

  • 優化二階段（Fluid 智能預讀）：開啟 AI 應用預讀，耗時驟降至 3 分鐘。

• 收益：12 倍的性能提升，使得原本因“啟動太慢”而無法使用的 Serverless 算力資源重新具備了生產可用性

2. 成本維度：TCO 顯著降低，消除“資源碎片”

通過 Fluid 的編排能力，我們成功打破了 GPU 資源與存儲資源的高昂綁定關系。

• 存儲成本降低顯著：得益于 跨 Namespace 數據共享機制，原本散落在不同項目組的相同基礎模型（Base Model）無需重復存儲和緩存。單份緩存數據支撐了上百個推理 Pod 的運行，大幅削減了分布式緩存集群的內存開銷。

• GPU 利用率提升：通過“潮汐式”自動伸縮，我們不再需要按照業務最高峰值（Peak）常駐昂貴的 GPU 實例。配合 3 分鐘極速啟動，業務可以在低谷期安全地將 GPU 資源縮容至極低水位，整體 GPU 資源閑置率降低了約 20%。

3. 穩定性維度：化解“驚群效應”，保障高并發

在游戲版本更新或活動期間，會有數百個推理服務實例同時啟動（并發拉起）。

• 保護底層存儲：若數百個 Pod 同時直接訪問底層的對象存儲（OSS/S3），極易觸發帶寬限流或存儲服務過載（Thundering Herd Problem）。Fluid 充當了巨大的流量“擋板”，所有高并發請求均由本地緩存層響應，徹底消除了底層存儲的 I/O 抖動風險。

• 推理吞吐穩定：本地化的數據訪問將 I/O 延遲從毫秒級（ms）降低至微秒級（μs），確保了 GPU 不會因為等待數據而空轉，保障了推理服務的 P99 延遲穩定性。

4. 效率維度：算法團隊的“零感知”體驗

對于算法工程師而言，基礎設施的復雜度被完全透明化。

• 接口統一：無論底層是 S3、HDFS 還是 CubeFS，算法工程師只需像操作本地文件一樣操作 PVC 掛載目錄，無需在代碼中引入復雜的 SDK。

• 環境一致性：從開發環境（Jupyter Notebook）到生產環境（Serverless Deployment），使用同一套 Dataset 定義，消除了“開發能跑，上線報錯”的環境差異問題。

結 語

網易游戲通過 Fluid 的實踐，成功構建了高效、彈性、成本優化的大模型推理數據基礎設施。這一實踐不僅解決了 GPU 資源緊張、業務峰值差異、彈性伸縮困難等迫切問題，更為游戲行業探索 AI 原生體驗提供了可靠的基礎支撐。

在游戲行業與 AI 技術深度融合的今天，基礎設施的現代化已成為創新的基石。Fluid 作為云原生數據編排的優秀代表，其在網易游戲的成功應用，為整個行業提供了可借鑒的范例。未來，隨著技術的不斷演進和場景的持續拓展，“以數據為中心”的架構設計已成為企業降本增效、構建競爭力的關鍵路徑，推動游戲行業進入一個更加智能、個性化和沉浸式的新時代。

最后，特別感謝 Fluid 社區的徐之浩、玖宇和顧榮老師。正是因為有這樣負責任的維護者和快速的社區響應，才使得我們的技術探索之路更加平坦，讓云原生 AI 架構在網易游戲順利落地。

作者簡介

廖海峰 (Senior Infrastructure Engineer)：負責網易互娛 AI 基礎設施平臺的算力基礎設施構建和穩定性保障，致力于為大規模游戲 AI 業務提供堅實的算力底座與服務支撐。

張　翔 (Head of AI Infrastructure)：負責網易互娛 AI 基礎設施平臺的技術演進與架構設計，致力于構建高性能、高可用、低成本的 AI 基礎設施平臺。

會議推薦

2026，AI 正在以更工程化的方式深度融入軟件生產，Agentic AI 的探索也將從局部試點邁向體系化工程建設！

QCon 北京 2026 已正式啟動，本屆大會以“Agentic AI 時代的軟件工程重塑”為核心主線，推動技術探索從「AI For What」真正落地到可持續的「Value From AI」。從前沿技術雷達、架構設計與數據底座、效能與成本、產品與交互、可信落地、研發組織進化六大維度，系統性展開深度探索。開往 2026 的 Agentic AI 專列即將啟程！匯聚頂尖專家實戰分享，把 AI 能力一次夯到位！

今日薦文

你也「在看」嗎？