作 者 | 黃潤鵬

出品 | 騰訊云開發(fā)者

隨著大模型技術(shù)的爆發(fā)，AI Infra 已成為基礎(chǔ)設(shè)施領(lǐng)域的核心戰(zhàn)場。過去1年多的時間，我們團隊落地了多個大模型應(yīng)用，包括語音合成大模型、內(nèi)容理解多模態(tài)大模型、生成式推薦大模型，跑通大模型訓練到推理的全鏈路。踩了很多坑，也積累了不少經(jīng)驗。本文將分享傳統(tǒng)后臺工程師積累的技術(shù)棧和方法論，如何延續(xù)并遷移到 AI 系統(tǒng)，并系統(tǒng)性拆解 AI Infra 的硬件、軟件、訓練和推理挑戰(zhàn)。

硬件演進

經(jīng)濟基礎(chǔ)決定上層建筑。軟件層面的架構(gòu)設(shè)計，無法脫離硬件約束。了解現(xiàn)代 AI 硬件特性非常有必要。

（一臺高性能的GPU服務(wù)器可以換一套深圳房子）

1.1 從CPU為中心到GPU為中心

傳統(tǒng)基礎(chǔ)設(shè)施以 CPU 為核心，通過多線程和微服務(wù)構(gòu)建分布式系統(tǒng)，處理高并發(fā)請求（如 Web 服務(wù)）。這些都有成熟的方法論了（如“海量服務(wù)之道”）。主要工作是邏輯事務(wù)的處理，瓶頸在網(wǎng)絡(luò) I/O 和 CPU 核心數(shù)量。發(fā)展到今天，硬件已經(jīng)很少是制約 CPU 系統(tǒng)設(shè)計的瓶頸。

而 AI Infra 以 GPU 為核心，其設(shè)計目標從邏輯事務(wù)處理轉(zhuǎn)向高吞吐浮點計算。此時CPU 多線程被 GPU 并行計算替代，內(nèi)存被顯存替代。如下圖所示，H20單卡96GB顯存，可以提供44TFlops的單精度浮點運算，算力和訪存帶寬是主流CPU數(shù)十倍甚至數(shù)百倍。每臺機器安裝8卡=768GB顯存，另外還有 CPU 192核384線程 + 2.3TB 內(nèi)存。

為什么 GPU 會成為核心？是因為 LLM 大模型每次生成一個 token，都需要讀取全量的模型參數(shù)。傳統(tǒng)的 CPU + 內(nèi)存的算力和帶寬無法滿足如此恐怖的計算密度，計算和通信都必須轉(zhuǎn)移（offload）到 GPU 內(nèi)完成。CPU 成為數(shù)據(jù)搬運工和“輔助處理器”。

為了更直觀地理解這個計算密度，我們做一個簡單的計算。不考慮計算的延時，LLM 大模型生成一個 token 的耗時公式計算為。

以 DeepSeek-R1-671B-A37B-FP8 模型為例，計算一個 token 耗時，H20 為 37B × 1byte ÷ 4000GB/s = 9ms，如果是 CPU 則為 37B × 1byte ÷ 64GB/s = 578ms 。

1.2 從“去IOE ” 到“AI大型機 ”

顯而易見，我們的現(xiàn)在身處新的一輪烈火烹油的硬件革命的歷史進程中，各種專用硬件、專用網(wǎng)絡(luò)層出不窮。DeepSeek-R1 和 QWen3-235B 千億級參數(shù)訓練需千卡 GPU 集群協(xié)同，通過專用網(wǎng)絡(luò)互聯(lián)構(gòu)建“AI超算”，其設(shè)計邏輯與以前的 IBM 大型機驚人相似——以硬件集中化換取極致性能與可靠性。

（IBM大型機）

傳統(tǒng) Infra 的分布式理念貌似在 AI 時代失效了。傳統(tǒng) Infra 追求橫向擴展，而 AI Infra 呈現(xiàn) “AI 大型機”特性，是因為傳統(tǒng)后臺服務(wù)的可以容忍毫秒級延遲，但 AI 集群不行，GPU 的算力是 CPU 的數(shù)百倍，微秒級的延時等待也會造成很大的算力損耗，需要硬件的高度集成。在可預(yù)見的1-3年的未來，這樣的專用硬件+網(wǎng)絡(luò)的集中式架構(gòu)很難發(fā)生比較大的改變。

