Aeza

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

Вопрос только в том, какому агенту. 22 сентября 2026 года Anthropic выпустила Claude Opus 5.5, а OpenAI через полтора часа ответила GPT-6 Sol. Обе компании бьются за одно и то же место – за ваш терминал и редактор кода. И бьются всерьёз: у Codex в августе было 20 млн активных пользователей, а Claude Code ещё в феврале приносил Anthropic больше 2,5 млрд долларов выручки в годовом исчислении. Метрики разные (пользователи против выручки), но масштаб понятен.

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

Что произошло за один сентябрь

Чтобы понять темп, достаточно посмотреть на один месяц:

Интересная деталь: 12 сентября глава Anthropic Дарио Амодеи опубликовал эссе с призывом притормозить гонку передовых моделей, а Сэм Альтман с ним согласился. Через десять дней обе компании выпустили новые модели в один день.

Кто выигрывает по факту? Свежие данные о доле – опрос JetBrains, в котором в мае–июле 2026 года ответили больше 15 тысяч разработчиков. На работе Claude Code пользуются около 39% из них, Codex – 16%. В январе у Codex было 3%, так что его доля за полгода выросла впятеро. Claude Code за то же время поднялся с 18%. GitHub Copilot за год просел с 29% до 21%.

Позиция A: решает модель

Сторонники этой позиции рассуждают довольно просто. Агент читает файлы, запускает команды и правит код, но найти, почему скидка ломает доставку, должна модель. Если модель не поняла связь между формой заказа и проверкой промокода, никакой интерфейс её не спасёт.

Разница между моделями пока что измерима. На независимом прогоне Terminal-Bench 4.0 от Vals.ai, где все модели работают в одной и той же простой оболочке, на 1 октября Claude Opus 5.5 решает 65,2% задач, Sonnet 5.5 – 64,1%, GPT-6 Astra – 59,6%, Fable 5.1 – 58,1%. Зато Astra дешевле на одну задачу, 9,58 доллара против 13,20 у Opus 5.5, и почти вдвое быстрее: 36 минут на задачу против 64. GPT-6.1 Sol за неделю после GPT-6 Sol прибавила на этом тесте 11 пунктов, до 55,1%, и обходится в 1,72 доллара за задачу. Для этой позиции это сильный довод: сменили модель в той же оболочке, и результат заметно вырос.

Компании, конечно, тоже меряются, и каждая выбирает удобный ракурс. Anthropic в анонсе Opus 5.5 приводит 66,4% на том же Terminal-Bench 4.0 против 57,9% у Astra, с оговоркой в сноске: Opus 5.5 замерен на уровне усилий xhigh, а для Astra взят результат на high, который опубликовала сама OpenAI. OpenAI в анонсе GPT-6 Sol пишет, что на AutomationBench от Zapier Sol обходит Claude Opus 5 при 9% стоимости задачи. Обе цифры настоящие и отвечают на разные вопросы: кто сильнее на пределе и кто дешевле на потоке.

А цены стали почти зеркальными. GPT-6.1 Sol и Claude Sonnet 5.5 стоят одинаково, по 2 доллара за миллион входных токенов и 10 за миллион выходных. Флагманы GPT-6 Astra и Claude Fable 5.1 – по 10 и 50. Opus 5.5 посередине, 4 и 20.

Главный аргумент позиции – обёртки становятся общими. В декабре 2025 года Anthropic и OpenAI вместе с другими компаниями передали в Linux Foundation свои стандарты: Anthropic – протокол MCP для подключения инструментов, OpenAI – формат AGENTS.md для инструкций проекта. Claude Code умеет читать AGENTS.md, формат Agent Skills понимают и Claude Code, и Codex. Apple в Xcode встроила сразу обоих агентов, а Codex, как и Claude Code, можно запускать через Amazon Bedrock. Вдобавок Codex CLI открыт под лицензией Apache 2.0, его можно форкнуть и доработать под себя, а Claude Code остаётся закрытым продуктом. Раз инструкции, инструменты и навыки переезжают вместе с проектом, держаться за конкретного агента незачем, можно брать лучшую модель месяца.

Позиция Б: решают оболочка и привычки

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

Люди привыкают к тому, как агент себя ведёт по умолчанию. Claude Code с августа на тарифах Pro, Max и Team по умолчанию работает в авторежиме: сам решает, какие действия безопасно выполнить без вопроса, а рискованные останавливает. Память между сессиями у него тоже включена сразу. Codex устроен иначе. Локальная память у него по умолчанию выключена, а свободу агента ограничивает песочница операционной системы. Внутри проекта он правит и запускает всё сам, за его пределы и в сеть ходит только с вашего разрешения. Приложение Codex с февраля строится вокруг параллельных задач в отдельных рабочих копиях репозитория. Claude Code тоже так умеет, но там это одна из возможностей, а у Codex – основа интерфейса. Кто привык к одной схеме, неохотно переучивается на другую.

К тому же со временем вокруг агента копится собственное хозяйство. Файл с правилами проекта, готовые команды для типовых задач, подключённые MCP-серверы трекера и базы, хуки, которые запускают линтер после каждой правки, и разрешения, которые команда месяцами подбирала, чтобы агент не спрашивал лишнего и не делал опасного. Часть этого стандарты переносят, но настройки прав и поведение по умолчанию у каждого агента свои, и переезд означает заново их выверять.

