Antigravity SDK и локальные AI-модели: что изменилось, как настроить и какие нужны GPU и VRAM

Antigravity SDK получил поддержку локальных AI-моделей: разработчики могут запускать модели на своём оборудовании и не отправлять данные во внешние облачные сервисы. Об этом 23 сентября 2026 года сообщается в анонсе Introducing Support for Local AI Models in the Antigravity SDK.

Что меняется практически. Раньше SDK в такой схеме был привязан к внешнему провайдеру: запрос уходил на чужой сервер, ответ возвращался по сети, оплата шла за токены. Теперь есть альтернативный путь: тот же SDK обращается к модели, которая работает на вашей машине или на сервере внутри локальной сети.

Чего в анонсе нет: списка поддерживаемых моделей, примеров конфигурации, требований к GPU и VRAM и описания механизма подключения. Это ограничение источника, и оно важное. Ниже разбираю, что известно точно, а где придётся открывать документацию SDK и проверять самостоятельно.

Что именно добавили в Antigravity SDK

Ключевое изменение: локальный запуск вместо облачных API

Локальная модель это файл с весами на диске и процесс инференса, который считает токены на вашем железе: GPU, CPU или их комбинации. Облачный API это удалённый сервер, к которому вы обращаетесь по сети и обычно платите за каждый миллион токенов. SDK в обоих случаях работает как клиент, меняется адрес, куда уходит запрос, и владелец железа.

Как именно Antigravity SDK соединяется с локальной моделью, из анонса не следует. Вариантов в индустрии несколько: встроенный рантайм внутри SDK, HTTP-запрос к локальному серверу вроде Ollama, llama.cpp или vLLM, отдельный адаптер под конкретного провайдера. От этого зависит всё остальное: какие модели подойдут, что придётся поднимать руками и как настраивать параметры. Первый шаг - открыть документацию SDK и найти раздел про локальные модели и провайдеров.

Отдельный момент, критичный для приватности: проверьте, остаётся ли у SDK возможность уйти в облако, если локальный сервер недоступен. Если такой фолбэк есть и включён по умолчанию, запрос с внутренними данными может уйти наружу в самый неудобный момент.

Кому это интересно в первую очередь

• Разработчикам, которые работают с приватными данными: внутренний код, медицинские записи, юридические документы, клиентские базы.
• Командам под регуляторными ограничениями, где передача данных стороннему провайдеру требует отдельных согласований.
• Владельцам локальных GPU-станций и домашних AI-серверов, у которых железо уже есть и простаивает.
• Тем, кто упирается в лимиты облачных API: rate limits, региональные ограничения, рост цен за токены.
• Разработчикам AI-функций, которым нужен дешёвый полигон для отладки пайплайнов без счёта за каждый тестовый запрос.

Логика экономики простая: локальный инференс переносит расходы с оплаты за токены на собственное железо, электричество и время инженера. Обещать кратную экономию заранее нельзя, всё зависит от объёма запросов и от того, что уже стоит в стойке.

Какие локальные модели поддерживаются

В анонсе нет ни списка моделей, ни перечня поддерживаемых форматов, поэтому любой конкретный ответ сейчас был бы догадкой. Есть два типовых сценария, по которым такие SDK обычно и работают.

Первый: SDK общается с локальным сервером через HTTP-интерфейс, совместимый с OpenAI Chat Completions. Тогда подойдёт почти всё, что умеет поднять такой сервер: Ollama, llama.cpp server, vLLM, LM Studio, text-generation-webui. Совместимость определяется рантаймом, а не SDK.

Второй: SDK знает о нескольких конкретных рантаймах и даёт отдельный адаптер под каждый, остальные не поддерживает. В этом случае список ограничен, и его нужно искать в документации.

Дальше типовые семейства моделей, которые вообще используются в локальных сценариях: Llama 3.x, Mistral и производные, Qwen, Gemma, DeepSeek. Это примеры распространённых локальных моделей, а не подтверждённый список совместимости с Antigravity SDK. Проверять нужно по документации SDK и живым тестовым запросом.

Форматы и рантаймы: GGUF, Ollama, llama.cpp, vLLM

GGUF это формат хранения весов, который читают llama.cpp и всё, что построено на нём: Ollama, LM Studio, ik_llama и похожие сборки. Внутри одного файла лежат веса с заданной квантизацией, метаданные и шаблон чата. Формат удобен для потребительских GPU и CPU и легко переносится между машинами.

vLLM это серверный рантайм. Он заметно быстрее на больших GPU и при параллельных запросах, поддерживает непрерывный батчинг, но требует больше памяти и внимания к настройке. Для одного разработчика на одной видеокарте выигрыш не так очевиден, для команды на несколько пользователей картина меняется.

