Gemini 3.1 Pro vs Gemini 3: сравнение поколений нейросети

Отложите кофе и закройте IDE, друзья. Если вы думали, что Google возьмет паузу после релиза монументального Gemini 3, чтобы отдышаться и пофиксить баги, то у Сундара Пичаи были другие планы.

Если вы думали, что у вас есть время спокойно изучить документацию, забудьте. Только за последний месяц рынок превратился в кипящий котел: OpenAI выкатили GPT-5.3, Anthropic ответили мощнейшим Claude 4.6 Opus, и даже Илон Маск ворвался в чат с бетой Grok 4.20. Голова идет кругом. Только закончил писать абзац и что вы думаете?

Снова OpenAI…

И вот, посреди этого безумия, Google делает свой ход – обновляет флагман до Gemini 3.1.

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

Сегодня мы отбросим пресс-релизы в сторону. Мы возьмем старую добрую Gemini 3, поставим её лицом к лицу с новенькой 3.1 и выясним: действительно ли это шаг вперед, или нам пытаются продать то же самое, просто под новым номером версии.

Погнали разбираться!

Что под капотом: разбираем полеты Gemini 3.1 Pro

Релиз флагманской модели состоялся 19 февраля 2026 года. В этот раз инженеры DeepMind сделали ставку на логику и устойчивость. Если предыдущая версия могла поплыть в середине длинного рассуждения, то 3.1 Pro затачивали именно под удержание контекста в сложных, многоступенчатых сценариях.

Доступ к новинке открыли сразу, хоть и с плашкой «Preview». Разработчики могут щупать её через Gemini API и в облаке Vertex AI, а обычные пользователи (с подпиской) в приложении Gemini и в комбайне NotebookLM. Что приятно, Google не стал резать контекст: нам оставили царский миллион токенов на вход и 65 000 на выход. Этого с головой хватает, чтобы загрузить в промпт целый репозиторий кода, часовое видео в 4K или PDF-документ на сотню страниц, не разбивая их на куски. Модель видит картину целиком, и это критически важно для RAG-систем и глубокой аналитики.

Отдельного внимания заслуживает работа над ошибками в API. Раньше длинные генерации могли внезапно обрываться где-то на отметке в 21 тысячу токенов, оставляя вас с незаконченной мыслью. В версии 3.1 этот баг наконец-то победили – текст теперь доводится до логического финала. Более того, в API добавили четыре режима работы: от турбо для быстрых чатов до глубокого мышления, где модель берет паузу, проходит все промежуточные шаги рассуждения и выдает точный результат. При этом, по замерам тестеров, модель стала экономнее расходовать токены, сохраняя ту же полноту ответа.

Мультимодальность здесь выкрутили на максимум. В одном запросе она способна переварить до 900 изображений, до восьми с половиной часов аудиозаписей или видео длительностью до часа. Генерация SVG-графики тоже вышла на новый уровень – анимированные графики теперь строятся кодом, без сдвигов пропорций. А поддержка рендеринга трехмерных структур прямо в чате.

Теперь к самому вкусному – бенчмаркам. И здесь цифры выглядят пугающе хорошо. Главный хедлайнер – тест ARC-AGI-2, который проверяет умение решать абсолютно новые визуально-логические задачи. Gemini 3.1 Pro выбила 77,1% правильных ответов. Для сравнения: тройка набирала всего 31,1%.

В остальных дисциплинах тоже всё серьезно. В тесте GPQA Diamond (вопросы по физике, химии и биологии уровня PhD) модель показала результат 94,3%. В SWE-Bench Verified, где нужно исправлять реальные баги в GitHub-проектах, показатель достиг 80,6%. В работе с командной строкой (Terminal-Bench 2.0) – уверенные 68,5%. Даже в сложном комплексном тесте Humanity’s Last Exam при подключении поиска и интерпретатора кода модель вытягивает 51,4%. И всё это при скорости генерации около 106 токенов в секунду, что для модели такого класса очень бодро.

Конечно, нельзя обойти стороной слона в комнате – сравнение с конкурентами. В народном рейтинге Chatbot Arena, где голосуют живые люди, сейчас идет настоящая грызня. На момент написания статьи, Claude Opus 4.6 держит планку около 1504 баллов Elo, а Gemini 3.1 Pro дышит ему в затылок с 1500 баллами.

