Antigravity SDK 可以在本機跑 Gemma 4

Google 開發者部落格把 Antigravity SDK 的本機模型支援標成 2026 年 9 月 23 日，作者是 Sachin Kotwani 和 Taylor Mullen。值得抄的不是隱私口號，是一條具體路徑：裝 SDK、把 Gemma 4 26B A4B 拉成 LiteRT 檔、用 LiteRTAgentConfig 指到磁碟上的路徑。同一篇裡有一場混合示範的紀錄：雲端花了 95 個 token，3,322 個 token、也就是該次執行的 97.2%，留在機器上。

如果你已經看過API 標價對照，或做過Claude 上下文壓縮的設定，這篇的帳單位置不一樣。那兩篇談的是提示詞離開大樓之後廠商怎麼計價。這篇談的是一條不必離開的路。

硬體那行很容易滑過去，事後又很貴。原文建議機器要有超過 24GB 的 VRAM，或同等的統一記憶體。筆記型電腦若只有 16GB 還要跟螢幕分，步驟可以裝完，26B 不會以你願意等的速度跑完。先停在這句。

9 月 23 日這篇實際加了什麼

原文列出的理由是成本、隱私、離線，以及跟雲端拆開的混合流程。成本指本機那段沒有 API 計費、也沒有速率限制。隱私用他們的說法，是程式碼和請求留在機器上。這對已經禁止把倉庫貼進聊天窗的公司有用。離線是指網路不穩時，代理迴圈還能跑。混合是指雲端模型負責規劃，本機模型碰檔案。

本機 26B 不會在困難的規劃任務上追上前沿雲端模型。原文也沒有這樣講。他們示範的結構剛好相反：Gemini 3.8 Flash 規劃，Gemma 4 26B 在 GPU 上執行。如果你要一個模型兩件事都做，這篇教學的形狀不對。下載權重之前先看混合那一節。

還有第二條入口，原文點了名，但沒把建構式印完整。LocalOpenAIAgentConfig 用來接任何 OpenAI 相容伺服器，例如 Ollama、LM Studio 或 vLLM。部落格說代理的編排、工具和工作流可以維持不變，只換推論後端。我們能乾淨抽出的文字裡沒有建構式參數，這裡不編。他們指的錨點是 Python SDK README 的本機模型一節。走 Ollama 的人看那一頁。這篇只跟 LiteRT 範例，因為那是原文裡有完整檔案的一條。

日期也有落差。索引把這則 URL 標成 9 月 24 日，頁面自己寫 SEPT. 23, 2026。引用以頁面為準。

安裝 Antigravity SDK 和權重

部落格的程式區塊在抽取時換行被黏在一起。反斜線是續行，重複出現的 litert-lm 是下一條指令黏到 pip 那行上。下面是還原，不是第二個來源。你打開原文若旗標不一樣，以原文為準。

先建虛擬環境並啟動：

python3 -m venv .venv
source .venv/bin/activate

再裝 SDK 和下載工具，然後從 LiteRT 社群倉庫匯入 Gemma 4 26B A4B 的 GPU 版。最後一個參數是範例稍後要用的本機別名 gemma4-26b。

pip install google-antigravity litert-lm
litert-lm import \
  --from-huggingface-repo=litert-community/gemma-4-26B-A4B-it-litert-lm \
  gemma-4-26B-A4B-it-gpu.litertlm \
  gemma4-26b

這個別名會影響後面的路徑。範例不會在執行時再去搜尋 Hugging Face，它直接開檔：

~/.litert-lm/models/gemma4-26b/model.litertlm

匯入結束後若這個路徑不存在，不要先怪代理。先查匯入。ls 一下 models 目錄。原文也指向 LiteRT-LM 概述，那是匯入成功、推論卻在安裝程式沒提到的 GPU 上失敗時才需要的頁。這裡不複述。

磁碟是另一個安靜的前提。26B 的 LiteRT 檔不是一個 pip wheel。匯入做到一半死掉，你拿到的不是一份 SDK 會好好解釋的半成品，而是一個偏短的檔和一長串堆疊。開始前先看剩餘空間，結束後再看路徑。

範例檔，包含那個沒被用到的 import

原文要你在專案目錄建 agy_sample.py，貼一段非同步腳本。換行按同一份抽取還原：

import asyncio
import os
from google.antigravity import Agent, LiteRTAgentConfig
from google.antigravity.hooks import policy

MODEL_PATH = os.path.expanduser("~/.litert-lm/models/gemma4-26b/model.litertlm")

async def main():
    print(
        f"Using local LiteRT model: {MODEL_PATH}. "
        "Please wait for local inference to complete. "
        "This could take several minutes."
    )
    config = LiteRTAgentConfig(model_path=MODEL_PATH).lightweight()
    async with Agent(config) as agent:
        response = await agent.chat("What files are in the current directory?")
        async for token in response:
            print(token, end="", flush=True)

if __name__ == "__main__":
    asyncio.run(main())