Второй аргумент – подписки. Большинство разработчиков платит за тариф и считает, сколько работы влезет в лимит, а цена токена их волнует меньше. Здесь обе компании ведут себя непоследовательно. OpenAI в конце сентября урезала тариф Pro за 200 долларов с двадцатикратного лимита Plus до десятикратного и добавила тариф за 500 долларов. Нынешним подписчикам старый объём оставили на время и пообещали разовый кредит, но на форуме это всё равно назвали «bait-and-switch». Anthropic в сентябре убрала летний бонус к лимитам Claude Code, и недельный объём стал примерно на 17% меньше летнего, хотя на четверть больше весеннего. В июне на неё к тому же подали иск, в котором утверждается, что реальный объём тарифов Max ниже обещанного. При этом 22 сентября вместе с Opus 5.5 Anthropic увеличила пятичасовые лимиты.

И третий аргумент – цифры использования. Доля Codex в опросе JetBrains выросла с 3% до 16% за то самое полугодие, когда у него появилось отдельное приложение. Copilot же, который даёт выбрать модели разных поставщиков, за год потерял больше четверти своей доли. Образовывается вывод, что людей переманивает продукт целиком.

Даже модель за пользователя чаще всего выбирает оболочка. Codex без явного выбора берёт рекомендованную GPT-6.1 Sol, хотя флагман у OpenAI – Astra. В Claude Code по умолчанию стоит Opus 5.5. Большинство так и работает, не заглядывая в настройки.

Вернёмся к нашей скидке

На сломанном оформлении заказа обе позиции видны хорошо. Найти, что промокод пересчитывается после смены адреса и обнуляет доставку, должна модель. Тут позиция A права, и слабая модель будет кругами гонять тесты.

А вот не тронуть соседний сервис оплаты, не запустить миграцию на рабочей базе и показать понятный diff, который вы примете за пять минут, – это работа оболочки, её режимов и настроек. Тут права позиция Б.

Поэтому мы советуем сравнивать стоимость принятой правки, а цену токена и место в рейтинге оставить на потом. Сколько времени прошло до изменения, которое вы готовы влить, сколько раз пришлось вмешаться и сколько ушло лимита или денег на все попытки.

Что думаем мы

Мы на стороне Б, хотя и с оговоркой. Сейчас модели двух компаний отличаются на несколько пунктов в независимых тестах, а лидер меняется чаще, чем команда успевает обновить свои инструкции для агента. Общие стандарты вроде MCP, AGENTS.md и Skills переносят между агентами инструкции и инструменты, но не всё. Не переносятся поведение агента по умолчанию, права, лимиты подписки и привычный ритм работы. За это и идёт война, и поэтому она тихая. Её ведут настройками по умолчанию и строчками в тарифах, а бенчмарки на презентациях – только фон.

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

А что выбираете вы? Codex с GPT-6.1 Sol или Claude Code с Opus и Sonnet? Если пробовали оба на одной и той же задаче, расскажите, что в итоге решило: модель, удобство, лимиты или цена. И если вы уверены, что права позиция A, а мы ошибаемся, давайте спорить в комментариях.

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

Дежурный открывает Grafana, а там всё зелёное. Процессор базы занят на треть, диск заполнен наполовину, PostgreSQL отвечает на проверки, реплика на месте. Панелей около трёхсот, и ни одна не горит.

Графики при этом не врут. Процессор правда свободен, место правда есть. Только они отвечают на вопрос «жив ли серверр», а человеку с попкорном важно то, сколько он ждёт.

По нашему мнению, у многих команд мониторинг базы собран из того, что легко измерить, и почти не помогает решить, что делать прямо сейчас. Косвенно это подтверждает опрос NeuBird, вендора ИИ-инструментов для дежурных: в феврале 2026 года компания опросила 1039 специалистов по SRE, DevOps и эксплуатации. У 78% хотя бы раз случался инцидент, на который не сработал ни один алерт. А 57% говорят, что по делу меньше 30% их алертов. Опрос вендорский, но картина узнаваемая: уведомлений много, а главное всё равно пропускают.

Что могло сломаться, пока всё зелёное

Для такой истории есть как минимум три сценария, и ни один из них не нагружает процессор.

Первый сценарий связан с очередью блокировок. В 20:55 выкатили миграцию с ALTER TABLE, которая добавляет колонку в таблицу фильмов. Для этого ей нужна самая строгая блокировка таблицы. А по той же таблице в это время идёт аналитический отчёт на двадцать минут. Миграция встаёт ждать отчёт, а все новые запросы к таблице, включая обычные SELECT из поиска, выстраиваются за миграцией. Запросы ничего не считают, они просто ждут, поэтому процессор отдыхает.

Во втором закончились соединения в пуле. Приложение ходит в базу через PgBouncer, а все 50 серверных соединений пула заняли медленные запросы и забытые открытые транзакции. Остальные клиенты стоят в очереди ещё до PostgreSQL, и сама база при этом может быть почти пустой.

В третьем каталог читает с реплики, а реплика отстала. Ошибок нет, просто зритель не находит серию, которая вышла десять минут назад, и жмёт «Обновить» снова и снова, добавляя нагрузку.

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

Подход A: будить по состоянию базы

Здесь исходят из того, что база почти всегда предупреждает заранее. Соединения подбираются к лимиту, реплика отстаёт всё сильнее, растёт WAL (журнал, куда PostgreSQL сначала записывает каждое изменение), транзакции висят открытыми. Если поставить пороги на эти показатели, дежурный узнает о проблеме до первой жалобы.

Подводит обычно настройка. Пороги берут из готовых наборов правил и ставят одинаковыми для всех баз: «соединений больше 80%», «реплика отстаёт больше чем на 10 секунд». Для одной базы 80% соединений означают обычный вечер, для другой аварию. Со временем такие алерты начинают пролистывать, а вместе с шумом и настоящую проблему.

На это есть ответ: шум – беда плохих порогов. Порог можно считать от обычного уровня конкретной базы или от скорости роста: «слот держит уже 40 ГБ WAL и прибавляет по 5 ГБ в час». Такой алерт сразу говорит, куда смотреть. Рост p99 сообщает только, что кому-то плохо.

