作者 | 廖海峰，張翔

背景：游戲行業(yè)智能化浪潮下的

基礎(chǔ)設(shè)施不斷演進(jìn)

作為中國(guó)領(lǐng)先的游戲研發(fā)與運(yùn)營(yíng)公司，網(wǎng)易游戲旗下?lián)碛小秹?mèng)幻西游》《大話西游》《蛋仔派對(duì)》等國(guó)民級(jí)游戲產(chǎn)品，以及游戲資產(chǎn)交易平臺(tái)“藏寶閣”等重要服務(wù)生態(tài)。隨著游戲產(chǎn)品矩陣的不斷擴(kuò)大和用戶體驗(yàn)需求的持續(xù)升級(jí)，網(wǎng)易游戲需要處理的數(shù)據(jù)類型和業(yè)務(wù)場(chǎng)景日益復(fù)雜多樣。

而大模型正深刻改變游戲行業(yè)。在 NPC 智能化、自動(dòng)化劇情生成、角色動(dòng)作捕捉及游戲資產(chǎn)生成等場(chǎng)景，特別是 RPG 與社交類游戲中，大模型已成為核心競(jìng)爭(zhēng)力。為了更好地通過生成式 AI 支持業(yè)務(wù)發(fā)展，網(wǎng)易游戲打造了面向云原生的Tmax AI 機(jī)器學(xué)習(xí)平臺(tái)，提供靈活的資源調(diào)度、高效的 AI 開發(fā)效率與易托管的 AI 服務(wù)。

Tmax 平臺(tái)構(gòu)建于 Kubernetes 之上，整合了 Kubeflow、自研調(diào)度器及 CubeFS 文件管理系統(tǒng)，支持從 Jupyter 交互式開發(fā)到分布式訓(xùn)練、再到模型推理部署的全鏈路 AI 生命周期管理。然而，隨著大模型推理業(yè)務(wù)規(guī)模爆發(fā)，平臺(tái)在資源彈性、數(shù)據(jù)訪問效率與多地域協(xié)同方面面臨嚴(yán)峻挑戰(zhàn)。

挑戰(zhàn)：大模型推理服務(wù)的

“不可能三角”

在構(gòu)建推理服務(wù)時(shí)，我們面臨著成本、效率與彈性的多重制約：

1. GPU 資源的稀缺性與異構(gòu)性

受限于供應(yīng)鏈，高端 GPU 資源稀缺且價(jià)格昂貴，且存量資源卡型復(fù)雜（異構(gòu)混部）。這要求平臺(tái)必須實(shí)現(xiàn)分鐘級(jí)彈性伸縮，絕不能按業(yè)務(wù)峰值長(zhǎng)期空置資源。

2. 業(yè)務(wù)峰值差異導(dǎo)致的資源浪費(fèi)

不同游戲業(yè)務(wù)的推理負(fù)載呈現(xiàn)顯著差異：

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

• 資源需求異構(gòu)：實(shí)時(shí)推理、批量處理、模型微調(diào)等場(chǎng)景對(duì) GPU 類型、顯存、網(wǎng)絡(luò)的要求各不相同

• 按峰值預(yù)留的低效性：為每個(gè)業(yè)務(wù)單獨(dú)預(yù)留峰值資源會(huì)導(dǎo)致整體利用率低下，資源浪費(fèi)顯著

按峰值疊加滿足所有業(yè)務(wù)將導(dǎo)致資源浪費(fèi)率高達(dá) 60% 以上。

3. Serverless 冷啟動(dòng)的致命延遲

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

4. 多地域存儲(chǔ)管理復(fù)雜度和計(jì)算資源的碎片化

• 跨地域管理難題：GPU 資源分布在多個(gè)地域，但模型數(shù)據(jù)需要高效同步和統(tǒng)一管理。

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

• 多環(huán)境運(yùn)行時(shí)支持：需要同時(shí)管理 IDC 物理機(jī)、云上 ECS 實(shí)例和 Serverless 容器服務(wù)等多種計(jì)算資源中的存儲(chǔ)訪問。要求存儲(chǔ)抽象必須具備跨集群、跨云廠商的一致訪問接口。

方案選型：為何選擇

Fluid+AlluxioRuntime？

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

二者抽象層級(jí)與架構(gòu)定位的根本差異

· Alluxio：本質(zhì)是分布式緩存引擎，提供內(nèi)存級(jí)數(shù)據(jù)訪問能力，核心價(jià)值在于作為計(jì)算與存儲(chǔ)間的虛擬化層，提供統(tǒng)一命名空間與緩存加速。

· Fluid：是基于 Kubernetes 及 Alluxio 等底層系統(tǒng)的云原生數(shù)據(jù)編排平臺(tái)，以數(shù)據(jù)集為中心進(jìn)行抽象，深度集成于 Kubernetes 生態(tài)。

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

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

