THINK BIG
本地 AI · 上下文長度 · 記憶體管理
AI 的「記憶」設太大，反而把整台電腦拖垮——上下文長度要怎麼抓
本地 AI 越用越慢、整台電腦跟著卡，除了顯卡沒用上，另一個常見原因是上下文長度設得太大。打 ollama ps 看 PROCESSOR 和 CONTEXT 兩欄，就能知道模型實際用了多少上下文、有沒有被擠到 CPU。
（本文以開源工具 Ollama 為例，因為它的官方文件把預設值和檢查方式寫得很清楚；其他本地執行工具原理相近，設定名稱不同。）
這篇和本報第 2 期〈本地跑大模型，GPU 真的有在動嗎？〉是一組。第 2 期講「模型根本沒用到顯卡」；這篇講另一種情況：顯卡有在用，但上下文設太大，記憶體被吃光。兩個問題都從同一個指令開始查。
一現象：上下文長度也要佔記憶體
上下文長度，白話說就是 AI 回答時一次能帶著的內容量，單位是 token。Ollama 官方文件的定義是：模型在記憶體中可以取用的最大 token 數。[2]
這個數字不是免費的。官方文件寫明，把上下文長度設大，執行模型所需的記憶體也會增加，調大之前要先確認顯示記憶體（VRAM）夠用。[2] FAQ 也提到，同時處理多個請求時，所需記憶體會隨「並行請求數 × 上下文長度」放大；並行請求數的預設值是 1。[1]
預設值要特別留意。Ollama 的 FAQ 寫的是預設 4096 個 token。[1] 另一頁〈Context length〉則寫成依顯示記憶體分級：小於 24 GiB 為 4k，24 到 48 GiB 為 32k，48 GiB 以上為 256k。[2] 兩頁寫法不同，我們的做法是不靠記憶推斷，直接用 ollama ps 看 CONTEXT 欄，以機器實際配置的數字為準。[2]
調整方式官方也寫得很清楚：要改整台服務的預設值，用環境變數 OLLAMA_CONTEXT_LENGTH；只改單一模型或單次對話，在指令列用 /set parameter num_ctx，或在 API 的 options 裡帶 num_ctx。[1]
二各方評價：要大，還是要穩？
主張開大的一方：Ollama 的〈Context length〉頁建議，網頁搜尋、AI Agent、程式工具這類需要大量上下文的任務，至少設到 64000 個 token；同一頁也說，為了最佳效能，可以用模型支援的最大上下文長度，並避免模型被卸載到 CPU。[2]
提醒成本的一方：同樣是官方文件，FAQ 說明可以開 Flash Attention，在上下文變大時明顯降低記憶體用量；也可以把 K/V cache（存放上下文的暫存區）量化，q8_0 約用 f16 一半的記憶體，q4_0 約四分之一，但精度損失在上下文越大時可能越明顯，影響多少要看模型和任務。[1]
兩邊其實不衝突。官方的前提一直是「機器放得下」：上下文可以開大，但要先算記憶體夠不夠，並確認模型沒有被擠到 CPU。[2]
三、我們實際做的時候的心得
以下是我們部署本地 AI Agent 時的實作觀察，不是產業統計，也不代表任何特定案場。
1. 「AI 越來越慢，是不是顯卡太舊？」是常見的問題，但常見的答案是設定。我們常遇到的情況是：有人為了讓 AI「記得多一點」，把上下文一口氣拉到很高，結果記憶體放不下，模型部分跑到 CPU，回應時間明顯拉長。
2. 統一記憶體的機器要更小心。顯示晶片和系統共用同一塊記憶體的電腦，上下文吃掉的不只是「顯卡的份」。我們常見的症狀有三個：回應時間越拉越長、整台電腦操作變遲鈍、硬碟開始大量寫入交換空間（swap）。這時候慢的不只 AI，其他程式也一起被拖住。
3. 先查需求，再定數字。我們不在一開始就給一個固定數字。比較穩的順序是：先跑幾個真實工作，看每次實際送進去多少 token，再決定上下文要留多少餘裕。Ollama 的 API 回應會附 prompt_eval_count（這次輸入了多少 token），拿來當依據就夠了。[3]
4. 交付前看 CONTEXT 和 PROCESSOR 兩欄。ollama ps 的 PROCESSOR 欄會顯示 100% GPU、100% CPU，或兩者的比例；[1] CONTEXT 欄顯示實際配置的上下文長度。[2] 我們交付前會把這兩欄截圖留存。
四我們的建議：先做三步
1. 先量，再設。拿你最常做的三到五種工作（例如回客服信、摘要會議紀錄、查內部文件），各跑幾次，記下 prompt_eval_count。[3] 最大值再加上回答需要的空間，就是你的起點。
2. 改完馬上看 ollama ps。PROCESSOR 欄如果出現 CPU 比例，代表模型加上下文已經超過顯示記憶體能放的量。[1] 先把上下文調回來，或評估 Flash Attention、K/V cache 量化，量化後要用你的真實工作再驗一次品質。[1]
3. 並行數和上下文一起看。要讓多個人同時用，記憶體需求是兩者相乘。[1] 先決定同時要服務幾個請求，再回頭定上下文。
一句話：上下文可以開大，前提是機器放得下。放不下的時候，慢下來的會是整台電腦。
先量、再設。設定值要能說出「為什麼是這個數字」。
（以下是 Think BIG 的實作主張，與上方報導區隔。）
我們部署本地 AI Agent 時，上下文長度不是憑感覺填的：依真實工作量定值——用客戶自己的工作內容實測輸入量，再決定上下文與並行數；交付時留證據——ollama ps 的 PROCESSOR、CONTEXT 兩欄截圖，連同設定值一起交給負責人；改設定要重驗——調整上下文、量化或並行數之後，用同一組工作重跑一次，確認速度和回答品質都還在可接受範圍。
我們的立場是：設定值要能說出「為什麼是這個數字」。本報第 13 期將延伸談模型選型，也以同一套邏輯為基礎。
常見問題
- Q1：上下文長度是什麼？
- AI 回答時一次能帶著的內容量，以 token 計算。Ollama 官方定義為模型在記憶體中可以取用的最大 token 數。[2]
- Q2：Ollama 預設的上下文長度是多少？
- 官方 FAQ 寫預設 4096 個 token；〈Context length〉頁則寫依顯示記憶體大小分為 4k、32k、256k 三種。[1][2] 兩頁寫法不同，請用
ollama ps的 CONTEXT 欄確認你的機器實際配置。[2] - Q3：怎麼調整上下文長度？
- 整台服務的預設值用環境變數
OLLAMA_CONTEXT_LENGTH；單一模型或單次請求用num_ctx（指令列/set parameter num_ctx，或 API 的 options）。[1] - Q4：上下文設大一定比較好嗎？
- Ollama 建議 AI Agent、程式工具這類任務至少 64000 個 token，但也說明上下文越大，需要的記憶體越多，要確認顯示記憶體夠用。[2] 我們的建議是先量實際需求，再決定數字。
- Q5：記憶體不夠，又需要較長的上下文，怎麼辦？
- Ollama 文件提到兩個方向：開啟 Flash Attention，以及把 K/V cache 量化（
q8_0約省一半、q4_0約剩四分之一），但量化對品質的影響依模型與任務而定，需要自己實測。[1] - Q6：這跟「GPU 沒在動」是同一個問題嗎？
- 不完全一樣，但查法相同。本報第 2 期談的是模型沒用到顯卡；這篇談的是上下文太大、記憶體放不下。兩種情況都可以先從
ollama ps的 PROCESSOR 欄看起。[1]
[1] Ollama，〈FAQ〉（上下文長度設定、
ollama ps 的 PROCESSOR 欄、OLLAMA_NUM_PARALLEL、Flash Attention、K/V cache 量化），查閱日期 2026-10-24：docs.ollama.com/faq ·
[2] Ollama，〈Context length〉（定義、依顯示記憶體的預設值、Agent 任務建議值、ollama ps 的 CONTEXT 欄），查閱日期 2026-10-24：docs.ollama.com/context-length ·
[3] Ollama，〈Usage〉（API 回應的 prompt_eval_count 等欄位），查閱日期 2026-10-24：docs.ollama.com/api/usage
本文為 Think BIG 產業觀察與第一手實作整理，引用均標註來源。「第一手心得」、建議與編按為 Think BIG 的實作觀點，不作為產業統計或客戶成效證據。