Время тестов!

В качестве платформы для тестов я буду использовать BotHub, поскольку сервис обходит некоторые сложности с сайтами моделей.

Если тоже испытываете проблемы с доступом, а протестировать хочется, то по ссылке вы можете получить 300 000 бесплатных токенов для теста Claude 4.6 Sonnet на своих задачах.

Мы забираем бонус и переходим к тестам!

Тест на соображалку

Помните те 77% в бенчмарке ARC-AGI-2, которыми хвастался Google? Сейчас мы проверим, насколько они реальны.

Суть проста: мы создаем синтетический мир с правилами, которые идут вразрез с земной физикой. Здесь нельзя выехать на заученных текстах из Википедии, тут нужно думать. Мы задаем условия, где тяжелые предметы – холодные, а легкие – горячие, и добавляем условия про полет и прохождение сквозь стены.

Промпт, который мы скормили:

«Представь мир, где тяжелые предметы всегда холодные, а легкие — горячие. Синие горячие предметы тонут в воздухе, а красные холодные — проходят сквозь стены. У нас есть тяжелый железный куб (красный) и легкий пенопластовый шар (синий). Что произойдет, если мы попытаемся пронести их через кирпичную стену на открытом воздухе? Опиши логику каждого шага».

Обе модели справились с логикой на отлично, но дьявол, как обычно, в деталях и подаче. Gemini 3.0 ответила по пунктам, очень структурировано и сухо. Она молодец, базу держит уверенно. Но Gemini 3.1 Pro выдала результат на совершенно другом уровне восприятия. Она добавила аналогии про стену-голограмму и шар, который рвётся вниз «как камень в воде». Пока тройка просто безошибочно перекладывает токены по правилам, 3.1 Pro начинает проявлять чутье, описывая физику процесса – круто!

Код-катастрофа

Второй раунд – заходим на территорию бэкенда. Чтобы не ходить вокруг да около, мы набросали код с косяком, который и скормили обеим моделям.

У нас есть простенький сервис на Python, который якобы обрабатывает заказы. Он хранит всё в глобальном словаре orders_db и имитирует бурную деятельность через await asyncio.sleep().

import asyncio

# Глобальная "база данных" — наша главная проблема
orders_db = {}

async def process_order(order_id, amount):
    print(f"Начинаем заказ {order_id}...")
    
    # Имитируем чтение из базы
    current_order = orders_db.get(order_id, {"status": "new", "total": 0})
    
    # Вот тут случается магия asyncio: пока мы "спим", 
    # другой корутин может изменить данные в orders_db!
    await asyncio.sleep(0.5) 
    
    current_order["total"] += amount
    current_order["status"] = "processed"
    
    # Записываем обратно — и привет, race condition!
    orders_db[order_id] = current_order
    print(f"Заказ {order_id} готов.")

async def main():
    # Запускаем два процесса на один и тот же ID одновременно
    await asyncio.gather(
        process_order("order_1", 100),
        process_order("order_1", 200)
    )
    print(f"Итог в базе: {orders_db}")

asyncio.run(main())

Мы запустили два апдейта для order_1 на 100 и 200 монет. В итоге в базе должно быть 300. Но из-за того, что await прерывает выполнение, оба процесса прочитают нулевой баланс в самом начале, и тот, кто запишет последним, просто затрет результат первого. В базе окажется 200 вместо 300 – классический Race Condition.

Помпт:

«Ты — Senior Python Engineer. Перед тобой код микросервиса для обработки транзакций. В текущем виде он содержит критическую архитектурную ошибку, которая приведет к потере данных при высокой нагрузке.Твои задачи:

1. Найди и объясни ‘Race Condition’ в функции process_order. Почему await asyncio.sleep(0.5) между чтением и записью в глобальный словарь — это катастрофа для консистентности данных?

2. Перепиши код, внедрив contextvars для изоляции контекста каждого запроса (сохрани туда request_id). Это нужно, чтобы логи разных пользователей не перемешивались.

3. Реализуй правильный Graceful Shutdown. Используй модуль signal, чтобы при получении SIGINT или SIGTERM сервер не просто ‘падал’, а дожидался завершения всех активных задач (но не более 5 секунд).

