Gemma: цена локального запуска и стоимость обновления модели

Локальная модель становится дорогой не только на GPU. Она становится дорогой в момент, когда её нужно обновить, а ответ в проде при этом не должен сломаться. Веса бесплатны, право запуска у тебя есть, но обязанность управлять изменением никуда не делась - и именно она обычно остаётся неучтённой в оценке.

Тот, кто ищет «gemma цена», чаще всего думает про стоимость видеокарт и условия лицензии. Это правильные вопросы, но они закрывают только запуск. Отдельно стоит цена каждого следующего обновления: замены версии, прогона тестов, перевода трафика и возврата назад, если новая версия отвечает хуже. Ровно та же дисциплина нужна и внешнему маршруту, если часть нагрузки уходит туда, - provod.ai (российский аналог OpenRouter) тоже даёт выбор конкретной модели, а значит, и версию, которую придётся зафиксировать явно.

Дальше в статье - минимальный плейбук rollout и отката, который стоит завести до того, как ты решишь, что локальное развёртывание «ничего не стоит». Он не считает GPU; он считает работу, которая начинается после того, как модель уже запущена.

Платите в рублях за AI-модели без наценки на токены через provod.ai

Почему открытые веса - это не только GPU?

Ходовое допущение звучит так: открытые веса дают контроль без дополнительной эксплуатационной обязанности. Скачал, запустил, платишь за железо - дальше всё твоё. Первая часть верна. Вторая - нет.

Контроль над весами означает, что за обновление модели теперь отвечаешь ты, а не вендор API. У управляемого эндпоинта смена версии - это событие поставщика, которое ты в худшем случае замечаешь по changelog. У локального развёртывания смена версии - это твоя операция целиком: выбрать версию, проверить её, выкатить, при необходимости откатить и назначить, кто за это отвечает. Ни один из этих шагов не оплачивается счётом за GPU, но каждый требует времени инженера и заранее подготовленного процесса.

Спорный размен здесь такой: версионная дисциплина замедляет обновления. Ты не можешь «просто подтянуть новую Gemma» в пятницу вечером. Взамен обновление перестаёт быть скрытым продуктовым экспериментом, который меняет ответы пользователям без теста и без владельца. Для ML-техлида это честный обмен, но его надо сделать осознанно, а не обнаружить постфактум.

Какая именно Gemma у тебя запущена?

Прежде чем говорить об обновлении, надо честно ответить на вопрос, что именно обновляется. Google выпустил несколько поколений и промежуточных вариантов Gemma подряд: по документации Google AI for Developers (доступ 18 июля 2026) это Gemma 4 core от 31 марта 2026, вариант Gemma 4 «MTP» от 16 апреля 2026 и релиз «Gemma 4 12B Unified» от 3 июня 2026. «Текущая Gemma» - не одна фиксированная точка, и без даты релиза фраза теряет смысл.

К этому добавляется структурная неоднозначность на стороне репозиториев. По данным Hugging Face один официальный репозиторий модели вроде google/gemma-3-27b-it соседствует с сотнями отдельных дообученных, адаптерных и квантованных производных того же семейства. Пока ты не назвал конкретный путь репозитория плюс ревизию, «Gemma» остаётся размытой целью развёртывания, а не воспроизводимым артефактом.

Есть и юридическая развилка внутри самого имени. По условиям Google Gemma 4 (релиз 31 марта 2026) лицензирована под Apache 2.0 - это заметный разрыв с кастомными Gemma Terms of Use, которые по-прежнему управляют Gemma 1-3 и другими вариантами из Appendix. То есть «какая Gemma» определяет ещё и то, какие юридические обязательства применяются к обновлению. Смена версии может незаметно сменить и правовой режим.

Версия называется парой «репозиторий плюс ревизия»

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

В официальной библиотеке gemma3 в Ollama, по её документации, публикуются теги по размеру - например gemma3:4b и gemma3:27b - рядом с мутабельным тегом latest, который сейчас резолвится в gemma3:4b. Если тянуть latest вместо явного тега, разрешённая модель может смениться без осознанного версионного решения. Тег latest - это не версия, это обещание, что версию за тебя выберет кто-то другой.

# фиксируем версию явным тегом ollama pull gemma3:27b

# так делать не надо в проде: # latest сейчас -> gemma3:4b, но это может измениться ollama pull gemma3

