llama.cpp CUDA Fusion 合併，提示詞處理速度最高提升 10.7%

llama.cpp 於 10 月 25 日合併一項 CUDA 最佳化；貢獻者的基準測試顯示，DGX Spark 的提示詞處理效能最高可提升 10.7%。llama.cpp CUDA fusion 變更將模型前饋網絡內的操作合併；此前饋網絡負責在注意力機制各階段之間轉換 token 表示。其效益關乎讀取提示詞，而非產生其後的每個回答 token。

貢獻者 anujj 的測量亦顯示 NVIDIA RTX 5090 有所改善，惟所報告的百分比增幅較小。這些比較由作者自行報告，尚未經獨立重現。相關變更可在已合併的程式碼中核實，但其實際價值仍取決於模型格式、硬件及工作負載。

核心比較在於融合執行，即合併相關操作，與既有將這些操作分開排程的執行路徑。較早前的一項提案以不同方式尋求同一機會。已合併的方法重新安排數值傳遞至 GPU 執行緒的方式，在不改變儲存模型權重的情況下減少中間工作。對於本機執行長提示詞的開發者而言，這是一項值得相對現有部署加以量度的具體軟件改進。

llama.cpp CUDA fusion 合併帶來甚麼改變

這項已合併的變更，將既有最佳化延伸至受支援 NVIDIA 硬件上較大型的提示詞處理工作負載。

CUDA 是 NVIDIA 的 GPU 運算平台，為此實作提供執行環境。MMQ 是 llama.cpp 的量化矩陣乘法路徑，處理涉及壓縮模型權重的計算。量化以較低數值精度表示這些權重，從而降低儲存及記憶體需求。

這項已合併的 fusion 變更針對受支援密集前饋層內反覆出現的序列。獨立的 gate 與 up 投影會轉換相同輸入；其後，門控線性單元（GLU）透過激活函數及逐元素乘法，結合兩者結果。

此前，該路徑上的大型工作負載會把投影及其結合分作獨立操作處理。據 anujj 表示，新實作會透過單一矩陣乘法 kernel 執行該序列。Kernel 是在多個 GPU 執行緒上啟動的函數。

這種整合很重要，因為周邊工作同樣消耗資源。準備輸入、啟動操作、寫入中間結果及再次讀取，都會增加額外成本。合併操作可望減少部分資料傳輸，同時保留預期的數學轉換。

這項變更並非同時將此構想引入所有執行路徑。該貢獻者表示，小批次 fusion 已透過其他矩陣向量實作存在。矩陣向量計算通常服務於比此處所強調矩陣矩陣計算更小的工作負載。

這個分別解釋了為何公告聚焦提示詞處理。Prefill 即在生成回答前處理輸入提示詞的階段，可呈現較大批次的工作量。新獲支援的執行路徑正針對推論的這一部分。

時間線同樣重要。Pull request 的開場描述日期為 10 月 4 日，項目則於 10 月 25 日將其合併。這次合併使實作進入項目的 master branch，並不代表每個已封裝的應用程式均已包含該變更。

桌面應用程式、容器或下游項目均可按自身時間表納入 llama.cpp。因此，用戶需要識別介面背後實際使用的 runtime 版本。應用程式更新與上游原始碼合併是兩回事。

對既有模型檔案而言，相容性情況相對直接。該貢獻者指出，儲存權重的佈局維持不變。用戶不應把標題中對交錯列的提及，理解為必須下載經特別重新排列的模型檔案。

因此，眼前的消息範圍狹窄而具體：受支援的執行序列現於上游多了一項可用最佳化。特定請求是否會使用它，取決於 runtime 的資格檢查。

基準測試增幅較有利於 Spark，RTX 5090 的提升則較小

所報告結果在列出的配置中呈現一致方向，但其幅度隨硬件及量化方式而變。

作者以搭載 GB10 處理器的 DGX Spark 進行測試，並另行測試 RTX 5090。兩張基準測試表均將標示為 master 的基線與該 pull request 作比較。每一列均顯示修改後實作有較高的提示詞處理吞吐量。

在 DGX Spark 上，列出的最大百分比提升來自使用 IQ4_XS（一種壓縮權重格式）的 Llama-3.1-8B。吞吐量由每秒 2,933.9 個 token 增至每秒 3,249.0 個 token。作者報告該配置提升 10.7%。

Spark 上其他 Llama-3.1-8B 結果雖低於此峰值，仍保留可觀的報告增幅。Q4_K_M 配置由每秒 2,749.3 個 token 增至每秒 3,000.6 個 token；Q5_K_M 配置則由每秒 2,699.4 個 token 增至每秒 2,960.3 個 token。

