• 測試時間：2026-10-23 19:38:00
• 測試項目：僅速度（生成速度、首字延遲、Prompt 前處理速度），不含品質評測
• 測試工具：自製 Python 腳本（標準庫 urllib + SSE 串流），OpenAI 相容 /v1/chat/completions

1. 受測對象

項目	值
引擎	Strata（llama-server 相容協定，serve/server.py --engine strata）
模型	qwen3.8-flash-next-iq3_s（Qwen3.8-Flash-Next GSQ-RCO，IQ3_S 量化，MoE + MTP）
端點	http://127.0.0.1:8080/v1
上下文	1,048,576 tokens（rope yarn ×4，KV cache int8）
並行槽數	1（total_slots: 1，單請求序列化）
加速設定	推測解碼 --spec 4、MTP、expert cache auto、prefill auto
驗證	無 API key
模態	text + image → text

2. 硬體環境

項目	值
主機	Dioscuri（Linux 7.0.0-38-generic）
CPU	Intel Xeon E5-2686 v4 @ 2.30GHz × 36 threads
RAM	247 GiB（測試時已用約 74 GiB）
GPU ×2	AMD Radeon AI PRO R9700（Navi 48，各 34.2 GB VRAM，05:00.0 與 08:00.0），ROCm/HIP
GPU（顯示用）	NVIDIA GeForce GT 1030, 2 GiB — 僅驅動桌面（gnome-shell），不參與推論
模型存放	/run/media/iceoff/Dioscuri_Data/LLM_models/Stara models/IQ3_S/（2 分片 GGUF）

3. 測試方法

一般社群常用的三項速度指標，皆以串流模式量測：

1. TTFT（Time To First Token）：送出請求 → 收到第一個 delta 的時間。注意此模型會先輸出 reasoning_content（思考過程），因此首字以 content 或 reasoning 任一出現 為準，避免低估。
2. 生成速度 (decode, tok/s)：(completion_tokens − 1) ÷ (最後一個 token 時間 − TTFT)，token 數取自伺服器回傳的 usage。
3. Prompt 前處理速度 (prefill / pp, tok/s)：prompt_tokens ÷ TTFT，用 4 種長度（約 750 / 2.8k / 5.7k / 11.3k tokens）量測規模效應。

控制變因：temperature = 0、max_tokens 固定、每次測試前先送一次 warmup、每組重複 3 次取平均。
為避免 llama-server 的 prefix cache（提示快取）讓第二次以後的請求虛快，prefill 測試每次都在 prompt 開頭插入隨機 nonce，並核對回傳的 cached_tokens = 0 確認是冷啟動。

3.5 推論實際跑在哪裡（實測佐證）

是：兩張 R9700 都參與推論（HIP，--layer-split auto 跨兩卡切層）。 依據：

證據	觀測值
引擎進程開啟的裝置	strata 進程持有 /dev/kfd、renderD128（R9700 #0, 05:00.0）、renderD129（R9700 #1, 08:00.0）
VRAM 佔用	GPU0 33.6 GB / 34.2 GB（98%）、GPU1 33.9 GB / 34.2 GB（99%），模型權重常駐
生成中的使用率（342 tokens 那一次，0.2 s 取樣）	GPU0 平均 69%（峰值 89%）、GPU1 平均 46%（峰值 89%）
生成中的功耗	GPU0 平均 171 W（峰值 301 W）、GPU1 平均 101 W（峰值 222 W），皆為 240 W 上限內

同時該次生成量到 73.4 tok/s，與表格中的 77–78 tok/s 一致，表示受測數字是雙卡 GPU 推論的結果，不是 CPU 推論。GT 1030 只是桌面顯示卡。

另一個值得注意的訊號：兩張卡在生成時都沒跑滿（69% / 46%），且負載不均，表示目前的瓶頸不在 GPU 算力本身，較可能在專家權重由系統 RAM 串流（--expert-cache auto、--ple-io ram、KV 只常駐 32,768）與 PCIe 傳輸，或推測解碼的接受率。此為推論，未做對照實驗驗證。

