抡锤者

davidwei0826

附一张DSH代码开发实图，快的让我有点不太适应。
屏幕截图 2026-10-29 142644.png

davidwei0826

日期：2026-10-29 ｜ QEngine 1.3-vision（sha256:9916432e）｜ driver 595.91.07 / CUDA 13.2
前情：这台机器从 10-25 起跑 SGLang 0.5.22 + DFlash 投机解码，一直是我的主力 agent 后端。这次把 QEngine 拉上来做了两轮同口径 A/B，已切换上线。

0. 机器（很简单，不用羡慕）

项	值
GPU	2× RTX 3090 24G（TP=2，NVLink），PCIe 直插
内存 / CPU	48 GB DDR4-2400 / 16 vCPU（PVE 虚拟机，宿主双路 E5-2697 v4）
模型	`RedHatAI/Qwen3.8-27B-INT4`（compressed-tensors pack-quantized，19.5 GB）+ QEngine release 的 `model_mtp_ft.safetensors` / `token_rank.bin`
上下文	262,144（引擎自报 `max context`）

1. 部署（三步，一共十几分钟）

# 1) 镜像：纯文本版 1.16 GB；带视觉 8.9 GB（同一个引擎，多 PyTorch + ViT）
docker pull ghcr.io/bpx03/qengine:1.3-vision

# 2) 权重（本机到不了 huggingface.co，走 hf-mirror；GitHub 资产走代理）
REPO=RedHatAI/Qwen3.8-27B-INT4; DEST=/mnt/models/qengine-int4; BASE=https://hf-mirror.com/$REPO/resolve/main
curl -sf "https://hf-mirror.com/api/models/$REPO" | python3 -c 'import json,sys
for s in json.load(sys.stdin)["siblings"]:
  if s["rfilename"].endswith((".json",".safetensors",".jinja",".yaml")): print(s["rfilename"])' |
while read f; do curl -fL -C - --retry 8 -o "$DEST/$f" "$BASE/$f"; done
for a in model_mtp_ft.safetensors token_rank.bin SHA256SUMS; do
  curl -fL -C - --retry 8 -x http://myproxy:7890 -o "$DEST/$a" \
       "https://github.com/bpx03/QEngine/releases/download/v1.0/$a"; done
( cd "$DEST" && sha256sum -c SHA256SUMS )

compose 里真正起作用的就这些（其余按默认）：

image: ghcr.io/bpx03/qengine@sha256:9916432e...   # 1.3-vision
environment:
  - QE_GPUS=0,1
  - QE_MAX_SEQS=32
  - QE_RESERVE_GB=1.0,1.0        # 显存几乎全给 KV
  - QE_KV_ARCHIVE_GB=16          # 主机 pinned KV 层
  - QE_PREFIX_GB=4
  - QE_MEM_MARGIN_GB=6
  - QE_EXTRA_ARGS=--served-name Qwen3.8-27B --vision 1 --vision-device cuda:1
      --max-image-pixels 1048576 --disk-cache /app/cache/diskcache --disk-cache-gb 10 --persist-idle 60

启动 105 秒就绪（权重 19.5 GB + 视觉塔 5.8s + pinned 池 12.6s），日志直接自报容量：

vision encoder on cuda:1 in 5.8s (max 1.0 MPix per image)
KV pool: 330752 tokens shared by 32 sequence slots (max context 262144)
archive pool: 21.5 GB pinned in 12.6 s

四个坑（都踩过）：--vision-device 要 torch 设备串（cuda:1，给裸数字直接崩）；host tier 默认按 48 GB×2 算，48 GB 内存的机器不调小会挤爆；--max-image-pixels 默认 4.2 MPix，会白吃掉 17 万 token 的 KV 池（改成 1 MPix 就回来了）；max context = min(模型, 池)，所以想让单流到 256K，必须先把池顶到 ≥262,144。

2. 实测数据

方法：自建 harness，Python 直打 /v1/chat/completions（stream + include_usage），每档换一个唯一 seed 保证是真冷 prefill；并发用 N 路同时发同一 prompt 测每流 decode；另有质量 10 题 / NIAH / 工具调用 / 视觉四条腿。引擎不返 llama.cpp 的 timings，用 max_tokens=1 探针推定 prefill。

prefill 随上下文深度（连贯散文语料，thinking off）

上下文	prefill t/s	首字
8 K	2,975	2.63 s
32 K	3,513	9.28 s
131 K	2,779	47.1 s

单流超长上下文（重复 filler 语料，口径与上表不同，别混着比）：254,000 token 一口吞，首字 60.4 s（≈4,200 t/s），decode 184 t/s。

并发 decode（每流 tok/s，同一 prompt）

	1 路	2 路	4 路
8 K	244.8	210.4	155.0
32 K	236.3	191.7	145.1

投机解码是 MTP（--mtp-k 7 + 那两个 release 文件），平均 accept length 6.00、接受率 71.4%。

KV 容量（GPU + 内存两级）：显存池 330,752 + 主机 pinned 21.5 GB。压力测试用 4 条全程互不相同的长会话（每 ~1500 token 插一段独占盐，杜绝块级共享）：

场景	每条实际 token	合计 KV	结果
4 路独立	132,358	52.9 万	4/4 成功，超出显存的部分走内存层
4 路独立	164,623	65.8 万	4/4 成功，其中一条从 archive 取回 131,072 token（日志：`cached 131072 from archive`）

重启不丢上下文（这条是我换它的真实动机）：docker restart 之后，同一条 132K 会话首字 2.45 s（全新冷吞要 60 s）；更早一次 20K 会话重启后追问 0.73 s，停机→可用 100 秒。

质量腿：10 题 10/10，NIAH 16K / 131K 全中，工具调用 PASS，视觉 4/4（红/蓝/圆/矩形全对）。

3. 和 SGLang 的对比

同机器、同一天、同一套探针（SGLang 0.5.22 + DFlash2 投机解码、--context-length 262144、hicache 8 GB）。注意两边权重不同（RedHatAI INT4 vs AutoRound W4A16），差异不能全归引擎；启动到启动本身有 ±10% 抖动。

项目	SGLang	QEngine
prefill 8K / 32K / 131K	2,498 / 2,266 / 1,622	2,975 / 3,513 / 2,779	×1.19 / ×1.55 / ×1.71
首字 32K / 131K	14.47 s / 80.8 s	9.28 s / 47.1 s	省 36% / 42%
每流 decode 8K（1/2/4 路）	176.7 / 171.3 / 136.1	244.8 / 210.4 / 155.0	+39% / +23% / +14%
每流 decode 32K	194.4 / 174.2 / 144.0	236.3 / 191.7 / 145.1	+22% / +10% / 持平
投机解码 accept length	3.7–4.3	6.00
冷启动	~12 分钟	105 秒
重启后缓存	全丢	保留（disk-cache，2.45 s 接回 132K 会话）
KV 总量（GPU+内存）	~41 万 token	~73 万 token（实测吃下 65.8 万）
跨请求部分前缀	radix 树，命中后 0.25 s	块哈希（`cached … from other slot`），命中后 0.67–1.6 s	SGLang 更锋利
视觉	未配	`--vision 1`
质量 / NIAH / 工具	10/10，16K+131K 全中	一样	打平（10 题不够狠，这点我不吹）

唯一明显输给 SGLang 的是热前缀的极致命中：同语料换问题，SGLang 首字 0.25 s，QEngine 0.67–1.6 s——它的缓存是按 prefill chunk 对齐的，尾部总有几 K token 要重算。但我实际体感是净赢：冷会话快 1.5–1.7 倍，而冷会话我每天遇到的次数远多于"完美命中前缀"。

4. 结论

值得换：显存紧张的双 3090/4090 档、多轮 agent（长 system + 工具往返）、讨厌重启代价的——收益最大。
先算内存：48 GB 内存下 pinned KV 层只能到 ~21.5 GB（再大就挤爆），我准备加到 96 GB 后把 QE_KV_ARCHIVE_GB 提到 48，KV 总量能上 130 万 token。这台机器上"能装多少 KV"完全由内存决定，跟显存无关。
顺手把主机 THP 从 madvise 改成 always：pinned 池从 228 秒降到 12.6 秒。引擎会抱怨"大页覆盖只有 67%"，但实测 prefill/decode 没有任何可测差异——那个警告不值得追。
许可是 PolyForm Noncommercial 1.0.0：个人自用没问题，商用要另外拿授权。

有问题问，配置和测试脚本都在，可以复现。

