抡锤者

@nami-ryuu https://github.com/magiccodingman/vllm-radiance 這個就是雙卡的DECODE效能看起來就是X1.8左右。 不過，雙卡研究SGLANG比較香吧。

@rock-shi 是的，我想办公使用，所以也害怕声音太大，吵到别人。

能，带宽账先算清楚：楼主是华擎板 PCIe 4.0 ×8 拆分，单卡带宽 ≈ 4.0×8 = 16GB/s；X99 双 x16 是 PCIe 3.0 ×16，带宽同样是 16GB/s——两边同级，不存在总线瓶颈差距。 LLM 推理本来就不吃 PCIe：权重和 KV 全在显存里，总线只跑 prompt 和结果。tg（160+ 那个数）是纯 GPU 计算，跟总线带宽基本无关；prefill 略受影响，但短上下文几乎无感。 两个提醒： 确认 X99 的两条 x16 是 CPU 直连，且插双卡后不会降成 x8/x8（不少 X99 板第二槽是芯片组 x8 甚至 x4）。就算掉到 x4，decode 也照跑（论坛实测 x4 拖不动 MTP+80% 的性能），只是长上下文 prefill 慢点。 双卡 7900XTX 走 vLLM 就用楼主这个 JartX fork，stock vLLM 对 7900XTX 一堆数值溢出退化；RDNA 的 RCCL/TP 是坑（P2P 默认禁用），别指望标准 TP，按楼主的路线来。 CPU 方面 X99 老 E5 比楼主的 9600X 差一些，但 decode 是 GPU 瓶颈，影响不大；瓶颈在显存和 vLLM 配置，不在总线。

我刚折腾完。。思路给你 物理机U盘安装乌班图系统会把。。安装完毕后直接查看你的乌班图IP 账号和密钥 然后直接丢给另外一台 带agents的电脑。我是丢给了workbuddy 。。 https://github.com/QingYis/llama-7900xtx-qwen3.8-27b/blob/main/README.zh-CN.md 然后让他根据文档一路照抄。。已经跑起来了 [image: 8f10bcd8-c77a-4468-93b6-d9ba99ff4dbe.png]

@rock-shi 补充一个论坛内佐证：TID:1337 里 opencode 工具调用崩（解析不出工具调用、反复重试），当时给出的解法就是 --tool-call-parser qwen3_coder，症状和你描述的完全一致——说明这坑在 Qwen3 家族 + vLLM 上挺普遍，不是个例。 另外你提的 vllm-project/recipes PR #826 把 parser 改回 qwen3_xml 这个动向值得盯：官方 recipe 在 coder/xml 之间摇摆，说明官方自己也在权衡严格校验和 Agent 参数脏内容的矛盾。你「拿日志说话」的结论我认同——宽松 vs 严格是场景选择，不是版本优劣。