虛擬環境開著的時候執行 python agy_sample.py。

這個檔有兩個地方，手癢整理之後會跟原文對不上。

from google.antigravity.hooks import policy 在範例裡，但聊天這段沒有呼叫它。你還沒加 hook 的話可以刪掉這行。我留在清單裡，是為了讓你看到部落格交出的樣子，不是一份整理過的分叉。linter 抱怨就刪，這支腳本沒有別的地方依賴它。

.lightweight() 是設定物件上的方法，不是註解。原文把它接在 LiteRTAgentConfig(model_path=MODEL_PATH) 後面。我沒有另一份文件說明它關掉了什麼。不要為了看模型會不會「更好」就先拿掉。第一次執行應跟範例一致，實驗留到你已經看到 token 流出來之後。

提示詞故意很無聊：列出目前目錄的檔案。這是工具呼叫檢查，不是跑分。如果模型靠記憶回答、根本沒看資料夾，你在指向倉庫之前就知道這個版本的習慣。如果它卡在「幾分鐘」，那跟他們印出來的警告一致。一台剛過 24GB 的機器跑 26B，感覺會像程式當住。先給範例要求的時間，再考慮殺掉。

async for token in response 就是這個例子裡的串流契約。沒有第二個客戶端，檔案裡也沒有 API 金鑰。如果你是從雲端教學抄習慣過來的，不要「以防萬一」再加一把鑰匙。這條路徑不需要。

混合執行才是值得抄的部分

上面的範例只證明權重載得起來。原文的混合一節，才是他們希望你拿到真工作上的形狀。

紀錄裡的示範，Gemini 3.8 Flash 當架構師。它根據檔名和任務描述做計畫，不接收原始碼。原文說這一步花了 95 個雲端 token，原始碼沒有離開機器。接著一批本機的 Gemma 4 26B 處理檔案，三個模組叫做 auth.py、billing.py、database.py。本機迴圈重現漏洞、寫候選修補、挑修補的毛病，再用回歸測試檢查。該次紀錄的 token 有 97.2%（3,322 個）留在本機。

要讀的是限制，不是百分比。雲端模型看到的是名字和任務描述，不是檔案內容。如果你的規劃提示詞裡貼了 auth.py，你已經離開那個示範。95 這個數字是「沒帶程式碼的計畫」。帶程式碼的計畫就是一次普通的雲端呼叫，應按雲端計價。Higgsfield 那篇是團隊故意用雲端模型把東西做出來的另一種收據。工作不同，不要把兩張收據加在一起。

範例專案在 goo.gle/47cKYyV。原文說你可以跑他們的三檔測驗，或把同一套指到自己的 Python 模組和測試。這篇文章沒有重跑那個測驗。95 和 3,322 是他們的紀錄，不是你的預期帳單。檔案大小會搬動本機 token 數。只要原始碼不上線，雲端那側不該跟著變。

同一篇還有一個較小、當天就試得完的例子。提示詞要求本機模型用 psutil 和 rich 做一個終端機儀表板：CPU、記憶體，以及依記憶體排序的前五個行程，存成 monitor.py，外加 requirements.txt，然後自己測一次。他們用的工作目錄是 ~/agy-test，腳本會先建好。設定類別和模型路徑跟前面相同。我會先跑這個，再碰安全測驗。模型如果不會寫檔，失敗方式很明顯，而且你不必信任一份對 auth.py 的修補。

什麼時候仍該走雲端

機器沒過 24GB、任務是規劃而不是磨檔案、或你需要幾秒而不是範例警告的「幾分鐘」，本機就不是預設。混合流程存在，是因為他們已經知道這件事。Flash 規劃，Gemma 做事。你若反過來，會得到一個慢的規劃器，加上一份碰過檔案的雲端帳單。那是同一張圖的貴版本。

如果你已經在跑 Ollama 或 vLLM，不想再維護一種權重格式，LocalOpenAIAgentConfig 是出口。部落格沒有給出的建構式，我不貼。打開 README 的錨點，抄他們的例子，代理迴圈維持你在 LiteRTAgentConfig 上測過的那套。這個類別在原文裡的意義，是後端換了，編排和工具不必改。如果你的工具仍假設環境裡有一把雲端金鑰，換設定不會幫你改寫工具。

本機示範還有一個常被跳過的限制。從不上傳原始碼的模型，仍會寫出壞修補。原文的測驗包含挑毛病和回歸測試。拿掉這兩步、直接套用第一份 diff，你得到的是一個有寫入權、沒有審查者的本機模型。那不是隱私功能，那是一次碰巧很便宜的未審查提交。把示範裡的測試指令留在迴圈裡，否則不要指到你在乎的倉庫。

9 月 23 日這篇是安裝說明，附帶一次量過的執行。裝好、確認 .litertlm 路徑、跑一次目錄列表，再決定混合拆分值不值得這個下載。97.2% 是這個拆分的論據，不是對你倉庫的承諾。