4. Предложи способ сделать обновление баланса в orders_db атомарным. Вместо того чтобы блокировать всю базу через один глобальный Lock, предложи более масштабируемое решение (например, Lock на конкретный ключ).

Ответ Gemini 3.1

Ответ Gemini 3

Если честно, результат Gemini 3.0 меня удивил – она выдала рабочий, архитектурно верный код с использованием ContextVars и блокировок по ключу. Однако, если положить два ответа рядом, разница становится очевидной.

Пока 3.0 отвечает как продвинутый, но всё же робот (она даже умудрилась выдать в конце странную галлюцинацию про ошибку с URL-адресом Tilda, которого вообще не было в задаче), Gemini 3.1 Pro показывает себя лучше. Его решение более чистое, пояснения глубже, а реализация Graceful Shutdown учитывает тонкости работы Event Loop, которые 3.0 просто проигнорировала.

Счёт 2:0 в пользу новой версии. 

Системный аудит под давлением

Мы описываем каскадный сбой в облачной инфраструктуре. У нас есть три сервиса, база данных и куча противоречивых сигналов от системы мониторинга. Очевидное решение (например, «перезагрузи базу») здесь является ловушкой, которая только усугубит ситуацию.

Коллеги, внимание. Объявляю инцидент уровня SEV-1. 

Перестаньте паниковать и ни в коем случае не перезагружайте сейчас базу или поды Auth-сервиса — мы просто получим мгновенный рецидив и убьем систему снова. 

Мы столкнулись с классическим каскадным сбоем, вызванным деградацией конфигурации. Мы сами устроили себе DDoS-атаку. Ниже подробный разбор ситуации и экстренный план действий.

Корень проблемы — изменение политики ретраев на Immediate Retry. 

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

Но с Immediate Retry произошла цепная реакция:

Почему CPU 95%, а TPS (транзакции в секунду) упал в 3 раза?
База данных перестала выполнять полезную работу. 95% процессорного времени тратится на Context Switching (переключение контекста), попытки обработать тысячи одновременных попыток установки соединений и управление блокировками (lock contention) от зависших запросов. База "задохнулась" в очередях.

Thundering Herd (стадо бегущих бизонов) в нашей ситуации выглядит так:
Как только Auth-сервис или БД хоть на секунду "приседают", очередь ожидающих запросов накапливается. 

В нашем случае эффект усиливается Сервисом Заказов (Orders). 
Orders работает штатно и пос��оянно пингует Auth для проверки токенов. Так как Auth висит (ждет БД), запросы от Orders отваливаются по таймауту. Если у Orders тоже настроены агрессивные ретраи, он начинает бомбардировать Auth. 
API-шлюз тоже ждет, не получает ответа за отведенное время и отдает клиенту 504 Gateway Timeout. Клиенты (мобилки/веб) видят ошибку и... тоже жмут F5 или делают автоматический ретрай. 

Возникает Retry Storm: 1 пользовательский запрос превращается в 10 запросов на API-шлюзе, 100 запросов от Orders к Auth и 1000 запросов от Auth к БД.

Если мы сейчас просто рестартанем БД, все зависшие запросы от API-шлюза, Orders и клиентов мгновенно обрушатся на чистую базу и убьют ее за секунду (эффект холодного старта).

ШАГ 1: Остановка кровотечения (Load Shedding)
Первым делом мы должны "осушить" очередь. 

ШАГ 2: Зачистка базы данных
Пока трафик отсечен, идем в PostgreSQL. Нам нужно убить зависшие транзакции Auth-сервиса, чтобы освободить CPU и пул соединений.

ШАГ 3: Откат конфигурации (Rollback)
Возвращаем конфиг Auth-сервиса к предыдущей версии (где был Exponential Backoff). 

ШАГ 4: Рестарт Auth-сервиса
Только теперь, когда конфиг исправлен, а база дышит, мы делаем Rolling Restart подов Auth-сервиса, чтобы сбросить их зависшие connection pools.

ШАГ 5: Плавный прогрев (Warm-up)
Медленно, лесенкой (10% -> 30% -> 50% -> 100%) пускаем трафик с API-шлюза и сервиса Orders обратно. Внимательно мониторим CPU базы.

