可行性 — 過了
pp2×tp2 在 Qwen3.8-27B 混合架構(GDN mamba+MTP)上能穩定起、能推理。最大的未知雷——mamba 層跨 pp 段——沒炸:每 rank Mamba Cache 正常分配、TritonGDNKernel 正常 dispatch、四 rank(PP0/PP1×TP0/TP1)排布正確。這是 POC 要驗的核心,達成。

速度 — 27B 上全面輸現役(如預期)

主因兩層:

1. 丟了 DFLASH spec(pp≠1 硬互斥)——tok/chunk 從 ~6 掉到 1.00,單路少吐一堆 token,這是大頭。
2. pp bubble + 每層仍走 PCIe。

我想玩很久了 所以之前问ai 问了很多
据ai 单发 可能比较慢
但是多发就快了
而且有96gb vram

开个4卡3090帖子吧
分享下硬件 psu 之类的
我想了解多点

问过ai 的确decode可能变慢 但是prefill 应该好点
跟两张nvlink 一样

3090(無 NVLink,全程 PCIe)並行配置比較表
數字全取自 skill 已固化實測(2026-09-15,社群 uni_bench 口徑,代碼場景)

口徑警告(避免誤讀)

• 709.8 是兩實例併發吞吐「相加」的系統總產能,不是單一請求變快。談速度看單路那列。
• 單路對照(公平比速度):tp=4 227.9 比 tp=2 249.7 還慢 9% —— tp=4 純速度單路、併發兩頭都輸。
• tp=2×2 贏在系統產能(多開一實例吃第二組卡),非單路更快;單路它 ~265,與 tp=2 同級(略高,因兩實例各獨佔一組 PHB 無干擾)。

一句話結論

• 現役 27B(~19GB,48GB 綽綽有餘):tp=2×2 系統產能最高(709),定案最優。
• tp=4 唯一價值 = 96GB 單一顯存池,只有在「模型/context 塞不進 48GB」時才選,代價是單路 -9%、併發 -37%。速度維度全輸。

架構：tp=2×2 雙實例 + sglang-router

對外入口 sglang-router → :8000 → round_robin 分流到 8001/8002
實例 A sglang-a → :8001 (GPU0/1, tp=2) healthy
實例 B sglang-b → :8002 (GPU2/3, tp=2) healthy

模型
target: /models/Qwen3.8-27B-AWQ-MTP (twolven abliterated)
draft: /models/Qwen3.8-27B-DFlash2
served-name: qwen3.8-27b，架構 Qwen3_5ForConditionalGeneration

兩實例共用啟動配方（一模一樣）
--tp-size 2 --context-length 262144
--mem-fraction-static 0.86
--kv-cache-dtype fp8_e5m2
--speculative-algorithm DFLASH --speculative-num-draft-tokens 8 (draft=DFlash2)
--mamba-ssm-dtype bfloat16 --max-mamba-cache-size 37 ← P3 修的 mamba cap
--max-running-requests 4
--chunked-prefill-size 2048 --max-prefill-tokens 8192
--enable-hierarchical-cache --hicache-ratio 6.0 --hicache-write-policy write_back ← 真復用
enable_thinking=false（全域關 think）
reasoning-parser qwen3 / tool-call-parser qwen3_coder

硬體 / 系統
4× RTX 3090，全卡 260W + persistence=Enabled，目前 idle（util 0%，溫 29-56°C）
顯存：四卡各佔滿 ~23GB/24GB（模型常駐）
RAM：247G，用 190G / 剩 56G（雙實例 hicache 各 ~43G）

DFLASH2 壓測 — 對齊 lcz.me/topic/1502 uni_bench 口徑

測試規格（帖子統一口徑，強度加倍版）
temp=0, streaming+include_usage, enable_thinking=false
rounds=6（帖子3）, max_tokens=1024（帖子512）, 並發4路（帖子2）
decode=(comp-1)/(total-ttft)，只信 usage.completion_tokens

A. 單實例 :8001 (tp=2, GPU0/1) — 與帖子同構（2×3090 tp=2 單實例）

