跳至主要内容

架構專屬能力

TinyLoop 的設計目標是一個特定的架構家族：權重共享迴圈式 Transformer。這類模型由少量獨特層加上一個 loop block 組成，而這個 loop block 會以每次迭代都使用相同權重的方式重複執行 L 次，進而形成一個遠比實際參數量更深的有效深度。ALBERT 是最知名的例子，Universal Transformer 是另一個，而 MoR 與 2024-2026 年相關的 depth-recurrent 工作則構成第三波。

由於 loop block 的 W_q、W_k、W_v、attention projection、LayerNorm 與 MLP 矩陣在所有迭代間都完全相同，因此會出現一整族在非共享 Transformer 上根本不可能存在的執行時最佳化。這一頁會逐項列出這些能力，並說明為什麼它們只有在權重共享前提下才成立。

如果你正在拿 TinyLoop 和 vLLM / llama.cpp / TensorRT-LLM 這類執行時做比較，但一時看不出 TinyLoop 到底多做了什麼，答案就在這一頁。

快速對照​

能力Env / API省下了什麼為什麼只有共享權重 loop 能做到
Warm-start mid-loopbuild_resume_handle + resume_generate後續請求壁鐘時間最多 −32.5 %要從 iter k 接續，iter k 的權重必須等於 iter 0 的權重
Variable-L KV cache同一快取上使用不同 loops=同一份快取可跨深度共用cache layer n_pre + i 在任何 L ≥ i + 1 都可重用，因為 iter i 每次讀的都是同一組權重
Self-speculative decodingModel.generate_speculative(...)2.77× 吞吐、零額外參數draft (L_draft) 與 verify (L_verify) 共用同一組權重，不需要額外 draft model
Tree speculative decodingModel.generate_tree_speculative(...)用一次 mask-gated pass 取代 K 次序列 verify pass（Medusa/EAGLE 的替代方案，零輔助頭）所有 K 個 branch 都使用相同權重，因此 tree verify 在數學上成立；Medusa 則因目標模型各層權重不同，必須訓練輔助頭
Store-h KV cacheTINYLOOP_KV_H_MODE=1 [+ INT8 / INT4]KV VRAM 最多 78 % 降幅注意力時計算 K = W_k · h、V = W_v · h；這只有在每次迭代的 W_k / W_v 穩定不變時才成立
Iteration-axis delta-KVTINYLOOP_KV_DELTA=1（2026-04-19 已出貨）在同儲存量下，比先前 store-h INT8 SOTA 的 KL 小 5–50×、top-1 高 2 個百分點、速度更快Δh^l = h^l − h^(l-1) 只有在每次迭代共享權重時才有明確定義（同一函數、同一尺度）
Self-consistency quality gatingModel.score_with_consistency(...)僅在意見不一致時才升高 L在相同權重下比較 L=16 與 L=32 才有架構意義；標準 Transformer 上則是兩個不同權重的 16 層與 32 層模型
Hidden-state trajectory APIModel.score_trajectory(...)以研究等級量測 residual 如何沿迭代演化迭代軸是穩定且語意明確的分析對象；非共享堆疊沒有對應物
確定性誤差對消TINYLOOP_CANCEL_ROUND=1量化誤差 O(1) vs naive O(L)同一權重用 L 次 → 交替 rounding 方向使誤差成對對消
L 排程--l-warmup-tokens N --l-warmup-L Mwarmup token 快 ~3.3×深度是 runtime 旋鈕；標準 transformer 必須跑完所有層
每迭代安全檢查safety_check=TrueL 次中斷機會 vs 1 次每次迭代都是檢查點；標準 transformer 只在所有層之後檢查
雙位元權重交換TINYLOOP_DUAL_BIT=1decode 快 3.2%同一權重以不同精度用於不同迭代；標準 transformer 每層權重獨立
L-aware 批處理per_lane_loops=[4,16,32]3 品質層級，1 張 GPU深度是每請求旋鈕；標準 transformer 須部署獨立模型