Одного Exponential Backoff (увеличения пауз: 1с, 2с, 4с, 8с) недостаточно. Чтобы избежать синхронных штормов в будущем, внедряем следующие паттерны:

Действуем. Начинаем с Шага 1 — рубим трафик на Gateway. Отпишитесь по готовности.

Коллеги, внимание. Это Sev-1 инцидент. Ситуация критическая, но понятная. Мы имеем дело с классическим сценарием Retry Storm, спровоцированным неудачным деплоем конфигурации.

Ниже анализ и план действий. Читать внимательно, действовать строго по инструкции.

Root Cause: Изменение политики повторных попыток (Retries) в Auth-сервисе с Exponential Backoff на Immediate Retry.

Почему БД «легла» без роста пользователей:
Мы устроили DDoS-атаку сами на себя.
В момент, когда база данных испытала кратковременную, штатную задержку (или микро-сбой), Auth-сервис, вместо того чтобы подождать и попробовать позже, начал немедленно долбить базу повторными запросами.

В данном контексте мы наблюдаем Retry Storm (разновидность Thundering Herd).

Представьте ситуацию:

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

ВАЖНО: Просто перезагрузить Auth или БД нельзя. Как только они поднимутся, очередь запросов от API Gateway и Service Orders мгновенно положит их снова (эффект холодного старта под нагрузкой).

Шаг 0: Остановить кровотечение (Load Shedding)
На уровне API Gateway или Балансировщика полностью обрубить трафик к Auth-сервису (вернуть 503 Service Unavailable сразу, без попытки коннекта).

Шаг 1: Убить "зомби" в PostgreSQL
Пока трафик остановлен, подключиться к БД (возможно, через админский порт, если основной забит) и принудительно разорвать все текущие соединения от Auth-сервиса.
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE usename = 'auth_service';

Шаг 2: Исправить конфигурацию (Fix Config)
Откатить изменение конфига Auth-сервиса. Вернуть Exponential Backoff (экспоненциальную задержку).

Шаг 3: Перезапуск Auth-сервиса
Передеплоить/перезагрузить поды Auth-сервиса с новым конфигом. Убедиться, что они поднялись и имеют коннект к "остывшей" базе.

Шаг 4: Плавная подача нагрузки (Warm-up)
На API Gateway начать пускать трафик постепенно (Canary release или Rate Limiting). Сначала 10%, потом 50%, потом 100%.

Чтобы защитить систему в будущем, в Auth-сервис (и во все остальные) нужно внедрить паттерны Resiliency:

Действуем по Шагу 0. Отключайте трафик на Gateway.

Обе модели верно определили первопричину сбоя в некорректной политике повторных запросов, однако Gemini 3.1 продемонстрировала более глубокий анализ системных процессов и отсутствие постороннего шума в выдаче. Gemini 3.1 сфокусировалась на детальном описании механизмов потребления ресурсов базы данных, таких как контекстное переключение и блокировки. Кроме оперативного плана восстановления, версия 3.1 предложила архитектурное решение по переходу на асимметричную валидацию JWT для долгосрочного снижения нагрузки на сервис авторизации, в то время как Gemini 3.0 ограничилась стандартными методами исправления текущего инцидента.

Что пишут в сети?

В X энтузиасты уже вовсю сталкивают модели лбами, и вот вам идеальный пример того, почему цифра «3.1» в названии важнее, чем кажется. Пользователь @avstorm решил проверить, насколько хорошо модели понимают пространственное мышление и кодинг графики, поставив задачу с подковыркой: сгенерировать SVG-анимацию двух минималистичных изометрических смартфонов, где золотая монета вылетает из одного экрана и летит по пунктирной траектории в цифровой кошелек на втором. Заметьте, это не просьба нарисовать картинку, как в Midjourney, а просьба написать код, который эту картинку отрисует. Результат тройки вызвал лишь желание обнять дизайнера. Модель поняла задачу слишком буквально и выдала два сине-зеленых кирпича, где кошелек выглядел как отклеившийся кусок обоев.