Подход Б: будить по тому, что чувствует пользователь

Здесь всё идёт от книги Google по SRE. Мониторинг там отвечает на два вопроса: что сломалось и почему. «Что» – это симптомы, которые видит пользователь, «почему» – причины внутри системы. Для симптомов предлагают четыре «золотых сигнала»: задержку, трафик, ошибки и насыщение. Если на алерт можно ответить механически, звонить дежурному незачем. Из причин будить стоит только по очень явным и близким, вроде «диск базы закончится через 4 часа».

Для PostgreSQL это значит, что на пейджер, то есть с ночным звонком, идут p99 ключевых операций, доля ошибок и время ожидания соединения. Блокировки, контрольные точки и диск остаются на дашборде, их открывают после того, как сработал симптом.

Минусы у этого подхода тоже есть. Метрики придётся встроить в каждый сервис, и ночью путь от «кому-то плохо» до причины получается длиннее. А главное, некоторые проблемы копятся неделями и никак не задевают пользователя до последнего момента. Когда симптом наконец появляется, база уже отказывается принимать запись.

p95 и p99: почему среднее успокаивает

Допустим, за минуту кнопку «Смотреть» нажали 1000 раз. 980 запросов отработали за 20 мс, а 20 упёрлись в блокировку строки и ждали по 3 секунды. Среднее получается около 80 мс. Вроде бы терпимо, алерт с порогом в 200 мс промолчит. p95, то есть время, в которое укладываются 95% запросов, показывает красивые 20 мс. И только p99 показывает 3 секунды: каждый пятидесятый зритель смотрит на колесо.

Считать процентили стоит по каждой операции отдельно и рядом показывать число запросов. Если поиск и «Смотреть» смешать в одну метрику, быстрый и частый поиск утопит медленную и редкую операцию. А если за час было пять оплат подписки, p99 по ним считать бессмысленно, хватит списка из пяти строк.

И ещё одно. Из стандартной статистики PostgreSQL процентили не достать. pg_stat_statements хранит для каждого запроса число вызовов, среднее, минимальное и максимальное время и разброс, а процентилей там нет. Их считают в приложении, обычно гистограммами в Prometheus, отдельно для ожидания соединения и для выполнения SQL. Так видно, где потерялось время – в очереди к базе или в самой базе.

Блокировки: очередь, которую не видно по процессору

Вернёмся к миграции. Алерт «в базе есть блокировки» тут бесполезен, потому что блокировки есть всегда, на них держится вся конкурентная работа PostgreSQL. Полезен ответ на вопрос, кто ждёт, сколько и из-за кого. Его дают представление pg_stat_activity и функция pg_blocking_pids():

Отдельно присмотритесь к статусу idle in transaction. Запрос закончился, а транзакция открыта, потому что приложение, например, ушло ждать ответа от платёжного сервиса. Такая сессия держит блокировки и мешает очистке старых версий строк. Её можно ограничить через idle_in_transaction_session_timeout, а с версии 17 есть ещё transaction_timeout на всю транзакцию. Его лучше ставить на роль приложения, иначе он оборвёт и долгие отчёты.

Для миграций есть простое лекарство, lock_timeout. Если миграция не получила блокировку за пару секунд, она завершается с ошибкой и освобождает очередь. Повторить попытку придётся самим, PostgreSQL этого не сделает, зато сервис не встанет.

Что увидит каждый подход? A сработает на правило «самая старая транзакция старше N минут» и, если повезёт, раньше пользователей. Но ночной отчёт тоже живёт долго, и порог придётся подбирать под каждую базу. B сработает на рост p99 у «Смотреть», а дежурный откроет запрос выше и быстро найдёт виновника. Долгие ожидания блокировок можно писать в лог и сейчас через log_lock_waits, а в PostgreSQL 19 (он пока в бете) его планируют включить по умолчанию и добавить представление pg_stat_lock.

Соединения: база свободна, а очередь стоит

В самой базе обычно смотрят число подключений относительно max_connections. Учтите, что часть мест зарезервирована (superuser_reserved_connections по умолчанию держит 3 слота для суперпользователей). Обычные клиенты упрутся в лимит раньше, чем график покажет 100%.

Если перед базой стоит PgBouncer, главный показатель живёт в нём. В выводе команды SHOW POOLS есть cl_waiting (сколько клиентов отправили запрос и ещё ждут серверное соединение) и maxwait (сколько секунд ждёт самый старый из них). Документация PgBouncer прямо пишет: если maxwait начал расти, пул не успевает обрабатывать запросы.

Подход A поставит здесь алерт на «занято 80% соединений». Подход Б поставит его на время ожидания соединения в приложении или на растущий maxwait. Второй вариант точнее. 80% занятых соединений при пустой очереди означают обычную работу, а секундная очередь бьёт по зрителям, даже если база загружена наполовину.

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

Реплика, WAL и старые транзакции: здесь прав подход A

В pg_stat_replication есть поле replay_lag, задержка применения изменений на реплике. Когда реплика всё догнала и записи нет, оно через какое-то время становится NULL, а у отвалившейся реплики строки в представлении нет вовсе, и алерт на replay_lag промолчит. Если каталог читает с реплики, надёжнее раз в несколько секунд записывать текущее время в служебную строку на основной базе и читать её с реплики (часы серверов должны совпадать). Разница и есть отставание, которое видит зритель.

С WAL всё серьёзнее. Слот репликации запоминает, какой журнал потребитель ещё не забрал, и не даёт его удалить. Если потребителя нет, например реплику выключили или про логического подписчика забыли, слот держит WAL начиная с позиции restart_lsn. Каталог pg_wal растёт, пока не займёт диск, и тогда база остановится. До этого момента пользователь не замечает ничего.

