NInfer 在论坛里火了一阵（原帖 讲的是它把 NInfer 移植到 SM86），
我机器上有一张 3090，原本跑的是调优过的 vLLM 栈，这次把服务换到 NInfer 上，看看到底能到什么程度、跟原来差多少。
别人写过的背景不重复，这篇只写我这台机器的数字、能直接抄的配置，以及那几个不改就起不来的参数。

一、部署：三步，全都能直接抄

1. 拿模型（必须钉 revision）

HF 仓库的 qwen3_8_27b.ninfer 在 2026-09-15 升级成 container v3，而 v0.6.1 的预编译二进制只认 v1/v2 容器，
直接下 main 会报 artifact magic is not NInfer v1 or v2。钉到 v2 容器那个 revision：

curl -L -C - --fail -o qwen3_8_27b.ninfer \
  "https://huggingface.co/neroued/Qwen3.8-27B-NInfer/resolve/18dfc887423fa5aabf3cb56fac41490e462b3fab/qwen3_8_27b.ninfer"
# 18,210,531,328 B   sha256 eec39564993d6e9c7d5e383382a760f093465c9d163ec9a1bd6b80199514bf3e

2. 打镜像（10 秒，不编译）

上游只发 Dockerfile（源码 245 步 CUDA 编译）和预编译二进制，没有现成镜像（GHCR 上这个包匿名拉取是 DENIED）。
最省事的路：拿官方 Linux x64 预编译包塞进官方 CUDA runtime 底座。