davidwei0826

整个kv在nvfp4的方案里最多只有256k.在单并发长上下文和双并发短上下文中，选择了后者。 Prefill在高上下文时衰减比较严重，均衡选择了c=2, ctx=128k。
V100这两天开始涨价了。纯文字llm，不做视频的，可以参考。

davidwei0826

成绩速览（V100-PCIE-32G / 200W / 单请求）

指标	最好	区间
decode	93.9 tok/s（编码任务，640 token，MTP 接受率 92%）	44.9–93.9 tok/s（取决于任务与 MTP 接受率）
prefill	1,019.0 tok/s（7.9K prompt）	505.8–1,019.0 tok/s（随上下文深度衰减）
TTFT	0.13 s（完全相同的 prompt 重发，前缀 100% 命中）	0.18–0.47 s（短 prompt）→ 1.96 s @2K → 250.27 s @128K
并发	2 路各 124.6K 上下文实测跑通	第二路排队 4m1.1s（prefill 串行）
显存	权重 19.7 GiB + KV 池 262,144 token	启动后 free 1.21 GiB

这篇针对 neroued/Qwen3.8-27B-nvfp4-NInfer 这个 nvfp4 制品，写两件事：
① 完整部署流程（含源码锚点、Dockerfile、制品下载校验、启动脚本、报错对照），别人或别人的 agent 照着能直接跑起来；
② 全部实测数字（上下文 / 制品 A/B / 任务类型 / 并发 / 显存容量 / 前缀复用），只列数据，结论很少。

给 agent / 想直接照做的人：把第 3 节那个脚本原样存成 deploy-v100-nvfp4.sh，sudo bash 跑完即可（驱动、Docker、CUDA 12.8、编译引擎、打镜像、下制品校验、启动、健康检查全在里面）。
所有锚点都已钉死：引擎 repo + commit、制品 repo + revision + sha256、镜像底座、启动参数。文中标注 ️ 的四处是必须照做的（非 open 驱动 / v2 容器制品 / 显式 --kv-capacity / --pending-timeout-ms），踩错会直接报错或起不来。

0. 环境

项	值
GPU	Tesla V100-PCIE-32GB（GV100，Volta SM70，32G HBM2，PCIe Gen3 x16）
形态	PVE 直通给 Ubuntu 24.04 VM（16 vCPU / 32G RAM / 200G 系统盘）
宿主 CPU	Xeon E5-2697 v4 @2.30GHz ×16（Broadwell，无 AVX-512）
驱动	580.178.04（非 open）
功率墙	200 W（V100-PCIE 默认 250 W）
引擎	NInfer V100/sm_70 分支，`hamawang/ninfer-v100-20260916` @ `f17d37fc98b78cc025a1037e8adb1f4fb83813fb`
编译	CUDA 12.8，`-DCMAKE_CUDA_ARCHITECTURES=70`
容器底座	`nvidia/cuda:12.8.0-runtime-ubuntu24.04`
制品	`qwen3_8_27b_nvfp4.ninfer`（20.02 GiB，container_version 2）
运行参数	`--max-context 131072 --kv-capacity 262144 --max-concurrency 2 --kv-dtype int8`
实测占用	权重 19.7 GiB，KV 池 262,144 token，运行时 10.8 GiB，启动后 free 1.21 GiB，ready 18.2 s

1. 部署

1.1 驱动（Volta 必须非 open）

sudo apt-get install -y "linux-headers-$(uname -r)" nvidia-driver-580-server
sudo modprobe nvidia && nvidia-smi -L
sudo nvidia-smi -pm 1 && sudo nvidia-smi -pl 200

-open 内核模块只支持 Turing 及更新架构，Volta 装上会报
not supported by open nvidia.ko ... does not include the required GPU System Processor (GSP)。
R580 是 Maxwell / Pascal / Volta 的最后一条驱动分支。
nvidia-smi -pl 不跨重启保留，需要开机重施（附脚本里给了 systemd oneshot 单元）。

1.2 引擎源码与构建

git clone https://github.com/hamawang/ninfer-v100-20260916.git /opt/ninfer-v100
cd /opt/ninfer-v100 && git checkout f17d37fc98b78cc025a1037e8adb1f4fb83813fb

# 需要 CUDA 12.8 toolkit（CUDA 13 已移除 Volta 的离线编译）
bash deploy-v100/scripts/build-v100.sh
#   = cmake -S . -B build-v100 -G Ninja -DCMAKE_BUILD_TYPE=Release \
#       -DCMAKE_CUDA_COMPILER=/usr/local/cuda-12.8/bin/nvcc \
#       -DCMAKE_CUDA_ARCHITECTURES=70 -DNINFER_BUILD_BENCHMARKS=ON
#     cmake --build build-v100 -j6

产物（可用于校验你自建的二进制，同 commit + CUDA 12.8 + sm_70）：

371fd8de37e73df12b1f61144e43b210a12f9c0ef4acc193f5ae3f11f4294658  build-v100/apps/ninfer
6671447e3cbbf07565dff9417462d01bcf8aa1093aa5c9f83fb6a9a0ce79ac10  build-v100/apps/ninfer-serve

1.3 打镜像（完整 Dockerfile）

底座必须与制品编译时的 CUDA 版本对齐（二进制 RUNPATH 硬指 /usr/local/cuda-12.8/...）：

FROM nvidia/cuda:12.8.0-runtime-ubuntu24.04

ARG DEBIAN_FRONTEND=noninteractive