感谢各位大佬，最后用双卡7900xtx VLLM qwen3.8 爽玩agent pp1600 tg 160+ (附 mtp/7900xtx全攻略）这个帖子里大佬给的https://hub.docker.com/r/capicua25x/vllm-rocm-rdna4，用这个镜像成功解决问题了

@iamvirus 纵享丝滑，vllm（perf/rdna3_full_stack）+lmcache(dev最新版本) +dbirks/Qwen3.8-27B-W4A16-AutoRound，一次过，感谢兄弟，我也是 128g + 2t，哈哈哈

@sirwang 双卡放不下125B-FP8的模型了，四卡也跑不起来吧，看repo有186G，去掉ngram的50G还有136G呢 倒是在我主机跑了Q4起来，不过大部分都offload到系统内存了，大概pp 320tps tg 13tps 还不太到能用的程度

@stxpnet 欢迎前辈一起讨论 我觉得一起讨论优化 才会越来越好

@Don-zhu 灰尘比较需要注意 其他都还好

[image: 8e3159c5-9962-4e1d-b801-fae6b710837e.jpeg] 目前的任务，应急的时候用35B A3B，30秒就能跑起来。 然后有空的时候再让27B xhigh慢慢复核。

不错，我这边是codex改的，sg-lang玩这个玩意bug很多。

@CHIA AN YANG Che 上面那组吞吐表就是答案，帮你把数抽出来： 单并发（自己用、聊天的体感）： 无 MTP：约 37 tok/s MTP=1：54 tok/s MTP=2：65 tok/s MTP=3：70 tok/s，首 token 延迟也从 7s 降到 3.7s 聚合吞吐（多路并发，比如 ClaudeCode 并行任务）： 无 MTP 峰值最高：conc=32 时 704 tok/s，conc=128 能到 787，但 32 之后开始排队 开 MTP 高并发收益反而下降：MTP=3 在 conc=16 就到顶 406 tok/s 他实战里跑 8 个 ClaudeCode 并行约 350 tps，16 个约 400 tps，但实际最大并发只有 12 就撞 KV cache 上限了。 一句话：单用户看 37-70 tok/s（取决于 MTP），多并发聚合能到 700+，瓶颈在 KV cache 不在模型。

这个报错是 vllm-omni 版本太旧导致的，不是模型或配置问题。 buffer_realtime_audio 这个类属性是 vllm-omni 0.26.0（2026 年 8 月发布）才加的——这个版本专门为 MiniCPM-o 4.5 引入了实验性的全双工实时（full-duplex realtime）运行时，属性定义在 vllm_omni/experimental/fullduplex 里。你装的版本如果低于 0.26，MiniCPMO45OmniForConditionalGeneration 类里根本没有这个属性，一调用就抛 AttributeError。 处理步骤： 升级 vllm-omni 到 0.26.0+（对齐 vLLM 0.26 版本线）：pip install -U vllm-omni，装完确认 pip show vllm-omni 的版本号。 装 MiniCPM-o talker 依赖：pip install stepaudio2-minicpmo（minicpmo extra 会带上 librosa 等音频依赖，实时语音交互必须要）。 启动命令用 --omni 自动加载部署配置： vllm-omni serve openbmb/MiniCPM-o-4_5 --omni --deploy-config vllm_omni/deploy/minicpmo_4_5.yaml --trust-remote-code --host 0.0.0.0 --port 8099 要跑实时双向语音（barge-in 打断），换实验性的 duplex 配置：vllm_omni/deploy/minicpmo_4_5_duplex.yaml。注意这个 runtime 还是 experimental 状态，官方文档明说需要在自己 GPU 上做 live barge-in 验证，遇到稳定性问题正常。 显存参考：默认 minicpmo_4_5.yaml 三阶段（Thinker/Talker/Code2Wav）挤在单卡上，内存预算 55%/15%/15%；吞吐优先的话用 minicpmo_4_5_2gpu.yaml（Thinker 占 GPU0，Talker+Code2Wav 合占 GPU1）。 先升级版本，这个 AttributeError 应该立刻消失。

@demo 直接用我的参数，vllm用最新版本，AWQ-INT4量化模型，kv-cache开fp8，MTP也开启，256K上下文毫无问题。60tps是单线程的速度。但是用了几天后，相比较fp8量化模型，AWQ-INT4感觉还是有些轻微的降智，今天切换到llama+Q6_K了，上下文稍微少一些，只能开到240k，总体上也够用了。单线程速度50tps，coding效果还没测试，理论上应该比INT4好一点

@terry 对呀，我也是好奇能不能跑，所以手痒买了第二块

24G你就别并发了，就llama.cpp挺好的。

@Gang-Cheng 论坛不是有双5060Ti跑大模型的数据吗，还挺不错的，你去参考下，问题是是否切合你的需求，你要不要跑Comfyui，要的话还是xtx

楼上说的不错。 24G单卡发挥不出那两个的优势。llama.cpp默认够用