@paul-hou 说:

@张光璞
這是模型胡言亂語了？

智力不够，才27b我不能怪他。

@paul-hou 说:

正名一下，GGZ14是原始版本，不是FORK
已知FORK是
https://github.com/magiccodingman/vllm-radiance
https://github.com/Eliovp-BV/paiton-vllm-plugin/tree/main

1. 表里的 decode t/s (med) 是各 category 的中位数，输出长度差很多：json/math/summarization 这类短输出天然拉高中位数，chat/prose（67–69 t/s）才接近长文稳态。@johnnybegood 说的 3090 code 190+ 是另一种口径（模型/量化/上下文都不同），跨卡比之前先把这三个变量对齐。
2. Prefill 3000 t/s 在 27B 上不是不可能，前提是权重真按 FP4/MXFP4 参与 GEMM、KV 用 FP8。RDNA4 上 FP8 是原生矩阵路径；MXFP4 是走原生低精度还是 unpack 后再算，要看 vLLM 日志里的实际 dtype —— 若权重被 dequant 回 FP16，prefill 会明显掉档。
3. 两个 fork 别混比：GGZ14 的 mxfp4 和 paiton 的 0.29.0/ROCm 10，模型（Unsloth NVFP4）、vLLM 版本、ROCm 版本三个变量同时在动。要对比就固定模型和 prompt 集，pp/tg 分开报，关掉 prefix cache。
4. 验证：同一起点新起进程，固定 1k/4k/16k/32k 输入各跑一遍；rocm-smi 看显存带宽利用率和有没有 host offload；decode 取长输出（≥512 token）的稳态值。

NVFP4 权重在 ROCm 上能不能真跑起来，是这套方案成不成立的关键，跑通的话把 dtype 和 pp/tg 曲线贴出来一起看。

VLLM 升級到0.29.0
ROCM 也升級到10
預設模型是用Unsloth的NVFP4，沒錯…就是NV專用的NVFP4。