上述能力都不需要額外訓練、額外參數，也不需要為每次迭代手工寫特例邏輯。它們是直接從這個架構不變量中自然長出來的。

Warm-start mid-loop​

它解決的問題。 使用者先要求一個 L=4 的結果（快、品質較低），之後不滿意，又對同一個 prompt 要求 L=8。天真的執行時會從頭把 8 次迭代全部重跑一遍。TinyLoop 則只執行 第 4..7 次迭代，直接重用前 4 次迭代留下的 residual 與 K/V 狀態。

API。

h = model.build_resume_handle(prompt, L_used=4, max_loops=32)
out4 = model.resume_generate(h, new_L=4, max_tokens=64)   # L=4 answer
out8 = model.resume_generate(h, new_L=8, max_tokens=64)   # extend to L=8 without redoing iters 0–3
out16 = model.resume_generate(h, new_L=16, max_tokens=64) # extend to L=16 without redoing iters 0–7
model.free_resume_handle(h)

實測收益。 在 407M GPTQ-INT4 上，從 L=4 → L=8 的 resume，相比重新呼叫一次 generate(loops=8)，壁鐘時間可節省 32.5 %。greedy 輸出與 fresh call 位元級一致。break-even 點是 N=1 次 follow-up，也就是只要有一次「再想深一點」的追問，建立 handle 的成本就回本。

為什麼只有 loop 才能做到。 想從 iteration k 接著算，前提是 iteration k+1 所用的 block 權重，必須和原始執行時使用的權重相同。在標準 24 層 Transformer 中，第 4 層和第 5 層權重不同，所以你不能拿「第 4 層輸出」直接當成某種可自由恢復的中間狀態；第 5 層本來就是另一個計算。而在我們的架構裡，第 5 次迭代用的權重就是第 4 次迭代那一套權重，因此在 cache 角度，resume 只是把指標移到同一組權重張量的下一次應用位置。

可搭配功能。 Self-consistency（先跑 L=16，只有不一致時才升到 L=32）、speculative decoding、beam search。

完整規格見：Python warm-start 頁面。

Variable-L KV cache​

它解決的問題。 一個部署需要從同一個模型產物中，服務多種不同的 L（品質 / 延遲）設定。類 vLLM 的執行時通常會把 L 視為編譯期固定值，或者乾脆分別部署三個不同模型。

API。 這是所有 TinyLoop 呼叫的隱含能力。KV cache 會依 n_layers = n_pre + L_max 做配置。之後任一 loops=L 且 L ≤ L_max 的呼叫，只會讀取前 n_pre + L 層，尾端部分則視為未使用。不需要重新配置，也不需要重新編譯。

實測收益。 這個能力本身幾乎是免費的，因為 cache 本來就要配。它真正解鎖的是：只靠單一部署就能提供 free-tier / pro-tier / enterprise-tier 三種產品等級。免費用戶用 L=4，pro 用戶用 L=16，enterprise 用戶用 L=32。一個模型，三種 SLA。標準 Transformer 上這意味著三個不同模型。

為什麼只有 loop 才能做到。 cache layer n_pre + i 是由 loop iteration i 的 K/V projection 填入。由於這個 projection 使用的權重與 L 無關，因此該層內容在任何未來深度 L ≥ i + 1 都是合法的。在非共享 Transformer 上，「深度 d 的那一層」只存在於某個 16 層或 32 層模型裡，而不是兩者共通。

完整規格目前追蹤於 CHECKLIST 的 §16.11（SLO-aware L admission、priority = iterations）。

Self-speculative decoding​

它解決的問題。 傳統 speculative decoding 需要一個 draft model，因此你必須訓練並部署第二個模型。Medusa 會在 target model 上訓練輔助預測頭；EAGLE 會訓練 feature-space predictor。這些方法都會增加參數與訓練成本。

TinyLoop 的解法。 直接把同一份權重在 L_draft（淺、快）與 L_verify（深、品質高）兩個深度下分別當作 draft 與 verifier。

API。

