以上截图是今天真实工作场景下的全量日志拿来分析的数据，PP的峰值数据不可信（因为SGLang推理框架的RadixAttention缓存真的优雅又高效），但均值数据确实比vLLM运行DSV4-Flash提高了能有接近4成。

启动参数脚本如下，先在从机运行启动脚本：

docker run -d --name sglang_glm53 --network host --gpus all --shm-size=32g \
  -v /home/bentonyi/LLM/LibertAIDAI/GLM-5.3-Flash-NVFP4:/models/glm53:ro \
  sglang-glm53:gb10 \
  python3 -m sglang.launch_server \
    --model-path /models/glm53 \
    --trust-remote-code \
    --tp-size 2 --nnodes 2 --node-rank 1 \
    --dist-init-addr 10.100.40.2:29500 \
    --attention-backend dsa \
    --dsa-prefill-backend tilelang --dsa-decode-backend tilelang \
    --moe-runner-backend flashinfer_cutlass \
    --kv-cache-dtype bfloat16 \
    --disable-shared-experts-fusion \
    --reasoning-parser glm45 --tool-call-parser glm47 \
    --mem-fraction-static 0.90 \
    --context-length 524288 \
    --max-running-requests 2 \
    --default-chat-template-kwargs '{"reasoning_effort": "low"}' \
    --host 0.0.0.0 --port 8000

主机等6秒运行脚本：

docker rm -f sglang_glm53 2>/dev/null
docker run -d --name sglang_glm53 --network host --gpus all --shm-size=32g \
  -v /home/bentonyi/LLM/LibertAIDAI/GLM-5.3-Flash-NVFP4:/models/glm53:ro \
  sglang-glm53:gb10 \
  python3 -m sglang.launch_server \
    --model-path /models/glm53 \
    --trust-remote-code \
    --tp-size 2 --nnodes 2 --node-rank 0 \
    --dist-init-addr 10.100.40.2:29500 \
    --attention-backend dsa \
    --dsa-prefill-backend tilelang --dsa-decode-backend tilelang \
    --moe-runner-backend flashinfer_cutlass \
    --kv-cache-dtype bfloat16 \
    --disable-shared-experts-fusion \
    --reasoning-parser glm45 --tool-call-parser glm47 \
    --mem-fraction-static 0.90 \
    --context-length 524288 \
    --max-running-requests 2 \
    --default-chat-template-kwargs '{"reasoning_effort": "low"}' \
    --host 0.0.0.0 --port 8000

这个参数设置得比较极限：通过计算得到内存红线设置在0.92可保证上下文512K的情况下最大并发为2（gb10集群仅作推理服务器不运行别的任何程序，连屏幕键鼠都不配的情况下）。
GLM5.3-Flash这模型因为激活参数18B，推理确实很慢，再加上这货的默认设置导致过度思考的问题：

加入 --default-chat-template-kwargs '{"reasoning_effort": "low"}' \后勉强可用，但效果还是远不如DSV4-Flash。也就是不愿意为“降速高达70%但智力没有相应程度的提升”买单，工作了一天准备换回DSV4-Flash。下一步准备测试Qwen4架构的qwen3.8-flash-next。因为都是以实际工作场景的数据日志进行性能分析，所以更新可能没那么快，主打一个真实可信。

最后引用一个社区排行榜的glm5.3-flash截图，tp2无论如何都还是捉襟见肘，要真想在gb10上爽玩还是得TP4集群。

@terry said:

半年前还没有Qwen3.5

在Hermes 四月份出現之前, 我大概頂多只是看新聞, 看了兩個月的OpenClaw熱潮,
逛帖子也頂多上一些Reddit 論壇 看大家聊AI未來10~20年的發展
沒想到半年內就出了 Qwen3.5, Qwen3.6, Qwen3.8

相比下M3 ultra 脱离了聊天就直接拉了，算力不够，空有高带宽 。

@kop-wang said:

6~7万，就能部署一个头部能力的全尺寸模型。响应能力、kvcache容量都是可用级别。
放在半年前都像做梦一样。

請問半年前是什麼場景呢？ 我是Qwen3.6 才開始研究Local LLM的

也有人兩台跑vllm的nvfp4可以參考:

毕竟30的tg/s还是稍逊了一点。

6~7万，就能部署一个头部能力的全尺寸模型。响应能力、kvcache容量都是可用级别。
放在半年前都像做梦一样。

主要是双GB10的RAM比较富裕，多session并行切换也不会频繁重复prefill。
所以prefill稍慢也不是不行。

而且据测试，GB10的prefill性能随context膨胀的下降趋势不明显。

这是在用hermes一边计划对齐部署glm5.3-flash方案，一边在用DSH做早课的2并发时候的实际场景decode截图，最高单会话能上到76.7t/s，最低也有35+保底。

这是让hermes读魔搭的glm5.3-flash几个不同版本的模型卡页面，pp大概在1600～2500之间浮动。

上图是工作界面，之后会把glm5.3-flash的实际使用评测也发进来。

关键在 MoE 的 decode 是带宽瓶颈不是算力瓶颈：每生成一个 token，要从内存读一遍"活跃参数"。GX10（和 DGX Spark 同源）内存带宽约 273GB/s（LPDDR5X）。

• Qwen3.8-Flash-Next 约 176B 总参、MoE 每 token 只激活约 18B，NVFP4 量化后整模型约 90-100GB，单台 128GB 的 GX10 就装得下；
• DS-V4-Flash 约 284B/13B 活跃，官方 FP4 权重约 168GB，单台装不下，这才是双机的理由（容量）；
• decode 速度上限 ≈ 活跃参数字节数 ÷ 带宽。Flash-Next NVFP4 每 token 读约 10GB → 单机理论 ~25 t/s 上限、实际 15-20；双机时每个请求仍只跑一台，带宽不会叠加。

双机真正的收益只有三样：

1. 容量：装 168GB 级的 DS-V4-Flash（楼主两台跑 DSV4 就是这个原因）；
2. 并发：两个请求各占一台，总吞吐翻倍；
3. prefill：吃算力，若做跨机并行确实更快。

别指望跨机 tensor parallel 提速 decode：MoE 的 TP 每个 token 都要 all-to-all 交换 expert 输出，跨机走以太网就是新瓶颈（坛里 RDNA TP 无 P2P 反负优化的实测 TID:1438 是同一个道理）。

另外 AA 榜单的能力排序是云端/API 配置下的数字，和本地量化部署的速度是两回事。按你现在的两台机器：Flash-Next 单台就能跑、DS-V4-Flash 必须双台，这个分工比榜单排位更影响实际使用。

所以是不是双GB10跑Qwen3.8-flash-next能获得更好的pp和tg的性能表现。