單路 decode
代碼生成 269.5 t/s (tok/chunk 6.01, TTFT 0.075s)
英文技術論述 169.8 t/s (3.81)
中文常規對話 119.4 t/s (2.68)
中文散文 70.0 t/s (1.57)

並發4路 aggregate
同 prompt (radix 命中) 714.0 t/s
不同 prompt 388.0 t/s

A.對照帖子（NVLink 王者版 / 無NVLink applejuice，都 rounds=3 max512 並發2）

場景 ws-ai(我) 樓主NVLink applejuice無NVLink
代碼單路 269.5 237/246.7 141/235.9
英文技術 169.8 166 140.8
中文對話 119.4 123 99.0
中文散文 70.0 92 61.4
並發同prompt 434.6(2路) 440 429.7
並發4路同 714.0 — —

判讀

• 單路全項贏或持平 applejuice（同為無 NVLink 同硬體），且贏樓主 NVLink 版的代碼/英文——無 NVLink 非瓶頸再次坐實。中文散文 70 稍低於樓主 92，是 accept len 低場景（tok/chunk 1.57），draft 命中差異，非環境問題。
• 並發同 prompt：2路434.6 對齊帖子 430/440；4路衝到 714，radix 命中下近線性放大（mrr=4 吃滿）。

B. 全系統 router :8000（雙實例 tp=2×2, 四卡全用）

單路 decode（經 router 分流，與單實例幾乎一致）
代碼生成 265.1 t/s
英文技術論述 172.2 t/s
中文常規對話 123.1 t/s
中文散文 71.6 t/s

並發8路 aggregate（雙實例 mrr=8 全壓）
同 prompt (radix 命中) 1387.1 t/s
不同 prompt 663.9 t/s

系統總產能全景（同代碼場景，同口徑）

配置 同prompt理想上界 不同prompt實戰
單實例 tp=2 2路 434.6 433.0
單實例 tp=2 4路 714.0 388.0
雙實例 8路（全系統） 1387.1 663.9

判讀

• 系統峰值 1387 t/s（8路同prompt），對比單實例4路714，雙實例近乎線性翻倍（1.94×）——四卡 tp=2×2 佈局的產能翻倍在系統級 uni_bench 口徑下坐實，跟 skill 記的 709 t/s（舊 rounds3/max512 版）同型放大。
• 不同 prompt 8路 663.9：這是最貼近來福真實負載的數字——8 張不同 issue 並發，無共享 radix，overlap 打折後系統仍能吐 664 t/s。對比單實例4路不同prompt 388，雙實例約1.71×。
• 單路 decode 經 router（265/172/123/72）vs 直打單實例（270/170/119/70）幾乎無損，round_robin 分流沒吃掉單路速度。

@starryskyknight 你之前那个贴 的成绩也是用375w 跑出来的？

1）单请求 138.8 t/s 基本就是这套配置的带宽天花板。AWQ-4bit 27B 权重约 14–15GB，TP=2 每卡读一半，按 3090 936 GB/s 折算理论 decode 约 125–135 t/s；跑到 138.8 说明权重读取已经贴住利用率上限，调度没拖后腿，再往上只能靠并发把 kernel 缝隙填满。

2）2 并发 260.9（1.88×）正常；但 4 并发合计反而掉到 243.4，比 2 并发低，这点值得查。262K ctx + fp8 KV 在 24G×2 上余量很薄，怀疑是 KV 装不下触发了 preempt/retract，或 chunked prefill 抢了 decode 的算力。建议看 SGLang 日志里 #retract/#preempt 计数和 mem_fraction_static，把 ctx 收到实际用量再复测，4 并发应能回到接近 2 并发的 1.8–1.9× 线性区。

3）NVLink「400 字回答搬 10.1GB」我持保留。TP=2 每 token 每层 all-reduce 约 2×hidden×2B≈20KB，60+ 层就是每 token 约 1.2–1.5MB，400 token 大致 0.5GB 量级。10.1GB 高了近 20×，更像把同一进程之前的 prefill 和 MTP 多步 draft forward 一起算进去了。建议清空计数后跑固定 prompt，测「增量字节 / 生成 token」，prefill 与 decode 分开报。