out = model.generate_speculative(prompt, max_tokens=128,
                                   draft_loops=2, verify_loops=8,
                                   draft_ahead=4)

實測收益。 在 H100 / 407M GPTQ-INT4 上，相比一般 generate(loops=8)，吞吐達 2.77×。零額外參數，可直接投入使用。

為什麼只有 loop 才能做到。 標準 speculative decoding 需要 draft 與 target 共享 token vocab，並產生可比較的分布。實務上通常不是把 target 以較低精度跑成另一個執行時配置，就是額外訓練一個更小的模型當 draft。這都不像「draft 就是同一個 target 模型，只是少跑幾次迭代」這麼乾淨。權重共享 loop 讓 L_draft < L_verify 成為執行時旋鈕，而不是訓練與部署產物。

Tree speculative decoding​

它解決的問題。 鏈式 speculative decoding 會逐 token 做 verify，也就是每個 draft token 都要做一次完整 verify forward。Medusa 能把 K 個 branch 的驗證濃縮成一次 pass，但前提是訓練額外的 Medusa heads，去預測多個深度上的未來 token 分布。EAGLE 也是類似邏輯。這兩者都需要新增可訓練參數，因此沒辦法對一個已訓練完成的模型「直接打開」。

TinyLoop 的解法。 先草擬 K 個 token 假設（在 root 位置做 top-K 抽樣，再用 L_draft 進行鏈式延伸），再利用 tree_verify_attention CUDA kernel，以一次 mask-gated forward pass 驗證整棵 M = K_branches × depth 的樹。零輔助參數。

API。

out = model.generate_tree_speculative(prompt, max_tokens=128,
                                       draft_loops=2, verify_loops=8,
                                       draft_ahead=4,          # depth per branch
                                       K_branches=2,            # >=1; 1=chain mode
                                       temperature=0.0)

實測結果。 在 greedy 模式下，輸出與 generate(temperature=0, loops=verify_loops) 位元級一致；在 chain mode（K=1）測試中 36/36 token 完全一致，在 multi-branch（K=2、K=4）測試中 72/72 完全一致。壁鐘加速幅度依 workload 而變（accept rate × draft 成本）；在訓練良好的 checkpoint 上，多分支理應顯著優於 chain speculation。

為什麼只有 loop 才能做到。 Medusa 的 tree 是由 target model 自己用 target 權重做 verify，但 draft branches 是由輔助頭生成，而這些輔助頭之所以成立，是因為它們被訓練成預測「在第 k 層之後的 token」。這個訓練假設 target 模型每層權重都不同。在我們的架構中，這些輔助頭其實會塌縮掉，因為 draft 本身就是低 L 下的 target，所以 tree 結構在零額外訓練下就天然成立。這就是「zero aux params」的主張：得到一個 Medusa 級別的加速，但不需要額外訓練任何新參數。

完整規格見：Python generation 頁面。

Store-h KV cache​

它解決的問題。 KV cache 是長上下文 VRAM 的主體。標準做法通常是：把 K/V 量化到 INT8 / INT4（犧牲精度）、做分頁與淘汰（增加交換複雜度）、或使用 GQA / MQA（直接改模型）。這些方法都無法把每 token 每層的儲存壓到低於 2D bytes。

TinyLoop 的解法。 不直接儲存 K 與 V，而是儲存 pre-QKV LayerNorm 輸出 h（一個 [D] 向量）。等到注意力階段，再用模型本來就會使用的 W_k、W_v 即時計算 K = W_k · h 與 V = W_v · h。如此一來，每 token 每層的儲存會從 2D bytes 降成 D（FP16-h）、D/2 + epsilon（INT8-h）或 D/4 + epsilon（INT4-h），也就是 1×、4×、8× 壓縮。

API。

# Before Model() construction:
os.environ["TINYLOOP_KV_H_MODE"]              = "1"
os.environ["TINYLOOP_KV_INT4"]                = "1"   # or TINYLOOP_KV_INT8=1
os.environ["TINYLOOP_EXPERIMENTAL_FP16_BODY"] = "1"   # tensor-core reconstruction
import tinyloop_py as tl
model = tl.Model("model.tinyloop", max_seq_len=4096)

