兩天前,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。
首次嘗試并未成功。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.