主張與數據來源

TinyLoop 和 vLLM、TensorRT-LLM 這類堆疊的差異

重點不是那些框架很弱，而是它們優化的是不同的預設假設。

問題	TinyLoop	通用 runtime
把共享 loop block 當成第一級 runtime primitive	是	通常不是
同一份 checkpoint 支援 runtime-variable depth	是	通常不會乾淨暴露
單 checkpoint 自我 speculative decode（draft_loops vs verify_loops）	是	通常不行，往往需要第二個 draft model
從共享 W_k / W_v 做 h-mode KV 重建	是	否
今天若要服務任意 checkpoint、拼完整 serving 生態	不是最佳選擇	是
若 checkpoint 家族本身已是 looped、weight-shared	往往更適合	往往不是

安全主張 vs 不安全主張

安全主張

• 當你想保留 looped transformer 的真實結構，並把這個結構變現成記憶體密度、cache 設計、單 checkpoint decoding tricks 時，TinyLoop 是更合理的 runtime。
• TinyLoop 在 H100 上已經有直接量測到的 runtime 勝場，例如 INT4 forward 30.48 ms、FP16-body 2.82 ms（seq_len=128, loops=8）。
• 權重共享的部署路徑，能讓 VRAM 成本不隨有效深度線性膨脹。

不安全主張

• TinyLoop 在所有 workload、所有 checkpoint、所有 serving 情境下都比 PyTorch、vLLM、TensorRT-LLM 更快。
• 在沒有 apples-to-apples 公開對照基準下，聲稱對通用 runtime 有普世性的 latency 優勢。
• 對所有 prompt 分布、所有長度區間都已經證明品質完全等價。

這個 repo 目前不支持上面那些不安全主張，因此 benchmark 頁面也不該假裝支持。

什麼時候該選 TinyLoop

當下列條件成立時，選 TinyLoop 比較合理：

• 你的模型家族本來就已經是 weight-shared 或 looped
• VRAM 密度是第一順位的部署限制
• 你希望深度 L 保持成 runtime 旋鈕
• 你要用 h-mode KV、delta-KV、單 checkpoint self-speculative decode 這類 loop-aware 特性

當下列條件成立時，generic runtime 仍然更合適：

• 你需要廣泛的 checkpoint 相容性
• 你現在就需要成熟 batching、scheduler、serving infrastructure
• 你的模型本質上就是普通 deep stack，沒有 loop-aware 結構值得保留

本頁數據來源

上面的數字主要整理自：

• docs/framework/current-status.md
• docs/framework/python-api/prefix-cache.md
• docs/framework/python-api/generation.md
• next.md
• tests/bench_hot_ops.cu
• tests/bench_marlin_gemm.cu
• tests/test_marlin_parity.py
• tests/test_marlin_asymmetric_parity.py
• tests/test_marlin_asymm_correction_kernel.py
• tests/bench_l2_residency.cu
• paper_draft/4_19.md
• paper_draft/data/