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