最近thinkingmachines的一篇博文在內外網引起了無數(shù)的關注和轉載，這篇文章的核心內容先是解釋了一下為什么LLM推理會有不確定性，隨后文章還給出了具體的解決方案。

在詳細介紹文章的內容之前，我們先來說一下thinkingmachines這家公司。它是由前OpenAI首席技術官Mira Murati與多位前OpenAI高管聯(lián)合創(chuàng)立。Murati 這個人經歷也比較神奇，首先她并不是AI科班出身，最早是在Tesla擔任model X的產品經理。然后在2016年加入openAI，并一路升到了openai的CTO，你不得不佩服在牛人面前行業(yè)或者說專業(yè)門檻似乎根本不存在。

說完上面的八卦之后，我們開始進入正題，先來聊一下LLM推理過程當中的不確定性是如何產生的。

在這篇文章出現(xiàn)之前，大多數(shù)人認為之所以產生不確定性主要是以下兩個原因導致的:

1. 浮點數(shù)不滿足結合律:以加法運算為例，咱們平時覺得（a+b）+c 和 a+（b+c）結果肯定一樣，但用電腦里的 “浮點數(shù)”（比如表示 0.1、1e20 這種數(shù)的格式）算，還真不一樣！

（0.1 + 100000000000000000000）- 100000000000000000000，結果是 0；
0.1 +（100000000000000000000 - 100000000000000000000），結果是 0.1。

其實，這個很好理解，因為因為浮點數(shù)只能存有限位數(shù)的精度，加超大數(shù)再減，小數(shù)的 “精度” 就被丟掉了。這就導致了如果一堆浮點數(shù)加的順序不一樣，最后結果可能就不一樣。

2. GPU并行計算：很多人會覺得GPU 是多核心并行計算，誰先算完不一定，所以結果不一樣。

針對上面的兩個誤解，文章也一一給了回應。首先，浮點數(shù)由于計算順序不同而導致丟精度確實不假，但是這個不是導致推理不確定性的直接原因；其次，GPU并行計算的這個說法壓根就是錯誤的，因為現(xiàn)在的 GPU kernel早就能避免 “誰先算完影響結果” 了。只有一種情況會讓 GPU 算得不一樣 —— 用 “原子加法”（多個核心往同一個數(shù)上加，誰先加不確定）。但 LLM 推理時，根本不用 “原子加法”！所以 GPU 并行不是罪魁。

文章中為了更好的解釋這個問題，提出了一個叫“batch-invariance”中文可以譯為“批次不變性”。而之所以LLM在推理時會產生不確性主要是因為很多的計算內核(kernel)不滿足“批次不變性”。簡單來說就是，用戶提交的同一個推理請求單獨算和跟別人一起打包算，結果可能不一樣。文章當中舉了一個具體的實際例子。

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')

上述例子當中，用 GPU 算矩陣乘法，先取第一個請求的矩陣單獨算（out1），再把所有請求打包算完后取第一個結果（out2），兩者差了 1669 多 —— 這可不是小誤差！文章還提到一個叫運行間確定性，意思是說同一批次運算結果是一樣的。

但是現(xiàn)在很多時候，為了提高LLM推理時GPU的利用率，一都使用動態(tài)批次調度的算法。也就是說，會根據(jù)當時服務器的繁忙程度來動態(tài)調整批次的大小。

既然問題已經找到了，那如何解決呢？文章提到，要讓 LLM 推理穩(wěn)定，就得讓每個計算步驟（主要是 3 個關鍵步驟）不管批次大小多少，算出來都一樣。這三個步驟按難度從低到高排序依次是：

1. 歸一化（RMSNorm）：給每個請求 “專屬核心”

RMSNorm 是給數(shù)據(jù)做歸一化的步驟，計算時需要 “求和取平均”。原來的問題：批次小的時候，GPU 核心用不完，就會讓多個請求共享一個核心，算的時候求和順序變了，結果也就不一樣了。解決辦法：不管批次大小，每個請求分配一個核心，讓每個請求的求和順序固定。就算批次小、有些核心空閑，也不共享 —— 大不了慢一點，換結果穩(wěn)定。

2. 矩陣乘法：固定 “計算瓷磚大小”

矩陣乘法是 LLM 的核心計算，快的關鍵是把大矩陣切成小 tile（比如 128x128），讓 GPU 高效算。原來的問題：批次小的時候，tile切得不一樣（比如批次 1 時不用大tile，批次 10 時用大tile），乘法順序變了，結果差了。解決辦法：不管批次大小，都用同一種 “tile大小” 算。哪怕批次小的時候有點浪費算力，也不換tile —— 性能會降一點（比如比最快的情況慢 20%），但結果穩(wěn)定。

3. 注意力機制（Attention）：固定 “拆分大小”

注意力是 LLM 理解上下文的關鍵，計算時要處理 “查詢（Q）” 和 “鍵值（KV）” 的匹配，需要求和。原來的問題：處理長文本時，KV 會存在緩存里，批次不同時，緩存里的 KV 和新算的 KV 結合方式不一樣（比如批次 1 時拆成 3 段算，批次 5 時拆成 2 段算），求和順序變了。解決辦法：不管批次和緩存里有多少 KV，都按 “固定大小拆分”（比如每次拆 256 個元素），哪怕最后一段不夠 256 個，也按這個規(guī)則拆 —— 確保求和順序永遠一樣。

文章中基于上述的方法實現(xiàn)了相應的batch-invariant 相關實現(xiàn)，具體結果如下：

1. 用 Qwen3-235B 在溫度 0、同一提示詞采 1000 次，默認內核得到 80 種不同結尾；換成 batch-invariant 內核后，1000 次完全一致。
2. 性能上，在單 GPU、Qwen-3-8B 的例子里：vLLM 默認 26s，未經深度優(yōu)化的“確定性模式” 55s，改進注意力后 42s。可見“可用、不至于災難”。
   

當然，上面主要是從我自己的視角對這篇博文的提煉，我強烈建議大家去讀一下原文。具體地址見引用。