# base 镜像只带 NVIDIA 源、没有 Ubuntu 归档，先换源再装运行库
RUN rm -f /etc/apt/sources.list.d/ubuntu.sources 2>/dev/null; \
    printf '%s\n' \
      'Types: deb' \
      'URIs: https://mirrors.tuna.tsinghua.edu.cn/ubuntu' \
      'Suites: noble noble-updates noble-backports' \
      'Components: main universe restricted multiverse' \
      'Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg' \
      '' \
      'Types: deb' \
      'URIs: https://mirrors.tuna.tsinghua.edu.cn/ubuntu' \
      'Suites: noble-security' \
      'Components: main universe restricted multiverse' \
      'Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg' \
      > /etc/apt/sources.list.d/ubuntu.sources \
    && apt-get update -qq \
    && apt-get install -y --no-install-recommends \
        ca-certificates libavcodec60 libavformat60 libavutil58 \
        libswscale7 libswresample4 libcurl4t64 \
    && rm -rf /var/lib/apt/lists/*

COPY ninfer ninfer-serve /usr/local/bin/
RUN chmod +x /usr/local/bin/ninfer /usr/local/bin/ninfer-serve

WORKDIR /workspace
EXPOSE 8080
CMD ["ninfer-serve", "--help"]

mkdir -p ctx && cp /opt/ninfer-v100/build-v100/apps/{ninfer,ninfer-serve} ctx/
docker build -t ninfer-v100:0.1.0 ctx/

libcuda.so.1 不打进镜像，由 --gpus 从宿主驱动注入（镜像与驱动版本解耦）。

1.4 下载 nvfp4 制品（必须钉这个 revision）

mkdir -p /srv/models && cd /srv/models
curl -L -C - -o qwen3_8_27b_nvfp4.ninfer \
  "https://hf-mirror.com/neroued/Qwen3.8-27B-nvfp4-NInfer/resolve/204e3d92c30d9d05f3300d2f52e443ad1edf6ddf/qwen3_8_27b_nvfp4.ninfer"

# 校验（必须一致，否则说明下错版本）
sha256sum qwen3_8_27b_nvfp4.ninfer
# bb3360522a06e136e0367f5703414d26272b7285c8a6ab6194135c17dbd81b32

字段	值
repo	`neroued/Qwen3.8-27B-nvfp4-NInfer`
revision（钉死）	`204e3d92c30d9d05f3300d2f52e443ad1edf6ddf`（2026-08-19）
文件 / 字节	`qwen3_8_27b_nvfp4.ninfer` / 21,492,695,040（20.02 GiB）
sha256	`bb3360522a06e136e0367f5703414d26272b7285c8a6ab6194135c17dbd81b32`
container_version	2

为什么不能下 main：仓库 main（a107ba1b）上的同名文件是 container v3（23,719,496,192 B），本引擎只认 v2，加载直接失败：

ERROR startup failed | inspecting artifact | 31.4 ms
FATAL server failed during startup | artifact magic is not NInfer v2

容器版本看文件头 8 字节即可判断：

dd if=qwen3_8_27b_nvfp4.ninfer bs=1 count=8 status=none | od -c
# 正确： N I N F E R \0 002
# v3  ： N I N F E R \0 003

实测下载速度（HF 官方站不可达时用 hf-mirror）：12.4 MB/s，20 GiB 约 29 分钟；curl -C - 支持断点续传。
制品建议放本地盘：本地盘加载 18.2 s，走 NFS 是 52–59 s。

1.5 启动脚本（可直接用）

#!/usr/bin/env bash
# ninfer-v100 run.sh —— nvfp4 + 2 并发 × 128K
set -euo pipefail

NAME=ninfer
IMG=ninfer-v100:0.1.0
MODEL_DIR=${MODEL_DIR:-/srv/models}
MODEL=${MODEL:-qwen3_8_27b_nvfp4.ninfer}
PORT=${PORT:-18080}
CTX=${CTX:-131072}          # 单请求逻辑上下文上限
KV_CAP=${KV_CAP:-262144}    # ★ 共享 KV 池，必须显式给 = 2 × CTX
CONC=${CONC:-2}             # 并发路数
PREFILL=${PREFILL:-2048}    # V100 推荐
PENDING_MS=${PENDING_MS:-600000}   # ★ 默认 30s 会把并发长请求挤成 503
API_KEY=${API_KEY:-}        # 留空 = 不鉴权

ARGS=(--host 0.0.0.0 --port 8080
      --max-context "$CTX" --kv-capacity "$KV_CAP" --max-concurrency "$CONC"
      --kv-dtype int8 --prefill-chunk "$PREFILL" --pending-timeout-ms "$PENDING_MS"
      --spec mtp --draft-tokens 3 --lm-head-draft
      --preserve-thinking --cors)
[ -n "$API_KEY" ] && ARGS+=(--api-key "$API_KEY")

case "${1:-start}" in
  start)
    docker rm -f "$NAME" >/dev/null 2>&1 || true
    docker run -d --name "$NAME" --restart unless-stopped \
      --gpus all --ipc=host \
      -e NVIDIA_VISIBLE_DEVICES=all -e NVIDIA_DRIVER_CAPABILITIES=compute,utility \
      -p "${PORT}":8080 -v "$MODEL_DIR":/models:ro \
      "$IMG" ninfer-serve "/models/$MODEL" "${ARGS[@]}"
    echo "started -> http://0.0.0.0:${PORT}"
    ;;
  stop)    docker stop -t 30 "$NAME";;
  logs)    docker logs -f --tail 100 "$NAME";;
  status)  docker ps -a --filter "name=^${NAME}$";;
  *) echo "usage: $0 {start|stop|logs|status}"; exit 1;;
esac

参数说明（都是实测踩出来的）

参数	为什么是这个值
`--max-context 131072`	128K 逻辑上限。超限请求被明确拒绝而不是截断：`400 context_length_exceeded: prepared prompt exceeds Engine max_context 131072`
`--kv-capacity 262144`	必须显式。nvfp4 权重 19.7 GiB 下 `auto` 只肯给 ~237K，而且 auto 模式要额外留 1 GiB headroom → 直接拒绝启动。显式 262144 正好 = 2×128K，实测启动后 free 1.21 GiB
`--max-concurrency 2`	引擎真批处理路数。客户端并发超过它会被饿（实测第 3、4 条掉到 5.7 tok/s）
`--kv-dtype int8`	Volta 没有 fp8 / nvfp4 / k8v4 的 KV 内核，只能 `bf16` 或 `int8`
`--prefill-chunk 2048`	V100 上的推荐值
`--pending-timeout-ms 600000`	默认 30 s。prefill 是单通道串行的，一条 125K prompt 要 prefill 4 分钟，第二路在队列里等超过 30 s 就被判 `503 request_queue_timeout`
`--spec mtp --draft-tokens 3 --lm-head-draft`	MTP 投机解码；decode 快慢几乎完全由它的接受率决定（见第 2.3 节）

1.6 验收

curl -s localhost:18080/health          # {"status":"ok"}
curl -s localhost:18080/v1/models       # max_model_len = 131072

curl -s localhost:18080/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "model":"qwen3.8-27b",
  "messages":[{"role":"user","content":"只回答两个字：收到"}],
  "max_tokens":16,"reasoning_effort":"none"}' | head -c 200

启动日志里会打出显存账本（--log-level debug 更详细）：

INFO  engine ready | qwen3.8-27b/nvfp4 | total 18.2s | weights 19.7 GiB
INFO  capacity | KV 262,144 tokens, int8, explicit | pages 4,096/4,096 | runtime 10.8 GiB | free 1.21 GiB
INFO  listening on http://0.0.0.0:8080 | model qwen3.8-27b | auth disabled

1.7 报错对照表

现象	根因	处置
`nvidia-smi`: `couldn't communicate with the NVIDIA driver` / `nvtop` 看不到卡	驱动没装（直通本身没问题，`lspci` 能看到 `10de:1db6`）	装 `nvidia-driver-580-server`
`not supported by open nvidia.ko ... GPU System Processor (GSP)`	装了 `-open` 驱动，Volta 不支持	换非 open：`apt purge "nvidia-*-open"` 再装 `nvidia-driver-580-server`
`cannot open shared object file: libcudart.so.12`	底座 CUDA 版本与二进制 RUNPATH 不一致	底座用 `cuda:12.8.0-runtime-ubuntu24.04`
`FATAL ... artifact magic is not NInfer v2`	下了 v3 容器制品（main 上的那个）	钉 revision `204e3d92c30d`（v2 容器）
`minimum Engine runtime reservation requires … but only … available after weights`	显存不够（`auto` 模式还要额外 1 GiB）	显式给 `--kv-capacity`，并按下表算容量
`503 request_queue_timeout`	默认 30 s 排队超时 + prefill 串行	`--pending-timeout-ms 600000`
`400 context_length_exceeded`	prompt + 输出超过 `--max-context`	调小 prompt 或调大 `--max-context`（受显存限制，见 2.5）

2. Benchmark

统一条件：贪心（temperature=0）、reasoning_effort: none（除注明）、prompt 为同一份技术文档按目标长度拼接；decode = 引擎口径「已提交输出 token / 秒」；TTFT = 服务端 prompt 处理时间（不含排队）；功率墙 200 W；负载期功耗中位 195 W、SM 频率中位 1087 MHz（最高 1380 MHz）。

2.1 上下文长度扫描（nvfp4 制品，单请求，128 输出 token）

目标上下文	prompt token	prefill tok/s	TTFT	decode tok/s	MTP 接受率
2K	1,967	1,003.5	1.96 s	56.8	47%（38/81）
8K	7,907	1,019.0	7.76 s	72.6	71%（45/63）
32K	31,667	868.6	36.46 s	57.2	60%（45/75）
64K	63,311	699.4	90.52 s	36.2	40%（37/93）
128K	126,599	505.8	250.27 s	37.0	60%（45/75）

补充：同一配置下 8K prompt、320 输出上限的持续生成实测 71.5 tok/s（MTP 71%）。

2.2 nvfp4 vs groupwise-int（同一脚本、同一参数，唯一变量是制品）

neroued/Qwen3.8-27B-NInfer @ 18dfc887423f（groupwise-int，16.96 GiB，sha256 eec39564993d…4bf3e）作为对照：

shape	groupwise-int：prefill / decode / MTP	nvfp4：prefill / decode / MTP
1K	987.9 / 41.8 / 51%	1,003.5 / 56.8 / 47%
7K	1,014.0 / 43.3 / 58%	1,019.0 / 72.6 / 71%
30K	864.7 / 42.4 / 65%	868.6 / 57.2 / 60%
61K	696.3 / 31.3 / 52%	699.4 / 36.2 / 40%
123K	505.9 / 29.5 / 63%	505.8 / 37.0 / 60%
编码任务（640 tok，两边 MTP 都 89%）	115.2 / 58.6 / 89%	119.5 / 90.9 / 89%
持续生成（8K，66 tok）	951.1 / 41.6 / 58%	954.5 / 71.5 / 71%
双并发（8K，均缓存命中）	批 wall 3.84 s / 188 tok / 48.9 tok/s	批 wall 2.55 s / 152 tok / 59.7 tok/s

上下文扫描那几行的 decode 不能直接横向比：权重不同 → 生成的文本不同 → MTP 接受率不同（40% vs 52% 之类），短样本下接受率差异会盖过真实速度差。编码任务那行是干净的（prompt、输出长度 640、贪心、MTP 接受率 464/523 vs 467/525 全部对齐）：58.6 → 90.9 tok/s。
注：这张表的数字来自成对跑的那一轮；同一 prompt 在 2.3 节另一轮里测得 93.4/93.9 tok/s（MTP 91–92%），两轮差异属运行间波动（同一制品重跑 ±3%）。

2.3 任务类型（nvfp4，8K 与 64K 两档）

任务	输出 token	8K：decode / MTP	64K：decode / MTP
写代码（LRU + pytest）	640	93.4 / 91%	93.9 / 92%
JSON 字段抽取	24	82.7 / 90%	82.7 / 90%
摘要（5.9K 文档）	56	81.2 / 81%	81.4 / 81%
翻译	48	78.7 / 76%	78.3 / 76%
推理（`effort=xhigh`，1024 思考 token）	1024	70.8 / 61%	70.6 / 61%
找 bug 根因（闭包 late-binding）	253	68.8 / 57%	68.8 / 57%
闲聊	92	55.8 / 42%	55.9 / 42%
写小说	257	44.9 / 26%	47.5 / 31%

TTFT 方面：短 prompt（几十 token）在 8K 与 64K 档几乎无差别（0.09–0.47 s），只有 5.9K 文档摘要那档是 5.8 s。

2.4 并发

（a）双并发长上下文（本机生产配置实测，2 路各 ~125K）

路	prompt token	TTFT（服务端）	其中排队	prefill tok/s	输出	wall
L1	124,632	241.0 s	0	517	61	319.9 s
L2	124,632	247.6 s（引擎记 8m8.7s）	4 m 1.1 s	503	61	490.9 s

（b）解码批处理（引擎 5 s 窗口口径，groupwise 制品同引擎测得）

batch	聚合 decode tok/s	相对 batch=1
1.00	60.4	1.00×
2.00	87.2	1.44×
3.98	126.8	2.10×

（c）端到端（每路冷启动 8K prompt + 320 输出 token，groupwise 制品）

服务端并发	客户端路数	单路端到端	聚合端到端	加速比
2	1	24.4 tok/s	24.4	1.00×
2	2	24.0–24.6	26.5–27.2	1.11×
4	4	23.9	29.3	1.22×

（d）服务端日志里的两个并发现象（原文）

# prefill 单通道串行：任一瞬间只有 1 路在 prefill，其他在等
throughput | 5.0s | prefill 409.6 tok/s (2,048 tok) | running 1 (prefill 1) | waiting 1 | host 53.9%

# prefill 会饿死 decode：有 prefill 时 decode 掉到个位数
throughput | 5.0s | prefill 819.2 tok/s (4,096 tok) | decode  3.2 tok/s | running 3 (prefill 1, decode-ready 2) | batch 2.00
throughput | 5.0s |                              | decode 126.8 tok/s | running 4 (decode-ready 4)              | batch 3.98

2.5 显存与容量（这块最实用）

用失败报错反解出的引擎显存公式（32G V100，int8 KV，MTP3）：

运行时占用 = 2.75 GiB（固定：state 槽 + workspace + CUDA graph） + KV 池容量 × 35,904 B
权重后可用显存：nvfp4 11.70 GiB / groupwise-int 14.75 GiB

实测容量上限（--max-concurrency 2，容量需为 64 的倍数，均为「能启动 + 能跑通请求」验证过的值）：

	groupwise-int	nvfp4
权重	16.7 GiB	19.7 GiB
权重后可用	14.75 GiB	11.70 GiB
`--kv-capacity auto`	328,960 token	拒绝启动（差 0.88 GiB）
最大共享池	358,912 token	267,456 token
双并发每路可用	≈179K	≈130K
2×160K（池需 327,680）	余 31,232	差 2.01 GiB；关掉 graph + state 槽也只省 622 MiB，仍差 1.40 GiB

单请求边界（--max-context 131072）：

HTTP 400 {"error":{"code":"context_length_exceeded",
  "message":"prepared prompt exceeds Engine max_context 131072", ...}}

2.6 前缀复用（同引擎，16K 文档）

（同一组测量：16K 文档，prompt 15,846–15,886 token，同引擎）

场景	prompt token	命中前缀 token	TTFT
冷请求	15,846	0	16.47 s
完全相同请求重发	15,846	15,839（100%）	0.13 s
同 prompt、只改 max_tokens（64 → 256）	15,846	15,839（100%）	0.13 s
prompt 后追加一句（Chat Completions）	15,855	0	16.72 s
同正文、换会话编号	15,846	0	16.80 s
显式 `prompt_cache_breakpoint` 写入后再追加读取	15,855	0	17.00 s
Anthropic `cache_control` 写入 → 追加读取	15,886	15,879	1.65 s
Responses API `previous_response_id` 续轮	—	15,917	1.17 s

2.7 运行条件

项	值
功率墙	200 W（默认 250 W，可设 100–250）
负载期功耗	中位 195 W，最高 228 W
负载期 SM 频率	中位 1087 MHz，最高 1380 MHz（卡的最大 SM 时钟即 1380）
空载	37–40 °C / 约 60 W
PCIe	Gen3 x16（8 GT/s），非瓶颈

3. 一键部署脚本

#!/usr/bin/env bash
# ============================================================
#  NInfer + Qwen3.8-27B (nvfp4) @ Tesla V100-PCIE-32GB
#  CUDA 12.8 / sm_70 / Docker / 200W / 2 并发 × 128K
#  用法: sudo bash deploy-v100-nvfp4.sh
# ============================================================
set -euo pipefail
MODEL_DIR=${MODEL_DIR:-/srv/models}
PORT=${PORT:-18080}; CTX=${CTX:-131072}; KV_CAP=${KV_CAP:-262144}
CONC=${CONC:-2};   POWER_LIMIT=${POWER_LIMIT:-200}
SRC_DIR=${SRC_DIR:-/opt/ninfer-v100}; CUDA_ROOT=${CUDA_ROOT:-/usr/local/cuda-12.8}
REPO=https://github.com/hamawang/ninfer-v100-20260916.git
COMMIT=f17d37fc98b78cc025a1037e8adb1f4fb83813fb
ART_URL=https://hf-mirror.com/neroued/Qwen3.8-27B-nvfp4-NInfer/resolve/204e3d92c30d9d05f3300d2f52e443ad1edf6ddf/qwen3_8_27b_nvfp4.ninfer
ART_SHA=bb3360522a06e136e0367f5703414d26272b7285c8a6ab6194135c17dbd81b32
IMG=ninfer-v100:0.1.0
step(){ echo; echo "==== $* ===="; }

step "1/6 NVIDIA 驱动（非 open）+ 功率墙"
if ! command -v nvidia-smi >/dev/null 2>&1; then
  apt-get update -qq && apt-get install -y "linux-headers-$(uname -r)" nvidia-driver-580-server
  modprobe nvidia 2>/dev/null || { echo "驱动已装，请重启后重新运行本脚本"; exit 0; }
fi
nvidia-smi -L
nvidia-smi -pm 1 && nvidia-smi -pl "$POWER_LIMIT"
# 功率墙不跨重启，落一个开机单元
cat > /usr/local/bin/nvidia-powerlimit.sh <<'EOF'
#!/bin/bash
for _ in $(seq 1 60); do nvidia-smi -L >/dev/null 2>&1 && break; sleep 5; done
nvidia-smi -pm 1 >/dev/null 2>&1 || true
nvidia-smi -pl "${1:-200}"
EOF
chmod +x /usr/local/bin/nvidia-powerlimit.sh

step "2/6 Docker + nvidia-container-toolkit"
if ! command -v docker >/dev/null 2>&1; then
  install -m 0755 -d /etc/apt/keyrings
  curl -fsSL https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/ubuntu/gpg \
    | tee /etc/apt/keyrings/docker.asc >/dev/null && chmod a+r /etc/apt/keyrings/docker.asc
  echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/ubuntu $(. /etc/os-release; echo "$VERSION_CODENAME") stable" \
    > /etc/apt/sources.list.d/docker.list
  apt-get update -qq && apt-get install -y docker-ce docker-ce-cli containerd.io
fi
if ! command -v nvidia-ctk >/dev/null 2>&1; then
  apt-get update -qq && apt-get install -y nvidia-container-toolkit || {
    curl -fsSLO https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
    dpkg -i cuda-keyring_1.1-1_all.deb && apt-get update -qq && apt-get install -y nvidia-container-toolkit; }
fi
nvidia-ctk runtime configure --runtime=docker
systemctl enable --now docker && systemctl restart docker

step "3/6 CUDA 12.8 toolkit（编译引擎）"
if [ ! -x "$CUDA_ROOT/bin/nvcc" ]; then
  curl -fsSLO https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
  dpkg -i cuda-keyring_1.1-1_all.deb && apt-get update -qq
  apt-get install -y cuda-toolkit-12-8
fi
"$CUDA_ROOT/bin/nvcc" --version | tail -1

step "4/6 构建引擎"
if [ ! -x "$SRC_DIR/build-v100/apps/ninfer-serve" ]; then
  command -v cmake >/dev/null 2>&1 && command -v ninja >/dev/null 2>&1 || apt-get install -y cmake ninja-build git
  [ -d "$SRC_DIR/.git" ] || git clone "$REPO" "$SRC_DIR"
  git -C "$SRC_DIR" checkout "$COMMIT"
  ( cd "$SRC_DIR" && CUDA_ROOT="$CUDA_ROOT" bash deploy-v100/scripts/build-v100.sh )
fi
sha256sum "$SRC_DIR"/build-v100/apps/ninfer "$SRC_DIR"/build-v100/apps/ninfer-serve

step "5/6 打镜像 + 下制品"
CTXDIR=$(mktemp -d)
cp "$SRC_DIR"/build-v100/apps/{ninfer,ninfer-serve} "$CTXDIR"/
cat > "$CTXDIR/Dockerfile" <<'EOF'
FROM nvidia/cuda:12.8.0-runtime-ubuntu24.04
ARG DEBIAN_FRONTEND=noninteractive
RUN rm -f /etc/apt/sources.list.d/ubuntu.sources 2>/dev/null; \
    printf '%s\n' 'Types: deb' 'URIs: https://mirrors.tuna.tsinghua.edu.cn/ubuntu' \
      'Suites: noble noble-updates noble-backports' 'Components: main universe restricted multiverse' \
      'Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg' '' \
      'Types: deb' 'URIs: https://mirrors.tuna.tsinghua.edu.cn/ubuntu' 'Suites: noble-security' \
      'Components: main universe restricted multiverse' \
      'Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg' \
      > /etc/apt/sources.list.d/ubuntu.sources \
    && apt-get update -qq \
    && apt-get install -y --no-install-recommends ca-certificates \
        libavcodec60 libavformat60 libavutil58 libswscale7 libswresample4 libcurl4t64 \
    && rm -rf /var/lib/apt/lists/*
COPY ninfer ninfer-serve /usr/local/bin/
RUN chmod +x /usr/local/bin/ninfer /usr/local/bin/ninfer-serve
WORKDIR /workspace
EXPOSE 8080
EOF
docker build -t "$IMG" "$CTXDIR"
mkdir -p "$MODEL_DIR"
if [ ! -f "$MODEL_DIR/qwen3_8_27b_nvfp4.ninfer" ]; then
  curl -L -C - -o "$MODEL_DIR/qwen3_8_27b_nvfp4.ninfer" "$ART_URL"
fi
echo "$ART_SHA  $MODEL_DIR/qwen3_8_27b_nvfp4.ninfer" | sha256sum -c -

step "6/6 启动"
docker rm -f ninfer >/dev/null 2>&1 || true
docker run -d --name ninfer --restart unless-stopped --gpus all --ipc=host \
  -e NVIDIA_VISIBLE_DEVICES=all -e NVIDIA_DRIVER_CAPABILITIES=compute,utility \
  -p "${PORT}":8080 -v "$MODEL_DIR":/models:ro "$IMG" \
  ninfer-serve /models/qwen3_8_27b_nvfp4.ninfer \
    --host 0.0.0.0 --port 8080 \
    --max-context "$CTX" --kv-capacity "$KV_CAP" --max-concurrency "$CONC" \
    --kv-dtype int8 --prefill-chunk 2048 --pending-timeout-ms 600000 \
    --spec mtp --draft-tokens 3 --lm-head-draft --preserve-thinking --cors
for i in $(seq 1 40); do
  [ "$(curl -s -o /dev/null -w '%{http_code}' "http://127.0.0.1:${PORT}/health" || true)" = 200 ] \
    && { echo "就绪: http://127.0.0.1:${PORT}/v1  (model id: qwen3.8-27b)"; exit 0; }
  sleep 5
done
echo "未就绪，看日志: docker logs ninfer"; exit 1

开机自启：容器带 --restart unless-stopped 即可；功率墙用上面那个脚本挂一个 oneshot 单元：

# /etc/systemd/system/nvidia-powerlimit.service
[Unit]
Description=Lock V100 power limit
After=systemd-modules-load.service
Before=docker.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/nvidia-powerlimit.sh 200
[Install]
WantedBy=multi-user.target

davidwei0826

不涨钱，上哪弄钱给李飞飞的世界模型？

davidwei0826

@Prio 说:

版主您好，我现在单卡3090用的syv-ai/HyperQwen 的官方方案，这个方案长上下文的情况下decode输出特别慢，只有9-12token/s，想问下有什么好优化方案

多长的上下文？HyperQwen的在我这160k上下文就20tps的decode了，可以想象再长点，速度慢到12tps也正常。
如果场景是长上下文，还是考虑ninfer吧，它更稳。160k上下文时 41.1tps decode。缺点是起手比HyperQwen慢一倍，prefill长上下文更慢。
我是用短上下文的，非cache对话，所以HyperQwen更适合我的场景。

davidwei0826

按照小特说的，和 HyperQwen（同一张卡上的 vLLM 栈）比：pp / tg 分开看，出现 crossover。基本上单卡还是用HyperQwen的方案更好。

先说测量口径：

同一张卡（单 3090，24G），同一个功耗墙 300W（gpu-power-limit.service 把两张 3090 都锁 300W，卡默认/最大是 350W；
实测满载 avg 286-300W、峰值 SM 1,890-1,980 MHz，供核对）。
pp 与 tg 分开测：pp = prompt token / TTFT（流式取首 token 时间）；tg = 生成窗口内的 token/s。
prompt 冷缓存：每个长度用独立随机文本 + 唯一 nonce 开头，响应里 cached_tokens=0 可自证没吃前缀缓存
（我第一版没做这一步，16K/32K 的 pp 被前缀缓存虚高到 2,257/3,154，已作废重测）。
生成端固定 256 token、关闭思考；KV 精度两边都是"4bit 级"但方案不同：HyperQwen 是 KVarN k4v2，ninfer 是 rk8v4(K8/V4)。

HyperQwen 单流 pp / tg 曲线：

输入 token	TTFT	prefill	decode	功耗 avg/max
955	0.75 s	1,276	107.7	175/299 W
3,668	1.85 s	1,978	110.6	249/299 W
14,546	6.99 s	2,081	82.5	270/298 W
29,113	15.4 s	1,886	57.5	283/299 W
58,031	37.0 s	1,569	37.8	287/298 W
116,101	99.1 s	1,171	31.4	286/300 W
159,249	161 s	990	19.9	288/299 W

和 ninfer 并排（同卡同墙）：

输入	HyperQwen pp	ninfer pp	HyperQwen tg	ninfer tg
~1-4K	1,276-1,978	~920	107.7-110.6	~52
~29K	1,886	823	57.5	~47 †
~58K	1,569	736	37.8	~48-55 †
~116K	1,171	611	31.4	51.5
~159K	990	544	19.9	41.1

† 这两点是 C2 两路并发下的单路值，不是 C1。

pp 差一倍的根因是算力路径：27B dense 每 prefill 一个 token 约 54 GFLOP；3090 的 FP16 tensor 是 71 TFLOPS、INT8 是 142 TOPS。
HyperQwen 走 int8 激活（INT8_ACT=int8 + int8 QK 预填注意力），14.5K 时 2,081 tok/s ≈ 112 TFLOPS ≈ INT8 峰值的 79%；
ninfer 是"反量化 → FP16 MMA"，925 tok/s ≈ 50 TFLOPS ≈ FP16 峰值的 70% —— 两条路的物理上限本来就差约 2 倍，不是谁写得烂。
（ninfer 侧我把 --prefill-chunk 从 512 扫到 3584 毫无变化，也说明它没有可调余量。）

但 tg 的形状完全不同，而且出现 crossover：decode 从 110 掉到 19.9（5.5×），
而 ninfer 的长上下文 decode 反而更稳 —— ≤30K 时 HyperQwen 快约 2×，~60K 被追平，≥116K 时 ninfer 反超 1.6-2×。
方向上说得通：KVarN 4bit 的反量化开销随深度增长，DFlash2 草稿只看 2K 窗口，
长上下文下草稿命中率掉下来；而 ninfer 的 ReplaySSM/MTP 在深上下文里保住了接受率。
所以"4bit KV ⇒ decode 更快"这条对本文的 ninfer 不成立 —— 它的 decode 优势来自别处，长上下文反超也不是量化的功劳。

取舍：短提示响应、批量 API、要 prefill 吞吐 → HyperQwen 明显更强；
单卡要 180K 长上下文 + 长对话里的稳定 decode，ninfer 在深上下文反而更划算。

davidwei0826

结论一句话，prefill和decode都不如 syv-ai/HyperQwen 。 3090单卡还是选这个方案吧

davidwei0826

3090 单卡跑 Qwen3.8-27B：NInfer 上机实测（180K 上下文 / C2 并发 / 4bit KV）

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


显卡	单张 RTX 3090 24G（SM86），功耗墙 300W（这卡默认 350W，影响见测评）
驱动	595.71.05
引擎	NInfer-3090 v0.6.1（官方 Linux x64 预编译包）
权重	`neroued/Qwen3.8-27B-NInfer` @ revision `18dfc887`（container v2，18.2 GB）
部署	Docker（CUDA 12.8 runtime 底座 + 官方预编译二进制）

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

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

参数	为什么必须这么写
`--kv-capacity 184320`（显式）	`auto` 在 C2 + MTP3 下直接拒绝启动：引擎最小运行时 6.68 GiB + 1 GiB 自动余量 > 权重加载后剩下的 6.63 GiB
`--pending-timeout-ms 900000`	默认超时下，C2 的第二个长上下文请求会在排队时 `error inference request expired while waiting for admission`
`--kv-dtype rk8v4`	int8 的 KV 在 C2 下最多只能开到 160K；rk8v4（K8/V4）能到 180K，实测两者速度没有差别
不加 `--vision`	开视觉要多占约 2.1 GiB，C2 下上下文从 180K 掉到 136K（余量只剩 48 MiB）

显存账（这张 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）。满载实测：

	功耗	SM 频率	温度
满载（util > 60%，n=43 采样）	avg 298 W / max 300 W（贴墙）	avg 1538 MHz（1395–1665）	74 °C

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

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

输入 token	并发	TTFT	prefill	decode/路	decode 合计	MTP 接受率	功耗 avg/max
8,359	2	9.2s / 19.0s	903 tok/s	35.7 / 38.2 tok/s	74 tok/s	48.2%	292 / 300 W
32,305	2	39.1s / 80.1s	823 tok/s	43.3 / 46.6 tok/s	90 tok/s	58.3%	294 / 300 W
64,233	2	87.2s / 177.5s	736 tok/s	55.3 / 47.7 tok/s	103 tok/s	54.1%	297 / 300 W
128,089	1	209.8s	611 tok/s	51.5 tok/s	52 tok/s	66.7%	295 / 300 W
173,832	1	319.6s	544 tok/s	41.1 tok/s	41 tok/s	52.2%	296 / 300 W

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

输入 token	并发	TTFT	prefill	decode/路	decode 合计	MTP 接受率	功耗 avg/max
8,533	2	9.6s / 19.8s	884 tok/s	66.8 / 67.6 tok/s	134 tok/s	98.2%	290 / 300 W
33,057	2	40.5s / 82.0s	815 tok/s	79.5 / 77.9 tok/s	157 tok/s	98.2%	296 / 300 W
65,829	2	90.1s / 181.2s	730 tok/s	74.8 / 73.6 tok/s	148 tok/s	98.2%	296 / 300 W
131,419	1	217.5s	605 tok/s	63.2 tok/s	63 tok/s	96.3%	296 / 300 W
178,335	1	331.6s	538 tok/s	58.9 tok/s	59 tok/s	96.3%	296 / 300 W

四个观察

prefill 是串行的，C2 的两个请求不是同时开始吃 prompt：第二个的 TTFT ≈ 排队（第一个的 prefill 时间）+ 自己的 prefill。
32K 输入时 39s / 80s，64K 时 87s / 177s，都是这个规律。所以 C2 的并发收益主要体现在 decode 阶段，不是 TTFT。
prefill 速度本身随输入变长而下降：8K 时 ~900 tok/s，64K 时 ~735，178K 时只有 ~545 tok/s。
长上下文真正的代价是 TTFT（178K 输入要等 5.5 分钟），不是 decode。
decode 几乎不随上下文衰减：coding 场景 36～55 tok/s、agent 场景 59～80 tok/s，178K 输入下反而还有 41～59。
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 开箱），本机实测：

输入长度	1K	4K	16K	64K	100K+
vLLM（INT8 激活路径）	2,056	2,170	1,965	1,412	1,161@100K、934@178K
ninfer（这篇）	~920	~920	892@20K	736	611@128K、544@178K

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

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

	用的单元	3090 上的算力	理论上限	实测达到
ninfer	反量化 → FP16 tensor core	71 TFLOPS	~1,315 tok/s	925（70%）
vLLM	INT8 tensor core（激活也量化）	142 TOPS	~2,630 tok/s	2,170（82%）

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 根本跑不起来。

davidwei0826

@kos-or 不会，看这个帖子里的对比： https://lcz.me/topic/1659
decode 短上下文差不多，prefill慢很多，越长越慢。
halogen是闭源专门优化的模型，等他出针对27B模型的版本把，或许会好一点。不过稠密模型全参数活跃，感觉也不会好到哪里去。

davidwei0826

听说 halogen 不错，手里正好有之前视作鸡肋的 MS-S1，这回支棱起来了。

halogen 是什么、官方怎么装、性能对比，论坛里几位老哥写得很细，不重复：

Flash-Next 完整实测 https://lcz.me/topic/1659 ｜ 27B 版实测 https://lcz.me/topic/1623
项目 https://github.com/peonist-ai/halogen-flash-server ｜权重 https://huggingface.co/peonist-ai/halogen-qwen3.8-flash-next

这篇只写我这台机器跑出来的数字和能落地的配置。

一、成绩


机器	MS-S1（Ryzen AI MAX+ 395 / Radeon 8060S / gfx1151），128G，BIOS carve 最小
系统	Ubuntu 24.04.3，内核 6.18.6
引擎	halogen-flash-server 0.8.0
权重	118 GiB
指标	官方	我这台
---	---	---
prefill @8K	~1,246 tok/s（TTFT 6.6s）	1,309 tok/s（TTFT 6.6s）
prefill @32K	~1,424 tok/s（TTFT 23.0s）	1,524 tok/s（TTFT 21.6s）
decode @32K	~41.7 tok/s	39.1 tok/s（draft 命中 97/149）
冷启动	—	48 秒（其中 pin 权重 42 秒）
热启动	—	6 秒

官方数字是真的，照配就能到。中间踩了三个坑，都记在下面。

二、能跑起来的最终配置

内核 cmdline：

quiet splash iommu=pt amdgpu.gttsize=126976 ttm.pages_limit=32505856

启动：

sudo podman run --rm --name halogen-flash \
  --device /dev/kfd --device /dev/dri --group-add keep-groups \
  --ipc=host --ulimit memlock=-1:-1 \
  -p 8731:8731 \
  -e HALOGEN_VISION_TOWER=/models/qwen38-flash-next-vision.hgn \
  -e HALOGEN_REASONING_EFFORT=medium \
  -e HALOGEN_MAX_TOKENS_DEFAULT=16384 \
  -e HALOGEN_CTX=184320 -e HALOGEN_KV_POOL_POSITIONS=184320 \
  -v /home/davidwei/models/halogen-models:/models:ro \
  ghcr.io/peonist-ai/halogen-flash-server:0.8.0

坑 1：内核里那两个祖传参数（最要命）

起服务加载到 preparing weights, layer 0 of 48 就崩，报 unspecified launch failure(719) at hipblaslt.cpp:187，dmesg 里是 amdgpu: ring sdma0 timeout + GPU reset + SW scheduler is used。

原因是我这台机器的 cmdline 里有早年加的这两个，官方配置里没有：

amdgpu.sched_policy=2      # 强制软件调度器
amdgpu.cwsr_enable=0       # 关掉 CWSR 抢占

去掉这两个，引擎 48 秒正常就绪。 对照数据：带这俩参数那次启动 GPU 挂死 4 次；去掉后 0 次。我在这上面耗的时间比下载 118 GiB 还多。

坑 2：官方文档说 6.18.6 内核不能用 —— 实测能用

README 要求内核 ≥7.0，说 6.18.6 上驱动会拒绝只读映射、pin 不了权重。我实测了它说的那个调用，是成功的：

hipHostRegister(只读文件映射, READONLY flag) -> hipSuccess | no error

引擎自己也打印了 checkpoint: pinned 65.60 GiB in 252 range(s) in 40.3 s (1.7 GB/s)。所以没必要升内核（我 apt 里 7.0.0 都备好了，白备）。

坑 3：官方建议的 `amd_iommu=off` 我这台吃不下

那一项官方说值 13–16% prefill，但我这台上开了就 sdma0 硬件超时（4 次挂死 vs 保持 iommu=pt 的 0 次）。不靠它官方数字一样达标，所以保持 iommu=pt。

另外 rootless podman 会直接挂住不动（ulimit -l 硬限制只有 15.6 GiB，而引擎要 pin 68 GiB），必须 rootful + --ulimit memlock=-1:-1。

三、权重下载：17 分钟

路线	速度
HuggingFace 走代理	7.5 MB/s（单连接），并发直接挂死 0
hf-mirror.com 直连 + aria2c 16 连接	122 MiB/s

118 GiB 十七分钟。两个坑：huggingface_hub 默认的 Xet 后端在代理下会静默卡死（不报错也不下载），要设 HF_HUB_DISABLE_XET=1；hf-mirror 会 302 到 Xet CDN，aria2 会按 blob 哈希命名文件，得显式 -o。

只下两个文件：qwen38-flash-next-w4b.hgn（115.55 GiB）+ qwen38-flash-next-w4b.overlay.hgn（2.40 GiB，质量 sidecar，引擎自动加载，必须留）。下完对 HF API 的 sha256 校验一下，我这边三个文件全 OK。

四、内存：别信 free

引擎启动会自己算账：

memory: 68.0 GiB weights locked + 5.1 GiB KV pool + 21.3 GiB working = 94.4 GiB in all
host memory left for everything else: 3414 contiguous 2 MiB blocks (13.3 GiB)
free(1) 会报成 79.8 GiB —— 内核把锁定的权重当成可回收缓存，实际不可回收

信引擎这行，别信 free。 我这台 free 报 79 GiB available，实际可用只有 13 GiB。

KV pool 一定要按需求降。 默认是 2×ctx，我一开始用默认，KV 吃了 11 GiB，宿主 free 掉到 1.2 GiB。注意 pool 不能小于 HALOGEN_CTX，只改 pool 会被引擎夹回原值，得两个一起降（就是上面配置里的 HALOGEN_CTX=184320 + HALOGEN_KV_POOL_POSITIONS=184320）。降完 KV 从 11 → 5.1 GiB，重启后宿主 free 回到 5.9 GiB。

顺手纠正一个流传的说法：HALOGEN_MAX_TOK 是单次 prefill 的分片大小（默认 32768，文档明确警告不要调），不是输出预算；输出预算是 HALOGEN_MAX_TOKENS_DEFAULT。另外 token 预算包含思考——预算用完不是截短回答，是 finish_reason: "length" + 空 content（思考在 reasoning_content 里，大部分客户端不显示）。先看 finish_reason 再骂模型。

vision 我开了也实测过（发一张纯色图问颜色，答「红色」）。reasoning_effort 我设 medium，默认的 xhigh 在 agent 长链任务上思考太久，体感拖沓。

五、剩下的空间正好搭个基座

94.4 GiB 常驻之后还剩十来 G，正好塞一个 embedding + 一个 whisper（Qwen3-Embedding-8B + large-v3-turbo，都跑在 GPU 上），知识库和语音识别就都有了。这样一台 MS-S1 就是个完整的个人 AI Agent 基座——Hermes 或者 DSH 直接连微信、QQ 之类，能当个人助理使了。

六、一句话总结

门槛不在装，在那几个参数。先把你 cmdline 里的祖传参数清干净，尤其 amdgpu.sched_policy=2 和 amdgpu.cwsr_enable=0。

感谢论坛几位老哥的实测帖，省了我大量试错。有同机型的兄弟要抄配置，cmdline 和容器参数照上面来就行。

davidwei0826

@Queen-Laura 如果是个人的卡，别太冲性能了，还是锁一下功率，虽然性能降一点，但是卡的温度明显降低，有助于延年益寿。天天听老特说3090矿卡容易坏，我这PDD买的，店铺链接都没了，心里着实不踏实。
我这里3090涡轮卡，没锁功率之前，350w满载，基本都是85度。锁了300w以后，基本都在76~78度。我看官方都是锁250w，我感觉损失太大了，得不偿失。

davidwei0826

两张nvlink我跑过，用的club-3090的vllm docker. 之前发过一片朋友圈如下：

双卡3090+nvlink，模型Qwen3.6-27B-autoround-int4。 kv cache fp8_e5m2, 上下文长度 262144 。采用 club-3090 的vllm运行参数和测试脚本 soak-test.sh， p50_decode_tps：61.34；p95_ttft_ms：4864 。

不过，最近用了 syv-ai/qwen38-27b-rtx3090 用一张3090也跑出了不错的速度（见我另一篇帖子。用的int4量化，上下文减到160k，不支持并发。不过一个人用的话够了）。

我觉得双卡3090跑qwen3.8-27b,最好的场景，应该是多人/Agent并发。用SGLang的redix tree缓存，加上双卡nvlink高带宽, 再配合HiCache应该有不错的效果。等我有时间和需求时搞一下。

davidwei0826

@Xiaote 说:

@huaye XU 你这个问题我在 TID:1308 那个帖答过一半，这里把另一半补上：

40t/s 对你的卡是正常的：5090 Laptop 是 256-bit GDDR7，实际带宽约 1TB/s，decode 35~45 t/s 就是这条带宽下的物理上限，不是配置问题。B 站那些 80t/s 是台式 5090 的 1.2TB/s+ 带宽，笔记本物理上做不到。

这个仓库的 dflash2 是 DeepSeek 系专用投机（DFLASH2 只对 DeepSeek 架构生效），qwen3.8 用不上，抄这个配置白抄；qwen 系要提速用 llama.cpp 的 MTP（投机解码 draft head），27B 上接受率约 40%，能提 30~50%。

vllm 单卡 24G 笔记本性价比低：vllm 的优势在多卡/高并发，单卡单人用 llama.cpp 更省事，而且你 96G 内存还能开 --cache-ram 兜底长上下文，vllm 那套在笔记本上反而是负担。

@huaye-xu
xiaote说的我持怀疑态度，你的显存带宽如果能达到1TB/s,应该比3090还快一点。算力你更是快一大截。你用NVFP4的模型，肯定效果会好很多。我觉得速度的话，MTP或者用DFLASH是关键。你这个速度更像纯模型速度。

如果你用DSH或者hermes的话，可以和我一样把合适的github仓库地址给他, 让他去给你配置。我就给他发了3090那个仓库的地址，说我需要用cuda0配置single profile,然后他就配好了，大概也就不到1小时。中间就让我提供了一次翻墙的代理。模型都是它自己下的。

Agent时代了，运维的逻辑变了。

davidwei0826

@terry 说:

@davidwei0826 DSH不错的话，Hermes和Codex测试了没？不过有一个Agent能用，就差不多了。

最近痴迷DSH,已经很久没有长时间使用Hermes和Pi等其他agent了，都是发些短任务。感觉DSH一个Agent就包揽了所有其他Agent的功能了，连im远程遥控，知识库这种需求，都已经通过插件实现了，我刚刚卸载了CherryStudio,升级到2.0以后太不稳定。 Opencode在开发完手里的项目以后，也不准备用了。全面转向DSH哈。

不过讲真，Hermes我感觉在我手里没有你说的那么好用，也可能是我给他一直配的是Minimax-M3模型，也不用他做开发吧。后面我再重新更新下Hermes,接ds4 flash试试。

davidwei0826

本来是双卡vllm的（用的club-3090的脚本），稳定运行，性能中规中矩。后来想要腾出一张显卡玩comfyui，所以想要一个靠谱的单卡方案。

club-3090里只有llama.cpp的单卡方案，prefill性能不行。于是用了 syv-ai/qwen38-27b-rtx3090 的vllm+dflash2 的方案。直接把github仓库地址丢给dsh远程配置的，起来以后效果不错，单人使用的话，打开

SPEC=dflash2
PREFIX_CACHE=1
CTX=huge
DFLASH_MAX_LEN=180000 #我最终用的是160k

实测性能如下， 128k上下文时，prefill ~800tps， decode 33~38tps ：
屏幕截图 2026-08-28 131305.png

屏幕截图 2026-08-28 105930.png
整体感觉和club-3090的双卡vllm的性能已经差不多了。接dsh跑了一下，整体感觉还行，TFTT第一次会比较长，后面因为PREFIX_CACHE就短下来了(当然也可能是tool calling的结果太短，没影响上下文)：

#DSH的第一个回答
Started 2026-08-28 14:39:15.324
Total duration 23.4 s
TTFT 20.8 s
Generation 2.60 s
Throughput 75.8 tok/s

#下一个回答
Started 2026-08-28 14:39:45.347
Total duration 2.18 s
TTFT 1.23 s
Generation 947 ms
Throughput 99.3 tok/s

#再下一个
Started 2026-08-28 14:39:49.862
Total duration 2.81 s
TTFT 779 ms
Generation 2.03 s
Throughput 92.1 tok/s

DSH里跑了4轮47步，最后一次的Throughput是49.1 tok/s，此时上下文 57.7k，基本和测试相符。
以后可以用gpu0配置gpu1上的comfyui了。

另外，有一个坑，就是开了单人的这些参数以后，不要多人或者多agent同时使用，争抢资源，缓存失效，两个速度都卡出翔。单个DSH的话，还是非常丝滑的。多人可以考虑官方的多人配置，损失decode速度，换多人可以同时使用。

davidwei0826

双卡3090 vLLM跑Qwen3.6-27B，强烈建议关注： https://github.com/noonghunna/club-3090 。
我自己的环境：双卡3090 nvlink，模型Qwen3.6-27B-autoround-int4。 kv cache fp8_e5m2量化, 上下文长度 262144 。采用 dual-mtp 的vllm运行参数和测试脚本(soak-test.sh)， p50_decode_tps：61.34；p95_ttft_ms：4864 。
官方给的测试，应该能到接近70tps，我的还有优化空间，但是能用了就没折腾，参考DUAL_CARD.md。
num_speculative_tokens我测了2,3,4,5。效果上3最好。

启动脚本：

root@NV-AI-3090Dual2:~# cat vllm.qwen3.6-27b.sh 
#!/bin/bash
source /root/.bashrc
source /root/venv/bin/activate
# vLLM 启动脚本 — Qwen3.6-27B-AutoRound-INT4
# 用法: bash start-vllm-qwen3.6.sh [TP] [PP]
#   TP: tensor-parallel size，默认 2
#   PP: pipeline-parallel size，默认 1

set -e

# ========== 参数 ==========
TP="${1:-${TP:-2}}"
PP="${2:-${PP:-1}}"
MODEL_PATH="/root/models/qwen3.6-27b-autoround-int4"
PORT="${PORT:-8000}"
HOST="${HOST:-0.0.0.0}"
MAX_MODEL_LEN="${MAX_MODEL_LEN:-262144}"
GPU_MEM_UTIL="${GPU_MEMORY_UTILIZATION:-0.92}"
KV_CACHE_DTYPE="${KV_CACHE_DTYPE:-fp8_e5m2}"
TEMP="${TEMP:-${TEMPERATURE:-0.6}}"
TOP_P="${TOP_P:-0.95}"
TOP_K="${TOP_K:-20}"
MIN_P="${MIN_P:-0.0}"
REPEAT_PENALTY="${REPEAT_PENALTY:-1.0}"

# speculative decoding
SPECULATIVE_CONFIG='{"method":"mtp","num_speculative_tokens":3}'

# 推理模板参数（关闭 thinking）
CHAT_TEMPLATE_KWARGS='{"enable_thinking": false}'

# ========== 环境变量 ==========
export NVIDIA_VISIBLE_DEVICES="${NVIDIA_VISIBLE_DEVICES:-all}"
export HUGGING_FACE_HUB_TOKEN="${HF_TOKEN:-}"
export VLLM_WORKER_MULTIPROC_METHOD=spawn
export NCCL_CUMEM_ENABLE=0
export NCCL_P2P_DISABLE=0
export VLLM_NO_USAGE_STATS=1
export VLLM_USE_FLASHINFER_SAMPLER=1
export OMP_NUM_THREADS=1
export PYTORCH_CUDA_ALLOC_CONF="expandable_segments:True,max_split_size_mb:512"

# NVLink 检测（自行补充 detect_nvlink.sh 逻辑，或删掉这两行）
# source /etc/club3090/detect_nvlink.sh
# _NVLINK_ENABLED=0  # 手动设置：0=无NVLink, 1=NvLink开启

# ========== 构建命令 ==========
ARGS=(
    --model "$MODEL_PATH"
    --served-model-name qwen3.6-27b-autoround
    --quantization auto_round
    --dtype float16
    --tensor-parallel-size "$TP"
    --pipeline-parallel-size "$PP"
    --max-model-len "$MAX_MODEL_LEN"
    --gpu-memory-utilization "$GPU_MEM_UTIL"
    --max-num-seqs 2
    --max-num-batched-tokens 8192
    --kv-cache-dtype "$KV_CACHE_DTYPE"
    --trust-remote-code
  #  --chat-template "${CHAT_TEMPLATE}"      # 没有自定义模板文件则删除此行
    --reasoning-parser qwen3
    --default-chat-template-kwargs "$CHAT_TEMPLATE_KWARGS"
    --enable-auto-tool-choice
    --tool-call-parser qwen3_coder
    --enable-prefix-caching
    --enable-chunked-prefill
    --disable-custom-all-reduce
    --speculative-config "$SPECULATIVE_CONFIG"
    --override-generation-config "{\"temperature\":${TEMP},\"top_p\":${TOP_P},\"top_k\":${TOP_K},\"min_p\":${MIN_P},\"repetition_penalty\":${REPEAT_PENALTY}}"
    --host "$HOST"
    --port "$PORT"
)

echo "=========================================="
echo "启动 vLLM | TP=$TP PP=$PP | $MODEL_PATH"
echo "=========================================="
echo "命令: vllm serve ${ARGS[*]}"
echo ""

exec vllm serve "${ARGS[@]}"
deactivate

davidwei0826

你是说prefill？ pp2048：452.44 ± 41.05 。 35B-A3B可以到977.46 ± 210.02

davidwei0826

前几天看到MTP的PR合并主线了，拉下来编译了一下，配合unsloth的带TPM的Q4量化模型，感觉这个显卡还可以再战。
Qwen3.6-35B-A3B Q4_K_M, 双卡， 101.89 TPS

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
qwen3.6-35B llama.cpp	pp2048	977.46 ± 210.02		2064.32 ± 518.14	2039.35 ± 518.14	2064.32 ± 518.14
qwen3.6-35B llama.cpp	tg32	101.89 ± 5.71	105.21 ± 5.85

Qwen3.6-27B Q4_K_M, 双卡， 36.4 TPS

model	test	t/s	peak t/s	ttfr (ms)	est_ppt (ms)	e2e_ttft (ms)
qwen3.6-27B llama.cpp	pp2048	452.44 ± 41.05		4259.39 ± 584.84	4239.24 ± 584.84	4259.39 ± 584.84
qwen3.6-27B llama.cpp	tg32	36.40 ± 1.42	37.56 ± 1.44

Qwen3.6-35B-A3B,有没有NVLink速度都差不多; Qwen3.6-27B,没有NVLINK的话， TPS稍微少一点，在30左右，不如单卡。
但是2080Ti 22G这个卡，单卡跑不了Qwen3.6-35B-A3B Q4_K_M, 我上面帖子那个跑27B模型的，也不是特别稳定，一周遇到两次OOM. 所以如果不是双卡，就不要挂mmproj了，很容易OOM.
还有，最近用Qwen3.6-35B-A3B 配合Hermes,感觉没有想象的那么拉。任务简单一点，基本都能做，结果也能接受。太复杂的任务，在另一个连着GLM-5.1或者MINIMAX2.7的Hermes上跑一下，然后复制过来就行了，私密场景的，也没有特别复杂的任务。配合100多TPS的速度，整体感觉很爽。

PS: 这两张卡是去年买了，总成本5k，现在我看4k就能拿下了，建议如果只跑Hermes,能接受Qwen3.6-35B-A3B 智商的，可以入，还能战。

抡锤者

davidwei0826

帖子