一、一張帳單裡的浪費：HBM 在 prefill 裡幹了什麼
一台 NVIDIA A100 伺服器，光是 HBM 的成本就佔到整塊卡製造費用的18%；到了 B200 上，這個數字攀升到45%。你花了近一半的錢買了高頻寬記憶體——然後在 prefill 階段，讓它空轉。
HMA-Serve 論文（arXiv:2606.29986）裡有一組測量資料：在 4K token 長度的 prefill 任務上，A100 的 HBM 頻寬利用率不足3%。16K token 時，這個數字跌到1% 以下。換句話說，你有一條八車道高速，但卡車只開了半條。
下圖展示了不同晶片在 prefill（高算術強度）和 decode（低算術強度）下的天花板差異：
MemHA 要回答的核心問題：為什麼非得用最貴的記憶體，去幹一件幾乎不需要頻寬的事？
二、兩種記憶體，各有各的好命
在正式介紹方案之前，先搞清楚兩種記憶體的底層差異——這是理解 MemHA 的前提，也是"為什麼便宜方案行得通"的根本原因。
2.1 HBM：為頻寬而生，代價是貴
HBM（High Bandwidth Memory）的核心設計思想是：把多層 DRAM 晶片疊在一起，通過 TSV（Through-Silicon Via，穿矽打孔）垂直打通，再用矽中介層（Interposer）和 GPU 晶片封裝在一起。
這種封裝有兩個關鍵效果：
- 頻寬極高：因為 DRAM 層和 GPU 直接挨著，資料匯流排極短，多層平行讀寫，頻寬可達2–8 TB/s
- 延遲極低：短匯流排意味著資料從記憶體到 GPU 計算單元路徑短，讀取延遲只有幾十納秒
代價很直接：TSV 打孔工藝複雜、良率要求高，矽中介層成本貴，HBM3e 的合同價格大約是每 GB 15 美元，是普通 GDDR 的約10 倍。
HBM 真正發揮價值的地方是 LLMdecode 階段：每生成一個 token，都要把整個 KV cache 和模型權重從記憶體讀一遍——30B 模型權重約 60 GB，對頻寬要求極端苛刻，沒有 HBM 就是等待。
2.2 GDDR：頻寬不如 HBM，但勝在便宜
GDDR（Graphics Double Data Rate）是傳統顯示卡的記憶體方案：晶片直接焊在 PCB 板上，通過普通 PCB 走線和 GPU 相連。
焊在 PCB 上的好處是工藝簡單、成本低，但代價是匯流排更長、頻寬受限：GDDR6 頻寬約864 GB/s，只有 HBM 的四分之一。
價格差距懸殊：Tenstorrent Blackhole p150（GDDR 加速器）算力約 664 TFLOPS（BFP8），售價約1300 美元；一塊 A100 要16000 美元以上，算力/美元比，p150 領先接近一個數量級。
關鍵洞察：GDDR 頻寬不夠，但 LLM 推理裡有一個階段根本不需要那麼高的頻寬——prefill。
2.3 prefill 和 decode：兩個完全不同的計算模式
在講異構方案之前，有必要把這兩個階段徹底搞清楚——它們是整個設計的出發點。
Prefill（預填充）是什麼？
當你在對話方塊輸入一段話，傳送給大模型，模型首先要把你輸入的所有文字（prompt）全部平行處理一遍，生成內部狀態，然後才吐出第一個字給你。這整個過程——從接收 prompt 到輸出第一個 token——就叫 prefill。
在計算上，prefill 做的是矩陣乘矩陣（GEMM）：把整段 prompt 的所有 token 打包成一個矩陣，一次性和模型權重相乘。因為單次操作處理了很多 token，每次讀記憶體能被大量計算"均攤"，算術強度高，頻寬壓力小。
Decode（解碼）是什麼？
Prefill 完成後，模型開始一個字一個字往外吐——每次只生成一個 token。這就是 decode 階段，也就是你看到文字在螢幕上流出來的過程，直到模型輸出完整回覆。
在計算上，decode 做的是矩陣乘向量（GEMV）：每次只處理一個 token，計算量極低。但每次生成都必須把 KV cache（之前所有 token 的歷史狀態）和全量權重從記憶體讀一遍——頻寬瓶頸，計算單元反而空著等。
類比：餐廳廚房
想像一家餐廳：
. prefill = 廚房大批次備菜：廚師一次切 100 盤食材，刀工要快（算力強），但不需要特別貴的配菜架（頻寬）
. decode = 服務員端菜上桌：每次只端一盤，但要在 100 張桌子之間跑來跑去——最需要的是腿快（頻寬），而不是刀工
這個比喻會貫穿全文，幫你理解後面的三把鑰匙。
三、跨廠商的好主意，撞上兩個大坑
MemHA 的核心思路清晰：
- GDDR 加速器（如 Tenstorrent p150）承擔 prefill，算力強、便宜，頻寬差無所謂
- HBM GPU（如 NVIDIA A100）承擔 decode，高頻寬硬需求完美匹配
理論上很美——工程上，兩個繞不開的坑。
坑 1：KV cache 格式"語言不通"
prefill 跑完，要把 KV cache 交給 decode 端繼續用。但 Tenstorrent 的 p150 輸出的是BFP8 tiled 佈局（一種分塊的低精度格式），而 NVIDIA 的 FlashAttention 期待的是paged row-major BF16（按行排列的 BF16 浮點）。
兩邊格式完全不同：精度不同（BFP8 vs BF16）、記憶體排布不同（tiled vs row-major）、分頁邏輯不同。
回到餐廳比喻：廚房（p150）做好了菜，但菜的包裝格式是日式便當盒；服務員（A100）只認法式蓋盤——直接傳過去，雙方互不認識。
如果強行在傳輸前做格式轉換，會多一次全量資料讀寫，額外消耗 HBM 頻寬，正好是 decode 最稀缺的資源。
坑 2：KV cache 傳輸直接堵死 TTFT
prefill 產生的 KV cache 體積不小：Qwen3-32B 在 8K 上下文時，一次 prefill 約輸出1 GB的 BFP8 KV cache。
100 Gbps RDMA 網路下，傳這 1 GB 要100–200 ms——幾乎和 prefill 本身一樣長。
如果順序執行（prefill 全部完成 → 傳輸 → decode 開始），使用者看到的首 token 延遲（TTFT）就是：
TTFT = prefill 時間 + 傳輸時間 + decode 第一步 ≈ 100ms + 150ms + ? = 250ms+
而同構系統（全用 A100）TTFT 只有 100ms 左右——直接翻倍。
回到餐廳比喻：廚房做完所有菜，才開始往服務員那邊送——客人等了做菜的時間，又等了運輸時間，然後才開始吃。
四、HMA-Serve 的三把鑰匙
HMA-Serve 是論文提出的完整系統，三個機制協同，每把鑰匙對應一個坑，最後合力解決問題。下圖展示了 HMA-Serve 的整體架構：
4.1 鑰匙一：分階段量化（解決格式問題）
核心想法：兩邊不強行統一格式，各用各的最優精度。
- prefill 在 p150 上用 BFP8（高算力效率）
- decode 在 A100 上用 BF16（高精度，防累積誤差）
- 中間傳輸時：保持 BFP8 raw bytes 原樣傳過去，不做格式轉換，到 decode 端再處理
為什麼 prefill 用 BFP8 不會掉精度：prefill 計算的是 KV cache 的初始值，這個值在 decode 階段會被重新精算重建——prefill 差一點沒關係，decode 精確就行。實驗結果也驗證了這一點：MATH500 全 BF16 vs BFP8 prefill+BF16 decode，精準率沒有顯著差別。
回到餐廳比喻：廚房（p150）用快速粗切（BFP8），配菜裝在密封盒裡原樣運給服務員；服務員（A100）在客人桌邊重新精確擺盤（BF16）——廚房省了功夫，客人吃到的還是精緻料理。
4.2 鑰匙二：計算-傳輸流水線（解決 TTFT 問題）
核心想法：不等 prefill 全部完成才傳，prefill 是逐層（layer by layer）執行的，第 i 層算完，KV cache 立刻推送——後續層的計算和前面層的傳輸平行進行。
具體：Transformer 有 32/64 層，layer 0 算完即傳，layer 1 還在算的時候 layer 0 的 KV 已經在路上了，最終大部分傳輸時間被計算時間"掩蓋"掉。
回到餐廳比喻：廚房不是"所有菜做完才出餐"，而是"前菜做好先端上去，主菜還在做，甜點再做"——客人開始吃前菜時廚房沒停，TTFT 就是等第一道前菜，而不是等全桌菜。
效果：高並行場景下，TTFT 幾乎不受傳輸影響，decode 側隨時有可用的 KV。
4.3 鑰匙三：延遲反量化（解決格式轉換開銷）
核心想法：BFP8 bytes 傳到 A100 後不立刻轉成 BF16——先存著，等到 paged-attention kernel 執行時在內部融合處理：BFP8→BF16 轉換、tiled→row-major 佈局變換、後 RoPE key re-layout，三件事一次 pass 搞定。
為什麼行得通：BFP8→BF16 本質是 bit manipulation（移位、掩碼、OR），走的是 GPU 的整型 ALU，不和 GEMM 佔用的 tensor core 爭資源——二者幾乎不衝突。
回到餐廳比喻：服務員端到桌邊再當著客人拆開密封盒、重新擺盤——拆盒和擺盤同時做，等菜上桌時已經是精緻法式蓋盤，客人感覺不到任何額外等待。
數字：融合後格式轉換耗時約1 ms（樸素 elementwise 實現要 8 ms），decode 吞吐僅下降約1%。
五、數字、邊界與落地
5.1 論文實測：降本幾倍、損失幾個點
測試配置：4 塊 Tenstorrent Blackhole p150（prefill 端）+ 1 塊 NVIDIA A100 80GB（decode 端），100 Gbps RoCE 網路互聯。
基線：DistServe-Homo（同構 1P1D，2 塊 A100）。
下圖展示了 HMA-Serve 在四種模型規模下，與各基線系統的端到端 goodput 對比（SLO 達成率 vs 請求量，以及 TTFT/TPOT 延遲分佈）：
從 SLO 曲線可以看到：
- Qwen3-8B（ShareGPT 混合負載）：HMA-Serve goodput 領先+3.2×
- Qwen3-14B（LongBench 長上下文）：goodput 領先+2.4×
- Qwen3-32B（arXiv 摘要任務）：goodput 領先+1.8×
- Qwen3-4B（512 token 短 prompt）：goodput 略低約-10%，但成本效率仍更優
下圖進一步展示單位美元 goodput（goodput-per-dollar），即成本效率對比：
- Qwen3-8B：4.8× 領先DistServe-Homo（同構雙 A100）
- Qwen3-32B：4.1× 領先
核心結論：質量無損——MATH500、AIME24、AIME25 三個 benchmark，HMA-Serve 追平全 BF16，沒有顯著精度損失。
LLM 推理系統最省錢的點，恰好在兩個不同廠商產品之間，不在任何單一廠商的產品線內部。
NVIDIA 自己也認同這個方向：Rubin CPX 就是面向 prefill 的 GDDR-based 加速卡，設計上就是和 HBM 的 Rubin 搭檔使用。
5.2 什麼場景最適合
- prompt 較長（≥ 4K token）的 prefill-heavy 工作負載：prefill 成為瓶頸，GDDR 的平行優勢最明顯
- batch 較大或並行較高的線上服務：流水線 pipeline 效果最好
- 對成本敏感、硬體預算有限的中小型推理叢集
5.3 落地最容易踩的坑
- KV 格式對齊是硬骨頭：需要自研 fusion kernel，不是裝個外掛就搞定的
- prefill runtime 需要侵入：逐層 completion event 需要 monkey-patch SDK，封閉商業 SDK 會很麻煩
- 網路頻寬是隱形門檻：100 Gbps RDMA 是工程可行的前提
- 廠商軟體生態尚早：Tenstorrent PyBuda/tt-metal 和 vLLM 的整合還在演進中
什麼場景不適合：短 prompt（≤ 512 token）純聊天、只關心單請求延遲、模型權重需頻繁熱更新的場景，當前效果不佳或工程代價偏高。 (老許漫談AIInfra)