本文將分享傳統(tǒng)后臺工程師積累的技術(shù)棧和方法論，如何延續(xù)并遷移到 AI 系統(tǒng)，并系統(tǒng)性拆解 AI Infra 的硬件、軟件、訓(xùn)練和推理挑戰(zhàn)。

作者 | rayrphuang

AI Infra 和傳統(tǒng) Infra 有什么區(qū)別？程序員積累的技術(shù)棧和方法論，如何復(fù)用到 AI 系統(tǒng)架構(gòu)設(shè)計(jì)上？

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

一、硬件演進(jìn)

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

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

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è)計(jì)的瓶頸。

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

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

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

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

2. 從"去IOE"到"AI大型機(jī)"

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

IBM大型機(jī)

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

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

二、軟件演進(jìn)

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

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

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

1. 深度學(xué)習(xí)框架

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

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

大家可能聽說過不同的深度學(xué)習(xí)框架——Tensorflow，PyTorch。現(xiàn)在是2025年，不用糾結(jié)選哪個(gè)，因?yàn)?PyTorch 就是 AI 模型訓(xùn)練、推理的深度學(xué)習(xí)框架的事實(shí)標(biāo)準(zhǔn)。開源模型和代碼都是 PyTorch 一邊倒。

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

2. GPU 編程

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

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

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

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

3. Python 編程

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

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

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

三、模型訓(xùn)練的挑戰(zhàn)

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

1. 存得下

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

(1) 顯存刺客：中間激活

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

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

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

(2) 模型并行

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

不同的模型并行策略

2. 算得快

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

(1) 通信計(jì)算重疊

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

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

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

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

1. 降低延時(shí)

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

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

(1) CUDA Graph

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

CPU 和 GPU 通信

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

多個(gè) GPU 內(nèi)核啟動(dòng)轉(zhuǎn)化為 CUDA Graph

(2) KV Cache：空間換時(shí)間

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

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

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

觀察到，經(jīng)過多次預(yù)測后，X @ W_K 和 X @ W_V 的結(jié)果上半部分都是相同的。這是由于 LLM 模型結(jié)構(gòu)的特殊設(shè)計(jì)導(dǎo)致的。這些重復(fù)計(jì)算的結(jié)果可以緩存（即 KV Cache）下來，空間換時(shí)間，減少計(jì)算量。幾乎所有的 LLM 推理框架都支持了 KV Cache，例如vLLM 。

(3) 流式響應(yīng)

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

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

2. 提高吞吐量

提高吞吐量是程序員在傳統(tǒng) Infra 領(lǐng)域孜孜不倦的追求，因?yàn)楦叩耐掏铝恳馕吨偷臋C(jī)器成本。實(shí)現(xiàn) AI 應(yīng)用的高吞吐本質(zhì)上就是提高昂貴的 GPU 的利用率，讓 GPU 單位時(shí)間能完成更多的任務(wù)。

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

(1) 傳統(tǒng)批處理

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

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

(2) 連續(xù)批處理

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

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

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

五、結(jié)語

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