選擇 Fluid 的綜合考量：

分析結(jié)論

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

1. 抽象匹配：Fluid 的"數(shù)據(jù)集"抽象更貼近 AI 應(yīng)用的數(shù)據(jù)使用模式，而 Alluxio 的"文件系統(tǒng)"抽象更底層。

2. 運(yùn)維簡(jiǎn)化：封裝 Alluxio 的運(yùn)維復(fù)雜性，提供了 Kubernetes 原生的管理體驗(yàn)。

3. 場(chǎng)景優(yōu)化：針對(duì) AI/ML 場(chǎng)景進(jìn)行了專門優(yōu)化，直接解決了大模型加載的關(guān)鍵痛點(diǎn)。

4. 生態(tài)集成：作為 CNCF 孵化項(xiàng)目，F(xiàn)luid 與云原生生態(tài)的集成深度和未來兼容性更好。

5. 長(zhǎng)期投資：多 Runtime 架構(gòu)避免了對(duì)單一技術(shù)的依賴，為未來技術(shù)演進(jìn)留出空間。

落地實(shí)踐：聲明式數(shù)據(jù)基礎(chǔ)設(shè)施

基于 Fluid 的云原生抽象能力，我們構(gòu)建了“計(jì)算 - 緩存 - 存儲(chǔ)”三層解耦架構(gòu)：

1. 底層存儲(chǔ)：CubeFS/OSS 存儲(chǔ)原始模型權(quán)重。

2. 加速層：Fluid + AlluxioRuntime 構(gòu)建分布式緩存層，跨地域提供統(tǒng)一訪問接口。

3. 計(jì)算層：Kubernetes 集群（含 Serverless 容器）運(yùn)行推理服務(wù)，通過 PVC 掛載數(shù)據(jù)。

架構(gòu)設(shè)計(jì)

關(guān)鍵配置實(shí)踐

1. 自動(dòng)預(yù)熱機(jī)制

針對(duì) DeepSeek-R1 等超大模型，啟用了 Fluid 的應(yīng)用預(yù)取功能，大幅縮短冷啟動(dòng)時(shí)間。

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

2. 智能彈性：GitOps 與定時(shí)伸縮

針對(duì)游戲業(yè)務(wù)明顯的早晚高峰特征，我們結(jié)合CronHorizontalPodAutoscaler與 FluidDataLoad實(shí)現(xiàn)了全自動(dòng)化的“潮汐式”管理：

• 高峰前：自動(dòng)擴(kuò)容緩存節(jié)點(diǎn)，并觸發(fā)模型數(shù)據(jù)預(yù)熱。

• 低峰后：自動(dòng)縮容緩存節(jié)點(diǎn)，釋放資源。

     targetSize: 20

使用定時(shí)預(yù)熱

  - path: /path/to/warmup # 指定了需要預(yù)熱的后端存儲(chǔ)系統(tǒng)路徑。

3. 跨 namespace 的緩存共享

在 Tmax 平臺(tái)中，存在“公共模型倉庫”與“多業(yè)務(wù)項(xiàng)目組”并存的場(chǎng)景。如果每個(gè)項(xiàng)目組（Namespace）都單獨(dú)部署一套 Dataset 和 Runtime，將導(dǎo)致：

1. 存儲(chǔ)冗余：同一個(gè) DeepSeek-V3 模型在集群中被重復(fù)緩存多次。

2. 內(nèi)存浪費(fèi)：多套分布式緩存系統(tǒng)占用大量?jī)?nèi)存資源。

3. 管理混亂：模型版本更新需要通知所有項(xiàng)目組手動(dòng)同步。

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

• Model-Hub Namespace：由平臺(tái)管理員維護(hù)，部署AlluxioRuntime和Dataset負(fù)責(zé)對(duì)接底層存儲(chǔ)并進(jìn)行數(shù)據(jù)預(yù)熱。

• Game-Project Namespace：分配給各游戲項(xiàng)目組，無需部署 Runtime，只需創(chuàng)建一個(gè)引用型的 Dataset 指向 Hub 中的數(shù)據(jù)集

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

      name: model-root

授權(quán)業(yè)務(wù)組在game-team-a命名空間引用：

    name: deepseek-mount

收益

• 一次預(yù)熱，全員加速：模型只需在公共空間加載一次，所有授權(quán)的業(yè)務(wù)組即可通過本地網(wǎng)絡(luò)訪問，無需重復(fù)下載。

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

• 極速啟動(dòng)：新開服的游戲業(yè)務(wù)無需等待模型下載，直接掛載公共緩存，實(shí)現(xiàn)秒級(jí)啟動(dòng)。

性能與成本收益

經(jīng)過超過一年的生產(chǎn)環(huán)境運(yùn)行，F(xiàn)luid + AlluxioRuntime 的組合不僅解決了技術(shù)層面的 I/O 瓶頸，更為網(wǎng)易游戲帶來了顯著的業(yè)務(wù)價(jià)值。以下是我們?cè)谛阅芗铀?、成本?jié)約、高并發(fā)穩(wěn)定性等方面的具體收益細(xì)節(jié)：

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

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

