1. 受測對象

2. 硬體環境

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 跨兩卡切層）。 依據：

同時該次生成量到 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）

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

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

前處理吞吐隨批次變大而上升（約 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 重送時 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），該次數據已作廢；本報告所有數字皆來自重跑後的乾淨數據。