Strata 越跑越慢，最讓人困惑的情況，是第一段回答很順，切換幾個 Agent、累積長對話之後，等待卻愈來愈久。你看到顯卡還有空間，便想加大快取；但真正被擠滿的，可能是系統 RAM，也可能是對話切換時重新讀取的提示詞。
這篇寫給已經讓 Strata 跑起來、卻不熟悉效能排錯的讀者。以 Qwen 路線、8GB VRAM＋32GB RAM 的資源限制為問題情境，帶你做一張可反覆填寫的監控紀錄，分辨逐一執行、停放 Session 與真並行。這是依官方文件整理的診斷方法；本文未在該硬體重跑，沒有自己的速度成績。
截至 2026 年 10 月 31 日，官方最新發布為 App 0.2.8，Control 與引擎套件為 0.1.54。下面的快取設定針對該版 Qwen 引擎；DeepSeek 使用另一條引擎路徑，請勿直接套用。
先說結論：能啟動、短測快、長跑穩，是三張成績單
端到端耗時＝排隊＋讀取提示詞＋生成回答＋工具執行。這是排錯時用的拆解：若工具與生成重疊，要在時間線上標示重疊，不能把重疊區間重複加總。只盯生成的 tokens/s，很容易漏掉前面長長的一段等待。
先把並行降到一個活動請求，留下穩定基準；再測 A→B→A 的停放切換；最後才在有資源餘裕時增加並行。停放像把工作簿收進抽屜；並行像同時攤開多本工作簿。抽屜放得下兩本，不代表桌面能同時處理兩本。
Strata 越跑越慢：先分清三種「快取」
VRAM 是顯卡旁邊的工作桌，RAM 是電腦的暫存空間，SSD 是儲存檔案的櫃子。Strata 的專家快取，決定模型哪些專家權重待在較快的位置；KV Cache，則保存模型讀過對話後的中間狀態。兩者占用的容量與用途不同。
第三個是 Conversation Cache（對話停放快取）。依官方 Qwen 文件，它把對話快照放在有上限的主機 RAM 裡，供交替請求恢復歷史，並非讓請求同時執行。快照本身增加的是 RAM 占用；恢復後的活動工作仍要使用引擎資源。
所以「快取調大」至少有三種意思。當你增加停放容量，可能減少重讀，卻也拿走作業系統與模型其他部分的空間。減少重讀的收益，要和多占 RAM 的代價一起驗收。
六步定位 Strata 越跑越慢的原因
①「先封存配方」：固定版本、模型與任務
昨天正常，今天變慢，究竟換了什麼？先用固定配方把問題縮小。保留啟動設定、App／Control／引擎版本、模型量化檔完整名稱與檔案雜湊，以及 Context 上限、MTP、KV 格式、並行數、工具與背景程式狀態。
已有 Terminal 的讀者可先執行 strata status --output json，再執行 strata monitor --once --output json，把狀態與監控快照存到自己的測試資料夾。版本資訊也要對照啟動日誌；App 的版本號不等於引擎號。這些指令用法可見官方 Terminal 說明。
任務選一個可核對答案的小型工作，例如讀固定的測試檔、透過已配置的讀檔工具取回內容，再用繁中輸出指定 JSON 欄位。把檔案、提示詞與期望答案保存，使用測試資料與限制範圍的工具權限。每輪沿用同一套輸入；若要測歷史增長，再明確標出每輪新增了什麼。
②「一起看四個儀表」：顯存、RAM、Swap 與磁碟
畫面停住時，GPU 使用率低就代表模型太小嗎？先用同步監控找出它在等什麼。瀏覽器 Monitor 可對照服務的 /metrics，其中 conversation_cache 區塊提供停放與重用資訊。Terminal 使用同一服務的監控資料，但其標準化快照不必包含 /metrics 的全部欄位。
欄位也要分種類：parked 與 bytes 是目前停放數與占用量；parks、restores、evictions 是累計事件，應在同一引擎執行期間記每輪前後差值。重啟後另開紀錄；last_reused／last_prompt 才對應最後一個請求，別把累計重用量當成這一輪省下的工作；欄位可對照該版服務實作。
Linux＋NVIDIA、且已有以下工具時，可以分別開三個終端視窗：nvidia-smi --query-gpu=timestamp,name,memory.used,memory.total,utilization.gpu,temperature.gpu --format=csv -l 1；vmstat -w -t 1；iostat -xz -y -t 1。用重新導向把各自輸出存檔，完成後按 Ctrl+C。第一條依NVIDIA 官方介面讀取 GPU；不支援的欄位可能顯示 N/A。
vmstat 的 si／so是換入／換出速率；先略過第一筆開機至今的平均值。Swap 已用容量大，與當下持續換頁，是不同訊號。iostat則幫你對照裝置讀取與等待；它是系統層資料，還要排除其他程式的磁碟活動。
Windows 可在工作管理員的「效能」分別觀察 GPU、記憶體與磁碟，再用資源監視器核對程序活動。不要把上述 Linux 指令直接貼進 Windows；這次比對的重點是相同時間點的資源變化。
③「先讓一個人做完」：建立逐一執行的基準
兩個 Agent 都慢，該先救哪個？用單活動請求拿掉競爭因素。先停好手邊任務，列出預設組態：strata launch --list-presets。將你的既有 preset 名稱代入 strata launch --preset "你的預設名稱" --parallel 1 --set conversation-cache-mib=0 --tune skip --access local --plan，先看啟動計畫。
確認模型檔已在本機、計畫沒有額外下載後，移除 --plan 才啟動。若同埠已有不同設定在服務，先結束任務，再使用 --restart；它會中止進行中的回答。官方 launch 規則說明，覆寫只影響這次啟動；本文刻意不加 --save-preset，方便回到原組態。
同一輪只送一個請求，完成才送下一個，並把冷啟動與暖機後分開記。這裡關閉的是對話停放容量；引擎仍可能重用活動對話或其他提示詞檢查點，因此不能把這個條件叫作「所有快取全關」。驗收結果是你得到一條可比較的基線，並非預期它一定最快。
④「收起再打開」：用 A→B→A 驗證停放恢復
開兩個聊天視窗，怎麼知道有沒有吃到快取？用交替續聊建立可觀察的切換。保持 --parallel 1，移除前一步的 --set conversation-cache-mib=0，其他條件沿用。只有原 preset 與底層設定也未明確指定快取容量時，才會使用自動容量；若原本有指定值，就先記錄該值。重新啟動後以日誌確認實際容量，依序完成 A 的回答、完成 B 的回答，再把 A 的完整歷史原樣送回續聊。
觀察日誌的 parked、restored、evicted，以及 prompt N tokens = X reused + Y read。三個請求刻意不重疊：你測的是換回舊工作時少讀多少內容。若換回 A 仍重讀很多，檢查提示詞前綴是否改了、快照是否超出容量、RAM 底線是否阻止停放，以及是否發生淘汰。
找日誌時，--no-tui 啟動完成會列出 Engine log 路徑，也可查看這次 run config 的 log 欄位。用文字檢視器開啟該檔；strata logs 顯示的是請求活動摘要，不能把它當成完整的引擎記憶體日誌。
目前官方預設在模型載入後，以高於 RAM 底線的餘裕估算快取：取其中 40%，最多 8192 MiB，按 256 MiB 級距計算，小於 1024 MiB 時關閉；conversation-cache-min-free-mib 預設為 2560。這些是容量規則，不是建議 32GB RAM 電腦直接分配 8GB。用啟動日誌確認這次實際採用的值。
⑤「一次只轉一顆旋鈕」：分開測 RAM、VRAM 與停放容量
重讀很多就把快取加大？先採單變量調整。在原本可運作的設定上，一次只改一項，重跑同樣的 A→B→A，最後再回到原設定確認變化可重現。三個方向各有交換：
- RAM 餘裕：
--set STRATA_RESIDENT_HEADROOM_GIB=6是把 resident 模式預留空間改成 6 GiB 的語法示例，不是通用推薦值。預留更多可能減少常駐權重，讓檔案讀取增加；應一起核對 resident／mapped 模式與日誌中的檔案讀取。 - VRAM 餘裕：
--set vram-reserve-mib=900示範預留 900 MiB。它保留顯存給其他工作，也可能減少引擎可用的容量；不要直接照搬別人的最小值。 - 停放容量：
--set conversation-cache-mib=1024示範明確限制為 1024 MiB。若降低後換頁減少、切回卻重讀更多，就把兩種成本與端到端耗時一起比較；容量與 slots 也要分次調整。
以上片段接在你原有的 strata launch --preset "你的預設名稱" 後，先加 --plan 檢查；正式改設定前先結束現有任務。RAM 預留、VRAM reserve、停放快取是不同旋鈕。數字只是示範可辨認的調整，不是本文在該硬體驗證過的最佳組合。
⑥「最後才同時開工」：真並行要看每個任務的完成時間
停放切換穩定後，才考慮並行驗收。資源仍有餘裕、單請求也穩定時，用相同 preset 的 --parallel 2 做啟動計畫。正式啟動後，先確認 /v1/status 的 concurrency.serving 至少為 2；這是實際可服務的容量，不是當下活動數，請求值也可能被引擎縮小。再讓客戶端同時送出 A 與 B，保存請求開始、首 token、結束的時間線，配合引擎活動確認重疊。容量只有 1 時，同時送出仍可能只是在排隊。
比較兩個任務各自等多久、一起完成需要多久、工具有沒有成功，以及答案有沒有變差。總吞吐增加與單人等待變長可以同時發生。若記憶體餘裕不足，就保留單活動請求與停放切換；這一輪不必硬跑真並行。
把症狀變成一張可重跑的監控紀錄
在試算表建立這些欄位：輪次、模式、版本、量化檔、Context、開始時間、首 token 時間、結束時間、提示詞重用／重讀、VRAM 峰值、可用 RAM 最低值、Swap 換入／換出、磁碟讀取、工具成功、繁中答案通過。不知道的欄位填「未取得」，不要把空白當成零。這張紀錄是待填的測試設計，並非已完成的測速報表。
例如你的任務是核對測試檔中的產品名稱：A 先讀清單，B 讀另一份說明，最後 A 回來回答。若 A 的生成速率相近，首 token 卻變晚，同時重讀 token 增加，先沿快照恢復這條線查；若 A 持續生成也變慢，且換頁與磁碟等待一起升高，則優先查整機記憶體壓力。這是判讀路徑，不是已測得的因果結論。
再加一道品質檢查：產品名稱是否逐字一致、JSON 欄位是否完整、工具結果是否真的被使用、繁中是否遵守指定用語。長任務可能出現重複生成、工具重試或前綴改寫；看到慢，不要直接把所有原因都歸給 SSD。
社群失速回報該怎麼用？先當線索，再找自己的證據
題目來自這則低顯存使用回報。作者列出的環境是 Linux、RTX 5060 Laptop 8GB 與 32GB RAM；後續換成 Gyro M 後，自述跑 Agent 一段時間出現 RAM／SSD 壓力，生成降到每秒 1–2 token，並表示仍在調查。這是作者的觀察，沒有足夠證據把同一根因套用到你的電腦。
版本也會影響品質判讀。0.2.8 發布說明記載，12GB 以下 RTX 曾使用的 routing 加速，因長對話重複文字回報而恢復較保守的預設。這說明回歸測試要同時看答案與速度；本文不建議為追求短測速度而先啟用那項加速。
你可以先定自己的停止條件：系統操作明顯失去回應、持續換頁且任務耗時惡化、工具錯誤增加，或答案開始循環，就結束這輪。先降 Context、減少活動請求或停放數，再回到已保存的組態重跑。每次只改一項，才能知道是哪一項帶來差異。
常見問題：八個先釐清的判斷
1. 8GB VRAM＋32GB RAM，一定能穩定跑 Agent？
不一定。量化檔、Context、工作集、其他程式與工具負載都會改變資源需求。把能啟動與連續完成實際任務分開驗收。
2. 停放兩個 Session，等於兩個 Agent 同時執行？
不等於。官方把 Conversation Cache 定義為保存歷史供交替恢復；並行還需要活動請求重疊。看客戶端時間線與引擎狀態，不能只看視窗數。
3. RAM 用滿，就是記憶體洩漏？
不能僅靠這一項判定。先分出模型常駐資料、對話快照與檔案快取，再看相同工作循環結束後的可用記憶體趨勢與程序占用。
4. Swap 已使用，就代表目前在瘋狂換頁？
不一定。已用容量是存量；Linux 的 si／so 才幫你觀察當下的換入／換出。對照時間線與磁碟資料再判讀。
5. Conversation Cache 愈大愈快？
要看整體交換。它可能留住更多歷史，也占用更多 RAM。比較切回重讀量、可用 RAM 與整個任務耗時，才知道該留多大。
6. 換量化檔後，可以直接與舊速度比較？
要分開標示。你同時改了模型表示與資源需求；先固定量化檔排查，再把另一個檔案當成新的測試條件，重做品質與效能驗收。
7. 改過參數，重送指令就一定已生效？
先看正在服務的組態。launch 可能沿用既有服務，或在設定衝突時拒絕啟動。結束進行中的任務、按需要重新啟動後，再核對日誌與狀態。
8. 該先買更快 SSD，還是加 RAM？
先完成監控紀錄。若主要在重讀提示詞，先查快照；若工作集與換頁造成等待，才評估容量；若檔案讀取成為瓶頸，再研究儲存裝置。讓證據決定下一筆成本。
給新手的三個重點
- 先做一個穩定任務：把單請求、停放切換、真並行分成不同條件。
- 一次看完整時間線：重讀、生成、工具與等待都要入帳，品質檢查也要保留。
- 一次只改一項：留存原組態，能退回，才能證明調整的效果。
接著閱讀
左右滑動查看更多推薦
下一步：先完成 A→B→A，再決定要不要並行
記住那個比喻：停放是抽屜，並行是桌面；端到端耗時才是你真正付出的等待。今天先保存一份原設定、選一個固定任務，記錄第一次 A→B→A 的重用與重讀。等你能解釋等待發生在哪一段，再調整下一顆旋鈕。想繼續建立系統化的 AI 工作流程，可以從 AI 教學專區接著學，或查看 AlphaLab 課程。