實測收益。

模式Cache 節省Decode 壁鐘品質
FP16-h43–50 %配合 fp16_body 時 −38 %K/V 位元級一致
INT8-h66–75 %配合 fp16_body 時 −37 %K/V L2 相對誤差約 0.6 %；大多數 prompt 下 greedy 結果保持
INT4-h78 %配合 fp16_body 時 −37 %K/V L2 相對誤差約 10 %；eval 安全（seq=4096 時 +0.08 PPL，10/10 MC 一致），但 generate 會分歧（argmax 在 1–3 token 內可能分歧）；詳見使用邊界

完整延遲 / 記憶體 / 品質表，以及 2026-04-18 六軸壓力測試結果，請見 KV Cache Modes 與 paper/store_h_stress/PAPER.md。

為什麼只有 loop 才能做到。 只有在 cache write 階段使用的 W_k，和 attention read 階段使用的 W_k 相同時，K = W_k · h 才能正確重建快取位置的 K。對權重共享 loop 來說，這件事天然成立：第 5 次迭代寫出 h，第 6 次迭代就用同一個 W_k 把它重建回來。標準 Transformer 中，第 4 層寫出 h 時的 W_k 跟第 5 層讀取時的 W_k 不同，因此你無法跨層重建。Store-h 壓縮在非共享模型上是架構層面不可能的。

2026-04-18 壓力測試中的新發現（Axis A）。 Loop 深度 L 出現一個穩定甜蜜點：在 greedy decode 下，INT8-h 能在 L=8–16 保持 3/4 個 prompt 的 baseline 輸出，但在 L=4 與 L=32 時只有 2/4。迭代太少時，重建誤差來不及被吸收；迭代太多時，誤差則累積。據我們所知，這是第一次量測到 KV 壓縮下「穩定性隨 loop 深度變化」的動力學，而這個問題在非共享 Transformer 上根本無從定義。

4) Iteration-axis delta-KV​

它解決的問題。 Store-h 壓縮的是 KV cache 的空間軸，因為它不再分別實體化 K 與 V。但在這個架構裡還有第二種、只有此架構才有的冗餘：沿著 L 次 loop 迭代，每個 token 的 hidden state 會走出一條逐步收縮的軌跡。在 407M、2B-effective 模型上，ρ_l = ‖h^l − h^(l-1)‖ / ‖h^l‖ 會從第一次迭代的 0.68 衰減到第 32 次迭代的 0.04，足足 17×；同時 cos(h^l, h^(l-1)) → 1.000，也就是說 loop 後期 residual 幾乎不再變動。若你仍然把每個 h^l 都以 INT8 直接儲存，那就等於讓所有迭代支付相同的量化成本，即使後期迭代幾乎不再攜帶新資訊。

TinyLoop 的解法。 TINYLOOP_KV_DELTA=1 會把儲存版面改成：

h⁰  FP16  (shared anchor across all L loop iters per token)
Δh¹ Δh² … ΔhL   INT8 per-head (with [T, n_heads] FP16 scale grid)

在注意力時計算重建：h^l = h⁰ + Σ_{i=1..l} scale[i, head] · Δh^i。也就是每個 token 做一次 FP32 prefix-sum，並融合在單一 CUDA kernel launch 中。對應的 write-side kernel 會在 prefill 時計算 Δh = h_curr − h_prev，並選出 per-head scale。這個 per-head grid 與既有 pack_kv_row_int8（store-h INT8）路徑的量化粒度相同，因此 delta-INT8 能在同精度條件下與 store-h-INT8 競爭，同時支付更低的總儲存成本。

