strata并发成功，双7900xtx ， 单流70-80token/s , 双流聚合 160 token/s
-
先上图：
硬件与模型
硬件
- CPU：AMD EPYC 7452
- GPU：2 × AMD Radeon RX 7900 XTX
- 显存：24GB × 2
- 系统内存：约 125GiB
- GPU 架构：gfx1100
- 推理后端：ROCm / HIP
- Strata：v0.1.43
模型
Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-proj模型相关文件：
/work/packs/iq3_s /models/IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00001-of-00002.gguf /models/IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00002-of-00002.gguf /work/mtp/rt并发方案：双单卡 replicas
这次没有采用传统意义上的 TP2 或 layer split，而是使用 Strata 自带的 replicas 机制：
replica 0 → GPU0 replica 1 → GPU1配置结构：
{ "replicas": [ { "gpus": [0] }, { "gpus": [1] } ] }这个方案的特点：
- 每张 GPU 运行一个独立模型副本；
- 每个副本拥有独立的推理 engine；
- 每个副本拥有独立的 KV、MTP 和会话状态；
- 两个副本共享主机侧专家 arena；
- 不是一个跨双卡切层的单实例；
- 不是 batch；
- 不是 batch-MTP；
- 每个副本仍然运行 solo MTP；
- 服务根据请求负载将请求路由到两个副本。
当前配置
模型与缓存
--pack /work/packs/iq3_s --native /models/IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00001-of-00002.gguf --ple-gguf /models/IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00002-of-00002.gguf --expert-profile /opt/strata/data/expert-profile.bin --expert-cache auto --max-context 262144 --kv int8 --kv-resident 32768 --shared-expert-arena /dev/shm/strata-shared-arena.bin --conversation-cache-mib 8192Prefill 与 MTP
--prefill auto:32768 --spec 4 --spec-min-p 0.5 --mtp /work/mtp/rt --mtp-window 32768PLE 与视觉
--ple-io direct --vision --vram-reserve-mib 700拒绝方向向量投影
--control-vector-scaled /models/Huihui-Qwen3.8-Flash-Next-refusal-direction-r.gguf:1.0 --control-vector-layer-range 4 44 --cvec-mode project --cvec-dir per-layer环境变量
STRATA_HIPBLASLT_TUNING=/opt/strata/tools/hip/gfx1100-hipblaslt-100202.txt STRATA_HIPBLASLT_VERBOSE=1 STRATA_HIP_WMMA=1 STRATA_STAGE_PIN=1 STRATA_WATCHDOG_S=180配置文件：
/home/kuma/projects/strata-docker/deploy-gsq-iq3s/config/config-iq3s-11436-replicas-opt.json共享专家 arena
两个副本通过下面的文件共享主机侧专家 arena：
/dev/shm/strata-shared-arena.bin当前大约占用：
47.96GiB该文件位于
/dev/shm，属于 RAM-backed tmpfs，不是 SSD。共享 arena 可以避免两个副本把专家权重完整复制两份到主机内存。
但是，共享 arena 不会共享以下内容：
- GPU expert cache；
- KV cache；
- MTP 草稿状态；
- 会话状态；
- 请求状态；
- 每个副本的运行时工作集。
因此，replicas 可以减少部分 RAM 重复占用，但不会让两个副本只占一份完整运行内存。
PLE 读取方式
当前使用：
--ple-io direct含义是：
- PLE/n-gram 表不完整预读到 RAM；
- 运行时按需从 NVMe SSD 随机读取；
- 主要目标是节省主机内存。
但是，PLE 的访问具有随机读取特征。长上下文 Prefill 时，如果 SSD 随机读取跟不上，会出现：
threads waiting on the disk以及：
no progress for 180 s during a request此时 GPU 可能处于低利用率甚至 0%，但请求不一定是真正死锁，而可能是卡在 PLE 的 SSD 随机读取阶段。
因此：
--ple-io direct优先解决的是内存容量问题，不保证解决长上下文首 token 延迟问题。
并发指标
Strata metrics 中常见字段：
queued running outside_slots replicas[].alive replicas[].running replicas[].routed replicas[].batch含义：
queued：Strata 路由层队列；running：当前承载的请求状态；replicas[].running：某个副本当前承载的请求状态；alive：副本 engine 是否在线；routed：累计路由请求数量；batch=0：当前没有使用 batch。
注意：
running 不等于 GPU 此刻正在计算当请求处于：
reading the prompt或者正在等待 PLE/SSD 时，GPU 利用率可能暂时为 0%。
一个请求一旦被分配到某个副本，不会因为另一张 GPU 空闲就自动迁移到另一个副本。replicas 是请求级路由，不是跨 GPU 的任务迁移机制。
测试结果
以下测试使用：
temperature=0 medium thinking这些结果只代表对应测试口径，不代表日常采样参数下的速度保证。
双路 64K
单请求：
83.6～85.5 tok/s双请求共同窗口聚合：
159.5～170.1 tok/s双路 128K
双请求聚合：
153.7 tok/s双路 240K
实际每路输入约：
245755 tokens双请求聚合：
159.6 tok/s资源采样：
最低 MemAvailable：约 32.8GiB Swap-out：0 Full memory PSI avg10：最高 0%这些结果只能说明对应测试条件下双副本可以工作，不能直接外推：
- 满 256K 长期稳定运行；
- 无限会话停放；
- 更高并发；
- 所有请求都能稳定双卡分流；
- dsh 多轮工具调用下的长期稳定性。
batch-MTP 对照
另外测试过两副本、每个副本 batch=2 的配置。
四路请求聚合结果：
开启 batch-MTP：151.4 tok/s 关闭 batch-MTP：104.2 tok/s在当时的测试条件下，batch-MTP 有明显收益。
但这个结果不能直接与双路 replicas 比较，因为两者的执行条件不同：
- 请求数量不同；
- 输出预算不同；
- 执行机制不同；
- 双路 replicas 使用每副本 solo MTP；
- batch-MTP 使用另一套 batch 执行路径。
当前采用：
11436：双单卡 replicas + solo MTP 不默认启用 batch-MTP -
@farmer-node 2x 3090 能用么？
@johnnybegood 可以的，不挑显卡，3090 单流可以到100token/s ，如果是双流应该可以上到200token/s
-
@johnnybegood 可以的，不挑显卡，3090 单流可以到100token/s ，如果是双流应该可以上到200token/s
-
-
@farmer-node 没搞明白是什么原理。 是不是只能在 linux上？ windows不行。
@johnnybegood 这个不是主要解决单对话问题吗？
简单来说就是 2张卡 同时跑两个llm
所以可以同时接收两个对话但是但对话的速度就变低了
基本上楼主的单对话跟我的单3090跑 strata 是一样速度其实这个测试我也试了
但是结论是如果很多对话同时发生
排队反而是最快的如果是agent 生成很多sub agent 排队效率比较高
但是如果是多用户 楼主的体验比较好我单人使用 而且把sub agent 分给27b 所以就没这个问题
0.1.43 可以直接 "replicas": 2
-
-
@johnnybegood 这个不是主要解决单对话问题吗？
简单来说就是 2张卡 同时跑两个llm
所以可以同时接收两个对话但是但对话的速度就变低了
基本上楼主的单对话跟我的单3090跑 strata 是一样速度其实这个测试我也试了
但是结论是如果很多对话同时发生
排队反而是最快的如果是agent 生成很多sub agent 排队效率比较高
但是如果是多用户 楼主的体验比较好我单人使用 而且把sub agent 分给27b 所以就没这个问题
0.1.43 可以直接 "replicas": 2
@applejuice 但是结论是如果很多对话同时发生
排队反而是最快的对的我也是在考虑这个问题。不就是双开么。
-
@懒人烘培 嗯，我也没跑多久，可能还有其他问题，大家可以一起测试，一起闭坑。
-
-
我的实际配置和测试情况如下，供参考。（AI生成）
硬件与模型
- Intel Xeon E5-2696 v4，X99 主板，内存约 126 GiB
- 2 张 AMD Radeon RX 7900 XTX，每张 24 GB 显存
- 模型：Qwen3.8-Flash-Next GSQ-RCO Abliterated IQ3_XXS
- Strata v0.1.43，MTP-4、KV int8，最大上下文 256K
双卡单实例：双卡自动层切分
两张卡共同运行一个模型实例，处理一条对话。
- 短输入单请求实测约 60.6 tok/s
- 最近一次长上下文请求：输入约 133K tokens（约 132K 命中上下文缓存），生成 3,448 tokens，耗时约 60.6 秒，约 56.9 tok/s
- 这是单请求测试，没有多请求并发
双卡双副本：每张卡各跑一个实例
两张卡分别运行独立模型副本，同时处理两个对话。
- 双请求并发时，每条请求约 85–94 tok/s
- 两条请求合计约 142 tok/s；首轮冷缓存约 110 tok/s
- 这是短输入并发测试，测的是两个请求的总吞吐，不是单条对话达到 142 tok/s
单卡情况
目前没有在这台机器上完成单卡 Strata 的独立测速，因此没有可比较的单卡实测数据。上述双副本测试虽然每个副本各用一张卡，但它测的是两个独立请求并发，不能当作单卡单请求成绩。
我的使用方式以单人单对话为主，目前采用双卡单实例层切分；双副本主要适合多用户或多个独立对话并发。
-
-
-
@farmer-node 没搞明白是什么原理。 是不是只能在 linux上？ windows不行。
@johnnybegood windows 没测试过， 但是我觉得换linux 平台是一个必选项，linux 平台 所有指令全部可以由ai 接管，而且linux 桌面版 可以平替 windows 桌面，如果真的要用windows ，也可以开虚拟机来跑windows，虽然效率会有一定影响，我觉得差别不大，除非你在虚拟机你玩3A 大作。
-
@johnnybegood windows 没测试过， 但是我觉得换linux 平台是一个必选项，linux 平台 所有指令全部可以由ai 接管，而且linux 桌面版 可以平替 windows 桌面，如果真的要用windows ，也可以开虚拟机来跑windows，虽然效率会有一定影响，我觉得差别不大，除非你在虚拟机你玩3A 大作。
@johnnybegood windows 没测试过， 但是我觉得换linux 平台是一个必选项，linux 平台 所有指令全部可以由ai 接管，而且linux 桌面版 可以平替 windows 桌面，如果真的要用windows ，也可以开虚拟机来跑windows，虽然效率会有一定影响，我觉得差别不大，除非你在虚拟机你玩3A 大作。
A卡跑模型必须Linux 呀。
-
，
F farmer node 引用了 此主题
-
，
-
，系统 取消固定了此主题
-
-
-
@kos-or
我不做选择
两个都要
-
@applejuice 这个图应该怎么解读？27B跟GPT5.6 能力区间这么接近吗？
-
@Ben-Lee 推理那些吧？ 能力还包过知识方面 27b 一定不够来
-
你这个功耗好低，我这个xtx7900 超白金二手，跑27b功耗一直在355w上下，最高甚至能到604w，大部分尖峰也在400w左右，工作区的高峰也在355w左右，然后显存温度一直在75-89之间变化，结温也是一直在78-89之间变化，边缘温度控制在60左右，最近室温也不算高，而且用的是显卡坞，开放式的，用了两个电扇在吹，夏天温度估计至少加8°，不知道我这个温度算不算正常，功耗非常高
@Hackner-Weinland 可以适当降低GPU 的电压，我之前比较激进，降了60mv ，但是开机1个月以后，死机了一次， 就改成了 现在的 -20mv，目前开机一个月还没有问题，没关机，一直跑
本帖参与讨论人数已达 10+，入选热议，作者 +3 积分奖励，感谢分享！