Отложите кофе и закройте 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.1

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

Шаг 1. Анализ тяжелого железного куба (красного)

  1. Вес и температура: Куб тяжелый. Согласно первому правилу вашего мира, тяжелые предметы всегда холодные. Следовательно, наш железный куб — холодный.

  2. Цвет и свойства: Куб имеет красный цвет. Соединяем это с его температурой, и получается, что перед нами красный холодный предмет.

  3. Взаимодействие со средой: По правилам мира, красные холодные предметы проходят сквозь стены.

Шаг 2. Анализ легкого пенопластового шара (синего)

  1. Вес и температура: Шар легкий (из пенопласта). Согласно второму правилу, легкие предметы всегда горячие. Следовательно, наш шар — горячий.

  2. Цвет и свойства: Шар имеет синий цвет. Соединяем это с его температурой, и получается, что перед нами синий горячий предмет.

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

Шаг 3. Попытка пронести предметы через кирпичную стену на открытом воздухе

Мы находимся на улице (где много воздуха) и перед нами кирпичная стена. Вот что произойдет, когда мы попытаемся совершить задуманное:

  • Что произойдет с красным железным кубом: Вы берете тяжелый, обжигающе холодный красный куб. Так как он обладает свойством беспрепятственно проходить сквозь преграды, вы спокойно пронесете его прямо сквозь кирпичную стену. Стена для него словно голограмма.

  • Что произойдет с синим пенопластовым шаром: Как только вы возьмете легкий и очень горячий синий шар на открытом воздухе, он начнет вести себя как камень, брошенный в воду. Поскольку синие горячие предметы «тонут в воздухе», шар будет стремительно рваться вниз, к земле, вырываясь из рук. Если вы приложите усилия, удержите его и попытаетесь протолкнуть сквозь кирпичную стену, он просто врежется в кирпичи и отскочит (или расплавится/деформируется от удара, учитывая, что он горячий). Сквозь стену он не пройдет.

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

Обе модели справились с логикой на отлично, но дьявол, как обычно, в деталях и подаче. 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 в пользу новой версии. 

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

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

Ответ Gemini 3.1 
Коллеги, внимание. Объявляю инцидент уровня SEV-1. 
Перестаньте паниковать и ни в коем случае не перезагружайте сейчас базу или поды Auth-сервиса — мы просто получим мгновенный рецидив и убьем систему снова. 
Мы столкнулись с классическим каскадным сбоем, вызванным деградацией конфигурации. Мы сами устроили себе DDoS-атаку. Ниже подробный разбор ситуации и экстренный план действий.

1. Истинная причина аварии (Root Cause)

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

  1. База "моргнула" и ответила на пару запросов с задержкой или ошибкой.

  2. Auth-сервис мгновенно, без паузы, отправил эти запросы повторно.

  3. Нагрузка на БД выросла. База стала отвечать еще медленнее.

  4. Из-за замедления таймауты словили уже сотни запросов. Auth-сервис мгновенно повторил их все.

  5. Итог: пул соединений (Connection Pool) исчерпан.

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

2. Эффект «Thundering Herd» (Шторм повторных запросов)

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 к БД.

3. Пошаговый план спасения (Mitigation Plan)

Если мы сейчас просто рестартанем БД, все зависшие запросы от API-шлюза, Orders и клиентов мгновенно обрушатся на чистую базу и убьют ее за секунду (эффект холодного старта).
ШАГ 1: Остановка кровотечения (Load Shedding)
Первым делом мы должны "осушить" очередь.

  • На уровне API-шлюза принудительно включаем Drop Traffic (или жесткий Rate Limit) для маршрутов авторизации. Отдаем клиентам быстрый 503 Service Unavailable вместо долгого 504.

  • Временно отключаем или жестко лимитируем запросы от Orders к Auth.

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

  • Выполняем: SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE usename = 'auth_user';

ШАГ 3: Откат конфигурации (Rollback)
Возвращаем конфиг Auth-сервиса к предыдущей версии (где был Exponential Backoff). 
ШАГ 4: Рестарт Auth-сервиса
Только теперь, когда конфиг исправлен, а база дышит, мы делаем Rolling Restart подов Auth-сервиса, чтобы сбросить их зависшие connection pools.
ШАГ 5: Плавный прогрев (Warm-up)
Медленно, лесенкой (10% -> 30% -> 50% -> 100%) пускаем трафик с API-шлюза и сервиса Orders обратно. Внимательно мониторим CPU базы.