回顧歷史，我們總是在尋求科技平權(quán)。前人推動“去IOE”（IBM小型機、Oracle數(shù)據(jù)庫、EMC存儲），用分布式廉價x86 pc機替代集中式高端硬件，本質(zhì)上是利用軟件創(chuàng)新重構(gòu)一個高可用+低成本的互聯(lián)網(wǎng)基礎(chǔ)設(shè)施。"AI大型機"是技術(shù)發(fā)展必由之路，但不是終極形態(tài)。長期（5年）來看，必然會出現(xiàn) "AI 去 NVIDIA 化"，重演“去 IOE”的歷史。

軟件演進

說完硬件體系的革命，接下來再關(guān)注下軟件層面的變化。

相比傳統(tǒng)后臺應(yīng)用的增刪查改，AI 應(yīng)用的新范式是模型訓練和推理。模型訓練是指通過海量數(shù)據(jù)擬合出一個復(fù)雜的神經(jīng)網(wǎng)絡(luò)模型，推理就是利用訓練好的神經(jīng)網(wǎng)絡(luò)模型進行運算，輸入的新數(shù)據(jù)來獲得新的結(jié)論。

舉個例子，訓練就是根據(jù) <年齡, 身高> 的分布使用最小二乘法擬合模型 y = ax + b，推理就是利用這個模型 y = ax + b，輸入一個新的年齡，預(yù)測身高。

2.1 深度學習框架

工欲善其事，必先利其器。傳統(tǒng)后臺應(yīng)用依賴 tRPC 或 Spring 等微服務(wù)框架，幫助我們屏蔽負載均衡、網(wǎng)絡(luò)通信等底層細節(jié)，我們可以把精力放在業(yè)務(wù)實現(xiàn)上。

與之相似，AI 應(yīng)用則依賴深度學習框架。如果沒有深度學習框架，我們就可能陷入在茫茫的數(shù)學深淵中，掙扎于痛苦的 GPU 編程泥潭里。有了深度學習框架，我們才可以把所有精力花在設(shè)計模型和創(chuàng)新本身上，而不用關(guān)注底層的實現(xiàn)細節(jié)，極大降低了 AI 應(yīng)用的門檻。

大家可能聽說過不同的深度學習框架——Tensorflow，PyTorch?，F(xiàn)在是2025年，不用糾結(jié)選哪個，因為 PyTorch 就是 AI 模型訓練、推理的深度學習框架的事實標準。開源模型和代碼都是 PyTorch 一邊倒。

得益于動態(tài)計算圖、自動微分和豐富的 Tensor 操作算子，PyTorch 能幫助我們快速實現(xiàn)模型設(shè)計。如下圖所示，只需要描述模型結(jié)構(gòu)+待學習的網(wǎng)絡(luò)參數(shù)，不需要關(guān)心數(shù)學計算和 GPU 編程的細節(jié)。

2.2 GPU 編程

絕大部分的 AI 應(yīng)用，的確不需要我們手寫數(shù)學計算的 GPU 代碼。但為了滿足模型創(chuàng)新的需求，有必要學習 GPU 編程。例如 Meta 發(fā)布的 HSTU 生成式推薦模型，核心的 hstu_attn 計算，如果直接用 PyTorch 框架算子組合實現(xiàn)，則時間復(fù)雜度為 O(M * N2) ，其中 M 和 N 是一個數(shù)量級，相當于O(N3) 。但是通過自定義內(nèi)核，可以優(yōu)化到 O(N2)。

在 GPU 核心上運行的代碼片段稱為內(nèi)核（kernel）。編寫高性能的 CUDA 內(nèi)核需要豐富的經(jīng)驗，并且學習曲線陡峭。因為我們習慣于傳統(tǒng) CPU 編程處理串行的計算任務(wù)，通過多線程提高并發(fā)度。而 GPU 采用 SIMT 架構(gòu)，有大量計算單元（CUDA Cores）和數(shù)萬個線程，但是被分組后的線程同一時刻只能執(zhí)行相同的指令。這與傳統(tǒng)CPU的串行思維、不同線程處理不同任務(wù)，存在根本性沖突，導致 GPU 編程學習難度大。

（現(xiàn)實生活中的SIMT架構(gòu)）

