AI 應用全球化浪潮下，推理效率與算力供給成為破局關鍵。AICon2025 上海站，GMI Cloud 資深架構師 Frank Lee 登臺演講，在題為《GMI Cloud 全球化高效能分散式推理服務構建實踐》的分享中以 GMI Cloud Inference Engine 為錨點，拆解其高併發、低延遲、動態擴縮容能力如何支撐全球 AI 業務爆發，深度分享 GMI Cloud 自研推理平臺的架構設計、跨區域合規部署及軟硬協同最佳化實踐，揭秘其實現推理成本、指數級效率提升的關鍵路徑。
我們是一家全球化 AI Native Cloud 服務商，主要為全球 AI 應用提供高效能的 GPU 雲服務。我們是英偉達全球 Top10 的 NCP，這就使得我們在英偉達最新 GPU 資源的獲取上有一些優勢。我們在亞太區有優先的 GPU 分配權，能穩定地拿到英偉達最優晶片。
同時我們的產品基於 GPU 叢集對外提供 IaaS 層和 MaaS 層的服務。IaaS 層是以 GPU 計算為核心的計算、儲存、網路三大件，其中計算部分的核心是以 GPU 為主的，形態主要以雲上裸金屬，GPU、雲容器，還有云上託管的 K8s 叢集為主。MaaS 層我們提供兩種型別的服務，一種型別針對自有模型客戶，他們有模型部署需求的，我們會提供推理平臺，給客戶提供一系列推理最佳化能力；另外一種是提供我們整合的開源最新最強的模型，這樣的模型會以 API 呼叫的服務來提供給客戶，這就是我們的業務整體構成。
我們現在在全球總共有 10 多個可用區，主要集中在北美和亞太區，歐洲也有少量節點，北美和亞和亞太這兩個區裡我們中國的 AI 出海企業比較集中，也是他們的使用者量和收入比較多的地方。亞太部分最近比較火的有新加坡和日本，是非常熱的熱點。
接下來我分享一下我們看到的一些關於 AI 應用及中國 AI 應用出海的趨勢，以及他們面對的在推理服務部署方面所遇到的一些問題。
首先我們看一下全球整體情況，這裡有個數據統計了過去一年，全球 AI 應用的總訪問量趨勢。我們可以看到從訪問量上來說，資料從去年 1 月開始差不多是 36 億，到去年 12 月底到了 76 億，基本上翻倍的增長，從收入和下載量來說也是有比較大的增長。
這個資料目前只統計到了去年 12 月，如果再統計到今年的 1~4 月，資料的增長應該會更高一些。也是因為 DeepSeek 在春節期間的出圈，把 AI 整體的滲透率提升了很多，像春節期間家裡的長輩都在使用 AI 產品了。
所以整個 AI 應用的部分從去年開始加速爆發，我們作為 GPU 雲服務商來說，從今年開始接到了很多客戶的需求都以推理為主，以應用客戶為主，訓練的部分明顯減少了。
我們再來看中國 AI 出海的情況，這裡也有資料，就是中國規模以上 AI 產品的數量大概在 300 多個，其中出海 AI 產品在 156 個，是截止 4 月份的資料。所謂規模以上就是月活在 5 萬以上的的應用。
這個資料在去年 1 月份時是 35 個，也就是說在上個月時已經增長到了 156 個，300% 以上的增長。同時過去兩三個月，每個月基本上是以 10~20 個的資料再增長，所以中國出海產品數量和使用者規模都在不斷增大，這也說明海外 AI 推理的算力需求將會不斷增大，算力需求的持續供應在 25 年會是比較重點的事情。
這是中國 AI 出海比較頭部的一些 APP 的下載量和收入按地區分配的情況。透過這個圖我們可以得出幾個結論，第一個結論是中國出海的這些 AI 應用，不是被某特定區域的使用者使用，而是廣泛的全球化使用者在使用，但它會有一些側重點。從下載量和收入上來說，它們的分佈會有一些差異，比如從下載量上我們可以看到很多應用在印度的下載量比較大，但從付費情況來說是北美，具體是指美國的付費佔比比較大。另外日本的付費比例也比較大，所以北美和日本這兩個區域是出海的首選。
我們在過去 2~3 個月裡經常會在社交平臺上看到某個 AI 應用突然爆火，在朋友圈裡刷屏，在短影片裡到處都是，但我們一旦要使用它的時候，就會發現要麼進入等待清單，要麼就是服務繁忙的狀態。這和 AI 應用整體的服務的能力，特別是算力服務能力跟不上有很大關係。所以如果我們能提供比較充足的算力服務，並且能及時擴容，對這些突然爆火的 AI 應用獲得比較初始的使用者規模，以及後續的使用者留存也是非常關鍵的。
總結下來，在現在 AI 應用全球化增長的趨勢下，如果要構建比較及時穩定的推理服務，主要面臨幾個問題。
第一個問題是現在出海應用覆蓋的區域比較廣，所以它的推理服務也要覆蓋各個區域。第二個是它的使用者規模在不斷增長，需要構建適應使用者增長的推理服務，具備自動擴容的能力，以便及時接住這些突發流量。第三，在有限的資源情況下，需要最佳化推理服務的效能，以獲得更好的 SLO 水平去服務使用者。最後一個是比較老生常談的問題，就是如何保證服務的穩定性。
接下來介紹一下我們 GMI Cloud 在幫助使用者構建這些推理服務時的一些實踐經驗。
我們今年服務的大多數客戶主要是推理需求的客戶，我們也有這樣的推理平臺滿足他的需求。推理平臺是構建在我們整個 GMI Cloud 的雲平臺之上，我們會在這個平臺上做一些幫助使用者快速部署推理服務，提供穩定的服務以及推理效能最佳化的一些工作，並且把它逐步產品化，對外提供服務。
首先給大家分享我們在推理服務自動擴縮容方面的一些實踐。自動擴縮容這個事情下面有三個子命題，分別是負載均衡、擴容的策略和冷啟動。
關於擴容，是說在現有的資源、服務水平下，怎麼讓現有資源能夠更均衡地對外提供服務，不會變成有的資源負載很高，有的負載很低，造成資源利用率不高的情況。
關於負載均衡，現在至少在語言模型方面，比較流行的是在 PD 分離的架構下做負載均衡。PD 分離架構下，P 負載和 D 負載是分開做負載感知和負載均衡的，相對來說 P 負載的均衡會比較容易一些，因為它基本上相當於無狀態的處理過程。所以我們基本上是直接基於它的負載水平來做排程，就是排程到負載較低的 worker 上，同時也會做一些動態排程，比如說我們會把使用者的 input 按照長度分成不同型別，排程在不同的 P worker 分割槽裡。
D worker 的負載均衡相對複雜一些，因為它混合了 kv cache 的命中問題，所以這一塊我們也做了一些比較細緻的工作，也會參照一些行業現在開源的最佳實踐。第一點，它的核心目標是我把 decoder 的任務排程在距離 kv cahce 命中率更高，並且負載更低的 worker 上。細節的部分，我們會做一些比如基於 prompt hash 或 input token ID 的字首匹配的一些計算，去計算整個 kv cache 的命中得分，根據得分加上 GPU 負載，以及現在的佇列長度去做綜合權重得分，根據得分去匹配最高得分的 worker。
還有一些場景，比如說現在我們接觸比較多的，像陪聊、擬人對話這樣的場景，它的特點就是多輪對話。多輪對話的輪次非常長，並且對於對話中上下文的保持要求比較高，這時就會導致如果要使用上面提到這種排程，有可能會出現一些上下文缺失的情況。所以這種情況我們也給客戶提供一些策略，就是基於 SessionID 的的保持，就是粘性排程的形式，同一個 SessionID 在同一個 D worker 上處理。
一旦整體負載都過高後就要擴容。擴容首先要涉及擴容策略的問題，什麼時候擴容，以及擴容的條件要怎麼設定？這個部分目前我們做了線性條件擴容的方法，會把所有叢集的 worker 負載，以及現在的 SLO 水平，包括首次延遲、整體吞吐，以及整體的使用者請求佇列長度等，把這些指標全部收集起來後給客戶排程編排器。編排器裡面是線性條件的組合，當某一個條件和某一個條件達到一定水平，就選擇擴容或縮容，並判斷縮容和擴容的的副本數量是多少。
但我們現在也在同客戶研究一些非線性方法，比如基於整體叢集的資料以及客戶未來流量的資料做一些預測，看這樣的預測時機和這種條件觸發的形式，哪一個會更準一些，對資源的利用率會更高一些。
一旦擴容條件觸發後，還會涉及到一個問題就是擴容的服務副本怎樣能夠更快速上線，也就是冷啟動如何做加速。這一塊核心的瓶頸主要是兩個，第一個是模型載入。我們知道大模型的模型權重一般小的幾十 G，大的有幾百 G，所以一般在雲上用推理服務時，會去從遠端物件儲存下載模型，再載入的 GPU 例項裡，再做推理服務，整個過程可能會耗時十幾分鍾。我們作為專門提供 GPU 雲服務的廠商來說在這裡會相對有一定優勢，比較簡單粗暴的方法就是給每 GPU 的叢集配備高速檔案儲存，透過 RDMA 的形式和 GPU 叢集相連，這樣就從本地高階高速檔案儲存直接進到 GPU 視訊記憶體，上百 G 的檔案幾秒鐘就載入完了。同時，關於Runtime 初始化這部分，GMI Cloud 也會做一些提前最佳化，包括模型執行圖的預編譯， kv 快取的預分配和通訊結構複用的一些操作，總之就是一旦擴容條件觸發後，我們去擴容新的副本時，能夠在分鐘級擴容起來提供服務。
另外，還有一些跨叢集跨地區的自動擴容問題。大家都知道，很多客戶的服務是多區域的，所以它的推理叢集一般會分佈在不同地方，大多都是會跨地區的。比如說有的在北美，有的在東南亞，這時我們也要去做整體多叢集的負載均衡和自動擴容。
第一層面的負載均衡是不同地區的負載均衡，GMI Cloud 是和 CDN 廠商合作，讓本地使用者訪問本地叢集獲得推理服務。同時基於所有收集到的推理負載資料，我們按照上面的邏輯去做單個叢集的負載均衡。自動擴容的編排計劃也可以按照叢集維度單獨定製擴容計劃。
還有一點，現在 PD 分離相關的技術比較火熱，很多大模型的推理，如果要節省推理成本，實現所謂的工業紅線，能夠提供推理服務賺錢，這一步目前看是少不了的。但 PD 分離這個技術和場景是強相關的，不同場景的 input 和 output 的長度也不太相同，所以這一點要根據場景做很多定製和適配，我們有一些實踐經驗可以給大家分享一下。
第一點就是什麼場景下適合做 PD 分離推理，什麼場景下適合做 PD 融合的？目前看來，因為 AI 應用客戶所使用的模型尺寸越來越小，大多數都是 10b 左右。這個時候就要看場景，有一些場景比如說很多 Agent 類的應用會拿一些小模型首先做意圖識別或者是做 function calling 工具呼叫。這部分的 input 長度不會特別長，並且呼叫的頻次也比較低，單卡就能放得下推理，去做 PD 分離需要更多資源，這個時候就不太划算了。
但有一些場景，比如說陪聊擬人對話的使用者訪問請求比較密集，呼叫頻次較高，同時它由於多輪對話導致上下文比較長。還有一些 RAG 場景的 input 是特別長的，這時如果 PD 融合推理，prefill 會擠佔 decode 資源，導致推理效能較差，所以這些場景是比較適合 PD 分離的。另外就是大尺寸模型，比如說 DeepSeek R1、V3 模型比較適合做 PD 分離。
PD 分離還涉及到 P 和 D 的比例問題，這個部分我們也自己做了一些實驗，根據我們所接觸到的一些客戶場景所得到的經驗資料給大家分享一下。
像通用性聊天使用者，輸入可能會比較短， input 在 512 token 以下的， P 和 D 的比例適合在 1:1。還有稍微長一點的輸入場景，prompt 在 1k 以上，這時 prefill 的資源會加多一些， P 和 D 的比例在 2:1 比較合適。還有 RAG 的 input 都是特別長的，可能要幾千甚至上萬 token，這時 prefill 比例會更大一些，4:1 比較合適。還有一些比較特殊的場景，對於首詞延遲要求比較高，要保證整體的服務流暢性，這時 decode 的比例多一點比較好。
有時候客戶的資源並不是那麼多，特別是創業公司的預算也比較有限，這時由於整個場景在動態變化，P 和 D 的比例也在變化，這時我們也也和客戶一起合作，看怎樣實現 P 和 D 的快速線上轉換。還有一點是關於 kv 快取池的問題，目前我們主要以 HBM 視訊記憶體作為快取核心。當整體場景比較大時，我們也會使用本機記憶體和本地的 SSD 硬碟來做整體的統一快取池的管理，在 kv 命中演算法和手段不變的情況下增大快取池大小，能夠非常有效地提升快取命中。目前來看，把本地記憶體和 NvMe SSD 都利用上的話，把快取命中率提升 50% 以上是比較容易的。
另外一個事情就是我們觀察到很多 AI 應用，它在持續服務過程中的使用者輸入，我們觀察到有 2/8 比例的現象，就是 20% 的 prompt 會被 80% 的使用者輸入，有一些高頻 prompt 存在。這時我們也會做動作，對使用者輸入的 prompt 做一些頻次統計，把高頻的 20% prompt 統計出來，把這部分的 kv cache 持久化儲存下來。這樣處理推理請求時，就可以先做雜湊比對，如果直接命中了，直接去從持久化儲存裡取這些 kv 就省去了前面的 prefill 階段。
目前 PD 分離的的技術基本上只能做到單叢集內，因為 PD 之間的通訊對通訊網路的要求非常高。我們也是這樣，但基於 kv 的持久化儲存可以跨叢集分享。雖說它服務的是不同地區的客戶，使用者的輸入還是有比較高的相似度的，這時某叢集的高頻 prompt 的 kv 共享給另外的叢集，也能提升另外一個叢集的整體資源處理效率。
另外我們在服務客戶的過程中發現比較有趣的事情，就是我們在軟體的層面去做 GPU 推理效能最佳化，做了很多工作，但是往往英偉達只要發一款新的 GPU，可能新的 GPU 所帶來的效能最佳化效率，比在軟體上做的效能最佳化效率要高很多。這是英偉達 3 月份發的資料，他們用 DeepSeek-FP4 的版本在 H200 和 B200 上跑了一下，可以看到在 B200 上跑的資料是在 H200 上跑的 25 倍以上，而現在 B200 的價格基本上是 H200 的價格兩倍不到，所以價效比是極高的。
這個 FP4 的版本，他們也在 MMLU 上做了評測，相對於 FP8 的版本有 99% 得分，基本上沒有什麼效能折損。所以說盡快獲取最新的 GPU 來做推理服務，可能是價效比最高最快的路徑。
我們也是少有的現在能夠拿到實際的 B200 資源的廠商。我們也拿 B200 的伺服器做了一下整體測試。推理的部分我們還在測試中，但預訓練的資料可以看到。我們這裡是基於 Llama 7b、13b 和 34b 的模型跑了預訓練，可以看到在不同的並行策略上，B200 比 H200、H100 的吞吐量至少有 50% 以上提升，高的可能有百分之七八十。
所以 B200 提升還是比較可觀的，我們接下來 B200 的的叢集也會在日本上線。
除了剛剛提到的一些推理最佳化相關的工作外，我們還做了一些幫助客戶快速部署和運維推理服務的工作，幫助客戶在我們的平臺上透過介面的形式快速構建映象，用內建的一些推理模板快速的部署推理服務。同時推理服務的全面監控也以資料看板的形式為客戶提供，推理服務的鑑權、服務的管理、計費的管理也為客戶提供了比較完善的功能。
推理服務的效能監控對於客戶來說是強訴求，這一塊我們基本上做到了全鏈可觀測，從硬體的狀態，包括 GPU 負載、GPU 溫度、磁碟狀態各方面，到系統的狀態以及推理負載狀態、推理執行框架狀態，包括推理執行的 SLO，全部都以不同的視覺化圖表為使用者呈現。
同時基於這些主指標，我們也會為客戶定義一些高階監控指標。比如說某些監控指標組合起來能夠發現某些問題。特別是在故障監測這部分，我們積累了幾十種故障監測策略，透過不同的指標綜合判斷是什麼樣的故障，它的故障等級是怎麼樣的。一旦發現這樣的故障，我們也有一定的自動化策略去處理，同時首先會把這些故障的原始完整資料鏈條拉出來給客戶，以告警的形式發給客戶。同時我們會根據故障的等級不同而採取不同的措施，如果是 P0 等級的，我們立刻去把推理負載所用的 GPU 叢集做物理隔離，同時快速取新的副本起來，維持整個服務的穩定性。
後續我們會配合人工服務，基於整個故障日誌所採集的故障資訊，最終分析整體的故障原因給客戶。同時分析出來的處理後內容又可以積累到我們故障感知、故障檢測和故障處理的整個流程中。
總結一下 GMI Cloud Inference Engine 的特點，主要有 4 個：
-
彈性伸縮；
-
提供高效的推理部署工作流，讓企業能夠一鍵部署整個推理服務；
-
能夠結合硬體給企業做整個推理效能的最佳化，為企業提供比較極致的推理效能；
-
透過全面的整體主動監控和故障監測與處理流程，以及我們線下的服務保障，給企業提供穩定的推理服務。
GMI Cloud Inference Engine 會基於一些開源模型構建一些 API 服務，GMI Cloud 在裡也做了很多推理效能的最佳化，目前推理服務的 API 已經上線我們的平臺，整體價格會比行業水平低一些。整體 API 的呼叫也是遵循 OpenAI 的 API 格式，可以直接以 OpenAI 的 API 形式來快速呼叫，接入自己的應用中。
過去，我們服務了一些圖片生成和影片生成的客戶，比如一個在北美的企業客戶，他們的核心訴求就是彈性擴容。它的使用者量在過去兩個月有比較大的增長，出現過一天內需要快速彈性擴容一倍的情況，過去一個月它整體的擴容水平是增長了 8 倍。
另外一個值得一提的是，歐洲的一家影片和音樂生成廠商，他們在我們平臺上做了訓練和推理兩個部分。訓練的部分，我們也有相應的服務幫他們做整體訓練速度的提升，主要就是整體通訊最佳化。推理的部分，他們目前也在用我們的“彈性推理”服務，因為歐洲的時間和北美使用者的時間和亞太使用者時間是相對比較錯開的，所以我們會有一些閒置資源去支撐他們在歐洲時間的推理高峰。
Frank Lee，GMI Cloud 資深架構師，深耕人工智慧領域 8 年。作為 AI 四小龍早期核心成員，深度參與企業從 0 到 1 的技術商業化突圍，親歷 AI 演算法從實驗室走向規模化落地的全週期實戰，對行業技術演進、市場需求匹配及商業閉環構建具有稀缺的早期開拓者視角。主導過 10 + 行業頭部客戶的 AI 解決方案落地，擅長從客戶痛點出發，利用 “演算法 + 算力 + 資料” 三位一體的端到端方案，將前沿技術轉化為可規模化複製的商業產品的成熟方法論。國內首批投身 AI 與雲原生融合的技術專家，深度理解 AI 模型訓練、推理部署與雲基礎設施的協同最佳化，在容器化排程、分散式訓練框架適配、資源彈性分配等領域積累了標杆級專案經驗。
6 月 27～28 日的 AICon 北京站將繼續聚焦 AI 技術的前沿突破與產業落地，圍繞 AI Agent 構建、多模態應用、大模型推理效能最佳化、資料智慧實踐、AI 產品創新等熱門議題，深入探討技術與應用融合的最新趨勢。歡迎持續關注，和我們一起探索 AI 應用的無限可能！