前言：ninfer 是啥，跟別人比強在哪、殘在哪

前一陣子分享了AMD端Halogen推論引擎的性能表現，
最近開始對這種專門優化的推論引擎蠻有興趣，我把手上的單卡RTX4090 24GB拿來實測，
要強調的主要就是這推論框架對20~24GB的卡非常適合

ninfer（Neroued/ninfer，2.2k stars）是一個從零手刻的 C++/CUDA 推理引擎，專門只幹一件事：把 Qwen3.5 Dense / MoE 幾個指定 checkpoint，在單張顯卡上推到物理極限。沒有通用架構支援，沒有多卡，沒有有的沒的——一個 GPU、一個常駐模型、開機定死的 KV 池，1~8 個併發請求。

它跟主流引擎的差別：

一句話定位：llama.cpp 是瑞士刀（什麼模型都能跑、什麼硬體都能上），vLLM 是公車（載多人、多模型、生產調度），ninfer 是 F1——只跑一條賽道（Qwen3.5家族 + 單卡），但在這條賽道上 decode 比誰都快、同 VRAM ctx 比誰都大（本篇實測：4090 上 262K + vision，llama.cpp 同卡只能 213K）。

代價：換模型要整個換（不能隨手抓個 GGUF 就跑）；併發一深就排隊（prefill 還跨 lane 互卡）；社群 port小（本文用的 4090 版），出問題自己解；DFlash2 這種新功能有版本配對失敗（v2/v3 artifact × 新舊引擎，本文實測踩過兩次啟動失敗才配對成功）。

適合誰：單卡、固定一個主力模型、要長 ctx + 高速 decode 的個人/小團隊 agent 用戶。

1. 測試軟硬體配置與模型量化格式

Server：Ubuntu 26.04（kernel 7.0.0-28）、i9-14900K（32 緒）、RAM 61GB、RTX 4090 24GB（24564 MiB，driver 595.91）、Docker 29.1.3 + NVIDIA Container Toolkit。
VRAM 保留：~1.3GB 我自己另外要留Embedding與Rereanker使用。

三個引擎，同一個模型家族（Qwen3.8-27B），三種量化：

nfer 本體是 alanthinker/ninfer-4090-yarn（官方 Neroued/ninfer 只認 RTX 5090 sm_120a，4090 只能用社群 sm_89 port）。llama.cpp 側掛 froggeric chat template + MTP + reasoning-budget 2048。

2. 配置流程教學

直接用docker非常簡單

# 1. 拉 fork 並 Docker build（host 工具鏈缺什麼都沒關係，全在 image 裡）
git clone --depth 1 https://github.com/alanthinker/ninfer-4090-yarn.git /data/ninfer-4090
cd /data/ninfer-4090 && docker build --tag ninfer-4090:sm89 .

# 2. 下權重——關鍵坑：fork 只吃 v2 artifact，main 分支現已是 v3（magic NINFER 0003）
#    且 09-06 版混了 DFlash2 companion weights（fork 會報 dflash2/feature_projection 拒載）
#    鎖定 08-14 commit（3526913004b1，magic NINFER 0002，17GB）：
curl -L -C - --fail --output models/qwen3_8_27b.ninfer \
  'https://huggingface.co/neroued/Qwen3.8-27B-NInfer/resolve/3526913004b1/qwen3_8_27b.ninfer'
xxd -l 16 models/qwen3_8_27b.ninfer   # 確認 NINFER ....0002

# 3. 起服（rk2v4 + vision + MTP3，262144 全滿版；rk4v4 把兩處數字換 240640、--kv-dtype 換 rk4v4-e8）
docker run -d --name ninfer --gpus all --publish 8080:8080 \
  --volume $PWD/models:/workspace/models:ro ninfer-4090:sm89 \
  ninfer-serve /workspace/models/qwen3_8_27b.ninfer \
  --host 0.0.0.0 --port 8080 --max-context 262144 --kv-capacity 262144 \
  --max-concurrency 1 --max-pending-requests 16 --pending-timeout-ms 600000 \
  --prefill-chunk 1024 --kv-dtype rk2v4-e8 --spec mtp --draft-tokens 3 \
  --lm-head-draft --vision --preserve-thinking

ctx 定尺寸心法：server 啟動會 fail-fast，缺多少精確到 byte（實例：要 5398826240、只有 5307427328，差 87MB → 245760 降 240640 一次過）。先估大再往下收，兩次重啟內必中。OpenAI 相容端點直接沿用 :8080/v1，model id 填 qwen3.8-27b，tool calling 照走。

3. 速度實測

方法：同文本（fox 重複句）、每檔冷啟動全量 prefill、decode 80 token、取 server 回報 timings。單位 tok/s。

prefill

decode（MTP 全開，KV 全駐留 at-depth）

4. 速度比較：llama.cpp vs ninfer rk4v4 vs ninfer rk2v4

• prefill 全線 llama 贏：−22%（8K）收斂到 −9%（200K），跟 fork 自承的 16–24% 一致。單發長文問答 llama wall-clock 最快。
• decode 全線 ninfer 贏：llama 隨深度一路掉（102→46），ninfer 全程平緩（rk4v4 最低 102）。agent 迴圈（prefill 一次、decode 幾十輪）總帳 ninfer 大勝。
• rk2v4 vs rk4v4：prefill −1~−11%（越深越虧，lattice 解碼開銷），200K decode 102→72 是最大一刀；其餘檔位 decode 只差 ~10%。
• 200K+ 是 ninfer 獨佔區：llama 213K 上限實測 200K 已是極限（1427/46 且無 vision 餘裕），rk2v4 直上 262144。

5. 精準度與智商比較：rk4v4 vs rk2v4

微基準 cosine：98.678% vs 96.155%（key 方向差 ~7°）。實測四關，兩邊逐題對打：

關卡	rk4v4	rk2v4
單針取回 100K / 200K / 258K（XK-73912）
20 組相似代碼混淆取真（100K / 200K）
雙跳推理 150K（更名+密碼二段跳 → 44-Blue-19）
工具參數精確傳遞 100K（WO-2026-88471）
五胞胎函數取號	（答 4）	（答 4，一字不差）

• 能考的格子全中，2.5% cosine 在取針、混淆、雙跳、工具四種高壓題、258K 深度下完全量不出來。
• 唯一共同翻車（五胞胎函數）兩邊錯得一模一樣——權重本體的數數極限，同權重必同錯，與 KV 無關；反而證明 rk2v4 行為與 rk4v4 逐字級一致。
• 附帶教訓：兩次「脫靶」都是 thinking 燒光 max_tokens（content 空、finish=length），不是取錯——生產環境 output 開大（16384）即避開。

6. 結論

• ** 262K 全滿 + vision，KV量化 rk2v4**：精準度零可觀測損失，拿 10% 速度換 22K ctx（rk4v4 卡死 240640，258K 的題連考場都進不去）。
• 要每 tok 最快，KV量化用rk4v4：decode、prefill都快一截，尤其是長ctx衰退小，滿意。
• llama.cpp 留著的理由只剩一個：純prefill場景、或是需要切到其他模型。
• **rk4v4就速度與容量最均衡，尤其是長ctx下decode明顯好過rk2v4更不用說llama.cpp、而200K下prefill也接近llama.cpp的水平，因為我有保留1.3G做另外用途，若不保留確定是262K+vision可以開到滿的。