一、先交代硬件：一台”不友好”的机器#

测试环境没有什么可炫耀的，恰恰是它的”不友好”让所有结论都有参考价值：

两个先天限制，直接决定了后面所有的性能形态：

1. 没有 NVLink。多卡并行的 allreduce 只能走 PCIe，带宽差一个数量级；
2. KVM 虚拟化。GPU 直通（passthrough）在虚拟机里经常降级，P2P 访问可能被虚拟化层屏蔽。

记住这两点，后面看到”单卡 47 tok/s 就是天花板”时会觉得合理。

二、惨案现场：48GB 双卡，30 tok/s#

最初的部署是最”标准”的：sglang + 双卡张量并行（TP=2）+ FP8 KV cache + 262K 上下文。配置无懈可击，速度一言难尽：单请求 decode 30 tok/s。

一台双 4090 的机器，跑 27B 模型只有 30 tok/s？查日志，三条信息把真相钉死了：

1
CustomAllReduceV2 is disabled because your platform lacks GPU P2P
2
capability or P2P test failed
3
CustomAllreduce is disabled ...
4
multimem all-gather disabled (CUDA driver error: invalid device ordinal)

组合起来就是：KVM 屏蔽了 P2P → 双卡之间无法直接通信 → 框架 fallback 到用 CPU 内存做中转 → 每次 allreduce 都要把激活值从 GPU 拷到 CPU 再拷回来。48GB 的卡，算力闲置，全在等内存总线。

修复方案是把 NCCL_P2P_DISABLE=1 之类的变量清掉、让驱动重新探测。但说实话，在 KVM 里 P2P 能恢复到什么程度全看虚拟化层脸色，真正干净解法是单卡。

三、单卡 + AWQ：48GB 装下 262K 上下文的算术题#

单卡路线的关键问题是：48GB 显存，27B 模型 + 262K 上下文，什么量化能装下？

这里要先认识 Qwen3.8 的一个特殊架构：它是 hybrid 架构——64 层里只有 16 层是标准 full attention（要存 KV cache），另外 48 层是线性注意力（GDN/Mamba 类），状态是定长的，不随上下文长度增长。这笔账和普通 Transformer 完全不一样：

逐项对比候选量化：

选 AWQ。最终生效的配置：

1
# 核心参数
2
--model-path Ar4ikov/Qwen3.8-27B-AWQ-W4A16-ASYM
3
--quantization awq
4
--context-length 262144
5
--max-total-tokens 262144
6
--kv-cache-dtype fp8_e5m2
7
--mem-fraction-static 0.9
8
# 单卡：没有 --tp，没有任何 NCCL 变量

实测结果：单请求 decode 从 30 → 47.6 tok/s（+59%），262K 上下文完整可用，显存占用 42.5/48GB。

顺便测了 GPU 功耗上限：空载打满 16K FP16 矩阵乘，GPU 能稳定拉到 449W / P0。而 sglang 服务时只有 134W——说明 decode 根本不是被功耗墙卡住的，是显存带宽的天花板，加多少电都没用。这是 4090 跑 LLM 的宿命：decode 阶段每生成一个 token 要把全部权重从显存搬一遍，27B 的 19.5GB 权重在 1TB/s 带宽面前，理论上限就在 50 tok/s 附近。

四、MTP：一条被数据证伪的优化#

Qwen3.8 自带 MTP（Multi-Token Prediction）头，AWQ 仓库里也附了量化的 model-mtp.safetensors。投机解码对 Qwen 系列理论上能加速 1.3~1.8 倍，看起来是白捡的优化。上线：

1
--speculative-algorithm EAGLE
2
--speculative-draft-model-path Ar4ikov/Qwen3.8-27B-AWQ-W4A16-ASYM
3
--speculative-num-steps 3
4
--speculative-eagle-topk 1
5
--speculative-num-draft-tokens 4

服务正常起来了，显存也够。然后看日志：

1
accept len: 1.02 ~ 1.23, accept rate: 0.01 ~ 0.07
2
gen throughput: 27 ~ 35 tok/s

接受率 2%。 意思是每猜 3 个草稿 token，主模型平均只认 0.06 个。每次验证都是白干，还倒贴 3 步草稿的开销。结果：

回滚。

为什么？MTP 草稿头和主模型都是 AWQ W4A16 量化的。投机解码的验证靠对比草稿分布和主模型分布，4-bit 量化引入的 logit 漂移让两个”同一个模型”的打分系统性对不齐——草稿头在量化噪声里自嗨，主模型一票否决。量化模型上叠投机解码，精度损失是复利的。

但这个故事没有结束，因为第七节会看到：换一个引擎、换一种 MTP 实现，同样的模型 MTP 接受率到了 46%。问题不在 MTP 本身，在对齐方式。

五、同台竞技：NInfer、sglang、llama.cpp#

为了找”到底谁快”，我在两台卡上同时跑了三套引擎，同一模型（Qwen3.8-27B 系），同一批 prompt，跑了一场完整的并发阶梯压测（1/2/4/8/16 并发 × 短/长上下文）。先报结果：

六、 Ternary-Bonsai-2-27B-PTQ1_0：1.75-bit 三元量化完整方案#

最后一个实验是最反直觉的。PrismML 出了一套 PTQ 三值化方案（Ternary-Bonsai-2-27B）：权重只取 {-1, 0, +1} 三档，1.75 bit/参数，整个 27B 模型（26.9B 参数）压到 5.6GB——比 AWQ 4-bit 还小 3 倍。