В PostgreSQL 18 появился idle_replication_slot_timeout. По умолчанию он выключен, а включённый помечает недействительными слоты, которые простаивают дольше заданного времени. Такой слот придётся пересоздавать.

Самое неприятное здесь – переполнение счётчика транзакций (XID wraparound). У PostgreSQL в «окне» около двух миллиардов номеров транзакций, и старые номера нужно периодически «замораживать», этим занимается autovacuum. Если он не успевает, база начинает писать предупреждения, когда до предела остаётся 40 миллионов транзакций. А когда остаётся меньше 3 миллионов, перестаёт выполнять команды, которым нужен новый номер транзакции. Проще говоря, перестаёт принимать запись.

Так в феврале 2019 года сломался Mandrill, сервис транзакционных рассылок Mailchimp. На одном из шардов кончились номера транзакций, и сбой длился около 40 часов. Ещё в ноябре 2018-го команда заметила, что счётчик прошёл примерно полпути, и завела в бэклог задачу на дополнительный мониторинг. Первое исключение ночью утонуло среди посторонних ошибок, а алерт на wraparound появился через полчаса после восстановления. Sentry в 2015 году наступил на те же грабли и лежал большую часть рабочего дня в США.

Пока счётчик растёт, p99 идеальный, и подход Б ничего не заметит. Поэтому возраст XID, место под WAL и состояние слотов мы бы держали на пейджере в любом случае. Порог по XID можно ставить с большим запасом, например на миллиард. Примерно на этой отметке Mandrill в ноябре и завёл свою задачу в бэклог. Только задача ждёт своей очереди, а алерт будит.

Диск и контрольные точки: смотреть вместе с задержкой

Во время контрольной точки (checkpoint) база сбрасывает на диск всё, что накопилось в памяти. Из-за неё и из-за диска мы бы ночью никого не будили. С 16-й версии время чтения и записи видно в pg_stat_io, но только при включённом track_io_timing. По умолчанию он выключен, и в колонках времени тогда стоят нули. Ещё в это время попадает чтение из кеша операционной системы, поэтому сам диск проверяют и через iostat или node_exporter.

Если точки из-за заполнения WAL идут чаще раза в 30 секунд, PostgreSQL сам напишет в лог «checkpoints are occurring too frequently» и посоветует увеличить max_wal_size. Разовое сообщение документация просит не считать поводом для тревоги, а частое вместе с ростом p99 на запись стоит разобрать. Только поднимать max_wal_size вслепую не надо: WAL займёт больше места, а восстановление после сбоя может затянуться.

Сравним подходы

Как настроили бы мы

Мы за подход Б на пейджере и за короткий список исключений из подхода A. Дежурного стоит будить, когда пользователям плохо: вырос p99 ключевых операций, выросла доля ошибок, клиенты ждут соединение. И отдельно, когда кончается ресурс, о котором пользователь узнает слишком поздно. Это запас номеров транзакций, место под WAL и состояние слотов, свежесть реплики, если с неё читают. Остальное лежит на дашборде и открывается после первого алерта.

Для каждого алерта мы бы задавали один вопрос. Понятно ли, что делать, если он пришёл в три часа ночи? Если ответ «посмотреть и закрыть», ему место на дашборде.

Хорошее ночное сообщение выглядит примерно так: «„Смотреть“: p99 4,2 с при обычных 300 мс. 37 сессий стоят в очереди к titles за ALTER TABLE (pid 81234), а он ждёт отчёт (pid 80112)». Плохое: «Активных соединений 80%». Первое сразу говорит, кому плохо и куда смотреть. Со вторым дежурный идёт листать те самые триста панелей.

Подход A выигрывает, когда приложение не размечено метриками и разметить его нельзя, скажем, в старом монолите, к коду которого боятся прикасаться. Тогда пороги по базе лучше, чем ничего. Только подбирать их придётся под конкретную базу и её обычную нагрузку, готовые правила из интернета подведут.

А как устроено у вас? Какой алерт PostgreSQL последний раз действительно спас ночь, а какой мигает месяцами, и его давно никто не читает? Если вы уверены, что будить дежурного надо по состоянию базы, расскажите в комментариях, где подход Б вас подвёл.

Получите 15% кешбэка на первое пополнение только в Aéza

В мае 2026 года Anthropic объявила, что получает Colossus 1 – кластер мощностью больше 300 МВт, где стоит свыше 220 тысяч GPU NVIDIA. Строили его для Grok, а владеет им SpaceX, которая в феврале купила xAI. Один разработчик моделей арендовал суперкомпьютер у другого, и рынок принял это спокойно.

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

Первое оружие: гигаватты

Мощность для ИИ сейчас считают в гигаваттах, а число ускорителей идёт вторым. Чипы можно купить за месяцы, а подключение нового дата-центра к сети и охлаждение занимают годы. Отсюда и анонсы сделок, где мощность стоит первой строкой.

OpenAI подробнее всех рассказывает, сколько мощности у неё уже работает. Финансовый директор компании в январе привела цифры: 0,2 ГВт в 2023 году, 0,6 ГВт в 2024-м и около 1,9 ГВт в 2025-м. В апреле 2026 года OpenAI сообщила, что по контрактам уже набрала больше 10 ГВт и перекрыла цель Stargate на 2029 год. Под неё подписаны и договоры на железо: с NVIDIA на 5 ГВт систем Vera Rubin, с AMD на 6 ГВт, с Broadcom на 10 ГВт собственных ускорителей и с AWS примерно на 2 ГВт Trainium. Складывать эти цифры не стоит, потому что во многом это чипы для тех же дата-центров.