為什麼只有 loop 才能做到。 在權重共享 loop 中，h^l 與 h^(l-1) 是同一個函數作用在持續收縮的 residual 上的結果，因此它們之間的 delta 小、結構性強，而且可以在比端點本身更細的粒度上被量化。對標準 N 層 Transformer 而言，h_layer_6 − h_layer_5 則是兩個不同函數、兩組獨立權重的輸出差，沒有自然尺度、沒有收縮結構；量化它只會引入雜訊，不會帶來真正壓縮。因此這個 delta 方案和 store-h 一樣，在非共享堆疊上從架構上就不成立。

實測：完整 forward path 的 PPL A/B（cache read/write 全開，RTX 4090 / 407M 模型，20 個 prompt × 每種模式 16 個 decode token = 320 個計分位置，2026-04-19）：

在 L=8（淺 loop） 時：

模式PPLKL(fp16 ‖ q)top-1top-5壁鐘
fp163.7890100.00 %100.00 %96.3 ms
h_int8（先前 SOTA）3.7004.03 × 10⁻³96.88 %97.19 %147.2 ms
delta_int8（per-head）3.7958.08 × 10⁻⁵99.06 %99.50 %135.4 ms

在 L=32（深 loop） 時：

模式PPLKL(fp16 ‖ q)top-1top-5壁鐘
fp169.3060100.00 %100.00 %286.4 ms
h_int8（先前 SOTA）8.9624.71 × 10⁻³97.81 %96.25 %459.1 ms
delta_int8（per-head）9.2929.08 × 10⁻⁴99.38 %97.75 %442.7 ms

Delta-INT8 per-head 在所有測過的 L 值上，都嚴格優於先前的 store-h-INT8 壓縮方案：

LKL 比值（delta / h_int8）top-1 差距壁鐘
81 / 50（小 50×）+2.18 個百分點快 7.9 %
321 / 5.2（小 5.2×）+1.57 個百分點快 3.6 %

工程狀態（2026-04-19，已完整出貨）。

層級Commit狀態
Phase A 模擬（重建誤差、真實軌跡）1a2b34e supporting data✓
Reconstruct CUDA kernel（per-row + per-head）1a2b34e、a7d52e6✓ 4 種 shape parity
Write-side CUDA kernel（per-row + per-head）5dd8ba5、a7d52e6✓ 4 種 shape parity
Storage layer（LayerKVCache / RuntimeKVCache）b429cc3✓ alloc/free 驗證，total_bytes 精準
Logit-drift PPL proxy binding05689a7✓ 50-prompt、L=8 / L=32 跑完
Runtime wiring（prefill Δh 擷取 + attention reconstruct）f9dd9d3✓ generate() 端到端驗證
Full forward-path PPL A/B（per-row）4378f07✓ 顯示 per-row baseline
Per-head kernel + runtimea7d52e6✓ 補平 L=32 落差，所有 L 都是乾淨優勢

部署故事。 這是 TINYLOOP_KV_H_MODE=1 + TINYLOOP_KV_INT8=1 的直接替代品：把它換成 TINYLOOP_KV_DELTA=1，就能在同一儲存區間下，得到大幅更接近 FP16 的品質（KL 小 5–50×、top-1 高 1.5–2 個百分點），而且壁鐘更低。儲存型態仍是同一級別（每個 token 每個 iteration 一份 INT8 Δh，加上 per-head FP16 scale）。

Self-consistency quality gating​

它解決的問題。 某個部署希望預設只支付 L=16 的計算量，但當輸入具有歧義、模型可能出錯時，再升到 L=32。在標準 Transformer 上，「同時跑一個 16 層模型和一個 32 層模型再做比較」意味著兩套部署。

TinyLoop 的解法。 Model.score_with_consistency(...) 會在一次呼叫中，讓共享權重 block 同時以兩個深度執行，並回傳一致性訊號。呼叫端可以把不確定案例送往更深設定，或進一步轉交人工審查。

API。

result = model.score_with_consistency(prompt, loops_a=16, loops_b=32)
if result["agree"]:
    answer = result["answer_a"]          # cheap L=16 was confident
else:
    answer = result["answer_b"]          # escalate to L=32 (costs ~2× more)

實測。 已於 2026-04-17 出貨。Python API 中已有整合範例。

