4090 48G + NInfer + Qwen3.8-27B 的折腾记录

[mydy2008]

折腾了一天，给大家分享点经验。

1、仓库地址：https://github.com/sergiuszm/ninfer-4090

先让AI修复一个5ms的bug，然后再编译。
还要注意模型不要下载最新的，下载这个兼容的。
https://huggingface.co/neroued/Qwen3.8-27B-NInfer/resolve/3526913004b1cf552cb57b88d6a5c6f5e4a89a70/qwen3_8_27b.ninfer

2、我的启动参数：

docker run -d
--name ninfer-qwen38-27b
--restart unless-stopped
--gpus all
--ipc=host
-p 30000:8080
-e TZ=Asia/Shanghai
-v "$PWD/models:/workspace/models:ro"
-v "$PWD/logs:/workspace/logs"
ninfer-4090:sm89
ninfer-serve models/qwen3_8_27b.ninfer
--host 0.0.0.0
--port 8080
--max-context 262144
--kv-capacity auto
--max-concurrency 3
--max-pending-requests 16
--pending-timeout-ms 600000
--prefill-chunk 1024
--kv-dtype fp8
--host-kv-mib 24576
--max-private-continuations 12
--max-shared-prefixes 8
--host-state-slots 72
--auto-long-anchors 4
--max-long-anchors-per-continuation 4
--spec mtp
--draft-tokens 3
--lm-head-draft
--vision
--device-state-slots 6
--model-id Qwen3.8-27B-AWQ-INT4

3、实际情况

单路 Decode：普通文本约 112 tok/s，代码约 150 tok/s。
3 路 Decode：聚合约 198.5 tok/s。
Cold Prefill：短板，128K 约 1500 tok/s。
多路 Cold Prefill：基本串行，这是最大缺点。
GPU FP8 KV：786,432 tokens。
Host KV：24 GiB，而且已经实测发生 D2H spill / H2D restore。
长会话恢复：可以从分钟级 Cold Prefill 降到几百毫秒。
Vision：可以开启，不损失 786K GPU KV。
MTP3：比 MTP4 更适合你的综合负载。
12 private continuations：目前比 10 明显更合适。
250ms planner patch：压力下实测有效。
（继续增大prefill-chunk和mtp并没有好的效果）

4、尚未解决的问题

虽然prefill比较慢，但是首token延迟很小，decode也很快，kv比sglang和vllm都多，用着非常舒服。但是使用openclaw的时候，同一个对话会挤占好几个槽位，搞的12个槽位会很快用完，造成重新prefill。AI说要等openclaw支持supportsResponsesContinuation（开发版已经支持了，但是懒得折腾，目前用vllm也还行）

[johnnybegood]

@mydy2008 偏弱， 还可以继续优化

[Xiaote]

@mydy2008 数据挺全。johnnybegood 说偏弱，先把天花板摆出来再决定救不救：

单卡 48G、带宽约 1008GB/s，27B AWQ INT4 权重约 14–15GB，dense 等价的 decode 上限约 65–70 t/s。你实测 112（文本）/150（代码），说明 MTP3 已经把它抬到理论值的 1.6–2.2 倍，decode 这条路基本到头，别为它加预算。

真正该动的是你指出的两点：

1. 冷 prefill 和多路 prefill 串行。128K 冷预填 1500 t/s，单条就要 80 多秒，几条 agent 链一起来就排队。能动的只有减少重算：把 openclaw 的会话固定住（一个会话别拆成多个 continuation），把前缀缓存共享、长锚点这些参数用满；prefill-chunk 加大没用，说明瓶颈在算力而不是调度。
2. Host KV 的 D2H/H2D 换页。一旦 spill，restore 会和 prefill 抢 PCIe 带宽。既然 fp8 KV 已有 786K token 容量，先把单会话 context 压到 64–128K（agent 用不到 256K），盯 host-kv-mib 的实际占用，把 spill 消掉比多塞长上下文划算。

MTP3 好于 MTP4 合理：k 越大 draft 前缀越容易落空，有效接受长度上不去，还多花验证 FLOPs。建议记一下每档 k 的接受长度和 draft 头耗时占比，确认 3 是最优点。12 个 private continuations 同理——先堵住一个会话占多槽这个漏，比继续加槽位有效。

[terry]

挺好的，我正在准备开机搞这玩意，我评估下是否值得。