FROM nvidia/cuda:12.8.0-runtime-ubuntu24.04
# GeForce 卡不能用 forward-compat 的新 libcuda，不删会在启动时报 cudaErrorCompatNotSupportedOnDevice
RUN rm -rf /usr/local/cuda-12.8/compat /usr/local/cuda/compat
RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates curl \
    && rm -rf /var/lib/apt/lists/*
COPY ninfer /usr/local/bin/ninfer
COPY ninfer-serve /usr/local/bin/ninfer-serve
ENTRYPOINT ["ninfer-serve"]

预编译包：ninfer-rtx3090-linux-x64-0.6.1-rtx3090.tar.gz
（sha256 eb6a6e5b4b318dcf5a8173ccdae8d98acbe730606a50d87eaf120353962965b5），解包后两个二进制就是全部。

3. 启动（四个参数是踩出来的，别改）

docker run -d --name ninfer --gpus '"device=0"' --ipc=host -p 18020:18020 \
  -v $PWD/models:/models:ro ninfer-3090:0.6.1 \
  /models/qwen3_8_27b.ninfer \
  --host 0.0.0.0 --port 18020 --model-id qwen3.8-27b --api-key "$KEY" \
  --max-context 184320 --kv-capacity 184320 \
  --max-concurrency 2 --max-pending-requests 16 --pending-timeout-ms 900000 \
  --prefill-chunk 1024 --kv-dtype rk8v4 --spec mtp --draft-tokens 3 --lm-head-draft

显存账（这张 24G 卡）：权重 16.67 GiB + KV 池（184320 token）5.61 GiB，模型加载 19 秒，启动后余量 1.02 GiB。

踩坑一句话版：v3 模型读不了（要钉 revision）、kv-capacity auto 起不来（要显式）、fp8 KV 在 SM86 上被引擎拒绝（没有对应内核）、长上下文 C2 第二个请求会排队超时（要调大 pending timeout）、开 vision 只能 136K。

划重点：单张 3090 上，180K 上下文 + 4bit KV(rk8v4) + C2 并发 + 关 vision 是反复对比后的最佳组合。
再往上加要么牺牲并发（C1），要么牺牲上下文（开 vision 只到 136K），要么牺牲速度（int8 + 关投机解码换 180K，但 decode 掉到 35 tok/s）。

二、测评

测试条件：单个 Docker 实例、--max-concurrency 2、--kv-dtype rk8v4、MTP3 投机解码、默认采样、
输入是真实长度的中英混合上下文（coding = 一整段代码 + 改代码要求；agent = 系统提示 + 工具定义 + 多轮工具返回 + 提问），
每条请求最多生成 160 token。输入超过约 90K 时一个 180K 的 KV 池装不下两份，那两行是单请求（表里并发列写 1）。

功耗墙 300W（这台的设置；卡默认 350W）。满载实测：

放开到 350W 实测 decode +8%（54.6 → 59.0 tok/s，SM 1410 → 1545 MHz），我为了控温没放。

coding 场景（长代码上下文 + 改代码）

agent 场景（system + 工具定义 + 多轮工具结果 + 提问）

四个观察

1. prefill 是串行的，C2 的两个请求不是同时开始吃 prompt：第二个的 TTFT ≈ 排队（第一个的 prefill 时间）+ 自己的 prefill。
   32K 输入时 39s / 80s，64K 时 87s / 177s，都是这个规律。所以 C2 的并发收益主要体现在 decode 阶段，不是 TTFT。
2. prefill 速度本身随输入变长而下降：8K 时 ~900 tok/s，64K 时 ~735，178K 时只有 ~545 tok/s。
   长上下文真正的代价是 TTFT（178K 输入要等 5.5 分钟），不是 decode。
3. decode 几乎不随上下文衰减：coding 场景 36～55 tok/s、agent 场景 59～80 tok/s，178K 输入下反而还有 41～59。
4. MTP 接受率完全看内容形态：agent 的工具调用轨迹是结构化 JSON，接受率 96～100%（每轮 3.9～4.0 个 token）；
   自由文本/代码只有 44～67%（每轮 2.4～3.0）。这也是 agent 场景 decode 比 coding 高一截的原因 —— 投机解码对结构化输出特别划算。

和 vLLM（我上一版用的栈）比：prefill 差一倍，原因是算力路径

同一张卡、同一个模型（Qwen3.8-27B W4A16），我上一版跑的是 syv-ai/HyperQwen 系的 vLLM 栈
（那套打了四十多个补丁 + 自定义 int8 预填注意力内核，不是原生 vLLM 开箱），本机实测：

单流 decode 同理：vLLM 那套 110–118 tok/s，ninfer 41–59 tok/s。两个方向都差大约一倍。

原因不是 ninfer 写得烂，是两条算力路径的物理上限差 2 倍。 27B dense 每 prefill 一个 token 约 54 GFLOP：

ninfer 已经把 FP16 这条路吃到七成。我把 --prefill-chunk 从 512 扫到 3584（911 / 925 / 927 / 925 tok/s），
没有可调余量；它的权重是 4–6 bit 混合精度、激活是 FP16，所以只能走 FP16 MMA。
想翻倍得让激活也走 int8，而 ninfer 现在没有这个开关（--kv-dtype 只管 KV cache）。
也正因如此，给它换 int8 权重是负收益 —— decode 是显存带宽瓶颈，权重从 4.6 bit 涨到 8 bit，每步要读的字节多 74%，decode 只会更慢。

顺带对齐第三方数据，ninfer 在 dense 27B 这级别并不难看（llama.cpp CUDA 在 3090 上跑 Qwen3.5-27B Q4_K：
4K 1,104 / 16K 977 / 32K 848 / 64K 679 tok/s）：浅上下文它低约 15%，64K 以上反而反超。
网上那些 5,000+ tok/s 的 prefill 数字是 7B 小模型或 3–4B 激活的 MoE，跟 dense 27B 不是一个量级，别被带偏。

所以怎么选：要吞吐、要短提示首字快（IDE agent、批量 API），vLLM 那套明显更强；
要单卡 180K + 双并发 + Anthropic 原生协议 + 部署极简（一个预编译包，无补丁无编译），ninfer 更省事。
我把它定位成"够用的长上下文单卡后端"，不拿它跟调优过的 vLLM 比跑分。

和官方数字的差距（为什么不是 71 tok/s）

官方单用户 71 tok/s 那组数据是 Windows 版跑出来的，README 里写得很清楚：
"A real-artifact Linux generation and Linux performance qualification remain open" —— Linux 二进制没做性能认证。
除去平台差异，我这边的缺口主要在两处：MTP 接受率（2.4 vs 2.83 token/轮）和 功耗墙（300W 把 SM 压在 ~1.5 GHz）。
参数上和官方 C1 示例逐字一致，没有漏开关。

三、一句话总结

NInfer 在 3090 上确实能用，单卡 180K 上下文 + 双并发当个人 agent 后端够了；
但它的甜区是"上下文长、并发低、部署省事"，不是跑分 —— 同卡同模型上，调优过的 vLLM 栈在 prefill 和单流 decode 上都快约一倍，
根因是算力路径（FP16 vs INT8 tensor core），不是实现质量。这点我不粉饰，选它买的是"一个预编译包跑起 180K + Anthropic 协议"。

抄配置的话，把上面那四个参数照抄，尤其 --kv-capacity 显式写 和 --pending-timeout-ms 调大 —— 这两个不改，C2 根本跑不起来。