https://yennj12.js.org/yennj12_blog_V4/tags/cuda-graph/Recent content in CUDA Graph on YennJ12 Engineering BlogHugo -- gohugo.ioen-usFri, 11 Sep 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/vllm-intro-part4-distributed-quantization-zh/Fri, 11 Sep 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/vllm-intro-part4-distributed-quantization-zh/大多數人遇到「模型放不下」的反應，是把 --tensor-parallel-size 開到卡數，跑起來就當解決了。 真正的答案是：TP 的每一層都要做一次 all-reduce，沒有 NVLink 的機器上這件事會吃掉你 40% 的時間；而在很多情況下，正確的答案不是切模型，是把模型變小。 放得下和跑得快，是兩個問題，常常要用相反的手段。 前言 Part 3 之前的所有討論都在一張 GPU 的邊界內。這一篇跨出去，並且處理三個互相糾纏的問題： 模型放不下一張卡 → 切開它（平行化） 模型放得下但太擠，KV 池不夠 → 壓縮它（量化） 模型放得下也不擠，但 GPU 沒跑滿 → 消除開銷（編譯與圖捕捉） 這三題的順序很重要，而多數人的直覺順序是錯的。先量化再考慮平行化——一個 70B 模型 FP16 要 140 GB（2 張 H100），FP8 只要 70 GB（1 張 H100 勉強、2 張很舒服）。省下來的不只是卡，還有 Part 3 講的那些 all-reduce 通訊。 本篇的目標：讀完之後，你能對著一個模型和一組硬體，說出該用哪種平行度、哪種量化、以及為什麼。 一、核心問題：三道不同的牆 你的模型 + 你的硬體 │ ┌───────────────────┼───────────────────┐ ▼ ▼ ▼ ┌───────────┐ ┌─────────────┐ ┌──────────────┐ │ 牆 ① │ │ 牆 ② │ │ 牆 ③ │ │ 容量牆 │ │ 頻寬牆 │ │ 開銷牆 │ │ │ │ │ │ │ │ 權重 > │ │ 權重放得下 │ │ GPU 利用率低 │ │ 單卡記憶體│ │ 但 KV 池太小│ │ 但不是 memory│ │ │ │ 併發 < 10 │ │ bound │ ├───────────┤ ├─────────────┤ ├──────────────┤ │ 解法： │ │ 解法： │ │ 解法： │ │ TP / PP │ │ 量化 │ │ torch.