Выбор рантайма влияет на три вещи: скорость генерации, объём занятой VRAM и удобство интеграции. Если SDK ожидает OpenAI-совместимый API, Ollama и vLLM дадут одинаковый интерфейс при разной производительности.

Как проверить совместимость своей модели

1. Открыть документацию Antigravity SDK и найти раздел про локальные модели и провайдеров. Это единственный надёжный источник по списку.
2. Поднять локальный сервер и убедиться, что он отдаёт OpenAI-совместимый эндпоинт, обычно /v1/chat/completions.
3. Сделать минимальный запрос напрямую к серверу, минуя SDK. Если сервер не отвечает сам, SDK тем более не поможет.
4. Повторить тот же запрос через SDK и сравнить ответы.
5. Проверить то, что нужно именно вашей задаче: стриминг, вызов инструментов (tool calling), структурированный вывод в JSON, работу с длинным контекстом.

Шаги 2 и 3 удобно делать через curl: так проще отделить проблемы рантайма от проблем конфигурации SDK.

Как настроить Antigravity SDK для работы с локальными моделями

Точных имён параметров в анонсе нет, поэтому ниже каркас, который используется в SDK с поддержкой локальных провайдеров. Конкретные названия полей и переменных окружения смотрите в документации Antigravity SDK.

Базовая конфигурация: провайдер, endpoint, модель

• Провайдер. Переключатель, который говорит SDK, куда обращаться: в облако или на локальный сервер. Это главный пункт, его забывают чаще всего.
• Endpoint. Адрес локального сервера. Типичные значения: http://localhost:11434 для Ollama, http://localhost:8000/v1 для vLLM.
• Модель. Имя, под которым модель зарегистрирована в рантайме. Не путать с путём к файлу GGUF: сервер ждёт идентификатор из своего списка, а не путь на диске.

Дополнительно выставьте таймауты. Локальная генерация на среднем железе идёт десятки секунд на длинный ответ, и дефолтный таймаут в 30 секунд обрежет нормальную работу. Если SDK требует API-ключ, локальному серверу обычно подставляют произвольную непустую строку: проверка ключа на стороне локального рантайма чаще всего отключена.

Типичные ошибки при подключении локальной модели

• Сервер не запущен или слушает другой порт. Проверка: curl к эндпоинту и ss -tlnp.
• Модель не загружена в память: рантайм перезагружает её на каждый запрос, первый ответ приходит через минуты.
• Имя модели в конфиге не совпадает с тем, что отдаёт эндпоинт /v1/models.
• Не хватило VRAM, и часть слоёв ушла на CPU. Скорость падает в разы, иногда до единиц токенов в секунду. Смотреть через nvidia-smi или логи рантайма.
• Таймаут на длинных ответах при живом сервере.
• Формат ответа не совпадает с ожиданиями SDK: другой шаблон чата, отсутствие поддержки tool calling, иная схема JSON.

Требования к железу: GPU, VRAM и RAM

Официальных требований Antigravity SDK в анонсе нет. Есть общее правило локального инференса: объём памяти определяется числом параметров модели и квантизацией, а сверху добавляется запас под контекст, оверхед рантайма и буферы.

Сколько VRAM нужно под модель: таблица ориентиров

Размер модели	Квантизация	Ориентир по VRAM
7-8B	4 бита (Q4)	5-6 ГБ
7-8B	8 бит (Q8)	8-9 ГБ
13B	4 бита	8-10 ГБ
30-34B	4 бита	18-22 ГБ
70B	4 бита	от 40 ГБ

Цифры приблизительные и описывают локальные LLM в целом, а не требования Antigravity SDK. К ним добавляется KV-cache: он растёт с длиной контекста и числом слоёв, а модели с grouped-query attention расходуют память заметно экономнее. На коротком контексте это сотни мегабайт, на 32K и выше счёт идёт на гигабайты. Практические выводы: 8 ГБ VRAM это минимум для 7-8B в 4-битной квантизации, 12-16 ГБ рабочий средний класс, 24 ГБ уровень для 30B+ в квантизации. Если веса и кэш не влезли, часть слоёв уходит на CPU, и скорость проседает. Как считать это заранее, разобрано в материале про оценку памяти под локальную LLM, а компромиссы между размером модели и квантизацией - в статье про модели в 16-24 ГБ VRAM.

Когда хватит CPU и встроенной графики

Запуск на CPU возможен через llama.cpp и Ollama, но скорость будет заметно ниже: единицы токенов в секунду на моделях 7-8B. Этого хватает для тестов, разбора документов и неспешных задач, для интерактивного чата уже некомфортно. Практический пример запуска на 12 ГБ VRAM с разбором KV-cache и выбора квантования есть в отдельной статье про быстрые локальные модели на 12 ГБ.