4. 結果一：生成速度（固定短 prompt，約 65 tokens）

max_tokens	次數	實際輸出 tokens	TTFT (s)	生成速度 (tok/s)	總耗時 (s)
128	3	128	0.45	84.9	1.95
256	3	256	0.33	78.1	3.60
512	3	411	0.35	77.6	5.64
1024	3	411	0.35	77.8	5.62

512 與 1024 兩組模型都在約 411 tokens 自然結束（finish_reason: stop），故兩列數字幾乎相同，屬正常。
三組重複間的離散度極小（例如 256 組為 76.95–78.62 tok/s），可視為穩定值。

5. 結果二：Prompt 前處理速度（冷啟動，prefix cache 未命中）

Prompt tokens	次數	TTFT (s)	Prefill (tok/s)	同場生成速度 (tok/s)
756	2	1.59	478	94.8
2858	2	2.30	1243	83.3
5672	2	3.55	1597	89.3
11258	2	5.79	1945	71.2

前處理吞吐隨批次變大而上升（約 500 → 2,000 tok/s）。短 prompt 時固定開銷（HTTP、排程、首個 prefill chunk、雙卡同步）佔比高；長 prompt 時才看得到穩態吞吐。
以約 11k tokens 的實測值回推，塞滿 1M 上下文約需 9 分鐘（1,048,576 ÷ 2,000 ≈ 524 s），長文件一次性的前處理成本偏高。

6. 結果三：Prefix cache 命中對照（附帶觀察）

情境	Prompt tokens	TTFT (s)	表面 prefill (tok/s)
冷啟動（nonce 每次不同）	5,670	3.55	1,597
重送完全相同的 prompt	5,640	0.45	12,519

同一 prompt 重送時 prefix cache 全命中，TTFT 從 3.55 s 降到 0.45 s。多輪對話、重複系統提示詞的實際體驗會明顯優於上表的冷啟動數字。

7. 結論

• 受測組態是雙卡 GPU 推論：2 × Radeon AI PRO R9700（各 34 GB VRAM 幾乎全滿），HIP + layer-split 跨卡。GT 1030 只負責桌面顯示。
• 生成速度：約 78 tok/s（短輸出 85 tok/s、長輸出 77–78 tok/s），單人使用文字對話體感順暢。
• 首字延遲：約 0.33–0.45 s（短 prompt）；11k tokens 的長 prompt 約 5.6–6.0 s。
• Prompt 前處理：約 1,200–2,000 tok/s（2.8k tokens 以上）；短 prompt 約 450–500 tok/s。
• GPU 還有餘裕：生成時兩卡僅 69% / 46%（峰值 89%），未吃滿算力，調校 expert-cache / KV / split 比例或提高 --kv-resident 應還有提升空間。
• 並行能力受限：total_slots = 1，同時只有一個請求在跑，第二個請求會排隊；多人共用時吞吐不會提升，只會拉長延遲。
• 100 萬 token 上下文是帳面規格：以實測前處理速度，填滿需約 9 分鐘；日常建議把有效上下文控制在數萬 tokens 以內。
• 推測解碼（spec 4 / MTP）已生效：若關閉，生成速度預期會明顯下降；本報告數字已含此加速。

8. 附錄

• 原始逐筆數據：raw_results.json（每次請求的 TTFT、token 數、tok/s、cached_tokens）
• 測試腳本：bench2.py（python3 bench2.py gen / python3 bench2.py pp）
• GPU 使用率取樣腳本：gpu_sample.py（直讀 sysfs gpu_busy_percent 與 power1_average，0.2 s 間隔）
• 重現方式：確認 8080 埠服務在跑後直接執行上述指令即可，無需任何套件（僅 Python 標準庫）。
• 註：初版報告誤把桌面顯示卡 GT 1030 當成推論 GPU，已依實際裝置與使用率觀測更正為 2 × R9700。
• 註：第一次測試期間觀察到伺服器進程曾中斷並自動重啟（PID 17104 → 24628），該次數據已作廢；本報告所有數字皆來自重跑後的乾淨數據。