跳至主要内容

生產路線圖

只有在工作順序被維持時，TinyLoop 才能成為可信基礎設施。

順序仍然重要：

  1. 先證明 decode 與 runtime 正確性
  2. 再強化效能與 serving 行為
  3. 再用量測證明其獨特研究優勢

若按此順序進行，TinyLoop 才能從「有趣的 runtime」走向「嚴肅的專用框架」。

階段 1：Decode 與 Runtime 正確性​

目標​

讓自回歸執行成為可用且可測試的能力。

已完成​

  • 預設開啟的 KV-cache decode
  • cached-vs-uncached regression 覆蓋
  • tokenizer-aware Python regression
  • prefix caching
  • sliding-window cache
  • 共享快取推測式 runtime
  • CTest 與 self-hosted CUDA CI 串接

尚未完成​

  • 更多 prompt 與更長執行長度的廣泛 regression 覆蓋
  • 一等公民的 tokenizer-backed CLI 行為
  • 更乾淨的公開 tokenizer 故事

退出條件​

TinyLoop 應能明確主張：

  • cached decode 為預設
  • parity 覆蓋容易重跑
  • 對外公布數字對應已檢查 runtime 狀態

階段 2：效能與 Serving 強化​

目標​

把 TinyLoop 變成可操作的 runtime，而不只是已驗證函式庫。

主要工作流​

Attention​

  • 妥善完成 FlashAttention-2 roadmap 項目
  • 保留 decode 的直接 cached single-query 路徑
  • 把目前較安全的 tiled prefill kernel 視為中介步驟，而非終局

依模式做記憶體分析​

  • 更清楚分離 prefill 與 decode 的預期
  • 讓 runtime 記憶體回報更容易理解

Serving 介面​

  • HTTP API
  • 模型生命週期管理
  • 健康檢查端點
  • 結構化 log 與 metrics

Batching​

  • paged attention
  • 先做 static batching
  • 之後再做更進階排程

退出條件​

TinyLoop 應能明確主張：

  • 已提供可用服務介面
  • 具備 runtime 失敗診斷能力
  • 具備模式感知的效能與記憶體預期

階段 3：證明獨特優勢​

目標​

展現主流 runtime 尚未具備的部分：

  • 可調適 loop 深度
  • 同權重自我推測式解碼
  • β-aware 量化優勢

主要工作流​

Early Exit​

  • 新增可設定的退出邏輯
  • 記錄每 token 的 loop 次數
  • 與固定 loop baseline 比較品質與延遲

β-aware 量化​

  • 先讓 GPTQ 穩定
  • 實作 β-weighted GPTQ
  • 在固定 bit-width 下證明可量測收益

混合 loop 次數的排程​

  • 僅在 adaptive loop depth 真的成立後再做
  • 避免排程器反而破壞 adaptive compute 的收益

退出條件​

TinyLoop 應能明確主張：

  • adaptive depth 可被量測
  • speculative decode 不只 demo
  • 論文中的量化主張是真實能力，而非願景

目前優先順序判斷​

從純框架/runtime 角度，目前最大操作缺口是：

  • serving
  • batching
  • tokenizer-first UX
  • 完整 FlashAttention-2 整合

從論文角度，最大剩餘研究缺口仍是：

  • 穩定 GPTQ，接著 β-weighted GPTQ

這兩組優先順序不同，請明確分開管理。