【TL;DR】
大型語言模型（LLM）雖然能解決高難度的數學問題，達到研究級水準，但在需要多步驟推理與長上下文的簡單計算任務上卻表現不佳。即使是兩個數字的乘法，或是解開小型數獨，對它們來說幾乎都不可能完成，除非依賴外部工具。
《但究竟需要什麼條件，才能讓 LLM 本身像電腦一樣可靠且有效率？》
我們透過在 Transformer 內部實際打造一台電腦來回答這個問題。我們將任意 C 語言程式碼轉換成 token，讓模型本身能夠在數秒內可靠地執行數百萬個步驟。
以下展示的是透過匈牙利演算法解決最小成本完美配對（min-cost perfect matching）優化問題時的運作方式——這是一個需要多步驟執行的問題。
[圖表：展示使用匈牙利演算法解決 10×10 最小成本配對問題的互動式執行過程，顯示逐步指派的運算追蹤與成本計算]
模型並未呼叫外部工具，而是透過 Transformer 權重直接執行程式，產生逐步的執行追蹤（execution trace）token，並在 CPU 上達到每秒超過三萬個 token 的處理速度。
這項技術的核心概念是一種全新的執行追蹤解碼路徑，它將模型中的注意力查詢從線性掃描轉換為對數時間的查詢，讓單次 Transformer 執行就能完成數百萬個正確的執行步驟。
【研究動機：LLM 無法計算】
目前最先進的語言模型能夠解決極具挑戰性的數學問題，有系統甚至能在國際數學奧林匹亞（IMO）達到金牌水準，或是處理開放的數學與科學難題。
然而，一個棘手的落差依然存在：即使是最先進的模型，在面對純粹計算性的任務時仍然會出錯。它們連基本的加法都會算錯，甚至連簡單的數獨題目都無法獨立解開。Sudoku-Bench 等基準測試讓這種失敗模式特別明顯，顯示未經輔助的解題率很低。
實務上，我們透過兩類權宜之計來填補這個落差：
• 工具使用：模型撰寫程式碼，由外部直譯器執行，再由模型回報結果。整合工具的方法可顯著提升數學推理能力。
• 智慧型編排：外層迴圈儲存中間狀態、分解任務，並在短上下文上反覆呼叫模型，實際上等同於在模型外部加裝一台狀態機。
這些方法非常實用，但它們凸顯了一個重要的限制：LLM 本身無法可靠地執行長且精確的計算，因此在實務上我們常將執行工作外包給外部工具或編排系統。
有個類比可以釐清這個區別。人類無法飛行。建造飛機並沒有改變這點，那只代表我們建造了會飛行的機器來代替我們。
今日的語言模型處於相同情境。當任務需要精確計算時，我們附加外部系統（直譯器、程式執行器、智慧代理迴圈），讓這些系統來執行計算工作。
但這意味著能力仍然存在於模型之外。模型本身根本受到限制：它無法執行它正在推理的計算，因此必須反覆將任務移交給另一個系統。
結果是，模型可以描述演算法、推理演算法，或編排工具來執行演算法，但它無法自己執行這些步驟。一個無法計算的系統，無法真正內化計算是什麼。
因此，真正的問題不在於模型能否談論計算，甚至能否透過工具存取計算。真正的問題是它能否在內部執行計算：可靠、有效率，而且能持續非常長的執行跨度。如果能夠，它就會從單純的計算協調者，轉變成電腦本身。
【我們如何將 LLM 變成電腦】
表面上看來，一切都沒有問題。驅動 LLM 的 Transformer 架構本身就極具能力。許多研究已經證明，不同變體的 Transformer 能夠執行複雜的計算，因為它們可以模擬圖靈機，因此能夠模擬任何有效的電腦。近期研究更顯示，它們甚至可以透過訓練獲得這些計算能力。
但理論上的通用性並不等於實際的執行能力。一個模型可能在表達能力上足以模擬電腦，但在實務上仍然是糟糕的電腦。傳統的通用性結果常仰賴於特定建構方式：真實機器中的簡單操作，對應到模擬模型中的冗長步驟序列。換句話說，表達能力本身並不保證實際的執行效率。
《我們透過在 Transformer 內部實作一台現代隨機存取記憶體（RAM）電腦來解決這個問題，而非純粹的理論計算模型。在我們的建構中，每個指令僅對應到少數幾個 token（最多 5 個）。》
但這樣還不夠。更深層的問題在於解碼過程本身。
Transformer 作為執行者存在結構上的劣勢：標準的自迴歸解碼讓每個步驟都必須與完整累積的歷史互動。真實的電腦會以大致恆定的工作量更新緊湊的狀態。而 Transformer 則是一次產生一個 token，同時持續與不斷增長的前綴互動。KV 快取（KV caching）避免了重新計算過去的鍵值投影，但解碼仍然需要關注已快取的前綴，因此每個步驟的工作量仍與序列長度相關。
《我們透過證明 Transformer 架構允許針對執行式追蹤的高效解碼方式，來消除這個劣勢。關鍵的技術突破是將查詢頭（lookup heads）限制在二維（head dimension 2），這使得解碼路徑中的主要檢索與更新運算可以在序列長度的對數時間內完成（針對這種結構化的執行器模式），而非完整的線性前綴注意力掃描。》
這強大到足以讓我們在 Transformer 內部執行任意程式達數百萬個步驟。
本文的其餘部分將詳細解釋這如何運作。歡迎跳至以下各節：
• 計算是什麼意思？——模型內執行與工具使用的差異：Transformer 自行一步步執行程式。
• 更多展示：數獨——在 Transformer 內部執行編譯過的解題器，解開被譽為世界最難的 Arto Inkala 數獨。
• 計算如何被編碼？——執行作為僅能追加的追蹤，以及 Transformer 如何透過回顧先前步驟來重建狀態。
• 指數級快速注意力——核心突破：二維注意力頭將注意力轉換為凸包查詢，實現在百萬步追蹤上的對數時間解碼。
• 接下來是什麼？——更豐富的注意力機制、大規模訓練、將程式編譯進權重，以及像軟體般成長的 AI 系統。
【計算是什麼意思？】
現今，當模型需要進行計算時，它會撰寫程式碼。例如，要計算 3+5，模型可能會輸出：
python -c "print(3+5)"
接著生成暫停。外部工具使用機制攔截這段程式碼，將其傳送到沙盒化的直譯器中執行，並將結果（8）注入回 token 串流。模型接著繼續，現在已經知道答案了。
這樣做有效，但實際的執行發生在模型外部。模型指定了計算，然後等待外部系統來執行。
我們的 Transformer 也會發出程式，但不是暫停等待外部工具，而是自己一步步在 Transformer 內部執行該程式。
為了達成這點，我們在 Transformer 權重內部實作了一個 WebAssembly 直譯器。WebAssembly 是一種低階指令集，設計用於快速、確定性的執行，也是 C 和 C++ 等語言可以編譯的通用目標。要計算 3+5，模型會撰寫：
{ i32.const 03 00 00 00 i32.const 05 00 00 00 i32.add 00 00 00 00 output 00 00 00 00 }
接著模型切換到快速解碼模式，在 Transformer 內部一步步執行該程式，產生 token 組成的執行追蹤：
03 00 00 00 commit(+1,sts=1,bt=0)
05 00 00 00 commit(+1,sts=1,bt=0)
08 00 00 00 commit(-1,sts=1,bt=0)
out(08)
halt
每一行包含模型產生的 token。堆疊增長，執行加法，輸出結果，然後停止，全部都在模型自己的輸出串流中完成，沒有外部往返。
[圖表：比較「工具使用」與「模型內執行」兩種流程，顯示外部工具呼叫與內部執行追蹤的差異]
關鍵差異在於工具使用是不透明的：模型交出控制權並收到一個黑箱答案。模型內執行則是透明的：每個中間步驟都顯示在追蹤中，而且模型從未離開自己的解碼迴圈。
【更多展示：數獨】
數獨是測試精確長期計算能力的另一個有效壓力測試。學習型神經網路方法可以在簡單或隨機的數獨上表現良好，但在困難的題目上完全失敗。常見的解釋是自迴歸模型基本上不適合約束滿足問題（constraint-satisfaction problems），因為它們逐個 token 提交答案，無法修正早期的錯誤。但我們的全自迴歸系統在這些基準測試上達到 100% 準確率，這暗示真正的瓶頸不在於自迴歸範式本身——而是解開困難數獨需要非常長的執行追蹤，而標準注意力機制讓長上下文生成變得過於昂貴。這正是我們的快速注意力路徑要解決的問題。
我們的系統在 Transformer 內部執行完全正確的編譯後數獨解題器。沒有學習式啟發法取代演算法，也沒有「模型建議解決方案」與「外部系統驗證」之間的落差。Transformer 一步步執行解題器。
這個保證是普世的而非僅針對特定基準：如果編譯後的解題器正確，Transformer 的執行也正確。實務上，這讓模型能夠解開甚至像 Arto Inkala 數獨這樣著名的難題，在不到三分鐘內達到正確解答。
[圖表：展示 Arto Inkala 數獨的互動式求解過程，顯示深度優先搜尋的執行步驟與數獨格子的填寫狀態]
【計算如何被編碼？】
理解自迴歸 Transformer 的有用方式是將其視為存活於自身歷史中的機器。傳統電腦有可編輯的記憶體，會隨著操作結果而更新。但在 Transformer 中沒有這種東西。
有一個固定的提示（輸入或程式）。然後有一個只會增長的追蹤（模型生成的 token）。在每個步驟中，模型只能透過少數幾個查詢（注意力頭）來「回望」過去，然後必須再附加一個 token。透過這個過程，我們需要找到一種方法來編碼一台運作中的機器。
為了建立對這個模型運作方式以及編碼如何運作的直覺，思考以下內容會有幫助。
【僅能追加的追蹤形式的計算】
要理解 Transformer 如何內部執行程式，將計算想成稍微不同的方式會有幫助。
想像一本筆記本，計算的每個步驟都寫在下一行。一旦寫下，前面的行就無法更改；筆記本只會不斷增長。
• 前幾行包含輸入（提示）。
• 每一新行記錄計算的下一步。
• 在每一步中，你可以回顧前面的行，但無法編輯它們。
這與自迴歸 Transformer 的運作方式驚人地接近：提示就是輸入，生成的 token 形成不斷增長的追蹤，而每個新 token 都是在透過注意力回顧少數幾個位置後產生的。
這裡有個簡單的例子。給定一個句子，計算動詞數量是奇數還是偶數。每個追蹤 token 恰好關注兩個位置：對應的輸入詞（檢查是否為動詞）和前一個追蹤 token（讀取目前的奇偶性）。
[圖表：展示單詞序列的注意力模式，說明每個執行步驟如何關注輸入詞與前一個追蹤狀態]
注意每個步驟只需要兩次回顧（一次到提示，一次到追蹤），無論句子多長。這是關鍵洞察：許多演算法可以表達為只會追加的追蹤，其中每個步驟只需要讀取固定數量的前面位置。
《計算能否被表示為一種只會追加的追蹤，其中每個步驟只需要回顧少數幾次？》
答案是肯定的。在我們的系統中，模型明確生成這樣的追蹤。它產生的 token 代表虛擬機器的演變狀態：指令指標、記憶體與堆疊操作、算術運算、控制流程和輸出。模型只需回顧相關的先前步驟就能重建目前狀態。
【技術說明：Transformer 能回顧什麼？】
在 Transformer 中，回顧操作比單純檢視過去的 token 更具表達能力。每個步驟還可以讀取決定要產生哪個 token 時計算出的中間狀態——這些對應儲存在不同注意力層中的數值。這樣想：每個注意力頭就像一個共享的一維陣列。處理 token 時，該頭首先在某個索引寫入一個值，然後可能（在另一個可能不同的索引）讀取一個值——一個寫入後面最多跟著一個讀取，順序如此。每個 token 讀取先前 token 發布的值，並發布值來通知未來的決策。
除了這個讀寫原語，注意力還可以計算累積和（cumulative sums）。這讓我們可以追蹤指令指標、運算元堆疊深度和呼叫堆疊深度等量，將它們作為 delta 增量的運行總和。總之，索引查找和加總就足以運行複雜的計算。
本文其餘部分專注於效率挑戰：即使 Transformer 可以表示這樣的執行追蹤，標準解碼在追蹤變長時仍需付出遞增的成本。我們的快速解碼路徑消除了這個劣勢，而二維注意力頭限制正是讓快速路徑成為可能的關鍵解鎖。
【關鍵突破：指數級快速注意力】
真實的電腦透過以近恆定的工作量更新緊湊狀態（暫存器、堆疊、記憶體）來執行長程式。
標準 Transformer 透過生成 token 來「推進狀態」，而每個下一個 token 是透過對永遠增長的前綴進行注意力計算來得出。KV 快取會重複使用先前計算過的鍵值，但它並未移除基本的擴展性：在每個步驟中，查詢仍然必須與隨生成 token 數量增長的快取互動。這就是為什麼解碼研究常變成 IO 問題：瓶頸變成「讓 KV 快取夠快，並對其進行評分」。
但無論 KV 快取做得多快，基本的擴展性仍然存在：第 t 個解碼步驟仍然必須與長度為 t 的前綴互動。這意味著每個步驟的工作量與追蹤長度線性增長，而生成 t 個 token 的總成本呈二次方增長。這是 Transformer 眾所周知的瓶頸，如何設計更快的替代方案也是活躍的研究領域。
如我們將在下文解釋的，我們的方法解決了二次方爆炸問題，並產生指數級更快的注意力查詢。我們的方法每個步驟只需 O(log t) 時間，而非 Θ(t) 時間。以下是實務上的展現，比較我們的 HullKVCache 與標準 KVCache：
[圖表：對比 HullKVCache 與標準 KVCache 的執行速度與 token 生成量，顯示 HullKVCache 達到每秒 31,037 token，而標準 KVCache 僅 673 token]
在我們關注的工作負載中（長執行追蹤，其中模型重複執行少數結構化查找），每個步驟的擴展性差異會產生複合效應。
線性掃描解碼器付出的成本會隨著追蹤增長而持續增加。基於凸包（hull-based）的解碼器則將每個步驟的成本本質上維持在與對數時間的檢索原語相關。在長期執行中，這改變了可行性的界限：在標準解碼下會慢到不切實際的計算，變得可以在數百萬個步驟內執行。
這也是為什麼收益在「枯燥」的確定性區段最為明顯：精確複製、狀態機步進，或長的機械式追蹤。這些正是我們不想花費完整注意力預算的地方。
【快速路徑：二維注意力】
我們透過重新建構問題來獲得這個加速。我們並非試圖全面提升 Transformer 的速度，也不想引入另一種架構。
相反地，我們聚焦於標準 Transformer，但採用可處理的參數化設定。我們特別針對頭維度（head dimension）很小的情況：二維。
這並不代表整個 Transformer 很小。你仍然可以有任意多的層、任意多的注意力頭，以及任意大的嵌入維度。這只代表跨 Transformer 層使用的嵌入被分割成更小的區塊，產生更多的注意力頭 n_heads = d_model / 2。
當然，這個限制對某些任務可能付出代價，也不是所有問題的萬靈丹。雖然我們仍在探索在訓練大型模型時這有多麼受限，但我們發現它仍然足夠靈活以進行有效訓練，並且能夠捕捉非常複雜的邏輯。
事實上，就圖靈完備性（Turing completeness）而言，二維注意力就是全部所需！而且它就足以靈活到像本文展示的那樣，表徵一整台 RAM 電腦。這是建構 Transformer 快速路徑的關鍵推手。雖然抽象推理和規劃仍是原始路徑的一部分，但繁重的計算任務可以走快速路徑。
模型本身是一個完全標準的 PyTorch Transformer，沒有什麼奇特的：
class VanillaTransformer(nn.Module):
def __init__(self, vocab, d_model=36, n_heads=18, n_layers=7, d_ffn=36):
super().__init__()
self.tok = nn.Embedding(vocab, d_model)
self.attn = nn.ModuleList([
nn.MultiheadAttention(d_model, n_heads, batch_first=True, bias=False)
for _ in range(n_layers)
])
注意：d_model = 36 且 n_heads = 18 恰好給出每個頭二維。該架構使用 7 層、標準的 nn.MultiheadAttention，以及門控前饋網路。沒有自訂的注意力核心，沒有稀疏遮罩；只是標準的 PyTorch。讓它特別的只有權重。
讓我們看看二維注意力如何帶來這些令人印象深刻的加速。
【二維注意力的幾何視角】
[圖表：展示二維平面上的注意力機制，顯示查詢向量 q 與鍵 k_j 的幾何關係，以及凸包上的支撐點查詢]
注意力機制的運作方式如下：
• 每個過去的 token 貢獻一個鍵向量 k_j 和一個值 v_j，
• 當前步驟形成一個查詢向量 q，
• 為每個鍵計算相關性分數 q·k_j，並且
• 該頭回傳所有鍵的值總和，以它們分數的 softmax 重新加權。
在我們的快速路徑所特別關注的情況下：
• 每個鍵是二維的，k_j ∈ R²，
• 查詢 q ∈ R² 可以被想成平面的一個方向，
• 而我們想要最大化該方向點積的點的值（硬最大值注意力）。如果平手，我們計算平均值。
儘管最大化查詢是對整個歷史的全域操作，但存在高效的資料結構可以在對數時間內回答這樣的二維注意力查詢。這正是計算幾何中經典的「支撐點」（supporting point）查詢：給定方向 q，找出凸包上最遠的點。我們透過在生成 token 時維護這樣的資料結構來加速解碼，讓我們能夠在整組過去的點上高效搜尋。
將頭維度限制在二維正是讓快速路徑成為可能的原因：在推論期間，我們可以用一種結構來取代暴力掃描（「對每個鍵評分」），其中最大值只需查看凸包上的極少數點就能找到。
【技術說明：為什麼二維就足夠了？】
為了實作記憶體和堆疊操作，我們需要每個注意力頭能夠回答「給我索引 i 最近儲存的值」這個查詢。這種索引查找正是需要二維鍵的原因。
將每個索引 j 儲存為二維鍵 k_j = (2j, -j²)。這樣查找索引 i 就等同於在方向 q = (i, 1) 上查詢，因為
argmax_j { (2j, -j²) · (i,1) } = i
二次項 -j² 對任何 j≠i 都會產生懲罰，確保只有完全匹配會贏得 argmax。
注意力還可以計算累積和，我們用它來追蹤指令指標和堆疊深度等量。如果所有鍵都設為相同的值，注意力會均勻地平均所有值，而乘上目前的 token 位置 t 就能恢復實際的總和。這只需要一維（甚至零維）的鍵——是索引查找迫使我們使用二維。
【那麼，接下來是什麼？】
我們展示了 Transformer 可以成為電腦，這開啟了軟體與神經網路之間的新介面。一旦程式能夠在模型自己的推論迴圈中高效執行，一個更大的設計空間就此展開。
【更豐富的注意力機制】
為了簡化，我們的建構使用硬最大值注意力。但這不是根本的限制。雖然我們還不知道能否以相同的效率維護精確的 softmax 注意力，但用 k-稀疏 softmax 注意力來近似它很容易：檢索前 k 個鍵，並且只在這些鍵上執行 softmax。透過在嵌套凸包中儲存點，這產生 O(k + log n) 的解碼成本。
這意味著幾何快速路徑不限於我們的執行器建構。原則上，它可以加速任何在解碼時使用二維頭的 Transformer，用高效的幾何檢索取代完整的線性掃描。同樣的機制也自然地透過三維凸包擴展到三維頭，雖然更高維度會迅速變得沒效率。關鍵問題是二維是否已經捕捉到大部分的加速，還是稍大的頭維度能解鎖更多能力。
[圖表：展示嵌套凸包與 k-稀疏 softmax 的概念，比較標準 Transformer（4 個頭 × 64 維）與二維頭 Transformer（128 個頭 × 2 維）的架構差異]
【使用二維頭訓練大型模型】
這裡使用的二維頭參數化本身並不小。總參數量可以與標準 Transformer 相當，因為模型可以簡單地使用更多的頭和層。真正的問題是這樣的模型在大規模訓練時能變得多有能力。
這個問題甚至超越了純粹的能力。這些模型在幾種模式下都可能有用：作為專用的快速路徑，與較慢但更通用的模型配對；作為單一系統內快慢混合架構的一部分；或作為推測性執行模型，快速提出 token，而常規注意力模型驗證並接受它們。無論它們最終的能力上限為何，它們已經暗示了一個強大的系統原語，用於加速更大的模型。
[圖表：展示部署模式——快速路徑、快慢混合、推測性解碼——的示意圖]
這裡展示的系統是一個設計為執行器的獨立 Transformer。自然的下一步是將它與大型語言模型結合，並訓練模型在需要精確計算時呼叫這個執行路徑。在這樣的混合系統中，語言模型會進行規劃和推理，而執行元件會執行演算法。
因為執行追蹤是前向傳遞的一部分，整個過程保持可微分：我們甚至可以透過計算本身傳播梯度。這讓它 fundamentally 不同於外部工具。它成為一個可訓練的計算基質，可以直接整合到更大的模型中。
【將程式編譯進權重，以及超越梯度下降的訓練】
在我們目前的原型中，模型學習一個直譯器，其行為編碼在權重中。但我們為生成這些權重建置的編譯機制可以更進一步。原則上，任意程式都可以直接編譯進 Transformer 權重，完全不需要將它們表示為 token 序列。
[圖表：展示從 C 語言原始碼編譯到 Transformer 權重矩陣的流程圖]
這會讓權重本身成為軟體的部署目標。模型不僅僅是學習類似軟體的行為，而是字面上內含編譯後的程式邏輯，作為其內部電路的一部分。
如果邏輯可以編譯進權重，那麼梯度下降就不再是修改模型的唯一方式。權重編譯提供了另一條路徑，將結構、演算法和保證直接插入網路。
認真看待這個想法，這暗示了完全不同的訓練圖像：不僅僅是用資料優化權重，還直接編寫模型的部分。將這個想法推到極致，你會得到不僅從經驗中學習，還能修改或擴展自己權重的系統，有效地重寫自己的內部機制。
【像軟體般成長的 AI 系統】
最後，如果軟體成為神經架構的一部分，那麼 AI 系統就需要一種隨時間成長的方式，就像今天的軟體函式庫一樣。現代軟體生態系透過累積模組、抽象層和可重用元件來演進。類似的過程可能最終發生在 AI 系統內部，新的計算能力被逐步添加到模型的內部執行引擎。
[圖表：展示 AI 系統像軟體函式庫般模組化成長的示意圖，顯示核心、數學、排序、圖論、加密等模組的疊加]
我們的工作展示了 Transformer 可以在自己的推論迴圈內部高效執行程式，而非作為外部工具。更廣泛的願景是，未來的 AI 系統不僅僅使用軟體；它們會內含軟體，將學習到的表徵與編譯後的演算法整合在單一計算基質中。在那個世界裡，軟體本身成為模型的一部分。
【結語】
我們展示了 Transformer 可以在自己的推論迴圈內部高效執行程式，不是作為外部工具，而是作為模型本身的一部分。這開啟了一條通往 AI 系統的道路，能夠將學習到的表徵與編譯後的演算法整合在單一計算基質中。
我們認為這很重要，因為我們關心的最困難問題——醫療保健、供應鏈和金融機構中不確定環境下的順序決策制定——將需要能夠靈活推理且可靠計算的系統。
我們正在建構這些系統，而且我們正在招募人才。如果你想在語言模型、強化學習和真實世界決策系統的交匯點上工作，歡迎造訪 https://jobs.ashbyhq.com/percepta。