4）「平均利用率 0.06% 所以 NVLink 不是瓶颈」方向对，但推理要小心：TP 的 all-reduce 是短促突发、延迟敏感的，用占峰值百分比衡量必然很低，低利用率不等于没用。该看每层 all-reduce 延迟，以及 nvidia-smi topo -m 是否真出 NV4、NCCL 是否走 P2P（Z890 上这步常被 ACS/驱动吃掉）。这两样贴出来对双卡党最有价值。

投票 zx-bench 没问题，请按你说的两层交：zx-bench 长协议打底 + 一组固定 p/n、pp/tg 分开的短协议，长短都交，跨卡才真能对照。

【投票：zx-bench】双 3090 + NVLink 配置卡，附一组实测数据

投票选 zx-bench。理由：仓库开放、题目可哈希复核、维度覆盖比较全。也赞成上面 @Xiaote 的意见——建议在长协议之外附加一组短协议数据（固定输入/输出长度、pp 与 tg 分开报），两种都交，方便跨卡对照。双 3090 按规则计 2 票。

既然是晒配置，先把我的双 3090 机器交出来，欢迎拍砖：

硬件

• 2 × RTX 3090 24G（功耗墙 375W × 2），NVLink 桥接（NV4 链路）
• CPU：Ultra 9 285K；内存 60G；主板 Z890
• 系统：Ubuntu，驱动 610.x

软件栈

• 引擎：SGLang（main 分支），TP=2
• 模型：Qwen3.8-27B（AWQ 4bit）+ 多步 MTP / DFlash2 投机解码
• KV cache：fp8_e4m3；上下文窗口 262,144 全开
• 其他：HiCache（write_back）、chunked prefill、投机块 8/8

实测（自测口径，输出固定 1024 tokens）

• 单请求：138.8 tok/s
• 2 并发合计：260.9 tok/s；4 并发合计：243.4 tok/s
• 长提示（约 5.8K 输入）热缓存后 TTFT 约 70ms

NVLink 观测（双卡党稀缺数据）

• 一次约 400 字回答，NVLink 实际搬运约 10.1 GB；空闲时为 0
• 开机 3 天累计约 9.15 TB；平均利用率约为峰值的 0.06%
• 结论：对这套配置 NVLink 不是瓶颈；TP2 的收益是把集合通信从 PCIe 挪开，而不是带宽不够用

同一对卡跑别的任务（供对照）

• 图像批处理：每卡一个实例并行，4 张去背级任务 14.7s（约 1.6–2×）
• 生成类：ComfyUI 官方 MultiGPU CFG Split（cfg>1 工作流）实测 1.71×（24s → 14s）
• 换用途开销：LLM 服务 ⇄ 媒体任务，去程约 24s、回程约 44s

硬件实拍：机器不在手边，先附系统实况截图（nvidia-smi + NVLink 拓扑，实机实跑）；实机照片回头补。数据为单机自测、自写脚本，欢迎按统一协议复测交流。

从已读取的 CBS 搜索结果和 refs 文件中，我已经掌握了足够的信息来回答这个问题。让我整理一下：

关键发现 1：syv-ai/qwen38-27b-rtx3090 项目（1.4k stars）

这个仓库专门针对单卡 RTX 3090 做了深度优化，使用了 INT8 激活量化 + FP8 KV cache 的组合：

• 基准测试：vLLM 0.27.1，单卡 3090 @ 250W
• 并发 64 请求时达到 ~1,094 tok/s（e2e）
• 使用 int8 activations on the MLP GEMMs（不是全 INT8 KV，而是 MLP 层的 INT8 激活）
• 上下文容量通过 INT8 缓存翻倍

关键发现 2：Reddit 用户 iamMess 的 381 tps 记录

这个用户在 RTX 3090 上跑出了 381 tps 的单请求成绩：

• 使用 INT8 KV cache（从 69,758 tokens 翻倍到 138,696 tokens）
• 组合方案：fp8 KV + int8 lm_head/embed_tokens + fp16 recurrent state + int8 activations
• 需要打 patch 到 vLLM 才能使用 INT8 KV
• 结合 DFlash2 + lookup-augmented drafting 实现高吞吐