Подписанная мощность ещё не работает. По оценке Epoch AI, которая следит за стройками по спутниковым снимкам и заявлениям подрядчиков, в середине апреля из семи площадок Stargate работала одна, в Абилине, примерно на 0,3 ГВт. Сама Epoch ждала там 0,6 ГВт к концу мая и 1,2 ГВт к концу года. А расширение Абилина сверх 1,2 ГВт в марте остановили из-за задержек с подключением к энергосети.

AWS обещает Anthropic до 5 ГВт, из них около 1 ГВт на Trainium к концу 2026 года. Google ещё в 2025 году договорилась поставить ей до миллиона TPU, а Broadcom на сентябрьском звонке с инвесторами рассказала о 1 ГВт Ironwood для Anthropic в 2026 году и ещё 5 ГВт TPU 8i в 2027-м. Дальше идут до 1 ГВт в Azure, до 2 ГВт на AMD, Colossus 1 и собственные дата-центры в Техасе и Нью-Йорке. Сколько из этого уже работает, Anthropic не раскрывает.

xAI строит быстро: первый Colossus, по словам компании, собрали за 122 дня. В проспекте SpaceX к IPO сказано, что Colossus и Colossus II вместе дают около 1 ГВт. Google зависит от чужого железа меньше всех: у неё своё облако, свои дата-центры и TPU, которые она разрабатывает вместе с Broadcom. Alphabet на 2026 год закладывает от 195 до 205 млрд долларов капитальных затрат.

Для масштаба: у Amazon план около 220 млрд долларов, у Microsoft – около 175 млрд, у Meta – 130–145 млрд. Большая часть этих денег уходит в дата-центры, которыми потом пользуются в том числе OpenAI и Anthropic.

Google заявляет для 8t до 2,7 раза лучшую производительность на доллар в обучении, чем у Ironwood. Это цифры самой компании, независимых замеров пока нет, а общую доступность обещали к концу года. В апреле Google ещё и объявила, что начнёт поставлять TPU отдельным клиентам для их собственных дата-центров. Первая выручка от этого ожидается в конце 2026 года, основная – в 2027-м.

У Amazon своя линия, Trainium. Третье поколение доступно с декабря 2025 года, у него 144 ГБ HBM3e на чип, а среди клиентов Amazon называет и Anthropic, и OpenAI. Microsoft в январе запустила Maia 200 и обслуживает на ней в том числе модели GPT-5.2.

OpenAI заказала свой чип у Broadcom. Ускоритель Jalapeño для инференса по собственным замерам OpenAI на пике пропускной способности делает в 1,5–1,9 раза больше работы на ватт, чем системы GB200 и GB300. Broadcom в сентябре сообщила, что начала отгрузки, а развёртывание на 1,3 ГВт запланировано на 2027 год.

xAI по-прежнему считает всё на NVIDIA. Стройка не ждёт, пока созреет свой кремний, но и наценку NVIDIA компании приходится оплачивать целиком.

Третье оружие: облако без эксклюзива

Ещё пару лет назад OpenAI жила в Azure, Anthropic – в AWS, Gemini – в Google Cloud. В 2026 году эксклюзивы почти исчезли. В апреле OpenAI и Microsoft переписали договор: OpenAI может продавать свои продукты через любое облако, хотя новинки по-прежнему выходят сначала в Azure. С июня модели OpenAI и Codex общедоступны в Amazon Bedrock. Claude с конца 2025 года есть во всех трёх крупнейших облаках, а Grok продаётся через Microsoft Foundry и Oracle OCI.

Дело в том, как покупают крупные клиенты. У банка или ритейлера уже есть договор с облаком, согласованные требования безопасности и бюджет, который надо потратить. Модель, которой нет в этом облаке, для них почти не существует. Вот поставщики моделей и идут туда, где у клиента уже лежат деньги.

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

Зависимость работает в обе стороны. Привязаны не только клиенты, но и сами лаборатории: контракт OpenAI на 250 млрд долларов в Azure или обязательство Anthropic потратить больше 100 млрд в AWS за десять лет держат их не слабее, чем облачный договор держит банк.

Четвёртое оружие: цена токена

Для разработчика вся эта война в итоге сводится к счёту за API. Вот что стоят флагманские и «рабочие» модели на начало октября 2026 года по стандартному тарифу и для запросов до 200 тысяч токенов:

Рынок разделился. Самые мощные модели продаются как премиум: GPT-6 Astra и Claude Fable 5.1 стоят одинаково, 10 долларов за миллион входных токенов и 50 за миллион выходных. Для сравнения, флагманский GPT-5 в 2025 году стоил 1,25 и 10. Gemini 4 Argon, который пока не вышел в открытый API, Google анонсировала по промо-цене 2 и 10 долларов, а после промо – 4 и 20.

В среднем сегменте, наоборот, идёт ценовая война. GPT-6.1 Sol, Gemini 3.1 Pro и Grok 4.7 стоят на входе по 2 доллара. Opus год назад стоил 15 и 75 долларов, а Opus 5.5 – уже 4 и 20.

Бывает и обратное движение. На странице цен Gemini 3.8 Flash прямо написано, что с 1 января 2027 года вход подорожает с 0,75 до 1,5 доллара, а выход – с 3,75 до 7,5. Google причин не называет, но похоже, что заканчивается промо-период.

На длинной дистанции цены всё же падают. Epoch AI посчитала, что стоимость одного и того же результата на математических и научных бенчмарках с 2023 года снижалась примерно в 13 раз в год, быстрее всего в первые месяцы после выхода модели-рекордсмена.

