-
，
T terry 将此主题从 LLM讨论区 移至此处
-
-
现在我再买双卡还会迟吗
@imbiplaza-ASUS 特么的xtx已经涨到8000了，瞬间冷静
，还是等崩盘吧
-
现在我再买双卡还会迟吗
-
@imbiplaza-ASUS 特么的xtx已经涨到8000了，瞬间冷静
，还是等崩盘吧 -
@imbiplaza-ASUS 特么的xtx已经涨到8000了，瞬间冷静
，还是等崩盘吧 -
现在我再买双卡还会迟吗
-
@imbiplaza-ASUS 特么的xtx已经涨到8000了，瞬间冷静
，还是等崩盘吧 -
继前帖 Vibe爆改VLLM Kernel 支持我的双卡TP 之后，我也是过上了多并发跑qwen3.8的好日子，可是没过几天就发现了新毛病：虽然VLLM的Paged attention缓存容量效率都不错，但是它是每~1600token进行前缀缓存，在长上下文中往往不如llama.cpp（完全缓存命中），总要等个1-10秒才吐字，这时候就想起来老特安利的SGLANG，调研一番后发现官方支持基本没有，比VLLM还烂。但是它和VLLM底层都用的是Pytorch，转念一想把对应的VLLM kernel port过来不就完事了？
正好这个周末GLM大赦天下无限token，打开ZCode直接开干！
下面贴repo，找个称手的LLM API和harness即可一键重现复制：
https://github.com/StevenChenSE/sglang/tree/gfx1100-support#chinese这里面唯一的遗憾就是折腾了两天也没法支持fp8 kv cache，双卡4路并发的情况下bf16缓存只能开到192k上下文。
下来扔几个实测数据吧，整体上来说SGLANG的超短上下文爆发力不如VLLM，在数学题比VLLM 130tok/s低大概30%。此外在agent工作流中，整体表现远远超过VLLM:
双路并发平均150-200tok/sec
deepseek harness编程实测：
实测在hermes & deepseek harness中，90%情况下ttft都在<1s，80k上下文之前TG在80-100之间波动，丝滑程度远超llama.cpp & vllm，接下来唯一的缺憾就是等下单的32g ddr5内存（肉痛啊喂）快到货尽快上hicache了，下个周末有空看看dflash效果如何。
以下数据为LLM生成。
1. 标准化上下文深度衰减测试 (
llama-benchy)标准 Prompt Prefill ($PP=2048$) 与 Token Generation ($TG=128$), 并发数 = 1
上下文深度 SGLang MTP-3 (本分支) vLLM MTP-3 基线 vLLM DFlash2 基线 对比 vLLM MTP-3 优势 Depth 0 97.1 tok/s 88.6 tok/s 71.1 tok/s +9.6% Depth 4,096 97.3 tok/s 83.3 tok/s 68.4 tok/s +16.8% Depth 8,192 91.5 tok/s 93.3 tok/s 71.8 tok/s -1.9% Depth 16,384 95.7 tok/s 75.9 tok/s 62.2 tok/s +26.1% 速度留存率 (16k / 0k) 98.5% 85.7% 87.5% 长文本衰减极低 2. 真实 120k Agent 多轮会话回放（16 轮离散交互）
采样自真实 120k 长文本 Agent 对话（332 $\to$ 120,443 tokens），启用 Radix 前缀缓存
评估指标 SGLang MTP-3 (本分支) vLLM MTP-3 vLLM DFlash2 提升幅度 平均生成速度 (Mean TG) 87.89 tok/s 63.50 tok/s 67.96 tok/s 提速 +38.4% 中位数速度 (Median TG) 85.97 tok/s 61.52 tok/s 67.16 tok/s 提速 +39.7% 抖动率 (CV Jitter %) 12.92% 45.34% 36.56% 平稳度提升 3.5 倍 最差轮次保底速度 66.71 tok/s 16.94 tok/s 32.94 tok/s 最低速度提升 4 倍 3. 数学思维链推理测试 (GSM8K & MATH-500)
Greedy 贪婪采样，temperature = 0.0，max_tokens = 1024
数据集用例 生成 Token 数量 首字延迟 (TTFT) Prefill 速度 生成速度 (TG) 准确率 GSM8K #1 48 0.169s 533.5 tok/s 98.9 tok/s 100% 正确 GSM8K #2 196 0.180s 626.9 tok/s 116.2 tok/s 100% 正确 MATH-500 #1 169 0.149s 556.4 tok/s 114.7 tok/s 100% 正确 MATH-500 #2 212 0.137s 533.3 tok/s 111.2 tok/s 100% 正确 综合平均 — 0.159s 562.5 tok/s 110.3 tok/s 100% 正确 4. 多并发吞吐实测 ($c=4$)
使用
llama-benchy进行多并发请求压测 ($PP=2048, TG=128$, Depth 0)推理服务引擎 并发数 Prefill 总吞吐 (PP) 生成总吞吐 (TG) 峰值生成吞吐 运行稳定性与说明 SGLang MTP-3 (本分支) c = 4 1,974.5 tok/s 147.5 tok/s 206.0 tok/s 100% 稳定运行，Decode CUDA 图与 MTP-3 正常工作 vLLM Baseline (无投机) c = 4 1,891.1 tok/s 83.1 tok/s 180.0 tok/s 原生稳定，但解码速度较低 vLLM DFlash2 c = 4 1,693.2 tok/s 75.9 tok/s 188.0 tok/s 投机开销导致多并发总 TG 吞吐反而低于 Baseline llama.cpp (MTP) c = 4 636.3 tok/s 50.1 tok/s — 受限于插槽并发队列瓶颈 ( -np 2)多并发核心结论：此前在 ROCm 平台上，vLLM 的投机解码在多并发下普遍面临崩溃或负优化（DFlash2 吞吐不如普通非投机模型，原生 MTP 则直接非法地址异常）。而 SGLang 依靠 Wave32 对齐的 Triton 解码图和独立的 Mamba 状态缓冲，在 4 并发下展现出 147.5 tok/s 的总生成吞吐，比 vLLM 基线高出 +77.5%，比 vLLM DFlash2 高出 +94.4%。
-
@flyer666 我也是5月份看老特的介绍买了张新卡, 前天咸鱼买了一张二手还没到...btw, 自己一个人用, 多并发好像不是必须, 在长context vs 并发 之间取舍?
-
@laobenxiong 不需要取舍，你可以主打一个长上下文，128k足够，其他的你开几个短的，就是agent有的时候会开subagent做小任务，正好。而且后续可以通过hicache，kv压缩来优化，跟着他折腾就好了，或者自己让AI研究也行。
