突破低記憶體硬體限制：從每秒 1.47 到 22 個 token

開發者指出，在標準 llama.cpp 環境下，嘗試載入 68GB 的 MoE 模型於 12GB VRAM 與 16GB RAM 的配置時，會因作業系統頁面快取頻繁換頁導致效能極低，僅能達到每秒 1.47 個 token。

另一款工具 Strata 雖然在擁有 48GB 至 64GB RAM 的高階配置下可達每秒 40 個 token 以上，但在 16GB RAM 的限制下必須強制使用低記憶體模式，效能降至每秒 8.11 個 token。

新推出的 Betelgeuse 引擎（包含 bel-cli 與 bel-server）在相同硬體條件下，冷啟動生成速度為每秒 16.80 個 token，熱啟動則穩定維持在每秒 22.03 個 token，峰值甚至可達每秒 48 個 token。

技術核心：VRAM 槽位池與 GPU 內部門鈴機制

Betelgeuse 採用「Arrival-Slack VRAM Slot Pool」技術，將約 5,000 個專家槽位非均勻分佈於剩餘的 VRAM 中，早期層分配較多槽位以利用計算空閒時間，後期層則較少。

傳統方法每生成一個 token 需進行 48 次 CPU/GPU 排程分割來確認遺漏的專家，這會消耗約 360 毫秒的同步等待時間；Betelgeuse 改為在 GPU 內部透過自定義 CUDA kernel 解決命中問題，僅在專家缺失時透過映射的主機門鈴通知 CPU。

此外，引擎將每層 token 嵌入預先載入至 CUDA 裝置，使整個解碼過程作為單一 CUDA Graph 重放執行，大幅減少開銷。

記憶體管理優化：RAM 受害者快取與磁碟讀取降低

當專家從 VRAM 池中被逐出時，Betelgeuse 將其移至主機 RAM 的專用「受害者快取」（Victim Cache），而非直接丟棄或重複載入至作業系統頁面快取，確保 VRAM 與 RAM 內容互斥且不重複。

此機制結合 io_uring 分頁器，將物理 NVMe SSD 讀取量從每 token 約 71 MB 大幅降低至 12.43 MB，顯著減少儲存裝置的瓶頸影響。

在模型檔案結構上，開發者移除了主 GGUF 檔案中冗餘的專家張量，將 Dense 層、專家資料與 N-gram 分片分離存放，避免磁碟空間重複佔用。

驗證結果：無專家剪枝且輸出完全一致

開發者強調，該引擎未進行任何專家剪枝或閾值過濾，所有 48 層中的每個路由專家均以完整精度計算。

透過比對 28,080 筆路由器記錄與 576 個生成 token，驗證結果與標準 llama.cpp 輸出逐位元組完全相同（差異為 0.000e+00），確保模型推理品質未因速度優化而受損。

在更大的 Q8_K_XL 量化版本（約 190GB）測試中，Betelgeuse 仍能維持冷啟動每秒 8 個 token、熱啟動每秒 12 個 token 的速度，而標準 llama.cpp 在此配置下會立即記憶體溢出或速度低於每秒 0.1 個 token。

未來規劃與資源連結

開發者已將此串流與受害者快取架構移植至 DeepSeek V4.1 Flash，早期測試顯示在相同硬體等級下可達到約每秒 25 個 token。

Betelgeuse 引擎的原始碼已發布於 GitHub，並向 llama.cpp 上游提交合併請求；預先打包的模型檔案則提供於 Hugging Face。