Но цена за токен ещё не цена задачи. Artificial Analysis прогоняет модели по одному набору тестов и показывает среднюю стоимость одной задачи. Grok 4.7 в режиме xhigh обходится в 3,74 доллара за задачу, а GPT-6.1 Sol в режиме max – в 0,72, хотя тарифы у них близкие. И набирает Sol больше: 52 балла против 46. Модель, которая много рассуждает, съедает разницу в тарифе своими токенами.

Пятое оружие: экосистема для разработчиков

Последнее оружие – инструменты разработчика. У каждой из четырёх компаний есть свой агент для кода: Codex у OpenAI, Claude Code у Anthropic, Gemini CLI у Google, Grok Build у xAI. Как они устроены и чем отличаются, мы можем разобрать в отдельной статье, здесь важнее другое.

Часть экосистемы стала общей. Протокол MCP для подключения инструментов к моделям придумала Anthropic, а потом его поддержали и OpenAI, и Google. Инструмент, написанный один раз, работает с моделями разных поставщиков, и это снижает цену переезда.

С открытыми весами картина другая. OpenAI, Google и xAI выложили модели с открытыми весами: gpt-oss, Gemma и Grok 2. Их можно запустить на своём сервере и не зависеть от чужого API. Claude доступен только через API и облака, так что команда, которой нужна модель у себя, к Anthropic с этим не придёт.

А что с самими моделями

Разрыв между лучшими моделями на удивление мал. В индексе Artificial Analysis на начало октября первое место у Claude Opus 5.5 с 58 баллами, но в режиме max, где задача стоит около 6 долларов. GPT-6 Astra набирает 53 балла за 3,26 доллара, Gemini 4 Argon – 53 за 1,99, Grok 4.7 – 46.

На арене, где модели сравнивают живые пользователи, первое место у Gemini 4 Argon, а между первым и четвёртым местом около 20 очков. При этом GPT-6 Astra там на 29-м месте, а Grok 4.7 – на 92-м, так что разные площадки видят разных лидеров. А классический тест на программирование SWE-bench Verified потерял доверие: OpenAI перестала публиковать по нему результаты, потому что нашла ошибки в тестах и следы задач в обучающих данных.

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

Что думаем мы

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

По этому критерию у каждой компании своя сильная сторона и своя уязвимость. Google меньше всех зависит от чужих чипов и облаков, но её новый флагман Gemini 4 Argon пока доступен только узкому кругу клиентов. OpenAI собрала больше всех контрактов и публикует рабочие гигаватты по годам, поэтому разрыв между подписанным и работающим у неё виден лучше всего. Абилин показал, что энергосеть договором не ускоришь. Anthropic разложила заказы по четырём платформам, но почти всё её железо принадлежит другим, а сколько мощности у неё работает, она не раскрывает. xAI строит свои кластеры быстрее остальных, но сидит на одном поставщике чипов, а Colossus 1 SpaceX сдала конкуренту.

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

Получите 15% кешбэка на первое пополнение только в Aéza

«Я сократил её с 9 000 голов примерно до 5 000, потому что мне нужно меньше голов». Это глава Salesforce Марк Бениофф в конце лета 2025 года рассказывает в подкасте про свою службу поддержки. По его словам, половину разговоров с клиентами там теперь ведут ИИ-агенты.

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

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

Позиция A: замена уже идёт, просто тихо

Сторонники этой позиции начинают с поддержки. В феврале 2024 года Klarna отчиталась, что её ИИ-помощник за первый месяц провёл 2,3 млн разговоров, взял на себя две трети чатов и сделал работу, на которую понадобилось бы 700 операторов. К ноябрю 2025 года компания оценивала его уже в 853 сотрудника и 60 млн долларов экономии.

Массовых увольнений при этом не было, и на этом лагерь A строит главный аргумент. Klarna почти перестала нанимать, и за год штат сократился примерно с 4 500 до 3 500 человек, ушедших не заменяли. Глава компании сам связывал это с ИИ. В новостях такое не выглядит как «ИИ отнял работу», хотя, по версии самой Klarna, дело как раз в нём.

Второй момент – фриланс. Исследователи изучили объявления на крупной фриланс-платформе после выхода ChatGPT. На навыки, которые ИИ закрывает сам, вроде текстов и переводов, спрос упал на 20–50% по сравнению с тем, что было бы при прежнем тренде. Сильнее всего пострадали короткие заказы на срок от одной до трёх недель. С картинками похоже. По данным другого исследования, после появления генераторов изображений объявлений о создании картинок стало на 17% меньше.

В России ситуация похожая. По данным hh.ru, за январь–август 2024 года вакансий копирайтера стало на 23% меньше, чем годом раньше, а вакансий редактора – на 44% меньше. В 2026 году, как пишут «Известия», копирайтеры и редакторы разместили больше 213 тысяч резюме при примерно 5 тысячах вакансий. В августе на одно место претендовали больше 80 человек.

И самое неприятное – молодые специалисты. Исследователи из Стэнфорда разобрали зарплатные данные миллионов работников в США по июнь 2026 года. Занятость людей 22–25 лет в профессиях, где ИИ применим сильнее всего, оказалась на 19% ниже, чем можно было бы ожидать, если сравнивать с ровесниками из менее затронутых профессий. Причём молодых в основном реже нанимают, а увольняют их не чаще прежнего. И падение видно там, где ИИ делает работу вместо человека. Где он только помогает, занятость молодых стоит на месте или растёт.

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

Позиция Б: ИИ ускоряет, а увольняют люди

Вторая сторона отвечает исследованием, которое стало классикой. Экономисты проследили, что произошло, когда 5 179 операторам поддержки одной крупной компании ещё в 2020–2021 годах дали ИИ-подсказчика. Число решённых обращений в час выросло в среднем на 14%, а у новичков – на 34%. Про сокращения в работе речи нет. Операторы стали работать быстрее и даже реже уходили из компании сами.

