结论先行：

• 速度：同机同法实测，NInfer 单路 88.2 t/s vs SGLang 98.3 t/s，SGLang 快 11.5%；但 NInfer 双路聚合能到 122 t/s。
• 智力：同一张卡、同一批题、同一评分脚本，AGIEval 1200 题打平（NInfer 1084 vs SGLang 1082），CEval+CMMLU 420 题 NInfer 领先 1.67pp。所谓"SGLang 智力更高"在数据上不成立。
• 稳定性：这是最大的坑。NInfer 这个 build 在 4080S 上并发必崩，崩了整卡进 full-chip reset，只能重启机器。我崩了三次，最后定位到 CUDA Graph 重放 × 批量（≥2 路）投机解码，加 --no-cuda-graph 解决，性能只掉 2.6%。
• 最终配置：单路 85.9 t/s、双路聚合 122 t/s、双路 × 256K 上下文全部跑通、显存余量 4.2GB。

之前关于SGLang的帖子：
https://lcz.me/topic/1654
https://lcz.me/topic/1631
https://lcz.me/topic/1629

一、测试机配置

注意：下载 artifact 必须用旧的那个 commit。HF neroued/Qwen3.8-27B-NInfer 现在的新版是 19.03 GiB（多了 DFlash2 companion weights），manifest 里写着 cuda_architecture: sm_120a + minimum_revision: 385b30ce，sm_89 的移植线用不了。旧版路径：
https://huggingface.co/neroued/Qwen3.8-27B-NInfer/resolve/3526913004b1cf552cb57b88d6a5c6f5e4a89a70/qwen3_8_27b.ninfer

二、速度对比（同一张卡、同一测法）

测法完全一致：同一段 prompt（Paris 历史）、max_tokens=256、temperature=0.7、reasoning_effort=medium、各跑 5 轮取平均，读服务端 per-request 的 timings。

同法差值 −11.5%。注意 NInfer 这条线用的是更小的 artifact（16.96 GiB 单文件，MTP + 视觉都内嵌），SGLang 那条线是目标模型 17.33 GiB + MTP 头 0.79 GiB + 独立 DFlash2 草稿 1.44 GiB，合计 19.56 GiB。

不过速度差异不能简单归因于引擎：两条线的量化方案不同（compressed-tensors INT4 vs groupwise-int）、投机机制不同（独立 1.92B 草稿模型 vs 内嵌单层草稿头）、上下文也不同（172K vs 262K）。要下"谁更快"的结论得先把这些变量对齐。

双路并发（NInfer 最终配置）：

有意思的是批处理下 MTP 接受率反而升高：单路 57% → 双路 71~74%，短请求甚至 92%。

三、智力对比（同一张卡、同一批题、同一评分脚本）

数据集两边各存一份并校验 md5 一致（agieval_eval.json 1200 题、combined_eval.json 420 题）。评分逻辑完全沿用原脚本，0-shot、temperature=0。

※ 两题是判分脚本的假阴性：一题答 C = πd（脚本期望的写法是 pi*d，语义其实完全相同）被判错；另一题答 反渗透，比脚本里的标准答案 蒸馏 更符合现代工程实际。人工看实际是 21/21。

AGIEval 分子任务

分歧 66 题：SGLang 对/NInfer 错 = 32，SGLang 错/NInfer 对 = 34 —— 完全对称。

结论：质量打平（NInfer 微幅领先），速度 SGLang 快 11.5%，稳定性 SGLang 完胜。 但 NInfer 换来的是 262K 上下文 + 双路并发能力。

四、三次崩卡（本篇最有价值的部分）

NInfer 这个 build 在 4080S 上有个致命特性：kernel 一挂就是整卡进 NV_ERR_GPU_IN_FULLCHIP_RESET 死锁，rmmod 卸不掉、nvidia-smi --gpu-reset 报 Not Supported（Xorg 占用），只能重启机器。我崩了三次。

崩溃 1 的源码级根因（确定性，可复现）

报错点在 bf16_gdn_gating_proj_kernels.cu:310 的协作启动。翻 sergiuszm/ninfer-4090 @ 1bd56c9a 的源码找到了：

