如何在 LLM 推理中戰(zhàn)勝不確定性
最近thinkingmachines的一篇博文在內(nèi)外網(wǎng)引起了無數(shù)的關(guān)注和轉(zhuǎn)載，這篇文章的核心內(nèi)容先是解釋了一下為什么LLM推理會有不確定性，隨后文章還給出了具體的解決方案。
在詳細(xì)介紹文章的內(nèi)容之前，我們先來說一下thinkingmachines這家公司。它是由前OpenAI首席技術(shù)官Mira Murati與多位前OpenAI高管聯(lián)合創(chuàng)立。Murati 這個人經(jīng)歷也比較神奇，首先她并不是AI科班出身，最早是在Tesla擔(dān)任model X的產(chǎn)品經(jīng)理。然后在2016年加入openAI，并一路升到了openai的CTO，你不得不佩服在牛人面前行業(yè)或者說專業(yè)門檻似乎根本不存在。
說完上面的八卦之后，我們開始進(jìn)入正題，先來聊一下LLM推理過程當(dāng)中的不確定性是如何產(chǎn)生的。
在這篇文章出現(xiàn)之前，大多數(shù)人認(rèn)為之所以產(chǎn)生不確定性主要是以下兩個原因?qū)е碌?
- 浮點數(shù)不滿足結(jié)合律:以加法運算為例，咱們平時覺得（a+b）+c 和 a+（b+c）結(jié)果肯定一樣，但用電腦里的 “浮點數(shù)”（比如表示 0.1、1e20 這種數(shù)的格式）算，還真不一樣！
（0.1 + 100000000000000000000）- 100000000000000000000，結(jié)果是 0；
0.1 +（100000000000000000000 - 100000000000000000000），結(jié)果是 0.1。其實，這個很好理解，因為因為浮點數(shù)只能存有限位數(shù)的精度，加超大數(shù)再減，小數(shù)的 “精度” 就被丟掉了。這就導(dǎo)致了如果一堆浮點數(shù)加的順序不一樣，最后結(jié)果可能就不一樣。
2. GPU并行計算：很多人會覺得GPU 是多核心并行計算，誰先算完不一定，所以結(jié)果不一樣。
針對上面的兩個誤解，文章也一一給了回應(yīng)。首先，浮點數(shù)由于計算順序不同而導(dǎo)致丟精度確實不假，但是這個不是導(dǎo)致推理不確定性的直接原因；其次，GPU并行計算的這個說法壓根就是錯誤的，因為現(xiàn)在的 GPU kernel早就能避免 “誰先算完影響結(jié)果” 了。只有一種情況會讓 GPU 算得不一樣 —— 用 “原子加法”（多個核心往同一個數(shù)上加，誰先加不確定）。但 LLM 推理時，根本不用 “原子加法”！所以 GPU 并行不是罪魁。
文章中為了更好的解釋這個問題，提出了一個叫“batch-invariance”中文可以譯為“批次不變性”。而之所以LLM在推理時會產(chǎn)生不確性主要是因為很多的計算內(nèi)核(kernel)不滿足“批次不變性”。簡單來說就是，用戶提交的同一個推理請求單獨算和跟別人一起打包算，結(jié)果可能不一樣。文章當(dāng)中舉了一個具體的實際例子。
import torch
torch.set_default_device('cuda')
B = 2048
D = 4096
a = torch.linspace(-1000, 1000, B*D).reshape(B, D)
b = torch.linspace(-1000, 1000, D*D).reshape(D, D)
# Doing a matrix vector multiplication by taking
# the first element of the batch
out1 = torch.mm(a[:1], b)
# Doing a matrix matrix multiplication and then taking
# the first element of the batch
out2 = torch.mm(a, b)[:1]
print((out1 - out2).abs().max()) # tensor(1669.2500, device='cuda:0')上述例子當(dāng)中，用 GPU 算矩陣乘法，先取第一個請求的矩陣單獨算（out1），再把所有請求打包算完后取第一個結(jié)果（out2），兩者差了 1669 多 —— 這可不是小誤差！文章還提到一個叫運行間確定性，意思是說同一批次運算結(jié)果是一樣的。
但是現(xiàn)在很多時候，為了提高LLM推理時GPU的利用率，一都使用動態(tài)批次調(diào)度的算法。也就是說，會根據(jù)當(dāng)時服務(wù)器的繁忙程度來動態(tài)調(diào)整批次的大小。
既然問題已經(jīng)找到了，那如何解決呢？文章提到，要讓 LLM 推理穩(wěn)定，就得讓每個計算步驟（主要是 3 個關(guān)鍵步驟）不管批次大小多少，算出來都一樣。這三個步驟按難度從低到高排序依次是：
1. 歸一化（RMSNorm）：給每個請求 “專屬核心”
RMSNorm 是給數(shù)據(jù)做歸一化的步驟，計算時需要 “求和取平均”。原來的問題：批次小的時候，GPU 核心用不完，就會讓多個請求共享一個核心，算的時候求和順序變了，結(jié)果也就不一樣了。解決辦法：不管批次大小，每個請求分配一個核心，讓每個請求的求和順序固定。就算批次小、有些核心空閑，也不共享 —— 大不了慢一點，換結(jié)果穩(wěn)定。
2. 矩陣乘法：固定 “計算瓷磚大小”
矩陣乘法是 LLM 的核心計算，快的關(guān)鍵是把大矩陣切成小 tile（比如 128x128），讓 GPU 高效算。原來的問題：批次小的時候，tile切得不一樣（比如批次 1 時不用大tile，批次 10 時用大tile），乘法順序變了，結(jié)果差了。解決辦法：不管批次大小，都用同一種 “tile大小” 算。哪怕批次小的時候有點浪費算力，也不換tile —— 性能會降一點（比如比最快的情況慢 20%），但結(jié)果穩(wěn)定。
3. 注意力機制（Attention）：固定 “拆分大小”
注意力是 LLM 理解上下文的關(guān)鍵，計算時要處理 “查詢（Q）” 和 “鍵值（KV）” 的匹配，需要求和。原來的問題：處理長文本時，KV 會存在緩存里，批次不同時，緩存里的 KV 和新算的 KV 結(jié)合方式不一樣（比如批次 1 時拆成 3 段算，批次 5 時拆成 2 段算），求和順序變了。解決辦法：不管批次和緩存里有多少 KV，都按 “固定大小拆分”（比如每次拆 256 個元素），哪怕最后一段不夠 256 個，也按這個規(guī)則拆 —— 確保求和順序永遠(yuǎn)一樣。
文章中基于上述的方法實現(xiàn)了相應(yīng)的batch-invariant 相關(guān)實現(xiàn)，具體結(jié)果如下：
- 用 Qwen3-235B 在溫度 0、同一提示詞采 1000 次，默認(rèn)內(nèi)核得到 80 種不同結(jié)尾；換成 batch-invariant 內(nèi)核后，1000 次完全一致。
- 性能上，在單 GPU、Qwen-3-8B 的例子里：vLLM 默認(rèn) 26s，未經(jīng)深度優(yōu)化的“確定性模式” 55s，改進(jìn)注意力后 42s。可見“可用、不至于災(zāi)難”。
當(dāng)然，上面主要是從我自己的視角對這篇博文的提煉，我強烈建議大家去讀一下原文。具體地址見引用。