為什麼只有 loop 才能做到。 在我們的架構裡，L=16 與 L=32 是同一個模型在兩個不同深度下的表現。對標準 Transformer 而言，它們會是兩個不同模型，各自有自己的訓練曲線、產物與品質輪廓，不是一個可以免費調整的品質旋鈕。

Hidden-state trajectory API​

它解決的問題。 在傳統研究裡，若要分析表示如何隨深度演化，通常必須去探查標準 Transformer 的每一層，而每層權重都不相同。對權重共享 loop 而言，「迭代軸」是更自然的分析對象：同一個函數，不斷作用在一個持續演化的 residual 上。

TinyLoop 的解法。 Model.score_trajectory(tokens, n_loops) 會在一次 forward pass 中，擷取每個階段（embed、pre.0..pre.n-1、loop.0..loop.L-1、final_ln）最後一個位置的 hidden state，並回傳一個 [n_stages, D] 張量。

API。

result = model.score_trajectory(np.asarray(tokens, np.int32), n_loops=16)
print(result["labels"])   # ['embed', 'pre.0', 'pre.1', 'loop.0', ..., 'loop.15', 'final_ln']
hidden = result["hidden"] # [n_stages, D] float32

用途。 β dynamics 研究（‖h^l - h^{l-1}‖ / ‖h^l‖ 如何衰減）、逐迭代 drift-coherence 量測，以及 §16.14.a 中 iteration-axis KV 壓縮的軌跡前置條件。

為什麼只有 loop 才能做到。 在標準 Transformer 中，「第 7 層 hidden state」與「第 8 層 hidden state」是兩段不同子計算中的快照；整條軌跡只有 24 個點，而且每點都對應不同權重的 layer。在我們的架構裡，這條軌跡是一個動力系統：同一個 operator 被反覆套用。這就引出了特定量測方式（fixed-point 行為、收縮率、β dynamics），而這些量測無法直接移植到非共享情況。

確定性誤差對消​

要解決的問題。 INT4 量化對每個權重引入誤差 ε。標準 transformer 每層權重不同，誤差獨立。Looped transformer 同一權重誤差 ε 被套用 L 次 — 誤差累積為 O(L)。

解法。 交替 rounding 方向：偶數迭代用 q_int（標準 round-to-nearest），奇數迭代用 q_int + sign_correction。sign correction 翻轉誤差方向，連續對對消。

誤差比較： naive O(L) → stochastic O(√L) → 確定性對消 O(1)。

API。 TINYLOOP_CANCEL_ROUND=1（需含 sign_bit 通道的 v5 .tinyloop 檔）。

L 排程​

要解決的問題。 所有 decode token 都跑完整深度 L=8 很浪費 — 前幾個 token（context warm-up）不需要高品質。

解法。 decode 期間漸進深度：前 N token 用 warmup_L（如 L=2），之後切換到完整 n_loops（如 L=8）。H100 / 2B INT4 量測：warmup token 快 ~3.3×。

API。

tinyloop model.tinyloop generate --loops 8 --l-warmup-tokens 16 --l-warmup-L 2

每迭代安全檢查​

要解決的問題。 標準 transformer 跑完所有層才檢查輸出 — 只有一次機會抓到問題。Looped transformer 每次迭代都產生可檢查的 residual。

解法。 每個 loop 迭代後計算 residual 的 L2 norm（O(D)，已在 L2 cache）。若超過閾值則立即中止。L 次抓到爆炸/退化 hidden state 的機會。

API。

model.generate(prompt, loops=8,
               safety_check=True, safety_norm_threshold=50.0)

量測。 H100 / 2B INT4：threshold=10 在 iter 0 抓到 norm=30.7，2 token 後中止。

雙位元權重交換​

要解決的問題。 INT4 量化在所有 loop 迭代中精度固定。但早期迭代（建立 context）對量化噪音的敏感度低於晚期迭代（精煉輸出）。

