Lucebox：讓 RTX 3090 重回戰場的不是新硬體，而是重寫推論軟體
這篇 Threads 介紹 Lucebox，一個把 LLM inference 針對特定 consumer hardware 手寫最佳化的開源專案。它的口號很直白：Open LLM inference, rewritten by hand for one specific chip at a time。換句話說，不等下一代硬體，而是把現有硬體的軟體堆疊重寫，榨出晶片本來就有、但通用框架沒有吃滿的能力。
官方 repo 是 Luce-Org/lucebox-hub。查 GitHub API 時的狀態：
- Repo：Luce-Org/lucebox-hub
- 描述：Lucebox optimization hub: hand-tuned LLM inference, built for specific consumer hardware.
- 授權：MIT
- 建立時間：2026-04-03
- stars：約 1,513
- forks：約 131
- 主要技術：CUDA 12+、C++17、PyTorch 2.0+（部分 build / benchmark）
- Reference target：NVIDIA RTX 3090（Ampere sm_86, 24GB）
Lucebox 的核心論點是：過去十年通用框架主導推論，是因為「替每顆晶片、每個模型家族手寫 kernel」太貴。大家選擇一套通用 stack，雖然到處能跑，但通常不是任何一張卡上的極限效能。AI-assisted development 改變了這個成本結構：以前要一季的重寫，現在可能在一個 release cycle 內完成。
這是這個專案最值得記錄的地方。它不只是又一個 inference repo，而是在押一個趨勢：
AI 讓專用最佳化的開發成本下降，所以「針對特定硬體 + 特定模型 + 特定 workload」重寫推論路徑，可能重新變得划算。
目前 lucebox-hub 裡三個主要子專案：
- Megakernel：把 Qwen3.5-0.8B 的 24 層合成單一 persistent CUDA kernel
以往 LLM 推論每一層、每個 op 都會牽涉 kernel launch、CPU/GPU round trips、framework overhead。Megakernel 的做法是把 Qwen3.5-0.8B 的 24 層 forward pass fused 到單一 CUDA dispatch。
README 數據：
- Target：RTX 3090
- 模型：Qwen 3.5-0.8B
- Method：82 blocks、512 threads、one persistent kernel
- Prefill pp520：21,347
- Decode tg128：413
- tok/J：1.87 @220W
- llama.cpp BF16 @350W：Prefill 11,247、Decode 267、tok/J 0.76
- PyTorch HF：Prefill 7,578、Decode 108
官方說法是：No CPU round-trips between layers、cooperative grid sync instead of ~100 kernel launches per token。這代表瓶頸不只在 FLOPS，而是在 launch overhead、memory movement、framework dispatch 與 power efficiency。
- DFlash 27B：把 DFlash speculative decoding 搬到 GGUF / RTX 3090
Speculative decoding 的基本精神是：小模型先草擬多個 token，大模型批次驗證，降低自回歸逐 token 生成的等待成本。Lucebox 的 DFlash 是 GGUF port，針對 Qwen3.5 / Qwen3.6 27B，在 RTX 3090 上跑。
README 數據：
- Qwen3.5-27B / Qwen3.6-27B
- Q4_K_M target + BF16 draft
- DDTree budget=22
- demo 最高 207.6 tok/s，對比 autoregressive 38.0 tok/s，約 5.46×
- HumanEval 10-prompt bench 平均 129.5 tok/s
- 比 autoregressive 快 3.43×
- 比 chain speculative decoding 多 15%
- 比同硬體上的 SGLang AWQ 快 2.8×
- 搭配 TurboQuant TQ3_0 KV cache，可在 24GB 下做到最高 256K context
這裡要保守看：這些是專案自己的 benchmark，且模型、量化、prompt、硬體功耗、context、batch 設定都會影響結果。但方向很明確：對 consumer GPU 來說，演算法 + kernel + memory layout 的改動，能把同一張卡的有效吞吐拉開很大差距。
- PFlash：用 speculative prefill 壓低長 prompt 的 TTFT
長 context 最大痛點常常不是 decode token/s，而是 time to first token（TTFT）。128K context 的 prefill 可能慢到使用者覺得整個系統掛住。
PFlash 的做法是：讓小 drafter（Qwen3-0.6B BF16）先掃長 prompt，對 token / span 打重要性分數；大 target（Qwen3.6-27B Q4_K_M）只 prefill 重要片段。官方稱這是 in-process speculative prefill，C++/CUDA only，不需要 Python、Triton、PyTorch runtime。
README 數據：
- 128K context：dflash daemon TTFT 24.8s，llama.cpp baseline 約 257s，約 10.4×
- 64K context：13.5s vs 134.95s，約 10.0×
- NIAH single-needle 在 32K → 128K context 都 retrieved
- keep_ratio=0.05，DFLASH_FP_ALPHA=0.85
- 使用四個 custom CUDA kernels：mean_K → score → select → sparse_fwd
- 使用 Block-Sparse-Attention（mit-han-lab/BSA，FA-2 derived）做 long-context drafter forward
這對本地長文問答、文件搜尋、RAG 前處理很有意義。因為實務上很多 local LLM 體驗卡在「第一個字太慢」，而不是後續 decode 太慢。
支援硬體與限制
Lucebox README 寫明所有實驗都以 RTX 3090 為 reference target，但支援 / 嘗試支援：
- Ampere：sm_86，RTX 3090 / A-series，reference
- Ada：sm_89，RTX 40xx，should work, unverified
- Blackwell consumer：sm_120，RTX 50xx，包括 5090，CUDA 12.8+
- DGX Spark / GB10：sm_121，CUDA 12.9+
- Jetson AGX Thor：sm_110，CUDA 13+
- Turing：sm_75，RTX 2080，CUDA 12+
但要注意，這不是給一般使用者一鍵安裝的 app。它更像研究 / hacking / kernel-level optimization repo。使用者需要 CUDA、CMake、submodules、模型權重下載、不同 GPU arch 的 build 設定，還要能理解 benchmark 條件。
我的判斷：
Lucebox 的戰略意義比單一數字更大。它指出 local AI 的瓶頸不一定是「硬體太舊」，而是「軟體太通用」。RTX 3090 這類 24GB consumer GPU 已經在很多人桌上，若推論 stack 能更貼近晶片、模型與 workload，local AI 的性價比會被重新估值。
這對 AI infra 有幾個啟發：
- 通用框架會繼續存在，但高價值 workload 會出現專用路徑
PyTorch、llama.cpp、vLLM、SGLang 這些通用框架適合廣泛模型與快速迭代。但若 workload 很固定，例如某個 27B 模型、某張 3090、某種長 context RAG，那手寫 kernel / custom decoder 可能值得。
- AI-assisted development 會讓 low-level optimization 重新流行
過去 kernel optimization 人力貴、週期長，只有 NVIDIA、Google、Meta、大廠 inference team 負擔得起。若 AI 能協助寫 / refactor / benchmark CUDA/C++，小團隊也可能做出更垂直的最佳化。
- 本地 AI 的競爭會從「能不能跑」走向「跑得多接近硬體極限」
2023–2025 年 local LLM 重點是量化、GGUF、能在 consumer GPU 跑起來。下一階段會是：同樣一張卡，誰的 TTFT 更低、tok/J 更高、長 context 更穩、推論成本更低。
- 對 BigIntTech 的用法：先追蹤，不急著導入 production
Lucebox 很值得追蹤，尤其如果未來我們要做 local AI appliance、私有化部署、客戶端 AI box、或低成本長文推論。但短期不應直接拿來 production，除非有明確 workload、可重現 benchmark、穩定 fallback 與安全評估。
最適合的實驗方向：
- 拿一張 3090 / 4090 / 5090 測固定模型的 TTFT、tok/s、tok/J。
- 跟 llama.cpp / vLLM / SGLang 做同 prompt、同模型、同量化比較。
- 特別測長 context RAG 的 first-token latency。
- 看輸出品質是否因 speculative / sparse prefill 受影響。
- 評估 build / deployment / driver 相依成本。
結論：
Lucebox 不是「3090 真的再戰十年」這麼簡單，而是提醒我們：AI infra 的下一輪效率提升，可能不是全靠新晶片，而是靠 AI 協助人類把軟體重新貼近硬體。硬體已經在桌上，真正浪費的可能是中間那層太通用的 inference stack。
參考來源：
- Threads 原文：https://www.threads.com/@largitdata/post/DX1zAszjzOy
- GitHub：Luce-Org/lucebox-hub：https://github.com/Luce-Org/lucebox-hub