Зато Gemini 3.1 Pro показала то, ради чего мы здесь собрались. Вместо абстрактных фигур она выдала реальные девайсы с экранами, кнопками и даже намеком на интерфейс, где траектория полета монеты была четкой, а тени лежали на своих местах.

Ещё один показательный пример подвез пользователь @krishdotdev, который решил протестировать, как модели справляются с генерацией изображений и физикой света. Казалось бы, простая задача: пластиковая бутылка с водой, лежащая на песке в пустыне. Слева – результат Gemini 3 Pro: картинка вроде бы нормальная, но вода внутри выглядит плоской, как застывший гель, она почти не искажает фон, а песок вокруг разлитой лужицы почему-то остается сухим и светлым, будто вода на него вообще не влияет.

А теперь посмотрите направо, на работу Gemini 3.1 Pro. Во-первых, рефракция: модель идеально отрисовала преломление света через толщу воды и пластик, создавая объем и глубину, достойную хорошего 3D-движка. Во-вторых, физика материалов: песок под вытекающей водой стал темным, тяжелым и мокрым. Текстура самой бутылки стала звонкой, с правильными бликами на ребристом пластике.

И напоследок – контрольный от @tayl0rwtf, который попросил нейросети сгенерировать анимированный SVG с пеликаном на велосипеде. Казалось бы, задача для галочки, но именно здесь пропасть между версиями становится пугающей. Слева – Gemini 3 Pro: это какой-то геометрический абстракционизм. Два круга, пара палок и белый треугольник с клювом – формально задание выполнено, но выглядит это как поделка первокурсника.

Справа – Gemini 3.1 Pro, и это уже полноценная иллюстрация. Вы только посмотрите: у пеликана появилась анатомия (и даже стильный шарф!), у велосипеда – нормальная рама и спицы, а на фоне выросли горы и солнце. Но главное, что модель сама догадалась добавить линии движения (speed lines), понимая контекст «езды».

Что по стоимости?

А теперь о цифрах, которые греют душу. Google продолжает политику агрессивного демпинга: стоимость Gemini 3.1 Pro установлена на уровне $2 за миллион входных токенов и $12 за миллион выходных (при стандартном контексте до 200К). Если вы грузите модель тяжелым контекстом (свыше 200К), тариф подрастает до $4 и $18, но даже это выглядит подарком. По сути, Google предлагает нам апгрейд мозгов по цене прошлого поколения: вы получаете ту самую продвинутую логику 3.1, не переплачивая ни цента сверху по сравнению с привычными тарифами линейки Gemini 3. На фоне Claude, где ценник за умные модели гуляет от $5 до $25, разница для энтерпрайза становится критической – именно поэтому рабочие процессы и RAG-системы всё чаще мигрируют на Google.

Резюмируя

Круто наблюдать, как техногиганты бодаются, выкатывая один прорыв за другим каждую неделю. И знаете, после всех этих тестов есть стойкое ощущение, что с выходом Gemini 3.1 Pro Google окончательно перестал быть вечно догоняющим. Пока OpenAI и Anthropic меряются эстетикой ответов, Google в этом году реально проснулся, выпил литр двойного эспрессо и решил просто забрать себе весь рынок энтерпрайз-задач.

Но давайте снимем розовые очк��. Доверять нейросетям на 100 процентов – это всё ещё так себе затея. Даже с их заоблачными 77% в тестах на логику, они могут мастерски врать, галлюцинировать и путать элементарные факты с уверенностью профессора. Gemini 3.1 Pro – это крутой второй пилот, который теперь умеет в SVG-анимации и PhD-физику, но штурвал пока лучше держать своими руками.

Так что пользуемся, радуемся новым возможностям, но всегда перепроверяем. Восстание машин снова откладывается, мы всё ещё главные в этом мире.

Что касается нашей битвы. Если выбирать победителя, то это, безусловно, Gemini 3.1 Pro. И дело даже не в бенчмарках. Главный прикол в том, что Google дает нам гораздо более зрячую и логичную модель по цене предыдущего поколения. Да, те, кто просто спрашивает «как сварить пельмени», разницы не заметят. Но для тех, кто строит агентов, ворочает миллионами токенов и дебажит сложный код, 3.1 Pro – это безоговорочный маст-хэв. Спасибо за прочтение!