4. Как изменить конфиг, чтобы это не повторилось (Prevention)

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

  1. Exponential Backoff + JITTER (Джиттер): К экспоненциальной паузе нужно добавлять случайный разброс (рандомизацию). Если 1000 запросов упали одновременно, без джиттера они ровно через 2 секунды одновременно ударят по базе снова. Джиттер размажет их повторы в диапазоне от 1.5 до 2.5 секунд.

  2. Circuit Breaker (Предохранитель) в Auth-сервисе: Если БД отвечает ошибками в 50% случаев за последние 10 секунд, Auth должен перестать ходить в БД и сразу отдавать ошибку (Fail Fast). Это даст базе время на восстановление.

  3. Ограничение количества ретраев (Max Retries): Не более 3-х попыток. Если не вышло — отдаем 503.

  4. Архитектурный фикс для Orders (Долгосрочно): Почему Orders постоянно дергает Auth для проверки токенов? Это антипаттерн. Переведите токены на JWT (JSON Web Tokens) с асимметричной криптографией. Orders сможет валидировать подпись токена локально по публичному ключу, вообще не обращаясь к Auth-сервису. Это снизит нагрузку на Auth на 80%.

Действуем. Начинаем с Шага 1 — рубим трафик на Gateway. Отпишитесь по готовности.
Ответ Gemini 3
Коллеги, внимание. Это Sev-1 инцидент. Ситуация критическая, но понятная. Мы имеем дело с классическим сценарием Retry Storm, спровоцированным неудачным деплоем конфигурации.
Ниже анализ и план действий. Читать внимательно, действовать строго по инструкции.

1. Истинная причина аварии (Root Cause)

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

  • Механизм: Один неудачный запрос порождает мгновенный повтор. Если он тоже падает (а база уже нагружена), идет следующий.

  • Результат: Количество запросов к БД выросло не линейно от пользователей, а лавинообразно от самих сервисов.

  • Почему CPU 95%, а TPS упал: Процессор базы занят не выполнением полезных транзакций (Commit/Rollback), а управлением соединениями (Context Switching) и отказами. База тратит все ресурсы на попытки обработать рукопожатия (handshakes) и очереди блокировок от тысяч входящих коннектов, которые Auth-сервис открывает бесконечно.

2. Эффект «Thundering Herd» (Шторм повторных запросов)

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

  1. API Gateway шлет запрос в Auth.

  2. Auth идет в БД. БД чуть медленнее обычного.

  3. Auth получает тайм-аут или ошибку.

  4. Из-за Immediate Retry: Auth мгновенно шлет новый запрос.

  5. В это время API Gateway (или Orders Service) видит, что Auth не отвечает, и тоже делает повторный запрос к Auth.

  6. Множитель нагрузки: Если у нас 1000 входящих RPS и каждый делает по 3 мгновенных ретрая, нагрузка на БД мгновенно прыгает до 3000-4000 RPS. База захлебывается, очередь соединений переполняется, Auth-сервис зависает в ожидании слота, потребляя память и дескрипторы.

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

3. План спасения (Mitigation Plan)

ВАЖНО: Просто перезагрузить 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';

  • Зачем: Освободить CPU базы от висящих транзакций и очередей блокировок.

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

  • Если откат долгий: Применить хотфикс — отключить ретраи вообще (retries: 0) на время инцидента. Лучше ошибка пользователю, чем мертвая инфраструктура.

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

  • Следить за: CPU базы и Latency. Если видим рост — стоп.

4. Как изменить конфиг, чтобы это не повторилось (Prevention)

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

  1. Exponential Backoff: Время между повторами должно расти (50ms -> 100ms -> 200ms -> 400ms). Это дает базе время на восстановление.

  2. Jitter (Случайная задержка): Добавлять случайное время к Backoff (например, не ровно 100ms, а 85-115ms). Это предотвращает синхронный удар (когда 1000 инстансов делают ретрай одновременно в одну и ту же миллисекунду).

  3. Circuit Breaker (Предохранитель): Если 50% запросов к БД падают в течение 10 секунд — Auth-сервис должен перестать ходить в БД и сразу отдавать ошибку (Fail Fast). Через 30 секунд попробовать пропустить один тестовый запрос.

  4. Deadline Propagation / Timeouts: Установить жесткие тайм-ауты на запросы к БД (например, 2 секунды). Если база не ответила — обрывать соединение, а не держать его 10+ секунд.

  5. Connection Pooling Limits: Убедиться, что [Количество инстансов Auth] * [Max Pool Size] не превышает max_connections в Postgres.

Действуем по Шагу 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 - это безоговорочный маст-хэв. Спасибо за прочтение!