1.75 bit 是什么概念？FP16 是 16 bit，INT8 是 8 bit，AWQ 是 4 bit，它直接干到不到 2 bit。理论上这已经是”还能不能算模型”的极限附近。

实测（llama.cpp，单卡 48GB，总显存占用仅 23GB）：

两个结论有点拧巴：

短上下文，它比 4-bit 还慢。 27~35 t/s，连 sglang 的 AWQ（53 t/s）都不如。原因在带宽路径：三值权重要么走专门的 ternary kernel，要么先解包成常规格式再算，反量化/重打包的开销在小 batch 下摊不薄。4-bit 至少还有成熟的 awq_marlin 这类融合 kernel。

长上下文，它追上来了。 上下文越长，decode 的耗时从”读权重”转向”读 KV”，量化格式的影响被稀释，75 t/s @32K 和 NInfer 的 86 t/s 差距收敛到 15%。而 prefill 是它的舒适区——1,500+ t/s 的 prompt 处理，40K 上下文 TTFT 最低 6 秒（KV 命中时）。

还发现一个部署层面的坑：compose 里写了 -c 262144 想要 262K 上下文，llama.cpp 默默降到了 64K（n_ctx_slot = 65536）——4 个并发 slot × 64K 的 KV 预算在 48GB 里刚好到顶。不报错、不警告，/props 里看着才发现问题。“你要的”和”你得到的”之间，永远要自己核对一次。

另外 llama.cpp 的”并发”值得单独说：--parallel 4 是 4 个独立 slot，每个独占 64K KV，新请求来了按 LRU 抢占最老的 slot，被抢的请求从头重算。压测里一路 5.7K 的请求被后来的 32K 请求踢掉，decode 从 88 t/s 掉到 8 t/s。这和 sglang 的连续批处理是两种哲学：前者是”公平排队”，后者是”拼车顺风车”，混规模负载下尾延迟差一个数量级。

1
FROM nvidia/cuda:12.8.1-devel-ubuntu22.04
2

3
RUN apt-get update && apt-get install -y git cmake build-essential \
4
    libcurl4-openssl-dev pkg-config ca-certificates \
5
    && rm -rf /var/lib/apt/lists/*
6

7
WORKDIR /opt
8
RUN git clone --depth 1 https://github.com/PrismML-Eng/llama.cpp.git
9

10
WORKDIR /opt/llama.cpp
11
RUN cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89 \
12
        -DCMAKE_BUILD_TYPE=Release \
13
    && cmake --build build -j$(nproc) --target llama-server llama-cli
14

15
EXPOSE 30000
16
ENTRYPOINT ["/opt/llama.cpp/build/bin/llama-server"]

1
services:
2
  bonsai:
3
    image: bonsai-2-27b:prismml
4
    restart: always
5
    ports:
6
      - "8188:30000"
7
    volumes:
8
      - /path/to/Ternary-Bonsai-2-27B:/models:ro # 5.6GB 的 .gguf
9
    deploy:
10
      resources:
11
        reservations:
12
          devices:
13
            - driver: nvidia
14
              device_ids: ["1"] # 挑一张卡
15
              capabilities: [gpu]
16
    command:
17
      - -m
18
      - /models/Ternary-Bonsai-2-27B-PTQ1_0.gguf
19
      - --host
20
      - 0.0.0.0
21
      - --port
22
      - "30000"
23
      - -ngl
24
      - "99" # 全量上 GPU
25
      - -c
26
      - "262144" # 目标 262K（实际生效值看下文"64K 的坑"）
27
      - -fa
28
      - "on" # Flash Attention
29
      - -np
30
      - "4" # 4 个并发 slot
31
      - --temp
32
      - "0.7"
33
      - --top-p
34
      - "0.95"
35
      - --top-k
36
      - "20"
37
      - --alias
38
      - Ternary-Bonsai-2-27B-PTQ1_0
39
    ulimits:
40
      memlock: -1
41
      stack: 67108864
42
    ipc: host
43
    healthcheck:
44
      test: ["CMD-SHELL", "curl -f http://localhost:30000/health || exit 1"]

七、一张 48GB 的账单#

把所有数字摆在一起：

回到最初的问题：这台机器到底能跑多快？单用户 47~100 tok/s，多用户聚合 340 tok/s，262K 上下文可用。 对一台 PCIe 互联的 KVM 虚拟机来说，这就是物理天花板了——再往上只有两条路：换有 NVLink 的卡，或者接受更狠的量化。

八、如果重来，我会这么做#

1. KVM + 多卡，默认怀疑 P2P。先看日志里 allreduce 走了哪条路，再谈优化。一条 NCCL_P2P_DISABLE 能偷走你 50% 的速度；
2. 单卡 + 4-bit AWQ 是 48GB 卡跑 27B 的甜点：262K 上下文、47 t/s、42GB 占用，质量损失可忽略；
3. 量化模型上慎开 MTP。2% 的接受率不是调参问题，是量化噪声问题。除非引擎用 LM head 同源打分（如 NInfer 的 --lm-head-draft）；
4. 按场景选引擎，而不是选”最快的”：个人用选 NInfer 这类高单流引擎，服务化选 sglang 这类连续批处理引擎，极端省显存（同卡还要跑绘图/embedding）选 Ternary-Bonsai 这类 1.75-bit 三元方案；
5. 配置要核对实际生效值。-c 262144 变成 64K 这种事，不会有任何人通知你。

所有数据来自 2026 年 9 月的实测，测试脚本和完整日志留档。模型：Qwen3.8-27B（hybrid 架构，16 层 full-attn + 48 层线性注意力 + MTP 头）。