先说句实话，我现在都不知道自己哪来的勇气。一个纯小白，在这个论坛里混了三个月，现在居然就敢大包大揽接下这么一个技术含量挺高的测试，回头想想，多少有点自不量力。结果这两天果然被现实狠狠地打脸。各种之前根本没想到的问题一个接一个冒出来，搞得我抓耳挠腮、鼻青脸肿，折腾了一天一夜多，整个人都有点焦头烂额了。

首先就是ROCm 7.2 升级到 7.14 带来的编译问题和系统兼容问题，vLLM的识图也一度崩了，最离谱的是，后来发现硬件这边居然也在捣乱。先是 CPU 温度超过警戒值，后来排查下来，怀疑和散热器压紧程度、接触状态有关；接着两张显卡温度也一度冲得很高，又牵扯出上下卡位、风道以及两张卡之间热量互相影响的问题。这些因素叠在一起，导致我最开始跑出来的结果甚至有点违反预期。

老特前不久的视频里很明确地说过，SGLang 相比 vLLM 是更高一档的存在。我第一轮测出来 vLLM 更占优势，更不用说vLLM可以Int8 KV量化，SGlang只能BF16。要不是我一直紧跟特哥的视频，我当时可能还真就信了，所以第一反应不是下结论，交作业，而是立马警惕，是不是我哪里搞错了？

带着这个怀疑，我训着AI（也是跟老特学的）把整套测试重新审了一遍，结果还真发现了降频、温度干扰以及测试方案本身的一些漏洞。后来又花了很多时间，把温度、驱动、配置、测试方法这些干扰项一个一个排掉。折腾到刚才，总算拿到了一组我自己看完以后比较放心能拿得出手的结果。毕竟发出来的东西还是要负责的，不能随便浪费大家时间。

下面直接上数据。

一、先汇报 PR #34058 / N=1 的实际结果

先把上次大家比较关心的这件事交代一下。

我这次实际按 PR #34058 对应的 N=1 路线继续用了下来。

结论很直接：

目前已经达到我认为可以投入实际生产使用的状态。双 7900 XTX 的 SGLang 路线正式打通，flyer666大神牛B！！！