Отдельная история – сама Klarna. Тот же глава компании, который рассказывал про 700 операторов, в мае 2025 года сказал, что ИИ-поддержка дешевле, но хуже, и что у клиента всегда должна быть возможность поговорить с человеком. Компания начала набирать операторов на удалёнку. А расходы на поддержку и операционную работу в третьем квартале 2025 года всё равно составили 50 млн долларов против 42 млн годом раньше. Klarna за это время выросла, так что сравнивать напрямую сложно, но и вывода «бот сэкономил всё» не получается.

Если отойти от отдельных компаний и посмотреть на рынок целиком, какой-то сенсации тоже не видно. Yale Budget Lab следит за структурой занятости в США с момента выхода ChatGPT и даже в данных по август 2026 года не видит заметной ломки.

Прогнозы тоже без паники. Международная организация труда оценивает, что с генеративным ИИ так или иначе пересекается четверть рабочих мест в мире, а в богатых странах – треть. Сильнее всего затронута офисная работа, но и там МОТ ожидает, что профессии в основном изменятся, а не исчезнут. Всемирный экономический форум к 2030 году прогнозирует 170 млн новых рабочих мест против 92 млн исчезнувших, и причины там не только в ИИ.

Сторонники позиции Б любят пример IBM. В мае 2025 года глава компании Арвинд Кришна рассказал, что ИИ-агенты взяли на себя работу пары сотен сотрудников HR. Но общая численность IBM при этом выросла. Освободившиеся деньги ушли на найм программистов и продавцов. Работу заменили, людей стало больше.

Ещё один довод Б – остыл весь рынок труда. На hh.ru в апреле 2026 года на одну вакансию приходилось в среднем 10,3 резюме, а нормальным считается до восьми. Тяжело сейчас всем. Правда, у копирайтеров конкуренция в восемь раз выше средней, и это сторонникам Б объяснить сложнее. Да и сами авторы стэнфордского исследования предупреждают, что их данные описывают картину, но не доказывают, что виноват именно ИИ. Часть разрыва объясняется образованием, а некоторые тренды начались ещё до ChatGPT.

Зато работа с текстом переезжает в соседние роли. В том же материале «Известий» есть и другие цифры: по данным «Авито Работы», спрос на SMM-специалистов в 2026 году вырос на 29%, а вакансий для контент-менеджеров опубликовано около 20 тысяч, вчетверо больше, чем для копирайтеров. Тексты по-прежнему кто-то пишет, только должность называется иначе и требует других навыков.

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

У сторонников A на историю Klarna, правда, есть ответ. Бота никто не отключил, по данным компании на конец 2025 года он ведёт около двух третей чатов. Людей вернули, чтобы у клиента был выход на живого оператора, а типовые вопросы, судя по всему, так и остались за ботом. Выходит, «откат» больше похож на тонкую настройку: сколько работы можно отдать ИИ, прежде чем клиенты начнут жаловаться.

Сводим обе позиции в одну таблицу

Если разложить аргументы по конкретным задачам, видно, что стороны часто говорят о разных вещах:

Позиция A смотрит на найм и заказы. Позиция Б смотрит на увольнения и производительность. И считают обе стороны честно.

Что думаем мы

На наш взгляд, ближе к правде позиция A. Замена идёт, и идёт через тех, кого не наняли. Но у неё есть чёткая граница, и тут права уже позиция Б. ИИ забирает не профессии целиком, а задачи определённого типа.

Объяснение у этого вполне техническое. Сегодняшние модели лучше всего справляются с задачами, где результат легко проверить, а ошибка обходится дёшево. Черновик перевода человек со знанием языка проверит за минуту. Типовой ответ про статус заказа легко сверить с базой. Если бот ошибся, клиент напишет ещё раз, и ничего страшного не случится.

На таких задачах раньше и учились новички. Младший оператор отвечал на простые вопросы, начинающий переводчик брал короткие заказы. Для ИИ нижние ступеньки карьерной лестницы – самые простые, их и убирают первыми.

А там, где ошибка стоит дорого, работу возвращают людям – Klarna это хорошо показала. Спорное списание денег или жалоба разозлённого клиента по-прежнему достаются человеку.

Работа уходит от специалистов и иначе. В отчёте OpenAI за июль 2026 года приводятся примеры: продавец может сам разобрать клиентские данные, которые раньше отдал бы аналитику, а владелец небольшой компании – сам написать текст. Аналитика при этом никто не увольнял, его могут просто не позвать. И это опять история про ненанятых.

Отсюда вопрос, который нас беспокоит сильнее, чем сокращения. Если нижних ступенек становится меньше, откуда через пять лет возьмутся опытные специалисты, которые будут проверять работу ИИ? Ответа на него пока нет ни у сторонников A, ни у сторонников Б.

Если вы только начинаете, ищите задачи, где ошибка стоит дорого и где нужно отвечать за результат. На наш взгляд, умение быстро поймать ошибку модели сейчас ценнее, чем умение быстро написать черновик. А компаниям, которые уже сэкономили на рутине, стоило бы часть этой экономии вкладывать в найм и обучение новичков.

А как у вас? Какие задачи на вашей работе за последние год-два ушли ИИ целиком, а какие после красивого демо всё равно вернулись к людям? Вашу команду сократили, перестали расширять или, наоборот, она стала брать больше работы? Если вы считаете, что мы ошибаемся и права позиция Б, расскажите, что видите у себя.

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

Что провайдер защищает, а что – нет

Хостинг-провайдер отвечает за физическую инфраструктуру, гипервизор и сетевую изоляцию между машинами. Операционная система, открытые порты, учётные записи и конфигурации сервисов остаются зоной ответственности администратора.

