AI 前沿 2026 年 6 月 21 日

2026-06-21 AI 前沿:LLM 推論成本估算與高通 NPU 編譯器逆向解析

餐巾數學估算 LLM 推論成本:從記憶體頻寬到每 Token…

餐巾數學估算 LLM 推論成本:從記憶體頻寬到每 Token 費用

injuly.in · 2026-06-21

injuly.in 的這篇技術文章以「餐巾數學」(napkin math)為方法論,系統性地拆解大型語言模型在現代 GPU 上的推論成本,從矩陣乘法的基本運算量出發,一路推導至每位用戶的月費。文章選用 NVIDIA B200 作為參考硬體,以具體數字錨定抽象概念,讓工程師能夠在部署前快速評估資源需求。

從矩陣乘法到 Roofline 模型

推論的核心計算單元是矩陣乘法。對於形狀 N×d 與 d×M 的兩個矩陣相乘,浮點運算量為 2NMd,記憶體存取量約為 d(N+M)(採用分塊(tiling)優化後)。注意力機制對批次輸入 X ∈ ℝB×N×d 的計算流程如下:

Q = X·W_Q,  K = X·W_K,  V = X·W_V
Attention(Q,K,V) = softmax(Q·K^T / √d) · V

FLOPs per batch : 2BNd²
Memory accesses : Bd(N + d)

引入 KV-Cache 後,每次前向傳遞只需處理單一新 Token,使每讀取一個位元組對應的計算量降至約 2B ops/byte,這正是 Roofline 模型的分析起點。B200 的記憶體頻寬為 8 TB/s、算力為 4,500 TFLOP/s,兩者之比為 562 ops/byte;由此推導出「讓 GPU 滿載所需的最低並行批次大小」:

2B = 562  →  B ≈ 331 個並行用戶

低於此批次大小時推論為記憶體頻寬瓶頸(memory-bound);超過時則轉為算力瓶頸(compute-bound)。兩個極端的中間地帶,正是大多數生產部署實際落點。

32B 模型的實際容量推算

文章以一個 32B 參數的模型為例,估算單張 B200 可同時服務的用戶數。模型權重佔 32 GB 視訊記憶體;若每位用戶擁有 200k 上下文並採用 GQA(Grouped-Query Attention),每位用戶的 KV-Cache 約需 26 GB,這直接決定了記憶體的硬上限。

場景同時服務用戶數備註
理論上限(100% 負載率)6 人無 KV-Cache 分頁
PagedAttention 啟用40–60 人動態分配、冷驅逐
生產估算(含閒置時間)300–800 人依請求分布而定

在 6 位用戶同時活躍的場景下,每次前向傳遞的資料傳輸時間約為 23.75 ms,計算時間僅 0.5 ms,因此整體吞吐主要受記憶體頻寬而非算力限制,每位用戶每秒可獲得約 40 個 Token 的生成速度。這個數字與業界實測的主流服務速率高度吻合,驗證了估算框架的實用性。

資本支出與租用模式的成本比較

文章最後將硬體規格換算為用戶成本。若以 40,000 美元購入一張 B200、服務 300 位用戶,每位用戶的硬體終身成本約為 133 美元(不含資料中心管理費)。若改採雲端租用模式(4 美元/小時),每位用戶每小時約 0.013 美元,換算月費約 9.36 美元。此框架的核心價值在於:工程師只需替換硬體規格表中的三個數字——頻寬、算力、售價——即可快速評估任意 GPU 在特定模型與服務規模下的經濟性,毋需等待實際壓測數據。

原始來源:Inference cost at scale with napkin math — injuly.in


逆向工程高通 NPU 編譯器:解析 QAIRT 排程器、記憶體配置與效能模型

datavorous.github.io · 2026-06-21

datavorous.github.io 的這篇研究文章針對高通 AI Runtime(QAIRT)v2.46.0.260424 進行逆向工程,目標是 Hexagon NPU 的編譯器後端函式庫。作者以 Linux x86_64 主機版的 `libHtpPrepare.so` 為分析對象,透過 Ghidra 反組譯、未被剝離的 C++ 函數名稱殘跡,以及對實際工具鏈的實驗性驗證,還原出編譯器在張量排程與記憶體配置上的核心邏輯。

逆向方法:Ghidra、符號殘跡與 AI 輔助分析

由於目標 `.so` 已被 strip,作者首先利用未被混淆的 C++ 函數名稱(unmangled symbols)作為語義錨點,在 Ghidra 的反組譯輸出中定位關鍵函式。對於難以理解的機器碼片段,作者進一步借助 Claude Code 輔助詮釋反組譯結果,再以參數掃描(parameter sweeping)在實際工具鏈上驗證推論的正確性。此方法論結合靜態分析與動態實驗,有效降低了對單一反組譯輸出的依賴。

VTCM 記憶體配置:從啟發式到 MILP 求解器

文章最引人注意的發現是高通編譯器的張量配置策略。編譯器並非採用簡單的貪婪式打包演算法,而是將張量配置建模為混合整數線性規劃問題(MILP),並呼叫開源求解器 HiGHS 求解。物理座標配置則由一個在三維座標空間中運作的遞迴回溯配置器(recursive backtracking allocator)負責,並依張量生命週期排序以降低碎片化。

編譯器在配置階段還可自動執行 relaxed_precision_cast 操作,將 float32 張量降精度至 FP16 或 BF16 以在記憶體壓力過高時騰出空間。編譯產出的二進位檔中亦內嵌 spillFillBufferSize 元資料欄位:當此值為 0 時,代表所有模型權重可完整放入晶片上記憶體(on-chip)而無需 spill,工程師可據此快速判斷模型是否適合特定硬體配置。

排程器設計與內部效能模擬器 Hextimate

排程器採用優先佇列廣度優先搜尋(Priority BFS)決定運算元執行順序,並以深度優先拓撲排序確保生產者與消費者運算元在時間上相鄰,以降低 VTCM 峰值用量。平局時依圖距離與分支排程優先級作為啟發式決策依據,最終給出二元判定:spill 或 no-spill。

編譯器內部另有一個名為 Hextimate 的分析效能模擬器,實作了教科書式的 Roofline 模型:

bandwidth = channels * width * efficiency * frequency
time      = bytes / bandwidth

Hextimate 分別對整數與浮點算力、多播(multicast)操作以及 KV-Cache、權重等特殊張量類型獨立計價,並透過「完全重疊」與「零重疊」兩種極端場景模擬記憶體競爭。此外,編譯器可識別 FlashAttention、MoE(混合專家)與旋轉位置編碼(RoPE)等特定計算模式,針對性地調整效能估算,顯示高通在編譯器層面已對主流 LLM 架構進行專門優化。

原始來源:Reverse Engineering the Qualcomm NPU Compiler — datavorous.github.io


End of article
0
Would love your thoughts, please comment.x
()
x