這些標籤代表不同的量化模型配置，並非同一二進位檔可互換的測量結果。其結果顯示，評估最佳化時應配對確切檔案格式。一個模型系列名稱本身遺漏了一項相關變數。

Spark 表格亦列出標示為 Qwen3.8-27B 和 Qwen3.6-27B 的模型。此處按貢獻者報告中的基準測試標籤重現這些名稱。效能表本身並未獨立確立其訓練細節、能力或更廣泛的可用性。

對於標示為 Qwen3.8-27B 的項目，Spark 的改善介乎 4.6% 至 7.4%。Q4_K_M 一列由每秒 840.1 個 token 升至每秒 899.9 個 token；IQ4_XS 一列則由每秒 882.4 個 token 增至每秒 948.0 個 token。

RTX 5090 的結果呈現不同幅度的提升。作者在其列出的配置中報告 1.9% 至 4.7% 的增幅。這個較小的百分比範圍，使針對特定硬件的解讀變得必要。

對於 IQ4_XS 的 Llama-3.1-8B，RTX 5090 的結果由每秒 12,997.6 個 token 增至每秒 13,603.3 個 token，報告增幅為 4.7%。至於 Qwen3.8-27B Q6_K 項目，吞吐量由每秒 3,220.5 個 token 上升至每秒 3,281.0 個 token，即 1.9%。

因此，llama.cpp fusion 基準測試支持一項有限結論：在作者選取的長提示詞測試中，該最佳化提高了所報告矩陣中各配置的輸入吞吐量。但這並不證明每款受支援 GPU 都會獲得相同增幅。

百分比比較亦未揭示為何 Spark 獲益較多。不同的記憶體行為、執行特性及既有瓶頸均可能影響最佳化結果。要確立其相對貢獻，須進行額外效能剖析，單憑這些標題數據無法提供。

對買家而言，有用的啟示是評估紀律。這些結果不足以僅憑百分比增幅決定硬件選擇。絕對吞吐量、模型適配度、記憶體容量及實際應用程式延遲，仍是獨立考慮因素。

交錯列減少計算之間的工作

實作的核心做法，是在套用 gate 操作前先把相關結果排列在一起。

Anujj 描述會以每八個為一組、交替方式載入 gate 與 up 列。這種排列讓相應數值置於同一執行緒的工作結果中，該執行緒便可在寫入最終輸出時結合這些數值。

暫存器是分配給執行中執行緒的 GPU 小型儲存位置，用來保存這些中間結果。在該處套用組合操作，可避免該部分計算經由中間輸出緩衝區進行一次獨立往返。預期節省源自執行組織方式。

實作保留一種累加器排列，而非為 gate 投影引入第二個累加器 tile。累加器會在乘法期間保存部分總和；tile 則是一組一同處理的矩陣元素區塊。

這項設計選擇，令此實作有別於較早前的 fusion 提案。根據貢獻者的描述，較新的方法遵循 am17an 的建議。兩項提案均針對相關操作，但計算組織方式不同。

這個差異屬實務層面，而非表面差別。保存更多中間狀態，可能增加 GPU 有限執行資源的壓力。只有節省量超過額外排程或儲存成本時，合併操作才有幫助。

這正是「較少 kernel」不會自動等於「更快推論」的原因。在某些條件下，較大的合併操作可能較低效地使用硬件。最佳化必須保留足夠的平行工作，同時避免產生抵銷效益的新限制。

已合併的程式碼透過資格檢查反映這項考慮。它會評估工作負載是否適合這條 fusion 路徑。即使數學操作獲支援，也不保證應執行 fusion。

該實作亦與 stream-k 競爭；stream-k 是一種沿矩陣乘法歸約維度分割工作的排程方法。融合路徑無法使用該種分解方式，因此須另覓方法判斷其 tile 排列是否提供足夠效率。

Johannes Gaessler 在審查期間提出此問題，要求預先比較預期 tile 效率與 stream-k。已合併的程式碼在選擇融合路徑前包含效率判斷，因此條件式執行是設計的一部分。

這項fusion 排程審查為此最佳化提供了最有用的懷疑觀點。它聚焦於看似吸引人的簡化措施可能損失效能的情況。這是技術限制，而非對基準測試存在與否的爭議。

因此，這裏的主要競爭仍在 runtime 內部。融合執行必須在合資格操作形狀下勝過既有排程方法。這些結果並無證據顯示其在其他推論框架上取得更廣泛勝利。