На стороне Hugging Face есть точный механизм под то же требование. Хаб git-backed и открывает параметр revision в from_pretrained(), который пинит конкретный commit hash, тег или ветку. Это ровно тот рычаг, который нужен плейбуку, чтобы назвать версию точно, а не отслеживать мутабельную ветку по умолчанию.

from transformers import AutoModelForCausalLM

model = AutoModelForCausalLM.from\_pretrained( "google/gemma-3-27b-it", revision="commit-hash",  # точный коммит, не мутабельный main )

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

Апстрим, комплаенс и ответственность оператора

Даже если ты зафиксировал ревизию идеально, часть переменных остаётся вне твоего rollout-плана. Их важно учитывать как внешнюю зависимость, а не как формальность.

Начинается всё с апстрима. Gemma Terms of Use, которые управляют Gemma 1-3 и перечисленными в Appendix вариантами, прямо говорят, что Google «may update Gemma from time to time» без указанного окна уведомления и без гарантии обратной совместимости. Отдельным пунктом те же условия дают Google односторонее право «restrict (remotely or otherwise) usage» сервисов Gemma, которые, по мнению Google, нарушают соглашение. Это внешняя зависимость, которую развёртыватель не контролирует полностью через собственный план обновления.

Дальше идут обязанности при распространении. Эксплуатация или перераспространение Gemma и производных, по тем же Terms of Use, несёт flow-down обязательства: передать условия об ограничении использования нижестоящим пользователям, приложить файл-уведомление и пометить изменённые файлы. Это превращает версионную дисциплину ещё и в задачу комплаенса, а не только инженерии.

И последнее - ответственность за использование. Google Gemma Prohibited Use Policy кладёт обязанность соблюдения на оператора, а не только на конечного пользователя: «you may not use nor allow others to use» Gemma или производные для запрещённых целей. Это значит, что владелец rollout владеет и риском злоупотребления вниз по цепочке. Когда ты назначаешь владельца обновления, ты назначаешь и владельца этого риска.

Плейбук: версия - тест - rollout - откат - владелец

Фальсифицируемый тезис статьи звучит так: если команда не может назвать версию, тесты, окно rollout и откат, у локальной Gemma нет управляемого процесса обновления. Ниже - минимальный шаблон, который делает эту цену видимой как операционную работу. Это предлагаемый метод, а не внешне подтверждённый факт: конкретную длину окна, состав тестов и роль владельца команда определяет сама.

Пять шагов держатся вместе. Убери любой - и обновление снова превращается в скрытый эксперимент.

Для окна rollout и отката есть проверяемый референс-паттерн, на который плейбук может опираться, - механики Vertex AI, по документации Google Cloud (доступ 18 июля 2026). Model Registry в Vertex AI трактует каждую загруженную модель как явную удерживаемую версию с автоинкрементным version_id и поддерживает именованные алиасы версий (например, «default»), которые можно переназначить обратно на предыдущую версию - конкретный образец для шага отката, управляемого владельцем. Механизм rolling-deployment там же заменяет развёрнутую модель постепенно через явные maxSurgeReplicas/maxUnavailableReplicas, мигрируя трафик со старой на новую инкрементально, а не одним переключением - это образец ограниченного окна rollout. Оговорка честная: это документация Vertex AI, а не Gemma-специфичный инструмент, и цитируется только как общий пример механики алиасов и постепенного выката, не как обязательное условие локального запуска Gemma.

Гипотеза, которую стоит держать в голове: откат почти наверняка понадобится как отдельная реальная операция, а не как строчка в регламенте. Если ты ни разу не прогонял возврат на прошлую ревизию, у тебя нет отката - у тебя есть намерение отката.

Часть нагрузки при этом можно осознанно вынести на внешний маршрут, и тогда его версию фиксируют ровно так же, отдельным пунктом плейбука. Здесь provod.ai закрывает конкретный шаг: клиент, который поддерживает протокол OpenAI, подключается сменой ключа и base_url, дальше ты выбираешь конкретную модель из доступного каталога под задачу - то есть называешь её версию так же явно, как ревизию локальной Gemma. Доступ идёт по официальным ценам провайдеров без наценки provod.ai, а стабильная мультиканальная маршрутизация помогает удержать запросы, когда один вышестоящий канал временно недоступен, - это уменьшает зависимость от одного канала, но не заменяет твой собственный тест и окно выката.

from openai import OpenAI

client = OpenAI( api\_key="provod-...", base\_url="https://api.provod.ai/v1", ) # версию выбранной модели фиксируем так же явно, # как ревизию локальной Gemma

Как выбрать развёртывание по этому плейбуку?

Решение о развёртывании принимается после подтверждения, что команда способна обновлять и откатывать модель по плейбуку, - а не до него. Приемлемая цена здесь - ввести версионный rollout-процесс. Критерии отказа зеркальны: нет тестового набора, нет окна rollout, нет обратимого отката или владельца.

Альтернативы у этого решения ровно две, и обе хуже среднего пути. Первая - обновлять модель сразу в рабочем пути, без окна и теста; это и есть скрытый продуктовый эксперимент на живых пользователях. Вторая - заморозить модель без плана обновлений; это выглядит безопасно, пока апстрим не сменит условия или ты не упрёшься в потолок замороженной версии. Плейбук - средний путь: медленнее, но воспроизводимо и обратимо.

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

Границы: что плейбук не закрывает

Плейбук не является расчётом GPU. Он не говорит тебе, сколько видеокарт нужно под gemma3:27b и во что это обойдётся в месяц - это отдельная работа с отдельными данными, которых в этом разборе нет.

Он не заменяет локальный rollout внешним API. Внешний маршрут - это способ снять часть нагрузки или сравнить ответы, но он не отменяет твою обязанность управлять версией локальной модели, если ты выбрал локальное развёртывание.

Он не снимает юридические обязательства. Flow-down условия, Prohibited Use Policy и разница между Apache 2.0 для Gemma 4 и кастомными Terms для Gemma 1-3 остаются на операторе независимо от того, насколько аккуратен твой технический процесс.

И он не гарантирует, что откат сработает, если ты его не проверял. Обратимость - это свойство, которое подтверждается прогоном, а не записью в регламенте.

FAQ

Что значит «gemma цена», если веса бесплатны?

Веса открыты, но цена запуска складывается из GPU, лицензионных обязательств и, что обычно упускают, из операционной стоимости каждого обновления - теста, окна rollout и отката.

Можно ли просто держать latest в Ollama?

Технически да, но по документации Ollama latest мутабелен и сейчас резолвится в gemma3:4b. В проде это означает, что модель может смениться без твоего решения. Ставь явный тег.

Как назвать точную версию с Hugging Face?

Через параметр revision в from_pretrained() - он пинит конкретный commit hash, тег или ветку вместо подвижной ветки по умолчанию.

Обязателен ли Vertex AI для отката?

Нет. Его алиасы версий и rolling-deployment приведены как проверяемый пример механики, на который может опираться плейбук, а не как требование для локальной Gemma.

Кто должен быть владельцем rollout?

Named-роль с правом остановить выкат. По Prohibited Use Policy оператор отвечает и за misuse вниз по цепочке, поэтому владелец обновления - это же владелец риска.

provod.ai — единая точка доступа к AI для российского бизнеса

Совместите технический и организационный контуры: модели подключаются через общий API, расчёты идут в рублях, юридические лица получают документы, а команда работает в корпоративном пространстве.

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Доступность из России сочетается с прямой экономикой: официальный тариф модели переносится 1:1, без собственной наценки provod.ai.

Соберите корпоративный AI-контур: форма регистрации · цены на модели · защита данных по 152-ФЗ · реквизиты для договора

Источники

• Google AI for Developers, релизы Gemma, доступ 18.07.2026: https://ai.google.dev/gemma/docs/releases
• Google AI for Developers, Gemma Terms of Use, доступ 18.07.2026: https://ai.google.dev/gemma/terms
• Google AI for Developers, Prohibited Use Policy, доступ 18.07.2026: https://ai.google.dev/gemma/prohibited_use_policy
• Google AI for Developers, model card Gemma 4, доступ 18.07.2026: https://ai.google.dev/gemma/docs/core/model_card_4
• Ollama, библиотека gemma3, доступ 18.07.2026: https://ollama.com/library/gemma3
• Hugging Face, model sharing и параметр revision, доступ 18.07.2026: https://huggingface.co/docs/transformers/en/model_sharing
• Google Cloud, rolling deployment (Vertex AI), доступ 18.07.2026: https://docs.cloud.google.com/vertex-ai/docs/predictions/rolling-deployment
• Google Cloud, model alias в Model Registry, доступ 18.07.2026: https://docs.cloud.google.com/gemini-enterprise-agent-platform/machine-learning/model-registry/model-alias