硬件与模型

硬件

• 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 8192

Prefill 与 MTP

--prefill auto:32768

--spec 4
--spec-min-p 0.5
--mtp /work/mtp/rt
--mtp-window 32768

PLE 与视觉

--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