這個機制亦釐清了用戶應如何看待 llama.cpp CUDA fusion。它是為既有計算重新組織工作，不會提高模型的推理能力、擴展其訓練知識，或消除無關的記憶體限制。

同一模型仍執行相同的一般任務。工程上的機會在於花較少時間取得某一特定序列的輸出。

更快的提示詞處理只改變等待時間的一部分

基準測試量度的是輸入處理，因此其實際價值取決於輸入處理在真實請求中所佔比例。

所報告的指令處理包含 16,384 個 token 的提示詞，並要求生成零個 token。Token 是模型消耗及產生的文字單位。此設定隔離提示詞吞吐量，而非量度完整對話回應。

該指令使用 2,048 的批次及微批次大小。微批次是從較大批次中劃分出的較小執行單位。它亦啟用 Flash Attention，這是一種旨在減少注意力計算期間記憶體流量的注意力實作方式。

作者為儲存鍵值快取指定半精度格式，該快取保存先前已處理 token 的注意力資訊。指令中出現五次重複。這些設定界定了測試條件，引用任何結果時亦應一併列出。

該專案的基準測試方法將提示處理與 token 生成區分開來。這項區分對解讀這些數字至關重要。每秒輸入 token 數與每秒輸出 token 數，回答的是不同的效能問題。

設想一名開發人員要求本地模型檢視一個大型原始碼檔案。處理該輸入可能會顯著增加答案開始前的延遲。較快的合資格預填路徑可改善互動中的這一部分。

簡短的對話交流則呈現另一種工作負載。與生成冗長回答所需的時間相比，其提示可能只需較少處理。相同的輸入吞吐量提升，因而只會影響總等待時間中較小的一部分。

已快取的提示又形成另一項區別。提示快取會重用系統已處理輸入的計算結果。當應用程式成功重用該項工作時，供此最佳化加速的新鮮輸入便會減少。

文件分析亦包含推論以外的工作。應用程式可能會擷取檔案、抽取文字、排列段落優先次序，或在向模型傳送任何內容前準備指令。更快的模型輸入處理並不表示這些周邊步驟也會更早完成。

對於維護可搜尋知識庫的團隊而言，這項區分有助作出更佳的效能決策。檢索品質及上下文選擇決定甚麼會送達模型。執行階段吞吐量則決定合資格計算能多快完成處理。

這項區分亦為應用程式維護者帶來壓力。他們需要知道產品採用哪一個執行階段，以及其常見工作負載是否會進入最佳化路徑。一則泛稱本地 AI 更快的發佈說明，無法回答這些問題。

有用的回應是在應用程式邊界進行量度。首個 token 時間量度輸出開始前的延遲。總回應時間量度整個互動，而生成吞吐量則量度輸出開始後的速度。

執行階段更新後，每項指標都可能有不同變化。預填改善可縮短初始等待時間，卻不會改變其後文字的生成速度。分開報告這些結果，能讓使用者更準確了解升級的影響。

對 llama.cpp 的提示處理而言，最有力的使用情境仍是合資格設定下新鮮而大量的輸入。作者的基準測試刻意強調這種工作負載。把其結果延伸至每一次聊天工作階段，便會超出證據所能支持的範圍。

支援格式及正確性檢查界定了邊界

合併後的程式碼包含重要限制，作者的正確性報告亦應在其所述測試覆蓋範圍內理解。

該 pull request 說明支援 NVIDIA Turing 或較新架構上的 Q4_K、Q5_K、Q6_K、Q8_0 及 IQ4_XS 權重類型。這些是受支援的權重家族。模型檔案可混合不同類型，因此檔案的整體標籤並不描述每個內部張量。

實作亦會檢查相關 gate 及 up 權重是否符合融合所需條件。形狀、類型及布局都很重要，因為合併操作預期相應的計算方式。不受支援的配置應保留另一條執行路徑。

合併後的程式碼排除了需要其列邊界回退機制的情況。回退機制處理無法整齊填滿正常處理圖塊的形狀。這項限制很重要，因為原始描述提到開發期間的測試涵蓋邊界情況。

因此，讀者應區分最初的測試摘要與最終程式碼的選擇規則。測試較廣泛的開發中實作，並不代表每種已測試形狀在合併版本中仍然合資格。最終的防護條件決定實際執行方式。

操作參數亦有限制。程式碼會在選擇融合前檢查特定的啟用設定。這些檢查可避免執行階段在所需行為不同時，把表面相似的操作當作可互換處理。