• 加載耗時(shí)大幅縮短：以 DeepSeek V3/R1 等大參數(shù)模型為例，通過對(duì)比實(shí)測(cè)：

• • 基線（跨地域直連 CubeFS）：受限于網(wǎng)絡(luò)帶寬與長(zhǎng)鏈路延遲，平均耗時(shí) 36 分鐘。

  • 優(yōu)化一階段（傳統(tǒng) Alluxio）：部署緩存后縮短至 14 分鐘，但仍受限于元數(shù)據(jù)同步和預(yù)熱效率。

  • 優(yōu)化二階段（Fluid 智能預(yù)讀）：開啟 AI 應(yīng)用預(yù)讀，耗時(shí)驟降至 3 分鐘。

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

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

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

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

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

3. 穩(wěn)定性維度：化解“驚群效應(yīng)”，保障高并發(fā)

在游戲版本更新或活動(dòng)期間，會(huì)有數(shù)百個(gè)推理服務(wù)實(shí)例同時(shí)啟動(dòng)（并發(fā)拉起）。

• 保護(hù)底層存儲(chǔ)：若數(shù)百個(gè) Pod 同時(shí)直接訪問底層的對(duì)象存儲(chǔ)（OSS/S3），極易觸發(fā)帶寬限流或存儲(chǔ)服務(wù)過載（Thundering Herd Problem）。Fluid 充當(dāng)了巨大的流量“擋板”，所有高并發(fā)請(qǐng)求均由本地緩存層響應(yīng)，徹底消除了底層存儲(chǔ)的 I/O 抖動(dòng)風(fēng)險(xiǎn)。

• 推理吞吐穩(wěn)定：本地化的數(shù)據(jù)訪問將 I/O 延遲從毫秒級(jí)（ms）降低至微秒級(jí)（μs），確保了 GPU 不會(huì)因?yàn)榈却龜?shù)據(jù)而空轉(zhuǎn)，保障了推理服務(wù)的 P99 延遲穩(wěn)定性。

4. 效率維度：算法團(tuán)隊(duì)的“零感知”體驗(yàn)

對(duì)于算法工程師而言，基礎(chǔ)設(shè)施的復(fù)雜度被完全透明化。

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

• 環(huán)境一致性：從開發(fā)環(huán)境（Jupyter Notebook）到生產(chǎn)環(huán)境（Serverless Deployment），使用同一套 Dataset 定義，消除了“開發(fā)能跑，上線報(bào)錯(cuò)”的環(huán)境差異問題。

結(jié) 語

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

在游戲行業(yè)與 AI 技術(shù)深度融合的今天，基礎(chǔ)設(shè)施的現(xiàn)代化已成為創(chuàng)新的基石。Fluid 作為云原生數(shù)據(jù)編排的優(yōu)秀代表，其在網(wǎng)易游戲的成功應(yīng)用，為整個(gè)行業(yè)提供了可借鑒的范例。未來，隨著技術(shù)的不斷演進(jìn)和場(chǎng)景的持續(xù)拓展，“以數(shù)據(jù)為中心”的架構(gòu)設(shè)計(jì)已成為企業(yè)降本增效、構(gòu)建競(jìng)爭(zhēng)力的關(guān)鍵路徑，推動(dòng)游戲行業(yè)進(jìn)入一個(gè)更加智能、個(gè)性化和沉浸式的新時(shí)代。

最后，特別感謝 Fluid 社區(qū)的徐之浩、玖宇和顧榮老師。正是因?yàn)橛羞@樣負(fù)責(zé)任的維護(hù)者和快速的社區(qū)響應(yīng)，才使得我們的技術(shù)探索之路更加平坦，讓云原生 AI 架構(gòu)在網(wǎng)易游戲順利落地。

作者簡(jiǎn)介

廖海峰 (Senior Infrastructure Engineer)：負(fù)責(zé)網(wǎng)易互娛 AI 基礎(chǔ)設(shè)施平臺(tái)的算力基礎(chǔ)設(shè)施構(gòu)建和穩(wěn)定性保障，致力于為大規(guī)模游戲 AI 業(yè)務(wù)提供堅(jiān)實(shí)的算力底座與服務(wù)支撐。

張　翔 (Head of AI Infrastructure)：負(fù)責(zé)網(wǎng)易互娛 AI 基礎(chǔ)設(shè)施平臺(tái)的技術(shù)演進(jìn)與架構(gòu)設(shè)計(jì)，致力于構(gòu)建高性能、高可用、低成本的 AI 基礎(chǔ)設(shè)施平臺(tái)。

會(huì)議推薦

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

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

今日薦文

你也「在看」嗎？