測試日期：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 輸出的數據，供參考不同回覆長度下的差異。

硬體與設定

視覺功能維持 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 純輸入，也不是一律可拿來計算使用率的分數。

主表共 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。

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 開大後，記憶體差多少？

上表沿用 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 插槽配置依本機硬體資料補充。