// bf16_gdn_gating_proj_plan.cpp —— 预算是按 128 SM 的 RTX 4090 写死的
constexpr std::int32_t resident_ctas_27(Bf16GdnGatingScheduleId schedule) noexcept {
    return schedule == Bf16GdnGatingScheduleId::MmaCooperativeSplit8 ? 256 : 128;
}

而运行时算占用率的函数没按 SplitK 区分：

// bf16_gdn_gating_proj_kernels.cu
if constexpr (std::is_same_v<Geometry, Bf16Gdn27Geometry>) {
    // Qualified on the sm_120a build ...
    return 2;          // ← split8/split4/split2 一律返回 2 CTA/SM
}

split2 的真实占用率是 1 CTA/SM（512 线程 × 74 寄存器 = 37,888 寄存器/CTA，一个 SM 只有 65,536，装不下两个）——代码注释自己都写了 "split4/2 (512 threads, 74 regs) admit 1 CTA/SM"。

在 80 SM 的 4080S 上：

单次 prefill token	路由	网格 CTA	设备上限	结果
1024	split8	192 → 被切片成 144+48	160	安全
1664	split2	78	80	侥幸
1665	split2	84	80	崩
2048	split2	96	80	崩（实测踩中）

在 128 SM 的 4090 上 96 ≤ 128 恰好塞得下，所以作者测不出来；换到 80 SM 的卡就复现。 fork README 里"chunk ≤2688 的硬崩已修"这句话不跨 SM 数迁移。

结论：--prefill-chunk 必须 ≤1024。

崩溃 3 的判定实验（本篇的重点）

崩溃 1 有明确源码根因，但崩溃 3 是"跑得好好的突然死"。已知事实是：

• 单路串行跑了 4 小时零事故（AGIEval 1200 题 145 分钟 + CEval 420 题 + 全部调参基准）
• 只要并发就崩，但崩的时间从 4 分钟到 30 分钟不等

于是做对照实验，全部 2 路并发、负载与崩溃基线完全一致、各跑 40 分钟：

实验	配置	时长	请求数	失败	聚合吞吐	结果
基线	MTP + CUDA Graph	30.4 min	648	2	123.6	崩
Arm 1	关闭 MTP	40.2 min	399	0	59.7	存活
Arm 2	MTP + --no-cuda-graph	40.0 min	842	0	122.5	存活

判定：崩溃根因 = CUDA Graph 重放 × 批量（≥2 路）投机解码。

• Arm 1 证明单纯"批量解码"不崩（关掉投机就能活）
• Arm 2 是关键：保留 MTP、只关 CUDA Graph，冲过了基线 30.4 分钟的崩溃点，且速度几乎无损
• 单路即使带 CUDA Graph 也稳 → 需要 Graph × batch 的组合才触发

长浸泡验证

90.1 分钟 / 854 轮 / 1895 请求 / 678,408 token  →  0 失败
聚合吞吐 均 123.1 t/s（最低 79.1，最高 150.4）
0 条 cudaErrorLaunchFailure/FATAL，0 个 full-chip reset，0 个 Xid，37°C

累计 130 分钟 / 2,737 请求 / 97.8 万 token 零失败，是崩溃点的 4.3 倍。

代价只有 2.6%：单路 88.21 → 85.9 t/s，双路聚合 123.6 → 121.9 t/s。

五、调参实测

原帖 1803 的参数是给 4090D 48G 的，我这台是 32G，而且 1803 用的是 --kv-dtype fp8。四轮实测：

1）--kv-dtype fp8 → rk4v4-e8：同显存 KV 池 +90%（345K → 654K），代价仅 −3.0% 速度、−2.8pp 接受率。README 预告 5.7% 的税，实测更省。fp8 不要用，同样显存只能放一半 KV。

2）裁剪 + C=2 更优：
--vision-max-tokens 8192 --media-cache-mib 256 --media-live-mib 512 --max-concurrency 2
→ 显存 −2.46 GB，速度回到基线。关键：KV 池 524,288 正好 = 2 × 262,144，引擎按"并发数 × max-context"精确配池，不是缩水。

3）rk2v4-e8 不采用：再省 2.2GB，但速度掉到 85.66；而 262144 已是模型上下文上限，2-bit 换不来更长上下文。

