2 x 5060 Ti 16 GB, DRAM:64GB, Strata 0.2.7 `--parallel` 併發測試報告

[XXX]

Strata --parallel 併發測試報告

日期:2026-10-28(CST)|測試者:柳玉(Hermes Agent)|現行配置:parallel 4

1. 軟硬體配置

硬體

• CPU:Intel Core i5-13500(13th Gen),20 logical CPUs,max 4.8 GHz
• RAM:61 GiB(引擎常駐 ~52–53 GiB,可用 ~8 GiB)
• GPU:2 × NVIDIA GeForce RTX 5060 Ti 16 GB(16,311 MiB/卡;layer split:CUDA0 跑 layers 0–23,CUDA1 跑 24–47)
• OS:Ubuntu 26.10,kernel 7.3.0-9-generic
• NVIDIA driver:580.178.04

軟體 / 模型

• Strata Terminal 0.2.7(build 0.1.52),engine cuda13
• 模型:Qwen3.8-Flash-Next,量化 IQ3_XXS(MoE,native experts;engine 載入 39.97 GiB weights @2.07 GiB/s,expert 主存放於 RAM、經 VRAM cache 流式取用)
• Context:65,536 tokens;KV:int8;MTP 投機解碼:spec 6 / mtp_max 4
• 端點:http://127.0.0.1:8080/v1(OpenAI 相容;另有 Anthropic 相容端)
• 啟動方式:systemd-run --user --unit=strata-qwen -p MemoryMax=infinity + strata launch --preset "IQ3_XXS 64K" --parallel N --set vram-reserve-mib=896
• 模型檔:~/.local/share/strata/Strata-data/(packs/iq3_xxs 為轉換後 pack)

2. 測試方法

• 腳本:Python threads + urllib 直打 /v1/chat/completions(~/.hermes/cache/scratch/llm_concurrency_bench.py)
• 每請求:短 prompt(繁中)、max_tokens=200;併發級別 1/2/4/8,每級 2 輪(級內全部同時發出);先 warmup
• 交叉驗證:GET /metrics、engine log 的 generated in X ms (Y tok/s) 與 decode expert cache hit rate 行
• 干擾說明:本 Hermes 對話本身由同一 server 驅動,個別數字可能含背景流量;「吞吐隨 parallel 變化的相對關係」不受影響

3. 結果

聚合吞吐(tok/s)

併發級別	parallel 1(預設)	parallel 2	parallel 4	parallel 8
1(2 req)	89.0	95.3	95.2	90.5
2(4 req)	90.0	91.4	133.5	123.9
4(8 req)	88.6	98.7	134.5	158.3
8(16 req)	90.1	98.5	133.8	152.4

延遲與命中率

	parallel 1	parallel 2	parallel 4	parallel 8
8 併發尾端延遲	35.5s	31.2s	22.8s	19.4s
單请求最快完成	~1.9s	~4.1s	~4.2s	~4.4s
單流 decode(batch 中)	~87 tok/s(獨行)	63–66	66–72	60–63
decode cache 命中率	92–99%	~91%	96–97%	50–74%(batch 路徑)
載入後 VRAM free	395 MiB	528 MiB	593/501 MiB	582/487 MiB
expert cache 規模	~9 GiB(12288 profiled pairs)	借調後縮小	8988 slots / 14.8 GiB	3719+2722 slots(被 slots 搶 4.11 GiB)

• 全部組合:請求全數成功,無 429/拒絕(engine 預設 max_concurrency: 0,HTTP 層不設限)
• --parallel N 生效證據:engine log strata verify: batch windows of up to N sequences(兩張卡皆有)

4. 解讀

1. parallel 1 = 串行 FIFO:連線收得但一次只 decode 一路,吞吐固定 ~90 tok/s,请求越多等越久。
2. parallel ≥2 = 真同時 decode:batch window 帶 N 個序列共用權重與被路由 expert 的讀取,聚合吞吐上升。
3. 代價一:單流變慢。batch 中每條流 ~60–72 tok/s(獨行 ~87);最快完成時間 ~2s → ~4.2s(主要是 CUDA graph 首用/共用 window 成本)。
4. 代價二:slots 搶 VRAM。每 slot 的 session state 從 expert cache 挖 VRAM;parallel 8 時 CUDA0 被拿 4.11 GiB,cache 縮到 3719/2722 slots,batch 路徑命中率掉到 50–74%,靠 PCIe/跨卡補讀(17.6%)。parallel 4 幾乎不傷 cache(命中率 96–97%)。
5. 甜點是 parallel 4:吞吐 +48%,尾端延遲 -36%,命中率不降反升。parallel 8 再多 ~15% 吞吐是拿命中率換的,長對話/真實多用戶場景可能反輸。
6. VRAM 全程處於引擎警告區(<512 MiB free 會警告,可能 paging 致 decode 暴跌):已用 --set vram-reserve-mib=896 保留;不要再加 context 或 slots。

5. 現況與備註

