雙卡同步與 MTP 加速機制
Geezuz kernel 源自 L-Forster 在 open-jet 專案中的單 GPU megakernel，其特點是將整個前向傳遞作為一個持續的 CUDA kernel 執行。開發者的分支版本將其拆分至兩張顯卡，透過 PCIe 直接同步並交換部分結果，而非依賴 NVLink。
該系統利用張量核心路徑支援 Q4_K、Q5_K、Q6_K 和 Q8_0 量化格式，並在單一週期中解碼最多 8 個請求。模型使用自身的 MTP（Multi-Token Prediction）頭來起草下一個 token，由於權重每次傳遞僅讀取一次，驗證 5 個起草 token 的成本幾乎與生成 1 個相同。
不同量化與並行請求下的速度表現
在兩張功率限制為 280W 的 RTX 3090 上，使用純 PCIe 連接且無 NVLink 的環境下，Qwen3.8-27B 於 Q4_K_M 量化時單請求速度為 190 tok/s，Q8_0 則為 143 tok/s。當同時處理 8 個請求時，總吞吐量分別達到 622 tok/s（Q4_K_M）與 610 tok/s（Q8_0）。
作為對比，llama.cpp 在相同提示詞下最快的雙 GPU 配置僅約 100 tok/s。Geezuz kernel 在保持與 llama.cpp 相同的輸出品質（以 KL 散度衡量）下，平均速度達 164 tok/s，程式碼生成任務則達 214 tok/s。
詳細基準測試顯示，在 10K context 長度下，Geezuz Q4_K_M 於 8 並行請求時總吞吐量為 550 tok/s，高於 llama.cpp 的 312 tok/s 與 vLLM GPTQ int4 的 576 tok/s。在 60K context 長度下，Geezuz Q4_K_M 於 8 並行請求時為 289 tok/s，而 llama.cpp 為 181 tok/s，vLLM 則因記憶體限制無法執行部分配置。
編譯資源需求與軟體生態整合
該專案提供 OpenAI 相容的伺服器介面，包含共享 KV 池與前綴快取功能，並預先打包適用於 RTX 30 系列顯卡的 tarball。然而，編譯過程需要消耗近 60GB 的系統記憶體。
編譯時間依 CPU 效能而異，在 Ryzen 5800X 上約需 55 分鐘，而在 Ryzen 9800X3D 上則縮短至約 30 分鐘。所有基準測試與逐版本變更日誌均已發布於 GitHub 倉庫中。
與 vLLM 的競爭現況
開發者指出，目前的下一個目標是在 8 個並行請求的場景下超越 vLLM，因為在該情境下 vLLM 仍領先約 15%。測試數據顯示，在 10K context 與 8 並行請求時，vLLM GPTQ int4 達到 576 tok/s，略高於 Geezuz Q4_K_M 的 550 tok/s。
開發者邀請擁有 RTX 4090 或 5090 顯卡的用戶提供測試數據，以擴展效能評估範圍。目前的測試均基於未調校的預設設定進行比較。