关键发现 3：yhavinga/vllm-gemma-int8-kv-rtx3090

这个 fork 实现了完整的 INT8 KV cache 支持：

• 支持 Gemma 2-27B 在 RTX 3090 上运行 128K 上下文
• +87% throughput on memory-bound workloads
• 使用 per-layer scales 进行 INT8 量化
• 是目前最完整的 INT8 KV 实现

关键发现 4：lued/Qwen3.8-27B-INT8-W8A16-MTP

HuggingFace 上的模型卡明确说明：

• 专为 Ampere 架构 GPU（RTX 3090）设计
• 使用 W8A16 量化 + INT8 KV cache
• 保留了 vision tower、thinking control 等特性
• 目标是在没有原生 FP8 tensor core 的硬件上获得最佳性能

结论：

1. INT8 KV cache 在 3090 上确实有实际用例，多个社区用户已经成功部署
2. 主要收益：内存节省约 2×（从 FP8 或 BF16 到 INT8），允许更长的上下文或更高的并发
3. 需要打 patch：上游 vLLM 对 INT8 KV 的支持还在开发中，需要使用 fork 或打 patch
4. 推荐方案：对于双 3090 TP=2 部署 Qwen3.8-27B，可以考虑 W8A8 权重 + INT8 KV cache 的组合

落地建议：

• 短期：关注 vLLM PR #40391 合入后可直接使用 --kv-cache-dtype int8
• 中期：使用 yhavinga 的 fork 测试 INT8 PTH
• 长期：等待上游正式支持后一键切换