Apple Silicon с унифицированной памятью это отдельный практичный вариант: память делится между CPU и GPU, поэтому модель крупнее помещается на машине, чем на дискретной видеокарте сопоставимой цены. Скорость при этом ограничена пропускной способностью памяти, а не числом вычислительных блоков. Для сборок под macOS и Apple Silicon стоит учитывать совместимость конкретной ветки рантайма, как в случае с ds4 с поддержкой GLM 5.3 Flash.

Про RAM отдельно: в системной памяти должны ужиться модель, KV-cache, сам рантайм и операционная система. Для 30B в 4-битной квантизации это ориентировочно 20 ГБ и больше, для комфортной работы на CPU имеет смысл смотреть на 64 ГБ.

Локальный режим против облачного: что выбрать

Сравнивать есть смысл по четырём осям: приватность, скорость, стоимость, контроль над версиями.

Приватность и контроль данных

При локальном инференсе промпты и ответы не уходят в сеть: данные остаются на вашем диске и в вашей памяти. Это главный аргумент для внутренних документов, кода и персональных данных. Оговорка: приватность ломается, если в SDK остался фолбэк на облако или включена отправка телеметрии, поэтому конфигурацию проверяют до первых реальных запросов. В облаке всё зависит от политики провайдера: обучение на данных, сроки хранения, регион обработки. Эти условия каждый провайдер описывает отдельно, их нужно читать, а не додумывать.

Скорость и latency

На скорость локально влияют класс GPU, квантизация, длина контекста и батчинг. Сетевой задержки нет, зато пропускная способность упирается в ваше железо: время до первого токена определяется обработкой промпта, дальше счёт идёт на токены в секунду. Облако даёт доступ к моделям, которые в потребительскую видеокарту не влезут, и обычно отвечает быстрее на длинных контекстах. Для интерактивных чатов с самыми сильными моделями облако часто практичнее, для пакетной обработки и предсказуемой нагрузки локальный режим вполне достаточен.

Затраты: токены против GPU и электричества

Облако это переменные затраты: расходы растут вместе с объёмом запросов. Локальный запуск это затраты постоянные: видеокарта или апгрейд, электричество, охлаждение, плюс время инженера на настройку и поддержку. При небольших объёмах облако почти всегда дешевле, локальный режим отбивается либо на постоянной высокой нагрузке, либо когда требования к приватности не оставляют выбора. Считать стоит не разовую цену GPU, а стоимость владения за два-три года в сравнении со счётом за токены на вашем профиле нагрузки.

Для каких сценариев локальный режим подходит лучше

• Работа с чувствительными данными: медицина, юриспруденция, внутренний код, клиентские базы.
• Офлайн-среды и изолированные контуры без выхода в интернет. Как собрать такой сервер и какие компромиссы по железу принять, разобрано в гайде про локальный AI-сервер без интернета до $5k.
• Разработка и отладка AI-функций: тестовые прогоны не тарифицируются по токенам.
• Постоянная высокая нагрузка, где переменные затраты облака становятся заметными.
• Эксперименты с кастомными и дообученными моделями, которые нельзя отдать внешнему провайдеру.

Когда облако остаётся практичнее

• Нужен доступ к самым сильным моделям, а не к тому, что помещается в вашу GPU.
• Нагрузка нерегулярная и пиковая: платить за пики проще, чем держать простой железа.
• Нет людей и времени на поддержку локального стека.
• Важны SLA, гарантированная доступность и предсказуемая поддержка.

Локальный режим это инструмент под конкретные требования, а не замена облаку целиком. Разумная схема для многих команд: гибрид, где приватные задачи идут на локальную модель, а сложные запросы уходят в облако.

Ограничения и что проверить перед переходом на локальный режим

• Качество локальных моделей обычно ниже топовых облачных: это видно на сложных рассуждениях и длинных агентных цепочках.
• Документация по локальному режиму в Antigravity SDK на старте может быть неполной: список моделей и параметры придётся уточнять.
• Обновления и совместимость зависят от вендора SDK и выбранного рантайма. Следить за версиями моделей приходится вам.
• Инфраструктура на вашей стороне: питание, охлаждение, шум, апгрейды при росте нагрузки.
• Рост требований не решается сменой тарифа: нужна новая видеокарта или вторая.

Короткий чек-лист перед первым запуском:

1. Открыть документацию Antigravity SDK и выписать поддерживаемые провайдеры и форматы.
2. Поднять тестовый локальный сервер и проверить ответ напрямую через curl.
3. Прогнать через SDK реальные промпты из вашей задачи, а не демо-примеры.
4. Замерить токены в секунду, latency до первого токена и занятую VRAM.
5. Убедиться, что нет фолбэка в облако и лишнего логирования.
6. Посчитать стоимость владения за два-три года и сравнить со счётом за токены.
7. Начать с одного внутреннего кейса и расширять только после того, как он отработает стабильно.

Подписаться на канал