現(xiàn)在推薦使用 Triton 編程語言完成 GPU kernel 的開發(fā)，它提供類似 Python 的語法，無需深入理解 GPU 硬件細節(jié)（如線程調(diào)度、共享內(nèi)存管理），而且和 PyTorch 深度學習框架的生態(tài)結(jié)合更好。推薦這個 Triton-Puzzles-Lite 項目用作 Triton 的入門學習。

2.3 Python 編程

正如客戶端開發(fā)離不開Kotlin/Objective-C，AI Infra 的編程第一公民就是 Python。PyTorch 深度學習框架的設(shè)計哲學強調(diào) Python 優(yōu)先 。

以前大部分模型還可以輕松導出 ONNX、TorchScript 等用 C++ 部署，現(xiàn)在隨著對模型的細粒度優(yōu)化和控制越來越多，比如 KV Cache、MoE/模型并行、復(fù)雜的if/for控制流、自定義 Triton 算子等，模型越來越難以脫離 Python 的控制部署。筆者也從“C++ Boy”變成“Python Boy”。

（筆者git提交的語言統(tǒng)計變化）

模型訓練的挑戰(zhàn)

我們一直追求更大的模型，DeepSeek-R1 有數(shù)千億參數(shù)，使用了數(shù)十萬億 token 的訓練數(shù)據(jù)，涉及算力、存儲、通信等多維度的工程挑戰(zhàn)。有了 PyTorch 深度學習框架，只是 AI 應(yīng)用落地的萬里長征第一步。接下來我們將討論深度學習框架之上的模型訓練的挑戰(zhàn)。

3.1 存得下

DeepSeek-R1 模型大小=670GB，而一臺 GPU 服務(wù)器有8張H20卡，提供768GB顯存，足夠存下一個完整的 DeepSeek 模型。那整個行業(yè)為什么還投入大量的人力物力，頂著通信延時造成的算力損耗，也要建設(shè)分布式 GPU 集群？核心原因是單臺 GPU 服務(wù)器“存不下”。

3.1.1 顯存刺客：中間激活

如下圖所示的模型，x1/x2/x3/x4 這些中間變量就是"中間激活"。它們是神經(jīng)網(wǎng)絡(luò)前向傳播（Forward）的“堆棧幀（Stack Frame）”——記錄每一層處理后的數(shù)據(jù)快照，確保反向傳播（Backward）可回溯梯度，根據(jù)預(yù)測誤差調(diào)整模型權(quán)重，最小化損失函數(shù)。

這些中間激活為什么會成為"顯存刺客"？是因為中間激活的空間復(fù)雜度是和輸入數(shù)據(jù)長度正相關(guān)的，特別的，對于 LLM 來說是O（N2）正比于輸入數(shù)據(jù)長度的平方，這是一個指數(shù)爆炸式增長的數(shù)字。類似函數(shù)遞歸不斷增長的“堆棧幀”導致的內(nèi)存溢出，我們遇到了 AI Infra 的 OOM（Out of Memory）挑戰(zhàn)。

借助 PyTorch 的 profiler 工具，我們可以直觀地看到這個OOM。下圖是訓練過程中不同階段的顯存分配，包括模型參數(shù)（Parameter）、優(yōu)化器狀態(tài)（Optimizer state）、中間激活（Activation）、梯度（Gradient）。在前向傳播結(jié)束后出現(xiàn)一個顯存占用（中間激活）的尖峰，遠大于模型參數(shù)本身。

3.1. 2 模型并行

傳統(tǒng)后臺服務(wù)使用分片（Sharding）策略解決單機存不下的問題。與之相似，AI Infra 提出“模型并行”，就是將單個大模型拆分為多個子模塊，并分布到不同 GPU 上協(xié)同工作，通過通信來共享數(shù)據(jù)。有不同的“拆分模型”策略，例如按模型模塊劃分，按張量（Tensor）劃分的，也可以將多種拆分方法結(jié)合起來一起使用。PyTorch 深度學習框架和開源方案 Megatron 都能幫助我們高效地實現(xiàn)模型并行。

（不同的模型并行策略）

3. 2 算得快