• 目前 server 以 parallel 4 執行中(unit strata-qwen),運行穩定、無 stall。
• 注意:--parallel 是啟動參數,不存在於 preset——純 preset 重啟會回到 parallel 1;要固定需 --save-preset 重存。
• 重啟程序(strata launch --stop + systemctl --user stop strata-qwen,再 systemd-run 重啟)中斷約 1 分鐘;model 從 page cache 重載約 20 秒。
• 原始數據:各級別 JSON 輸出與 engine log 留存於 ~/.local/state/strata/launch/iq3_xxs-64k.engine.log。

[Kai X.]

本机：2×RTX 5060 Ti 16 GB，Ryzen 7 3700X / 92 GB DDR4-3200 / IQ3_S / 测试时同样用 64K
日期：2026-10-29 ｜ Strata Terminal 0.2.7（engine 0.1.52）｜ driver 595.99.02

1. 配置

项	值
模型	SC117 abliterated IQ3_S（expert arena 约 50.3 GB）
拆分	layer split：CUDA0 layers 0–23，CUDA1 24–47；PCIe 4.0 x8 + x8
上下文	65,536
KV	int8
MTP	--spec 4 --spec-min-p 0.5
其它	--prefill auto、--pipeline-windows 2、--trim-stage-weights、--vram-reserve-mib 1024、学习型 expert profile
并发	通过 config 的 "parallel": N 设置（--batch N），每级重启

2. 方法

• Python threads + curl 直打 /v1/chat/completions；
• 短提示（中文，要求约 300 字）、max_tokens=200、greedy、关闭思考；
• 并发级别 1 / 2 / 4 / 8，每级 2 轮，级内同时发出；先 warmup 1 发；
• 聚合吞吐 = 该轮总输出 token ÷ 墙钟时间（含排队与 batch 等待），尾延迟 = 最慢一条的墙钟；
• 另核对 /metrics 的 slots / VRAM free 与引擎日志的命中率。

3. 结果（聚合吞吐 tok/s，两轮）

并发	parallel 1	parallel 4	parallel 8
1	76.4 / 88.2	72.7 / 86.4	—
2	84.6 / 81.3	80.9 / 83.7	—
4	79.8 / 78.6	110.7 / 116.1	98.0 / 114.6
8	79.4 / 80.2	110.4 / 109.3	122.2 / 130.1

尾延迟（8 并发，秒）：parallel 1 20.2 / parallel 4 14.6 / parallel 8 12.3

项	parallel 1	parallel 4	parallel 8
专家槽	10,332	8,397	6,232
加载后 VRAM free	733 MiB	655 MiB	643 MiB

4. 和原帖的对比

原帖（IQ3_XXS，i5-13500，64 GB）关键数字：parallel 4 在并发 4 时 133.5 / 134.5、并发 8 时 133.8；parallel 8 并发 4 时 158.3、并发 8 时 152.4。

场景	原帖	本机	差异原因
parallel 4 @ 并发 4	133.5–134.5	110.7–116.1	本机 IQ3_S 的 arena 50.3 GB（原帖 IQ3_XXS 42.9 GB），同显存下槽位更少（8,397 vs 8,988）
parallel 4 @ 并发 8	133.8	109.3–110.4	同上，外加 CPU 单核性能/内存带宽差异
parallel 8 @ 并发 8	152.4–158.3	122.2–130.1	本机 parallel 8 时槽位只剩 6,232，命中率下降
parallel 1 单流	~89–90	76.4–88.2	口径一致（单请求 200 token）

趋势完全一致：

1. parallel 1 是串行 FIFO，聚合吞吐固定在 ~80–88，并发越高尾延迟线性变长；
2. parallel 2 提升有限（batch 窗口利用率不高）；
3. parallel 4 是甜点：并发 4/8 时聚合 +38~45%，尾延迟从 20 s 降到 14.6 s；
4. parallel 8 吞吐还能再高（+12~18%），但 expert cache 从 10,332 掉到 6,232 槽，和原帖“slots 抢 VRAM、命中率下降”的结论一致；
5. 单流会略降（88 → 86），和原帖“独行 ~87、batch 中 60–72”的方向一致。

5. 结论

• 同型号双卡上，原帖的 parallel 4 结论可以复现：多客户端/多 agent 并发场景值得开 parallel 4；
• 我的模型更重（IQ3_S），相同显存下槽位少约 600，聚合吞吐低 15–20%，但相对关系不变；
• 单用户、单 agent 串行使用时 parallel 1 仍是最优（单流最快、槽位最多），这也是我们服务器的默认配置；
• 如果开 parallel 4，建议同时把 vram-reserve-mib 保持在 1024、上下文控制在 64K 左右，并监控 decode expert cache hit rate 是否跌破 90%。

6. 附：默认配置（parallel 1，131072 上下文）的单流数据

同一台机器、同一模型，未开 parallel 时：

提示	prefill	decode
34.6K	2,387 tok/s	90.1 tok/s
69.2K	2,808 tok/s	92.0 tok/s
129.9K	2,989 tok/s	84.2 tok/s

命中率 99.5%，槽位 9,828。供“单流 vs 并发”取舍参考。

[terry]

并发1就行了，排队未必比抢资源差，其实大多数任务都可以通过排队调度。

[XXX]

@terry
怕只有一個行程時卡住, 就停在那.