4）思考预算不是速度杠杆（固定 20 题探针）：

模型自然思考只有 ~800 token，budget ≥4000 完全是死参数。2000 省 10% 且不掉分。

六、长上下文 × 双路并发验证

KV 池零余量下两路都跑满上下文，是唯一没底的边界。分级加压：

级别	双路各 prompt	合计 token	占 KV 池	TTFT	decode	墙钟	结果
L1	63,362	126,724	24%	53 / 55s	3.7 / 72.3	109s
L2	126,695	253,390	48%	125 / 127s	3.6 / 70.7	253s
L3	200,584	401,168	77%	235 / 233s	61.1 / 3.3	470s
L4（单路）	211,140	—	40%	250s	58.5	252s
L5（极限）	258,640	517,280	98.7%	335 / 346s	3.5 / 52.8	682s

双路 × 256K 可用，即使池子占满 98.7% 也不崩。

三个必须知道的行为特征：

1. prefill 是串行的，会饿死另一条通道：一条解码期撞上另一条 prefill 时被压到 3.3~3.7 t/s（日志实证 queue 5m35.8s、prefill 770.8 tok/s）。双路收益只在"两条都在解码"时兑现。
2. 长 prompt 的 TTFT 是硬成本：63K→53s，127K→126s，200K→235s，258K→335s（prefill 770~860 tok/s）。
3. MTP 接受率不随深度衰减：200K 处 58.8~60.4%，258K 处 54.2%。

七、最终启动参数

docker run -d --name ninfer-qwen38-27b \
  --restart unless-stopped --gpus all --ipc=host \
  -p 8080:8080 -e TZ=Asia/Shanghai \
  -v "$PWD/models:/app/models:ro" -v "$PWD/logs:/app/logs" \
  nahsilabs/ninfer-4090:1bd56c9a \
  models/qwen3_8_27b.ninfer \
  --host 0.0.0.0 --port 8080 \
  --max-context 262144 --kv-capacity auto \
  --max-concurrency 2 \
  --no-cuda-graph \
  --prefill-chunk 1024 \
  --kv-dtype rk4v4-e8 \
  --vision --vision-max-tokens 8192 \
  --media-cache-mib 256 --media-live-mib 512 \
  --max-pending-requests 16 --pending-timeout-ms 600000 \
  --host-kv-mib 24576 --host-state-slots 72 \
  --max-private-continuations 12 --max-shared-prefixes 8 \
  --auto-long-anchors 4 --max-long-anchors-per-continuation 4 \
  --device-state-slots 6 \
  --spec mtp --draft-tokens 3 --lm-head-draft \
  --model-id Qwen3.8-27B

实测结果：显存 28.6G / 32.8G（余量 4.2G）、单路 85.9 t/s、双路聚合 122 t/s、KV 池 524,288、上下文 262,144。

八、踩坑速查

九、结论

1. 4080S 32G 跑 NInfer + Qwen3.8-27B 是可行的，不用编译，社区有现成的 sm_89 镜像。
2. 质量和 SGLang 打平：AGIEval 1200 题 90.33% vs 90.17%，CEval+CMMLU 89.29% vs 87.62%。换引擎不会掉智力，反而在 CEval 上更高。
3. 速度 SGLang 领先 11.5%（98.3 vs 88.2 t/s）。但 NInfer 的权重占用更小（16.96 GiB vs 19.56 GiB），并换来 262K 上下文和可用的双路并发（聚合 122 t/s）。两者量化方案与投机机制都不同，速度差不能纯归因于引擎。
4. 这个 build 的并发是带雷的：必须 --no-cuda-graph，代价 2.6%。
5. 两条硬红线：--prefill-chunk ≤ 1024、--max-concurrency ≤ 2。碰了就要重启机器。

一句给同好的话：这张卡上用 NInfer，"稳"比"快"重要得多——先把那两个 flag 钉死，再谈调优。

技术来源

全部数据取自 ninfer-serve 服务端 per-request 日志与容器日志，不是客户端 SSE 计数（客户端计数会明显低估）。三次崩溃的 dmesg / journalctl -b -1 证据、源码片段、以及 1895 请求的浸泡日志均可复现。