建設(shè)分布式 GPU 集群的原因，一個是因為“單機存不下”，另外一個是提升訓練速度。但簡單的機器堆疊，算力不一定有線性的增長。因為分布式訓練并不是簡單地把原來一個 GPU 做的事情分給多個 GPU 各自做。需要協(xié)調(diào)多個 GPU 機器計算任務(wù)分配，GPU 機器之間的數(shù)據(jù)傳輸會引入網(wǎng)絡(luò)IO和通信開銷，降低訓練速度。

3. 2.1 通信計算重疊

如下圖所示的常規(guī)訓練時序是串聯(lián)式的，存在許多網(wǎng)絡(luò) IO，GPU 利用率低，訓練速度慢。我們希望 GPU 大部分時間都在計算，而不是花在數(shù)據(jù)傳輸或等待其他 GPU 的工作上。

傳統(tǒng)后臺服務(wù)我們通過多線程或異步 IO 避免阻塞 CPU 主線程，與之相似，AI Infra 提出通信計算重疊的方法論。GPU 編程模型中有流（stream）的概念，一個流表示一個 GPU 操作隊列，該隊列中的操作將以添加到流中的先后順序而依次執(zhí)行。不同流之間可以并行執(zhí)行。那么通過令計算和通信操作加入不同的流中，可以做到二者的執(zhí)行在時間上重疊。例如 TorchRec 的 訓練流水線 能幫助我們實現(xiàn)高效的通信計算重疊。

模型推理的挑戰(zhàn)

AI 模型訓練成本很高，優(yōu)秀如 DeepSeek 也要燒掉500萬美金，但再貴也只是一次性的。而模型推理的成本更高，因為用戶越多，AI 模型推理次數(shù)越多，總成本越高。模型推理面對的挑戰(zhàn)和傳統(tǒng) Infra 非常相似，主要是2個挑戰(zhàn)：高吞吐（降本），低延時（增效）。

4.1 降低延時

現(xiàn)在的 AI 模型越來越多地直面終端用戶，需要和用戶進行實時的交互，例如文本對話和語音合成。模型推理耗時過高，會直接造成用戶體驗受損，用戶流失與轉(zhuǎn)化率下降。

傳統(tǒng)后臺服務(wù)我們使用鏈接復(fù)用、緩存、柔性等技術(shù)降低系統(tǒng)響應(yīng)時間。AI Infra 也有相似的做法。

4.1.1 CUDA Graph

在 GPU 編程模型中，CPU 和 GPU 是異構(gòu)的，CPU 通過 API（例如 CUDA API） 向 GPU 提交任務(wù)，然后異步等待 GPU 的計算結(jié)果返回。GPU 收到任務(wù)后，會執(zhí)行內(nèi)核啟動、內(nèi)存拷貝、計算等操作。這個過程中，涉及到 CPU 與 GPU 之間的通信、驅(qū)動程序的處理以及 GPU 任務(wù)的調(diào)度等環(huán)節(jié)，會產(chǎn)生一定的延遲。模型推理需要執(zhí)行大量重復(fù)的 GPU 操作，每個的 GPU 操作都要重復(fù)執(zhí)行上訴環(huán)節(jié)，這些非核心的 GPU 開銷會成倍數(shù)地放大，影響最終響應(yīng)時間。

（CPU 和 GPU 通信）

在傳統(tǒng)后臺服務(wù)，我們使用 Redis 的 Lua 腳本封裝多個 Redis 操作和計算邏輯，一次提交，減少網(wǎng)絡(luò)開銷。與之相似，AI Infra 利用 CUDA Graph 技術(shù)將多個 GPU 操作轉(zhuǎn)化為一個有向無環(huán)圖（DAG），然后一次性提交整個 DAG 提交到 GPU 執(zhí)行，由GPU自身來管理這些操作的依賴關(guān)系和執(zhí)行順序，從而減少 CPU 與 GPU 之間的交互開銷。

（多個 GPU 內(nèi)核啟動轉(zhuǎn)化為 CUDA Graph）

4.1.2 KV Cache：空間換時間

LLM 大模型推理存在大量矩陣乘法運算，且高度依賴上下文信息。每次推理都需要將之前生成過的詞重新輸入模型進行計算。這種計算方式使得復(fù)雜度達到了 O（N2），其中必然存在大量的重復(fù)計算。

例如，給定“天氣”，模型會逐個預(yù)測剩下的字，假設(shè)接下來預(yù)測的兩個字為“真好”。

