通用 Runtime 在 Looped Checkpoint 上會輸在哪裡
這一頁回答的不是「通用 runtime 很弱嗎？」答案當然不是。真正的問題是：它們預設優化的是另一種模型假設。
如果 checkpoint 的本質是：
embed -> pre blocks -> shared loop block x L -> head
那麼通用 runtime 通常想看到的是：
embed -> block 1 -> block 2 -> ... -> block N -> head
這個結構不匹配，就是 TinyLoop 的優勢來源。
| 面向 | 通用 deep-stack baseline | TinyLoop | 節省 / 收益 |
|---|---|---|---|
| 每實例權重 VRAM | 2,700 MB | 204 MB | 13.2× 更小 |
| 80 GB GPU 可容納實例數 | 29 | 392 | 13.5× 更多 |
| 每 MB VRAM 的 tokens/s | 19.0（Pythia-410M FP16） | 83.2 | 4.4× |
| 相對 generic INT8 KV 的 KV 節省 | ~50 % | ~78 %（INT4-h） | 多省 28 個百分點 |
| Prefix cache 攤提倍率 | 每個 cached token 只有 1× | 每 token 有 L× | L = 8 時等效 8× |
| Loop block 是否更容易塞進 GPU L2 | 否 | 是 | 額外吃到 cache residency 優勢 |
| INT4 GEMM 峰值 | 受限於 generic INT4 路徑 | 達 FP16 tensor-core 峰值的 86% | 消費級 Ada 上特別明顯 |
1. 每實例權重記憶體
這個比較不是公開發表的 latency bakeoff，而是部署層最實際的記憶體成本：你到底是在保存共享 block，還是把有效深度當成真的 N 層攤開。
| 路徑 | 每實例權重記憶體 |
|---|---|
| 通用 deep-stack runtime | 2,700 MB |
| TinyLoop shared-block runtime | 204 MB |
這代表：
- 當記憶體是第一瓶頸時，TinyLoop 的價值非常直接。
- 在這個比較下，模型 footprint 大約 小 13×。
- 這個優勢會一路傳導到 serving density、edge fit、多模型併存。
2. 80 GB GPU 上的模型密度
用同一組 per-instance 數字做最簡單的 back-of-the-envelope 計算：
| 路徑 | 80 GB GPU 可放幾個實例 |
|---|---|
| 通用 deep-stack runtime | 29 |
| TinyLoop shared-block runtime | 392 |
這就是實際部署故事：
- 同一張 GPU 上可以塞更多 tenants
- 可以常駐更多 checkpoints
- edge / on-prem 部署包絡線會小很多
3. 為什麼這不是同一類 runtime
選 TinyLoop，通常是因為你要保留 looped transformer 的原始結構，而不是把它硬展平成一般深層堆疊。這個選擇會帶來幾個通用 runtime 很難補回來的特性：
- 深度
L可以保留成 runtime 參數，而不是 checkpoint 形狀的一部分。 draft_loops/verify_loops可以在同一份 checkpoint 上做 self-speculative decode。h-mode / delta-KV 這種 KV cache 壓縮，能直接利用共享的W_k/W_v。- Prefix cache 的攤提，不是只在 token 軸上重用，還能沿 iteration 軸同步受益。
反過來說，如果你的需求是廣泛模型覆蓋、成熟 batching、完整 serving 生態，那 generic runtime 仍然是對的工具。TinyLoop 的優勢不是「什麼都比較快」，而是當模型家族本來就是 looped、weight-shared 時，它能保留並變現那個結構。