本地AI的隱形殺手：我們如何用32K上下文干掉Gemma的沉默bug

兩天前，Gemma 4還寫不完一個功能。今天它獨立完成搜索模塊，推送到GitHub，現在已經在這篇文章的頁面上線運行。

按下?K（或Ctrl+K），你會看到vibescoder.dev的搜索彈窗——純本地RTX 5090運行，零云API調用，零成本。Claude只負責代碼審查和潤色。這是一個本地模型與云端模型各司其職的協作樣本。

轉折點來自一次失敗的對比實驗。我們讓Gemma 4與Opus 4.6同臺競技：為博客開發公開搜索功能。Opus 4.6一次性完成——698行代碼橫跨6個文件，8分鐘內提交推送。Gemma 4的規劃堪稱精彩，然后戛然而止。八輪提示后產出：3個半成品文件，0次提交。

我們稱之為"智能體鴻溝"：能寫代碼的模型，與能交付功能的模型之間的差距。但遺留了一個未解之謎：Gemma或許并非拒絕編碼，而是空間耗盡。

深度排查揭示了根源：隱形思考token正在吞噬生成預算。

Gemma 4默認啟用推理模式，在輸出可見內容前生成思維鏈token。這些思考token被隱藏——用戶永遠看不到——但仍計入num_predict限制。Ollama的默認配置下，模型把全部token預算耗盡在推理環節，實際代碼輸出為零。

這不是模型故障，是配置故障。

紙面修復方案簡單：擴大預算。但實現路徑需要更換整套推理棧。

Ollama擅長拉取和運行模型，卻不擅長精細控制。關鍵需求包括：--reasoning-budget參數，用于封頂隱形思維鏈的token消耗，強制模型在觸及限制后轉向實際內容輸出。Ollama完全沒有對等功能。

遷移過程充滿波折。Ollama的blob文件無法直接使用——llama.cpp需要標準GGUF格式，而Ollama采用獨立工具無法加載的分割存儲。我們從Hugging Face拉取完整Gemma 4 26B-A4B GGUF（unsloth/gemma-4-26B-A4B-it-GGUF，Q4_K_M量化，16.9GB下載），以調優參數啟動llama-server：

~/llama.cpp/build/bin/llama-server -m ~/models/gemma4-26b/gemma-4-26B-A4B-it-UD-Q4_K_M.gguf --ctx-size 32768 -n 32768 --reasoning-budget 4096 --reasoning-format deepseek --parallel 1 --host 0.0.0.0 --port 8080 -ngl 999

隨后將Coder指向新端點。提供方基礎URL從Ollama的localhost:11434切換至llama-server的localhost:8080/v1/，模型配置填入完整GGUF文件名，上下文與輸出限制設為32K。

首次嘗試并未成功。