將“真”拼接到“天氣”的后面，即新的輸入為“天氣真”，再預(yù)測“好”。

4.1.3 流式響應(yīng)

有時候模型推理延時實在避免不了，可以從工程交互上想辦法。傳統(tǒng)后臺服務(wù)的 RPC 通信是一問一答方式，這種方式不太適合語音合成或者文本對話的場景。因為大模型推理需要幾秒-幾十秒，如果等待模型推理結(jié)束才展示結(jié)果，用戶會等待較長的時間，體驗很差。

流式響應(yīng)就是當模型推理計算得到第一個token或者第一個音頻幀的時候，立馬展示或者播放給用戶，同時后續(xù)的模型推理結(jié)果在已經(jīng)建立的 TCP 流上繼續(xù)順序傳輸。工程上從關(guān)注模型推理的整體耗時，改為關(guān)注首token或首個音頻幀的耗時。幾乎所有的 LLM 推理框架都支持了流式響應(yīng)。

4.2 提高吞吐量

提高吞吐量是程序員在傳統(tǒng) Infra 領(lǐng)域孜孜不倦的追求，因為更高的吞吐量意味著更低的機器成本。實現(xiàn) AI 應(yīng)用的高吞吐本質(zhì)上就是提高昂貴的 GPU 的利用率，讓 GPU 單位時間能完成更多的任務(wù)。

盡管模型推理需要執(zhí)行萬億次浮點運算，但 GPU 有大量的計算單元（CUDA Cores），單個請求的模型推理很難令 GPU 利用率達到飽和。提高 GPU 利用率有2個方法：傳統(tǒng)批處理和連續(xù)批處理。這里的“傳統(tǒng)批處理”是相對于“連續(xù)批處理”這樣的新型批處理方式而言的。

4.2.1 傳統(tǒng)批處理

其實傳統(tǒng)后臺服務(wù)也大量使用了批處理，例如 Redis 的 MGet 命令，單次請求就完成所有 key 的獲取，將 N 次網(wǎng)絡(luò)往返（RTT）壓縮為1次。與之相似，模型推理的批處理就是將多個輸入樣本打包（batch），將原本串行的 N 次輕量的推理計算，合并為 1 次重量的計算，實現(xiàn)單位時間內(nèi)處理更多的請求，提高了 GPU 利用率。

“打包輸入樣本”是一個共性需求，大部分推理框架都提供該功能，例如 Triton Inference Server 的 Batcher 。

（模型批量推理流程圖）

4.2.2 連續(xù)批處理

傳統(tǒng)批處理類似 “固定班次的公交車”：乘客（請求）必須等待發(fā)車時間（組建一個batch），發(fā)車后所有乘客同步前進。即使有乘客提前下車（短請求完成），車輛仍需等待所有乘客到達終點（長請求完成）才能返程接新乘客。傳統(tǒng)批處理存在著資源浪費：GPU 要等待長請求處理完，不能處理新的請求而空閑。

這個問題在 LLM 應(yīng)用領(lǐng)域顯得特別突出，因為不同用戶請求 Prompt，模型的回答結(jié)果長度差異巨大，如果使用傳統(tǒng)批處理，GPU 空閑率很高。這個本質(zhì)上是個任務(wù)調(diào)度問題，傳統(tǒng)后臺服務(wù)我們使用工作竊取算法（work stealing）解決線程空閑問題，與之相似，AI Infra 提出“連續(xù)批處理”解決這個問題。

連續(xù)批處理類似“隨時隨地拼車的順風車”，每輛車（GPU）在行程中可隨時上/下客。新乘客（請求）直接加入當前車輛的空位（空閑計算單元），已完成的乘客立即下車（釋放資源）。幾乎所有的 LLM 推理框架都支持了連續(xù)批處理能力，例如 vLLM 的 Continuous Batching。

（連續(xù)批推理流程圖）

結(jié)語

AI Infra 面對的工程挑戰(zhàn)，例如計算、存儲、通信，大部分是新時代的老問題，我們在傳統(tǒng) Infra 領(lǐng)域都能找到對應(yīng)的場景和解決思路。差異只在于戰(zhàn)場從 CPU 轉(zhuǎn)移到 GPU，傳統(tǒng)后臺工程師積累的方法論，依然可以無縫銜接到 AI Infra。

感謝你讀到這里，不如關(guān)注一下？