範圍亦集中於密集前饋操作。專家混合模型會把 token 路由至選定的子網絡，因此引入不同的執行需求。審查明確指出仍需額外支援工作，而非證實這些模型獲得全面覆蓋。

其他硬件後端不會僅因支援 llama.cpp 而獲得這項最佳化。貢獻者明確將此變更與其他後端區分開來。因此，NVIDIA 硬件的結果不能證明 Apple GPU 或 AMD 配置可獲得同等效益。

正確性證據令人鼓舞，但仍屬作者自行報告。Anujj 表示完整的後端操作測試套件已在 GB10 上通過。報告亦稱矩陣乘法套件已在 RTX 5090 上通過。

貢獻者另行報告，在指定測試中啟用及停用融合後，困惑度結果完全一致。困惑度量度模型預測評估文本的能力。它提供有用的數值檢查，但並不代表所有可能的應用程式行為。

這個結果支持的說法比普遍輸出一致更狹窄。某項既定評估上的分數相同，並不能證明在所有提示、設定或平台上生成的答案都完全一致。更廣泛的驗證需要更廣泛的證據。

在本報告檢視的資料來源中，llama.cpp 融合基準測試亦缺乏獨立重現。上游審查及合併證明專案接受了該程式碼，卻不會令貢獻者的量度變成外部效能審計。

這些邊界都不會抹去所報告的增益。它們界定了該主張在哪些情況下具實用價值。擁有相符硬件及模型類型的讀者，有具體理由進行測試；其他配置則需要另行取得證據。

最有力的解讀應結合兩方面。這項變更具有明確機制及已發表的量度數據，同時亦附帶明確條件，規範其何時運行。

三個訊號將顯示改善能傳播得多廣

下一批證據應把上游程式碼、可重現量度與使用者實際感受到的延遲連繫起來。

第一個訊號是下游採用情況。在未來數月，應用程式發佈及封裝版本應可確立哪些產品包含已合併的實作。這很重要，因為使用者往往透過另一個應用程式使用 llama.cpp。

該專案的CUDA 建置指引說明上游編譯途徑。封裝發行版可遵循不同的發佈時間表。與所包含原始碼掛鈎的版本識別碼，比泛稱使用最新後端更具資訊價值。

若廣泛使用的應用程式納入這項變更，即時採用的理由便會更充分。若它們仍停留在舊版修訂，合併的實際影響範圍仍然有限。這種結果反映的是發行時機，而非否定底層最佳化。

第二個訊號是在明確設定下獨立重現。具參考價值的報告應列明硬件、模型檔案、執行階段修訂版本及基準測試參數。它們亦應將新鮮提示處理與已快取輸入及生成輸出分開。

在不同提示長度下重現，可釐清增益對工作負載規模的敏感程度。跨受支援 GPU 世代的報告，則可測試其趨勢是否能超越所列機器而持續。顯示效能倒退的結果，將有助識別選擇邏輯的限制。

相關問題不在於每次運行是否都能達到標題中的最高值，而在於可比較的工作負載是否在可接受變異範圍內，呈現可重複的改善。較小但穩定的增益仍可能具備營運價值。

第三個訊號是應用程式延遲。團隊應量度更新執行階段後，是否能在具代表性的請求中縮短答案開始前的等待時間。他們應把生成吞吐量及總回應時間保留為獨立量度。

這些證據可將核心變更連繫至使用者體驗。長篇、未快取提示的較低初始延遲，將支持該實作的實際承諾。總回應時間不變，則表示其他階段主導了所量度的工作流程。

擴展格式或架構支援屬於額外開發，而非此合併已確立的事項。未來的主張應說明其自身的實作及量度。現有結果提供比較基線，而非預先確認這些延伸。

目前而言，llama.cpp CUDA 融合提供了一個具體理由，值得重新檢視本地推論效能。它針對合資格前饋計算中的重複工作，並報告在已披露的提示處理條件下可量度的增益。這已足以支持進行評估，毋須承諾全面加速。

在更新現有部署前，請保留其目前的執行階段識別碼及一組具代表性的請求。更新後比較相同的模型檔案、提示長度、快取條件及輸出設定。把初始等待時間與答案生成分開記錄，並在每項結果旁保留基準測試參數。對於長文件工作流程，應納入貼近日常使用情況的新鮮輸入，而非完全依賴合成吞吐量。對於對話工作負載，請檢查較短的輸入處理延遲是否足以對體驗帶來實質影響。然後根據自身量度，決定上游改善應如何納入你的發佈時間表。更新後的執行階段，是否真的縮短了使用者實際等待的請求部分？