跳至主要内容

Runtime 模式

把 TinyLoop runtime 分成不同模式來看，會更容易理解。

Inspect​

目標：

  • 驗證 artifact metadata
  • 估算記憶體占用
  • 避免完整上傳權重

使用時機：

  • 檢查新的 .tinyloop 檔案
  • 規劃 VRAM 預算
  • 驗證轉換輸出

Benchmark​

目標：

  • 測量 runtime 延遲與吞吐
  • 在不必要時避免完整 logits 工作

使用時機：

  • 分析 kernel
  • 比較不同 runtime 模式
  • 量測 loop 次數影響

重要注意事項：

  • benchmark 使用合成 token id
  • benchmark 不是品質評估
  • TINYLOOP_CUDA_PROFILE=1 會輸出分段時間

Score​

目標：

  • 物化每個序列位置的 logits

使用時機：

  • 執行任務評估迴圈
  • 比較不同實作輸出
  • 觀察位置層級行為

成本取捨：

  • 輸出記憶體需求最高
  • 不是 decode 迴圈的首選 helper

Score Last Token​

目標：

  • 只計算最後一列 logits

使用時機：

  • 實作文字生成
  • 做 next-token 排序
  • 最小化輸出配置

這是 decode 風格工作負載偏好的低記憶體 scoring 路徑。

Generate​

目標：

  • 執行一般自回歸解碼

目前行為：

  • cached decode 預設開啟
  • TINYLOOP_DISABLE_KV_CACHE=1 會強制 uncached 參考路徑
  • cache_window 可限制 KV cache
  • CLI 仍以 raw bytes 方式 tokenization prompt

Speculate​

目標：

  • 使用同一模型跑快速 draft 與較慢 verify

目前行為：

  • 已有共享快取的推測式 runtime
  • 已有 accept-or-resample 邏輯
  • 已有推測式 regression
  • 更廣泛 serving 等級驗證仍是開放工作

Prefix Cache 重用​

目標：

  • 對共享前綴只 prefill 一次
  • 在重複請求中重用該前綴

這和一般 generate() 不同，重點是工作負載重用而非一次性生成。

實務建議​

建議：

  • 先跑 inspect
  • 用 benchmark 做純 runtime 量測
  • 用 score_last 做 decode helper
  • 用 generate 產生一般自回歸輸出
  • 共享重複 prompt 時用 prefix cache
  • 只有在你刻意需要該行為時才用推測式解碼