strata并发成功，双7900xtx ， 单流70-80token/s , 双流聚合 160 token/s
-
這機制感覺很巧妙 希望能節省的RAM多一點, 否則開雙實例RAM壓力很大;
并发方案：双单卡 replicas
这次没有采用传统意义上的 TP2 或 layer split，而是使用 Strata 自带的 replicas 机制：
replica 0 → GPU0
replica 1 → GPU1共享专家 arena
两个副本通过下面的文件共享主机侧专家 arena：共享 arena 可以避免两个副本把专家权重完整复制两份到主机内存。
但是，共享 arena 不会共享以下内容：
GPU expert cache；
KV cache；
MTP 草稿状态；
会话状态；
请求状态；
每个副本的运行时工作集。 -
单流跑内存暂用是60G 左右， 2个实例是90G 左右，共享内存在16G 左右
兩個實例 = 单流 60G x 2 = 原本佔用120G
所以新的技術是節省了 120-90 = 30G RAM嗎？ -
-
-
-
-
-
@farmer-node
RX7900 XTX 雙卡大利多 ：- RX 7900XTX 雙卡一次跑兩個QFN實例 節省約30G RAM
- .GPU核心溫度50C (原本跑27B 都約在80C) , 顯存溫度約多少？大約60度嗎？
- 雙卡消耗 400W 以內 平均一卡 200W以內
- QFN_IQ3_S 单流70-80token/s , 双流聚合 160 token/s 速度上已經具有可用性了
- Prefill (?) 方面之後看效率上是否能配合Decode
-
@farmer-node
RX7900 XTX 雙卡大利多 ：- RX 7900XTX 雙卡一次跑兩個QFN實例 節省約30G RAM
- .GPU核心溫度50C (原本跑27B 都約在80C) , 顯存溫度約多少？大約60度嗎？
- 雙卡消耗 400W 以內 平均一卡 200W以內
- QFN_IQ3_S 单流70-80token/s , 双流聚合 160 token/s 速度上已經具有可用性了
- Prefill (?) 方面之後看效率上是否能配合Decode
-
@kos-or 功耗相比vllm 或是sglang 小很多，单卡不到200，prefill 最新版本有优化，单卡能跑到2000左右，很神奇。
-
功耗相比vllm 或是sglang 小很多，单卡不到200，prefill 最新版本有优化，单卡能跑到2000左右
看來這是目前 雙卡RX7900 XTX的最佳配置了 Strata + 併行 Qwen Flash
顯卡溫度低 + 功耗低
-
先上图：
硬件与模型
硬件
- 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 但是结论是如果很多对话同时发生
排队反而是最快的对的我也是在考虑这个问题。不就是双开么。
-
@懒人烘培 嗯，我也没跑多久，可能还有其他问题，大家可以一起测试，一起闭坑。
-