[34m1512.21.100.458[0m [32mI [0mslot get_availabl: id 0 | task -1 | selected slot by LCP similarity, f_sim_best = 0.960 (> 0.100 thold), f_keep = 0.978
[34m1512.21.102.469[0m [32mI [0mslot launch_slot_: id 0 | task 179867 | processing task, is_child = 0
[34m1512.25.007.360[0m [32mI [0mslot print_timing: id 0 | task 179867 | prompt processing, n_tokens = 2772, progress = 0.99, t = 3.60 s / 769.60 tokens per second
[34m1512.25.854.391[0m [32mI [0mslot print_timing: id 0 | task 179867 | prompt processing, n_tokens = 3284, progress = 1.00, t = 4.13 s / 794.77 tokens per second
[34m1512.29.124.872[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 157, tg = 51.62 t/s, tg_3s = 51.94 t/s
[34m1512.32.140.736[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 337, tg = 55.65 t/s, tg_3s = 59.68 t/s
[34m1512.35.187.308[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 517, tg = 56.80 t/s, tg_3s = 59.08 t/s
[34m1512.38.195.238[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 697, tg = 57.56 t/s, tg_3s = 59.84 t/s
[34m1512.41.221.698[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 870, tg = 57.48 t/s, tg_3s = 57.16 t/s
[34m1512.44.257.726[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 1050, tg = 57.78 t/s, tg_3s = 59.29 t/s
[34m1512.47.291.415[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 1230, tg = 58.00 t/s, tg_3s = 59.33 t/s
[34m1512.50.327.965[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 1410, tg = 58.16 t/s, tg_3s = 59.28 t/s
[34m1512.53.372.754[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 1590, tg = 58.27 t/s, tg_3s = 59.12 t/s
[34m1512.56.385.800[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 1770, tg = 58.42 t/s, tg_3s = 59.74 t/s
[34m1512.59.434.598[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 1950, tg = 58.47 t/s, tg_3s = 59.04 t/s
[34m1513.02.481.957[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 2128, tg = 58.47 t/s, tg_3s = 58.41 t/s
[34m1513.05.513.377[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 2301, tg = 58.36 t/s, tg_3s = 57.07 t/s
[34m1513.08.523.772[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 2478, tg = 58.39 t/s, tg_3s = 58.80 t/s
[34m1513.11.541.732[0m [32mI [0mslot print_timing: id 0 | task 179867 | n_gen = 2655, tg = 58.41 t/s, tg_3s = 58.65 t/s
[34m1513.14.620.649[0m [32mI [0mslot print_timing: id 0 | task 179867 | prompt eval time = 4999.56 ms / 3288 tokens ( 1.52 ms per token, 657.66 tokens per second)
[34m1513.14.620.655[0m [32mI [0mslot print_timing: id 0 | task 179867 | eval time = 48518.05 ms / 2830 tokens ( 17.15 ms per token, 58.31 tokens per second)
[34m1513.14.620.656[0m [32mI [0mslot print_timing: id 0 | task 179867 | total time = 53517.61 ms / 6118 tokens
[34m1513.14.620.658[0m [32mI [0mslot print_timing: id 0 | task 179867 | graphs reused = 168461
[34m1513.14.620.678[0m [32mI [0mslot print_timing: id 0 | task 179867 | draft acceptance = 0.98375 ( 1877 accepted / 1908 generated), mean len = 2.97
[34m1513.14.625.043[0m [32mI [0mslot release: id 0 | task 179867 | stop processing: n_tokens = 82966, truncated = 0

楼主是计划用https://github.com/suncityldp/zx-bench跑分吗？
那基准模型准备用哪个？用llama.cpp？

【[34m1511.02.675.371[0m [32mI [0mslot get_availabl: id 0 | task -1 | selected slot by LCP similarity, f_sim_best = 0.609 (> 0.100 thold), f_keep = 1.000
[34m1511.02.677.275[0m [32mI [0mslot launch_slot_: id 0 | task 179136 | processing task, is_child = 0
[34m1511.07.156.058[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 4096, progress = 0.66, t = 3.87 s / 1058.37 tokens per second
[34m1511.09.350.049[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 6144, progress = 0.69, t = 6.06 s / 1014.27 tokens per second
[34m1511.11.576.393[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 8192, progress = 0.72, t = 8.27 s / 990.22 tokens per second
[34m1511.13.833.318[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 10240, progress = 0.75, t = 10.52 s / 973.22 tokens per second
[34m1511.16.124.567[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 12288, progress = 0.77, t = 12.80 s / 959.87 tokens per second
[34m1511.18.445.539[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 14336, progress = 0.80, t = 15.11 s / 948.52 tokens per second
[34m1511.20.803.575[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 16384, progress = 0.83, t = 17.46 s / 938.41 tokens per second
[34m1511.23.191.536[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 18432, progress = 0.85, t = 19.84 s / 929.01 tokens per second
[34m1511.25.611.080[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 20480, progress = 0.88, t = 22.25 s / 920.44 tokens per second
[34m1511.28.061.603[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 22528, progress = 0.91, t = 24.69 s / 912.36 tokens per second
[34m1511.30.544.094[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 24576, progress = 0.94, t = 27.17 s / 904.64 tokens per second
[34m1511.33.061.573[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 26624, progress = 0.96, t = 29.67 s / 897.37 tokens per second
[34m1511.35.609.548[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 28672, progress = 0.99, t = 32.21 s / 890.10 tokens per second
[34m1511.35.838.717[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 28839, progress = 0.99, t = 32.96 s / 874.96 tokens per second
[34m1511.36.659.693[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt processing, n_tokens = 29351, progress = 1.00, t = 33.38 s / 879.32 tokens per second
[34m1511.39.916.632[0m [32mI [0mslot print_timing: id 0 | task 179136 | n_gen = 162, tg = 53.38 t/s, tg_3s = 53.70 t/s
[34m1511.39.966.643[0m [32mI [0mslot print_timing: id 0 | task 179136 | prompt eval time = 34222.77 ms / 29355 tokens ( 1.17 ms per token, 857.76 tokens per second)
[34m1511.39.966.649[0m [32mI [0mslot print_timing: id 0 | task 179136 | eval time = 3066.01 ms / 164 tokens ( 18.81 ms per token, 53.16 tokens per second)
[34m1511.39.966.688[0m [32mI [0mslot print_timing: id 0 | task 179136 | total time = 37288.78 ms / 29519 tokens
[34m1511.39.966.691[0m [32mI [0mslot print_timing: id 0 | task 179136 | graphs reused = 166881
[34m1511.39.966.698[0m [32mI [0mslot print_timing: id 0 | task 179136 | draft acceptance = 0.80159 ( 101 accepted / 126 generated), mean len = 2.60
[34m1511.39.970.413[0m [32mI [0mslot release: id 0 | task 179136 | stop processing: n_tokens = 75261, truncated = 0
[34m1511.42.636.940[0m [32mI [0mslot get_availabl: id 0 | task -1 | selected slot by LCP similarity, f_sim_best = 0.979 (> 0.100 thold), f_keep = 0.999
[34m1511.42.638.860[0m [32mI [0mslot launch_slot_: id 0 | task 179217 | processing task, is_child = 0
[34m1511.48.703.820[0m [32mI [0mslot print_timing: id 0 | task 179217 | n_gen = 165, tg = 54.10 t/s, tg_3s = 54.42 t/s
[34m1511.51.747.295[0m [32mI [0mslot print_timing: id 0 | task 179217 | n_gen = 348, tg = 57.12 t/s, tg_3s = 60.13 t/s
[34m1511.54.754.268[0m [32mI [0mslot print_timing: id 0 | task 179217 | n_gen = 524, tg = 57.59 t/s, tg_3s = 58.53 t/s
[34m1511.57.797.304[0m [32mI [0mslot print_timing: id 0 | task 179217 | n_gen = 704, tg = 57.98 t/s, tg_3s = 59.15 t/s
[34m1512.00.816.266[0m [32mI [0mslot print_timing: id 0 | task 179217 | n_gen = 855, tg = 56.39 t/s, tg_3s = 50.02 t/s
[34m1512.03.855.881[0m [32mI [0mslot print_timing: id 0 | task 179217 | n_gen = 1033, tg = 56.75 t/s, tg_3s = 58.56 t/s
[34m1512.06.878.310[0m [32mI [0mslot print_timing: id 0 | task 179217 | n_gen = 1195, tg = 56.30 t/s, tg_3s = 53.60 t/s
[34m1512.09.892.918[0m [32mI [0mslot print_timing: id 0 | task 179217 | n_gen = 1356, tg = 55.94 t/s, tg_3s = 53.41 t/s】这个数据你觉得有用吗？即时在跑的日志。

llama-server的参数：
【
--chat-template-file "%CHAT_TEMPLATE_FILE%" ^
--host 0.0.0.0 ^
--port 3527 ^
--reasoning off ^
--n-gpu-layers -1 ^
--ctx-size 196608 ^
--flash-attn on ^
--cache-type-k q4_0 ^
--cache-type-v q4_0 ^
--spec-type draft-mtp ^
--spec-draft-n-max 2 ^
--spec-draft-n-min 1 ^
--temp 0.7 ^
--parallel 1 ^
--kv-unified ^
--jinja
】

要让跨机跑分真的可比，建议先把变量表钉死再投票，否则投完套件还是抄不了作业：

• 套件 + 精确版本/commit（只写 zx-bench 不够，它换一版 prompt 集数字就变）；
• pp（prefill）和 tg（decode）分开报，标注 prompt 长度与生成长度，单流一个 t/s 没有信息量；
• 量化格式（Q4KM / AWQ / INT4）、KV cache dtype + 上下文长度、并发数、是否开投机解码（MTP/DFlash）；
• 硬件附 nvidia-smi topo -m、NVLink 有无及 topo -p2p r、驱动/CUDA、功耗墙；
• 3 小时/套太长，建议短协议打底（llama-bench 固定 -p/-n/-r）+ 一个真实 agent 任务，两者都交。

另一个方法学点：附则按「稠密 FP16 算力 ÷ 71」折算票数，对推理场景偏了——decode 是显存带宽瓶颈，不是 FP16 算力瓶颈。3090 是 936 GB/s、3080 20G 约 760 GB/s、7900XTX 960 GB/s、R9700 640 GB/s，按算力折票会把带宽强、算力弱的卡低估。建议权重表同时列带宽，或干脆一卡一票 + 按显存分档（24G / 32G / 48G+）。

我可以按这套模板交一份 3080 20G / 7900XTX 的对照数据进来。