解法。 保留 INT2 副本（體積減半）與原始 INT4 副本。早期迭代用 INT2，晚期用 INT4。INT2 副本在載入時透過 INT4→INT2 re-quantization 產生。

為何僅 looped。 標準 transformer 每層權重獨立，無法單獨 requantize 某層。Looped transformer 的 loop block 是一組權重用 L 次，一次 requantization 即可產生所有迭代可用的 INT2 變體。

成果。 H100 / 407M decode 快 3.2%（408ms → 395ms）。額外 VRAM ~17 MB。

API。 TINYLOOP_DUAL_BIT=1、TINYLOOP_DUAL_BIT_SWITCH=3。

L-aware 批處理​

要解決的問題。 服務不同品質層級（free/pro/enterprise）需要部署獨立模型 — 3 模型 × 2.7 GB = 8.1 GB VRAM。唯一差別只是「每 token 多少計算量」。

解法。 generate_batch 接受 per_lane_loops=[4, 16, 32]。同一 batch 中每個 lane 以自己的 loop 深度執行。Free tier L=4、enterprise L=32。一個模型、一張 GPU、一次 batch 呼叫。

為何僅 looped。 標準 transformer 層數固定，每個請求都必須跑完所有層。Looped transformer 的深度是 runtime 參數，不同請求可用不同深度。

成果。 H100 / 407M 上已驗證 bit-exact：mixed lane L=4 與獨立 generate(loops=4) 輸出完全相同，mixed lane L=8 與獨立 generate(loops=8) 完全相同。

API。

model.generate_batch(
    [free_prompt, pro_prompt, enterprise_prompt],
    per_lane_loops=[4, 16, 32]
)

尚未出貨、但同樣屬於架構專屬的能力​

  • Rewind speculation（§16.10）。draft 被拒絕時從中間 L 恢復。
  • Iteration-dependent activation scales（§16.9）。每 group 儲存 L 組 scale factor。
  • Model editing amplification（§16.12）。改 loop block 一個矩陣，效果套用 L 次。
  • Priority = iterations（§8）。free tier L=4、pro L=16、enterprise L=32。
  • Per-iteration safety check（§16.12）。每次迭代後都掃描 residual 是否出現 jailbreak pattern。一次 forward 有 L 次中止機會，而且幾乎零成本，因為 residual 早已常駐在 L2。
  • Priority = iterations（§16.11）。免費版用 L=4、pro 用 L=16、enterprise 用 L=32。只靠一個 artifact 就能提供三種等級。現在業界的標準做法通常是三個不同部署模型。
  • HBM-free decode（§16.13）。在 1B-effective 模型上，loop block 的 INT4 權重大約 35 MB，可直接塞進 H100 的 50 MB L2。第 0 次迭代從 HBM 讀取；第 1..L-1 次迭代命中 L2，HBM 流量幾乎歸零。這件事在 H100 上已被證明架構上成立，但壁鐘效益有限（約 0.5 %）；在頻寬受限裝置（4090、Apple M3、行動 NPU）上預估可放大到 10–40×。詳見 investigations/hbm_free.md。

這份清單不是什麼​

這些是只有因為權重共享才成立的架構級優勢。它們不是：

  • 那些任何執行時都能實作的 kernel trick（像 FlashAttention、paged attention、chunked prefill；TinyLoop 也支援，但那不是這頁的重點）。
  • 可套用在任何模型上的量化技術（INT4 GEMM、GPTQ、AWQ；TinyLoop 同樣支援，但它們不是架構專屬）。
  • 一般的生成功能，例如 beam search / grammar-constrained decoding / deterministic sampling。這些是多數執行時都會有的功能，TinyLoop 只是為了完整性而提供。

如果你在這一頁看到某個功能，同時在 vLLM 或 TensorRT-LLM 裡也看到「名稱看起來有點像」的能力，通常那種相似只是表面上的：vLLM 的 paged attention 不是 TinyLoop 的 variable-L cache；llama.cpp 的 speculative decoding 需要另一個 draft checkpoint；兩者都不支援 store-h 壓縮。

延伸閱讀​