После выдачи машины проверьте стартовые настройки доступа: на части образов всё ещё может быть открыт root-доступ по паролю, SSH часто принимает соединения на стандартном порту 22, а пакеты могут требовать обновления. У многих современных провайдеров вход по паролю или под root уже отключён по умолчанию, но это нельзя считать универсальным правилом. Автоматические сканеры добираются до нового сервера в течение нескольких минут после получения публичного IP.

Baseline: минимум для нового VPS

Настройка VPS начинается не с деплоя приложения. Базовый харденинг нового сервера занимает 15–30 минут и снижает риск типовых атак: брутфорса SSH, сканирования открытых портов и эксплуатации устаревших пакетов.

Создайте непривилегированного пользователя с sudo и настройте аутентификацию по SSH-ключу. Root-логин по паролю отключите в /etc/ssh/sshd_config директивой PermitRootLogin no. Смена стандартного порта SSH снижает шум от автоматических сканеров.

Firewall и fail2ban

Настройте ufw или iptables: разрешите только нужные порты, остальное заблокируйте. Утилита fail2ban автоматически банит IP после серии неудачных попыток входа и хорошо дополняет правила firewall.

Автообновления и мониторинг логов

Включите unattended-upgrades для автоматической установки обновлений безопасности. Периодический просмотр /var/log/auth.log и вывода journalctl помогает заметить подозрительную активность до того, как она перерастёт в инцидент.

Чек-лист baseline-настроек

•  Создан непривилегированный пользователь с sudo

•  Root-логин по паролю отключён

•  SSH-аутентификация переведена на ключи

•  При необходимости изменён стандартный порт SSH

•  ufw или iptables настроен, лишние порты закрыты

•  fail2ban установлен и активен

•  unattended-upgrades включен

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

Провайдер может обещать 99,9% аптайма VPS, но аптайм продукта и аптайм инфраструктурного узла остаются разными показателями. Когда сервис падает, причина часто находится за пределами зоны ответственности провайдера: в приложении, деплое, базе данных, DNS или внешних API.

Что именно гарантирует VPS-провайдер

SLA VPS-провайдера покрывает доступность физического узла, сетевого канала и питания. Если оборудование работает и сеть доступна, инфраструктурная часть SLA может считаться выполненной. Код, конфигурации, база данных и внешние зависимости остаются в вашей зоне ответственности.

Где на самом деле ломается аптайм

На практике многие простои возникают не из-за сбоев инфраструктуры, а из-за ошибок в коде и операционных процессах. Неудачный деплой, утечка памяти, переполненный диск, истёкший SSL-сертификат, недоступный DNS или упавший сторонний API гасят сервис независимо от стабильности хостинга.

Ошибки на стороне команды

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

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

Стабильность сервиса на VPS складывается из нескольких пунктов. Автоматические бэкапы и снапшоты упрощают восстановление после сбоя. Проверки состояния и алерты сокращают время обнаружения инцидента. CI/CD-пайплайн с проверками и понятным откатом снижает риск ошибок при деплое.

Чек-лист надёжности

•  Бэкапы и снапшоты настроены и проверены

•  Мониторинг и алерты подключены до деплоя

•  Есть процедура отката для каждого релиза

•  SSL-сертификаты обновляются автоматически

•  DNS TTL снижен перед плановыми миграциями

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

Пометка NVMe в тарифе не гарантирует предсказуемых задержек для Cloud VPS. Реальные характеристики дисковой подсистемы зависят от архитектуры хранилища, QoS-политик и уровня виртуализации I/O. NVMe важен, но не решающий фактор.

Что на самом деле определяет скорость диска в VPS

Производительность VPS под дисковой нагрузкой ограничивается несколькими факторами одновременно. QoS-политика и burst-лимиты IOPS могут влиять на результат не меньше, чем тип накопителя. Виртуализация I/O через virtio добавляет небольшой накладной расход. Конкуренция соседей по хосту даёт непредсказуемость p99-задержек.

Local NVMe vs сетевое хранилище

Local NVMe даёт наименьшую задержку: p99 в пределах 100–300 мкс. Сетевые решения (NVMe-oF, Ceph RBD, SDS) повышают p99 из-за сетевого round-trip, зато включают репликацию и снапшоты. Выбор NVMe VPS оправдан для stateful-нагрузок с жёсткими требованиями к fsync-задержкам.

IOPS, латентность и предсказуемость под нагрузкой БД

PostgreSQL и MySQL создают смешанную дисковую нагрузку: случайное чтение небольших блоков, fsync для WAL и последовательные сканирования. В продакшен-среде на Cloud VPS p99-задержка fsync напрямую влияет на задержку коммита. Burst-лимиты могут скрывать ограничение дисковой подсистемы до тех пор, пока нагрузка не превысит гарантированный уровень IOPS.

Как правильно бенчмаркать

Классическая ошибка: фиксировать средний throughput вместо p99-latency. Запускайте fio с параметрами --rw=randread --bs=4k --iodepth=32 и смотрите процентили задержки. Утилита ioping показывает задержку одиночного I/O. Для PostgreSQL используйте pgbench после нескольких прогонов на прогрев кэша.

Что узнать у провайдера до миграции

•  Гарантированные IOPS и burst-лимит вашего VPS

•  Архитектура хранилища: локальный NVMe или распределённое хранилище

•  Есть ли гарантии по p99-задержке

•  Схема репликации и RPO при сбое диска

•  Доступность снапшотов и периодичность их создания

•  Наличие оверкоммита и политика изоляции I/O

Тип диска в тарифе – это отправная точка. Перед миграцией проверьте дисковую подсистему по чек-листу и прогоните собственные тесты: реальные p99-задержки и стабильность IOPS могут отличаться от описания тарифа.