先說清楚身分，免得被當成來打廣告的：我是 LibreDB Studio 的維護者之一，那是一個 MIT 授權的開源資料庫 IDE。下面的數字都是我們自己連續跑了 11 天測出來的，不是抄文件。

我們踩到的

為了搞清楚小參數的開源模型到底能不能驅動 Agent，我們把 39 個開源權重模型全部走 Ollama 跑在本地，6 類任務，總共 8,199 次執行。

中間有一批資料被污染了，回頭複查才找到原因：

不限制 context 長度的時候，一個 7.1 GB 的模型會照它完整的 262,144 token 視窗去要記憶體，在一台 64 GB 的機器上實際佔到 51 GB。

最難受的不是佔得多，是日誌裡看不出來。你只會看到一次沒跑完的執行，和「模型逾時」長得一模一樣，沒有 OOM，也沒有明確的錯誤訊息。我們早期有一批評測結果就是這樣廢掉的。

把 num_ctx 固定到 32,768 之後，同一個模型掉到 5.1 GB，而且有一個 3B 模型的某類任務直接從 0/5 變成 5/5。也就是說，我們本來以為「這個模型不行」，其實是記憶體被 context 吃光了。

想請教的

1. 你們在本地跑模型的時候，怎麼給 context 長度定上限？按記憶體比例算，還是固定值，還是按任務類型分檔？有沒有一條能用的經驗公式？

2. 有沒有辦法在執行前就判斷「這個設定會不會爆記憶體」，而不是跑掛了再回頭查？我們現在是跑之前先粗算一遍，但算得很粗。

3. 這種「看起來像逾時、其實是記憶體」的狀況，你們一般怎麼在日誌裡分辨？我們現在是額外記一筆記憶體取樣，但總覺得有更省事的作法。

完整資料、評分腳本和論文都公開了：https://arxiv.org/abs/2609.21341

如果你們也在本地跑模型做評測，這一條值得回去翻一下自己的資料，我們就是這樣發現的。