而且不是“能启动、能跑请求”这种意义上的可用。在我后面重新做完的正式测试里，SGLang 已经不只是恢复正常，很多和我真实 Agent 工作负载相关的项目，实际表现已经超过了之前我用的很顺手的vLLM。（这个也是跟着flyer666大神的帖子 ”双卡7900xtx VLLM qwen3.8 爽玩agent pp1600 tg 160+ (附 mtp/7900xtx全攻略）” 学到的。 Respect！https://lcz.me/topic/1363 ）

尤其是：

• 长期 Agent 追加轮
• 多个 64K 请求并发
• 文本→图片→再返回文本
• 64K decode

所以在我现在这套双 7900 XTX / ROCm 7.14 / Qwen3.8-27B 环境里，我已经把SGLang正式部署为我的生产环境。

注： N=1 后，64K fresh prefill 不再把正在 decode 的 Agent 完全饿死，但重 prefill 仍会造成显著性能下降。这其实也很合理。B 的 64K fresh prefill 本身就是一个非常重的 GPU 任务，它进来以后会大量占用算力和带宽。双卡总资源固定，A 的 decode 被挤压是正常的；N=1 做到的是不让 A 完全没饭吃。

下面汇报测试细节，欢迎批评指正

二、测试平台

硬件环境

两套生产配置

这里先声明一下：这不是完全归一化的学术 benchmark。 我测的不是“把所有参数强行改成完全一样以后，哪一个 scheduler 理论上更强”。

打通这条 SGLang 路线以后，我真正想测的其实很简单：同样的硬件、同样的模型、同样的 196K 上下文目标，SGLang 和 vLLM 到底哪个更适合我真实的 Agent 使用场景。

三、我的真实使用场景

这个部分其实比单纯的 benchmark 数字更重要。我的机器不是拿来给多个人同时跑 API 的。大多数时间，我就是自己用两个长期 Agent。

Agent A：分析 / 推理

主要做：

• 分析
• 调研
• 公司报告
• 长文本
• 学习资料
• 各类推理任务

Agent B：创意 / 多模态

主要做：

• 图片
• 视频
• 多模态
• 创意任务
• 偶尔回到文本分析

偶尔的 Agent C

第三个 Agent 在我的NAS上，主要负责：

• 系统监控
• 系统管理
• 检查所有机器状态
• 远程唤醒
• 家庭智能助手
• 一些比较轻量的后台任务（邮件，提醒，定期搜寻资料等）

但三路长期重负载不是我的常态。

为什么我最终把 Context 定在 196K？

每一个 Agent 我都配置到：196,608 tokens，约 192K。

这个数字不是随便拍脑袋定的。主要是结合双 7900 XTX 的实际 KV 容量，反复讨论以后选出来的生产平衡点。

在我现在的配置下：

SGLang

因为还是 BF16 KV，所以 KV 空间比较紧。196K 65%压缩阈值这个设定下：

两个长期 Agent 基本是比较安全的。

再加入第三个大 Context session，就开始很容易发生 eviction。

vLLM

vLLM 使用 INT8 KV，KV 容量明显大一些。从这次实际测试表现看，大致可以理解成：

比 SGLang 多出半个到一个 session 的余量。

也就是大约 2.x 个类似长期上下文的空间，而不是无限增加。

所以最终对我来说，196K + 双 Agent 本身就是一个经过取舍以后比较合理的生产点。（注意，Qwen3.8 27B的雷霆大思考是病，得治，网上有药）

而且我的 Agent 不会真的一路堆到 196K

我的Hermes Agent压缩机制大约到 65% context 左右就会压缩。压缩以后回落到大约 25%，同时保留：

• 最近约 20–30 条重要消息
• 最早 1–2 条关键内容
• 压缩后的长期摘要

所以现实里我根本不会经常跑到 190K+。这也是为什么这次 196K 极限测试因为测试载荷多了几个 token 而作废以后，我没有再专门补测。对我的生产场景意义不大。

我的 workload 和 Coding Agent 其实不太一样

还有一点必须特别说明。我的工作比较发散，两个Agent大多数时间都算是“脉冲式”推理，基本没有双路满载的情况。具体来说 -

一个 Agent 可能正在做：

公司分析、报告、调研、长文本推理

另一个 Agent 可能已经跑去：

做图、做视频、看图片、多模态

所以这并不像很多 Coding Agent：

• system prompt 类似
• tool schema 类似
• repository 内容高度重复
• 大量代码 prefix 可以反复共享

我的两个主 Agent 之间，真正完全相同的大段业务 prefix 并没有那么多。所以从这个角度讲：

我的 workload 其实并不是特别“照顾”SGLang prefix cache 的 workload。远远没有发挥SGLang高效缓存命中的实力

同一个 Agent 自己继续聊天，cache reuse 当然非常明显。但跨 Agent 的共享命中率不会像 Coding / 大规模同质 Agent 那么高。我平时使用两个 Agent 的任务内容差异较大，因此跨 Agent 可复用的大段 prefix 不多，新任务更容易表现为 fresh prefill，而不是高比例 prefix hit，如果你的 workload 是：

• Coding Agent
• 多个 Agent 共用同一套 tools
• 大量相同 system prompt
• 大量重复 repository/context
• 显存又比我的双 24GB 更充裕

那么我认为 SGLang 的 prefix cache 优势反而可能比我这里体现得更充分。

四、核心结果

1. 单流：两边差距其实不大

32K Cold Prefill

32K 基本可以认为打平。

64K Cold Prefill

Prefill 还是几乎一样。但 64K Decode：> SGLang 领先大约 15%。

2. 长期 Agent：这里开始真正拉开

两个 64K 长期 Session 建好以后，继续原来的会话：

这是我最看重的项目之一。

0.402 秒 vs 2.254 秒。

SGLang 后续轮响应大约快：

5.6 倍。

这已经不是 benchmark 表格上好看一点的问题。

长期 Agent 每天真正用的时候，0.4 秒和 2.2 秒的体感完全不一样。

3. 一个 Agent 正在 Decode，另一个突然进来一个 64K 重任务

vLLM 最大那一下停顿更短。

但 SGLang：

• 原 Agent 吞吐更高
• 新任务完成更快
• 大多数 token 输出更连续

所以综合下来，我还是判 SGLang 略胜。

不过这个测试也证明了一件很现实的事情： 显存能解决“装不装得下”，解决不了无限算力。

三路、四路都同时真正 Decode 的时候，两张 7900 XTX 的总算力就在那里，不可能每一路都保持单流速度。我自己用短上下文的三个Agent实测时，已经感觉到明显卡顿了，算力瓶颈开始显现。

4. KV Retention：这一项 vLLM 明确赢

加入第三个 Agent 后：

SGLang

两个原来的 64K Session 回来：

• ~48.4s
• ~48.4s

基本都需要重新 Prefill。

vLLM

一个大部分被驱逐。

另一个还能：

~2.29s

所以这一项：

vLLM 明显胜出。

但这里要再次提醒：

• vLLM = INT8 KV
• SGLang = BF16 KV

这很大程度上就是 KV 容量的直接差异。

如果以后 SGLang 的 8-bit KV 在 gfx1100 / ROCm 上稳定打通，这一项我认为非常值得重新测。顺带说一句，这两天折腾的时候倒是误打误撞把 FP8 KV 给跑通了，只不过现在速度慢得比较明显，肯定还有坑，暂时谈不上实用，flyer666大神也尝试过了也还没搞定，但是AMD社区发展很快，后面我继续盯着看有没有大神们的分享。

5. 2 / 3 / 4 个 64K 同时进入

这是我这轮最惊讶的结果之一。

SGLang 基本是：

大家一起进来，差不多一起出去。

vLLM 则出现明显 TTFT 阶梯：

• 2 并发：48 → 97s
• 3 并发：48 → 97 → 100s
• 4 并发：48 → 97 → 100 → 103s

至少在我这套双 RX 7900 XTX TP2 环境下：

SGLang 并发 Prefill 调度明显占优。

注：这一组输出只有 2 tokens，因此主要衡量 64K 并发 prefill、TTFT 和整批 wall-clock，不代表 2/3/4 路持续 decode 吞吐。

6. 多模态

单独看一张图片：

纯视觉：vLLM 略快。 但是我真正的 Agent 工作方式通常是：

长文本 → 看图识图 → 再回原来的长文本

图片之后返回原文本：

• SGLang：0.233s
• vLLM：20.268s

这里差距就完全不是一个量级了。所以：

单图：vLLM 略胜。

真实文本 + 视觉长期 Agent：SGLang 明显胜。

五、最后结论

先声明：

这个结论只代表我的硬件和 workload，不代表所有人。

如果你的显存更大、长期并发 session 更多，而且 KV retention 的优先级高于交互延迟，那么 vLLM 的 INT8 KV 路线依然非常有吸引力。我的结论并不是“vLLM 不行”，而是 在我的 workload 权重下，SGLang 更合适。我的真实使用前提已经决定了选择：

• 常态就是两个长期 Agent
• 第三个 Agent 只是偶发监控/管理，用云端模型花不了多少钱
• 每个 Agent 虽然设到 196K，但 65% 左右就会主动压缩
• 工作内容发散，不是大量重复 Coding Prefix
• 更在意长期 Session 返回速度和双并发体验

在这个前提下：

我最后选择 SGLang 做主力。

因为对我最常发生的场景来说，它已经表现出：

• 64K Decode 更快
• 长期 Session 返回明显更快
• 双/三/四 64K 并发 Prefill 更强
• 文本→图片→文本工作流明显更顺

而 vLLM 最大的优势：KV retention 在我的生产策略里反而不是最高优先级。如果以后 SGLang 能把 gfx1100 下稳定的 INT8 KV 打通，那我认为它目前最明显的短板也基本补上了。

最后还有一个问题我后面很想继续测： > 1 个双卡 TP2 SGLang > vs > 2 个单卡独立实例 到底双卡协同能不能真正做到：

1 + 1 > 2

这个我觉得比继续追几十个 tok/s 更有意思。对了，这次主要围绕 SGLang、vLLM 和 llama.cpp 三条本地推理路线展开。当前这一轮先完成了 SGLang vs vLLM 的正式对比，llama.cpp 因为双卡实现方式不同（layer split，不是 TP=2），我准备单独开一轮测试，避免混在一起造成误导。特哥一直鼓励我发新帖，我正在弄，弄好了我一起发我的本论坛处女楼主贴。

最后聊点题外话。

感谢 AI 治好了我的“电子阳痿”。无比怀念当年天天晚上工会活动，我法师准时上线，和一帮兄弟姐妹一起开荒魔兽世界的日子——美好、热血，也确实挺不务正业。现在年纪大了，游戏买了一大堆，全躺在硬盘里吃灰，删又不舍得删，打开玩又确实意兴阑珊。

结果这几个月折腾 AI，居然又找回了当年那种感觉：白天上班，晚上回来折腾机器、编译、跑模型、改参数、看视频、查日志，一不小心又干到下半夜。

区别只是当年开荒的是副本，现在开荒的是 ROCm、SGLang、vLLM、llama.cpp，还有各种自建 Skill。

更妙的是，这次在家天天熬夜的理由还格外冠冕堂皇——“学习 AI、研究新技术、提升生产力”。连申请显卡经费审批都顺利了不少，居然和当年的高手们“名正言顺申请 5090以便在特殊时期更好的上网课”那种窃喜和偷感共情了。

仔细想想，人其实没怎么变，只是当年折腾装备、插件和副本，现在折腾显卡、推理框架和 Agent。还是那个毛病：一旦找到新坑，就总想往深里挖。

搞不懂就查，跑崩了就重来，偶尔折腾出一个能用的结果，那个爽感还真和当年首杀 Boss 有点像。

游戏还是继续吃灰吧。现在这个“副本”，感觉还够我开荒一阵子。