Strata 雙卡 RTX 5060 Ti 16GB Qwen3.8-Flash-Next ：196K／256K 長 Context 實測
-
雙 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 插槽配置依本機硬體資料補充。
-
-
-
-
@johnnybegood 抱歉，18k台幣，我的數學是體育老師教的
-
-
-
-
-
-
-
-
-
-
RTX 5070 Ti 16GB 方案才是最有性价比
這是因為Nvidia 的產品規劃有問題
RTX 5080 和 RTX 5070 Ti 共用 GB203晶片, 一樣都是16GB VRAM 但5080價格差異不少(!?) ; decode 卡在 VRAM 頻寬只差異 7%
不過看網站Qwen3.6-Flash-Next (QFN) 的數據資料還不夠多, 後期排名應該會改變,
以打遊戲來說 當然要選 RTX 5080; 以VRAM來說就選 5060 Ti 16GB, 我看"yu
" 的數據跑分 QFN應該會是最有性价比, 但要依靠使用者們去上載測試數據 就會變第一了ChatGPT : RTX 5080 vs RTX 5070 Ti — GB203 GPU 規格比較
兩張顯卡均採用 NVIDIA Blackwell GB203 GPU，RTX 5070 Ti 為停用部分運算單元的版本。
GPU Specification Comparison
規格 (Specification) RTX 5080 RTX 5070 Ti 5080 優勢 GPU Die GB203 GB203 相同 Architecture Blackwell Blackwell 相同 SM 數量 84 70 +20% CUDA Cores 10,752 8,960 +20% Tensor Cores (5th Gen) 336 280 +20% RT Cores 84 70 +20% VRAM 16GB GDDR7 16GB GDDR7 相同 VRAM Bus 256-bit 256-bit 相同 VRAM Speed 30 Gbps 28 Gbps +7.1% VRAM Bandwidth 960 GB/s 896 GB/s +7.1% L2 Cache 64 MB 48 MB +33.3% Boost Clock 2,617 MHz 2,452 MHz +6.7% FP32 Compute 56.3 TFLOPS 43.9 TFLOPS +28.2% AI Performance 1,801 TOPS 1,406 TOPS +28.1% TGP 360W 300W +20% 功耗 PCIe 5.0 x16 5.0 x16 相同 Local LLM Inference Analysis
1. Decode Performance (TG)
- RTX 5080 記憶體頻寬比 RTX 5070 Ti 高 7.1%。
- 對 Memory Bandwidth-bound Decode 工作負載，
理論優勢主要來自 VRAM Bandwidth。 - CUDA Cores 增加 20%，不代表 TG 增加 20%。
2. Prefill Performance (PP)
- RTX 5080 SM 數量增加 20%。
- Tensor Cores 增加 20%。
- FP32 理論算力增加約 28%。
- Compute-bound Prefill 有機會獲得較大的效能提升。
3. VRAM Capacity
- 兩款均提供 16GB GDDR7。
- 單卡模型權重與 KV Cache 容量基本相同。
- RTX 5080 不具備 VRAM 容量優勢。
Conclusion
比較項目 RTX 5080 相對優勢 SM / CUDA / Tensor Cores +20% FP32 Compute +28.2% VRAM Bandwidth +7.1% VRAM Capacity 0% L2 Cache +33.3% TGP +20% 結論：
RTX 5080 具有明顯的運算能力優勢，
但 VRAM Bandwidth 僅比 RTX 5070 Ti 高 7.1%。對 Memory Bandwidth-bound 的 Local LLM Decode，
RTX 5070 Ti 可能提供更好的 Price/Performance。以上為硬體規格推導，並非實際 LLM Benchmark 數據。
