雙 RTX 5060 Ti 16GB 跑 Qwen3.8-Flash-Next：196K／256K 長 Context 實測
測試日期：2026-10-06～10-07｜Strata v0.1.40.1（engine 0.1.40）
之前用手上的 RTX 5060 Ti 16GB ×2 跑 Qwen3.8-27B，不管是 vLLM 還是 SGLang，最常卡住的不是模型載不載得進去，而是 KV pool 不夠大，context 很難拉到 196K 以上。
在我當時的雙卡 TP 配置下，除了模型權重，還得負擔額外的顯存開銷，真正能留給 KV cache 的空間並沒有想像中多。即使調到接近目標，也可能得犧牲一些 prefill 或 decode 速度。
但長鏈任務跑久了，對話、程式碼和工具結果會不斷累積，還是希望能在這套硬體上多留一點 context 空間，不要太早就得壓縮或截斷前面的內容。
這次改用 Strata 跑 Qwen3.8-Flash-Next IQ3_S，比較 Max Context 196K 與 256K：同樣的輸入，開更大的上限會不會多等、吐字會慢多少，以及接近滿載時還能維持什麼表現。
測試從 16K、32K、64K 一路到接近 256K 總容量，主比較全部實際輸出 8K tokens；另外也保留短上下文搭配 1K 輸出的數據，供參考不同回覆長度下的差異。
硬體與設定
| 項目 | 配置 |
|---|---|
| CPU | Ryzen 9 5900X，12 核心／24 執行緒 |
| RAM | 64GB DDR4-3600；swap 8 GiB |
| GPU | RTX 5060 Ti 16GB ×2，PCIe x8＋x8 |
| 系統 | Ubuntu 24.04.4 LTS；NVIDIA driver 610.57.04 |
| 模型 | Qwen3.8-Flash-Next IQ3_S |
| KV cache | INT8 |
| 推理設定 | 單請求；layer split、expert cache、prefill 都用 auto |
| 其他設定 | MTP spec=4、spec-min-p=0.5；VRAM reserve=700 MiB；thinking 關閉、temperature=0 |
視覺功能維持 GPU 啟用。這次測的都是文字輸入，沒有測圖片處理。〔1、2〕
兩個上限分別是 200,704 tokens（196K） 與 262,144 tokens（256K），本文 K 以 1,024 計算。同一輸入檔位在兩種設定下使用相同 request 內容，同一時間只讓一個容器使用 GPU。
這是 fresh prefill，不是完整 cold start。 所有測試的 cached_tokens 都是 0，也就是整段輸入重新處理，沒有沿用前綴 KV 快取。計時從模型已啟動後送出請求開始，不包含容器啟動或模型載入；也沒有把清空 OS 檔案快取當成測試條件。長鏈任務接續前一輪、能重用快取時要等多久，這次沒有測。〔1、2、3〕
主比較：每次都輸出 8K，先看要等多久
TTFT 是送出請求後，到收到第一段文字的時間；Prefill 是讀取輸入的速度，Decode 是生成回答的平均吐字速度。「全程」包含讀取輸入與輸出完整 8K 的時間。
下表按同一個 Max Context 分組。分子是測試檔位、分母是設定上限：16K～128K 按輸入長度命名，196K／256K 則是連同 8K 輸出、接近該總容量的檔位，不是 196K／256K 純輸入，也不是一律可拿來計算使用率的分數。
| 測試檔位／Max Context | TTFT（秒） | Prefill（tok/s） | Decode（tok/s） | 全程（秒） | Expert 命中率 | PCIe routed |
|---|---|---|---|---|---|---|
| 16K／196K | 8.18 | 2,018.8 | 98.5 | 91.33 | 93.2% | 2.2% |
| 32K／196K | 13.64 | 2,418.5 | 94.0 | 100.72 | 94.0% | 1.7% |
| 64K／196K | 23.66 | 2,785.5 | 89.8 | 114.83 | 92.8% | 2.4% |
| 128K／196K | 44.72 | 2,946.0 | 92.7 | 133.06 | 95.4% | 1.0% |
| 196K／196K | 66.81 | 2,895.9 | 95.3 | 152.75 | 95.2% | 1.2% |
| 16K／256K | 8.22 | 2,009.7 | 90.9 | 98.30 | 91.1% | 3.2% |
| 32K／256K | 13.70 | 2,408.0 | 92.3 | 102.45 | 94.3% | 1.6% |
| 64K／256K | 23.72 | 2,778.9 | 84.5 | 120.63 | 91.7% | 2.9% |
| 128K／256K | 44.85 | 2,937.5 | 89.2 | 136.68 | 94.3% | 1.5% |
| 196K／256K | 66.68 | 2,902.5 | 81.9 | 166.63 | 89.6% | 4.2% |
| 256K／256K | 89.16 | 2,862.5 | 83.0 | 187.82 | 93.4% | 2.0% |
主表共 11 次請求，全部實際輸出 8,192 tokens，沒有前綴快取命中。16K～64K 是 10/7 補測，其餘是 10/6 的長上下文測試，沒有把 1K 輸出的結果混入主比較。〔1、2〕
精確輸入為：16K＝16,384、32K＝32,768、64K＝65,536、128K＝131,072 tokens；196K 檔位＝192,504，256K 檔位＝253,944 tokens。後兩者加上 8,192 output 和 8-token safety slack，剛好等於 200,704、262,144。PCIe routed 是引擎回報的 routed experts 比例，不是 PCIe 頻寬使用率或 OS swap 比例。
相同輸入，上限開大幾乎沒有多等
五個能直接對照的檔位，Max 196K 和 Max 256K 的 TTFT 差距都不到 0.14 秒，Prefill 差距都不到 0.5%。這幾次量到的結果是：把上限開大，沒有讓同樣長度的輸入明顯多等。〔1、2〕
等待時間比較有感的差別，來自這次實際送了多少內容：16K 約 8 秒、32K 約 14 秒、64K 約 24 秒、128K 約 45 秒、196K 檔位約 67 秒，接近 256K 總容量則約 89 秒。 這些都是沒有重用前綴的等待時間，不代表 Agent 每一輪都要等這麼久。
Prefill 隨輸入變長，先升高、再大致持平
兩個設定都呈現相近的結果：16K 約 2,000 tok/s，32K 約 2,400，64K 約 2,780，到了 128K 以上大致落在 2,860～2,950 tok/s。因此，較短輸入的平均讀取速度比較低，但因為內容少，首字仍然更早出現。〔1、2〕
這組數據顯示的是平均吞吐隨輸入長度的變化；測試沒有拆解每個內部階段的耗時，還不能據此確認是哪些固定開銷或排程機制造成。
吐字速度有代價，不能說 256K 完全免費
相同輸入、同樣輸出 8K 的五組比較中，Max 256K 的 Decode 都比 Max 196K 低，差距約 1.8%～14.1%。例如 32K 從 94.0 降到 92.3 tok/s，差得不多；196K 檔位則從 95.3 降到 81.9 tok/s，差得比較明顯。〔1、2〕
196K 檔位在 Max 256K 下也同時出現較低的 expert 命中率（95.2% → 89.6%）與較高的 PCIe routed 比例（1.2% → 4.2%）。這些值得一起看，但每組只有一次，而且生成內容、MTP 接受率也可能不同，不能把差距全部歸因於某一項因素，也不能把 14.1% 當成固定損失。〔1〕
最高那組 253,944 prompt＋8,192 output 仍完整跑完：約 1 分 29 秒開始回答，平均 83.0 tok/s，全程約 3 分 8 秒。 這是接近完整 256K 預算的結果；沒有額外留給下一輪工具結果或歷史增長的空間。〔1〕
補充：同樣輸入，1K 與 8K 輸出差多少？
短上下文最初也測過只輸出 1K 的版本，這裡一起保留。兩輪沿用相同 prompt，request 只改了 max_tokens：1,024 → 8,192；兩輪各組都實際輸出到設定上限，沒有前綴快取命中。〔2、3〕
下表每格都是「1K 輸出 → 8K 輸出」，粗體為 8K 結果。排列仍先 Max 196K，再 Max 256K。
| 測試檔位／Max Context | TTFT（秒） | Prefill（tok/s） | Decode（tok/s） | 全程（秒） | Expert 命中率 | PCIe routed |
|---|---|---|---|---|---|---|
| 16K／196K | 8.04 → 8.18 | 2,051.4 → 2,018.8 | 78.2 → 98.5 | 21.11 → 91.33 | 86.2% → 93.2% | 5.4% → 2.2% |
| 32K／196K | 13.62 → 13.64 | 2,422.4 → 2,418.5 | 81.7 → 94.0 | 26.12 → 100.72 | 92.0% → 94.0% | 2.4% → 1.7% |
| 64K／196K | 23.62 → 23.66 | 2,791.0 → 2,785.5 | 76.7 → 89.8 | 36.94 → 114.83 | 92.7% → 92.8% | 2.1% → 2.4% |
| 16K／256K | 8.21 → 8.22 | 2,012.7 → 2,009.7 | 77.1 → 90.9 | 21.45 → 98.30 | 86.1% → 91.1% | 5.4% → 3.2% |
| 32K／256K | 13.68 → 13.70 | 2,411.5 → 2,408.0 | 75.3 → 92.3 | 27.24 → 102.45 | 92.5% → 94.3% | 2.1% → 1.6% |
| 64K／256K | 23.70 → 23.72 | 2,781.3 → 2,778.9 | 74.1 → 84.5 | 37.49 → 120.63 | 91.8% → 91.7% | 2.5% → 2.9% |
1K 輸出資料來自前輪短上下文測試，8K 為本輪補測；兩者不是同一次回答的前 1K 與完整 8K 分段統計。〔2、3〕
開始回答的等待幾乎相同，平均吐字速度則不同。 這六組的 TTFT 只差約 0.01～0.14 秒；Prefill 除了 16K／196K 約差 1.6%，其餘差異都在 0.2% 以內。8K 輸出的平均 Decode，則比 1K 輸出高約 14%～26%。
不過，這不代表 1K 的數據不準，也不能直接說輸出越長一定越快。例如 64K／196K 的 expert 命中率幾乎沒變（92.7% → 92.8%），Decode 卻從 76.7 升到 89.8 tok/s；同時 MTP 接受率由約 73.0% 升到 90.2%。平均速度反映的是各自整段生成過程，報告不足以把差異全歸因於暖機。〔2、3〕
所以 8K 主表用來比較相同輸出長度下的兩種 Max Context；1K 對照則保留給較短回覆的速度參考。8K 的每秒吐字較快，不表示整次回答更早結束——它的輸出量畢竟是八倍，「全程」欄也把這個差別列出來了。
Context 開大後，記憶體差多少？
| 項目 | Max 196K | Max 256K |
|---|---|---|
| GPU0 常駐 expert slots | 4,736 | 4,540 |
| GPU1 常駐 expert slots | 3,764 | 3,487 |
| 兩卡合計 | 8,500 | 8,027 |
| Expert cache 合計 | 約 16.05 GiB | 約 15.14 GiB |
| Prefill chunk | 8,192 | 8,192 |
| 系統可用 RAM 最低值（長上下文測試） | 7.27 GiB | 7.25 GiB |
| GPU0 顯存峰值（長上下文測試） | 15,543 MiB | 15,543 MiB |
| GPU1 顯存峰值（長上下文測試） | 15,670 MiB | 15,676 MiB |
上表沿用 10/6 長上下文報告的常駐數量及資源紀錄。常駐 expert slots 合計少了 473 個，約 5.6%，expert cache 約少 0.91 GiB。兩組 auto split 都相同：GPU0 跑第 0～22 層，GPU1 跑第 23～47 層；prefill chunk 也都維持 8,192。〔1〕
這裡的 slots 是各層的 expert 快取位置，不能把容量比例直接當成命中率。系統可用 RAM 看的是整台主機的 MemAvailable，不是 Strata 單一程序的用量。
本次短上下文＋8K 輸出，請求期間最低仍有約 7.6～8.0 GiB 可用 RAM；前輪長上下文最低約 7.25 GiB。兩批 8K 輸出測試的正式請求期間，都沒有新增 swap-out、OOM、direct reclaim 或 allocstall。〔1、2〕
部分組別有背景記憶體掃描與短暫等待；短測的 memory PSI full avg10 最高為 2.20%，所以不能說完全沒有記憶體壓力。但紀錄沒有顯示持續 swap thrashing 或明顯本機 shell 卡頓。這些是全主機指標，不能全部算在 Strata 頭上，也不等同測過遠端 SSH 延遲。〔2〕
啟動載入則要另外看：256K 啟動時確實出現大量記憶體回收與配置等待，196K 前輪啟動也有類似現象。請求跑起來之後的表現，不代表載入那段時間同樣輕鬆。 兩張卡的顯存也都很滿。〔1〕
實測啟動參數
使用 Strata v0.1.40.1（engine 0.1.40），Docker image 針對 SM120 編譯，包含 vision 支援。兩個設定共用同一套 IQ3_S 的兩個 GGUF shard、Strata pack、rt MTP、BF16 mmproj 與 expert profile。〔4〕
以下只列主要參數，供讀者或 Agent 對照；不是完整啟動指令或完整設定檔。模型與其他檔案路徑依各自環境補上。
Docker 參數節錄：
--gpus all \
--ipc=host \
--ulimit memlock=-1:-1 \
--restart=no
實測容器直接啟動 serve.server、讀取 Strata JSON，沒有透過預設 installer 重新產生配置。JSON 的主要設定如下，省略模型與其他檔案路徑：〔4〕
{
"gpu": [0, 1],
"layer_split": "auto",
"parallel": 1,
"args": [
"--expert-cache", "auto",
"--prefill", "auto",
"--spec", "4",
"--spec-min-p", "0.5",
"--max-context", "200704",
"--kv", "int8",
"--vision",
"--vram-reserve-mib", "700"
],
"vision": {
"gpu": true,
"max_tokens": 1024
}
}
Max 196K 使用 200704，Max 256K 改成 262144，其餘推理設定相同。 兩種 profile 二選一啟動，不同時載入。未額外設定 kv-resident，也未開啟 LOW_RAM 或 stage trim。vision.max_tokens=1024 是圖片 token 設定，不是文字輸出長度。〔4〕
兩組最後都由 auto 選到 GPU0 第 0～22 層、GPU1 第 23～47 層，prefill chunk 為 8192。這些是啟動後量到的結果，不是手動鎖定的參數。〔4〕
測試請求設定
Temperature、thinking 和文字輸出長度另外放在 API request，不是 Docker 參數。主比較使用以下設定；補充的 1K 輸出測試只將 max_tokens 改為 1024：〔4〕
{
"stream": true,
"stream_options": {"include_usage": true},
"max_tokens": 8192,
"temperature": 0,
"seed": 160841,
"chat_template_kwargs": {"enable_thinking": false},
"reasoning_effort": "none",
"reasoning_budget_tokens": 0
}
每次核對實際 token 數，確認 cached_tokens=0、cache_n=0。本文的 prefill 是沒有重用前綴快取的完整 prompt 處理；容器啟動與模型載入時間不算在 TTFT 裡。〔1、2、3、4〕
這份數據能說明到哪裡
這次用中性記錄與長篇清單測試，不是真實 Agent 任務。主表的輸出長度已統一為 8K，1K 另外列作參考；但每個條件只有一次，不同檔位的輸入內容和生成路徑仍可能不同。這不是能隔離所有變因的統計 benchmark，也沒有驗證長文理解正確率、圖片處理峰值或長時間連續運作。
目前這套 5900X＋64GB RAM＋雙 5060 Ti 16GB，已實際完成從 16K 輸入到接近 256K 總預算的單請求測試。以 8K 輸出主表來看，Max 196K 的 Decode 約 90～99 tok/s，Max 256K 約 82～92 tok/s；相同輸入的首字等待幾乎不變，吐字速度則有不同程度的下降。〔1、2〕
對想替長鏈任務多留上下文空間的人，這份資料提供的是兩件具體資訊：更大的上限能實際用到哪裡，以及換到這些空間時，讀取等待與吐字速度各付出了多少代價。至於反覆工具呼叫、快取重用與真正長鏈任務的表現，不在這次測試範圍內。
數據與設定來源均為本機測試紀錄：
〔1〕2026-10-06《Strata 0.1.40.1 Vision ON：196K 與 256K 單請求測試》。
〔2〕2026-10-07《Strata 0.1.40.1 Vision ON：16K／32K／64K＋8K Output 測試數據》。
〔3〕2026-10-07《Strata 0.1.40.1 Vision ON：16K／32K／64K 測試數據》（1K output）。
〔4〕《Docker 啟動方式：Strata 0.1.40.1、Vision ON、196K／256K》（依實測容器、設定檔與啟動紀錄整理）。
RAM 速度與 PCIe 插槽配置依本機硬體資料補充。