80/20 Почти два года назад я устроился работать в гигакод, где моей задачей была разработка кодинговых агентов. С точки зрения современных агентов, тогдашние предложения были довольно примитивными — ну, был кодчат, который отвечал на вопросы по репозиторию, был автокомплишн, в особо продвинутых случаях, была возможность попросить ллмку написать функцию в файле — и она её впихивала в заданное место с переменным успехом. Я же делал эксперименты именно с мультиагентным написанием кода. У меня был агент, пишущий план, агент, пытающийся ваншотить задачу, был агент-критик, был агент-отладчик, который по трейсбеку правил баги. Если мне не изменяет память, мне тогда удалось с помощью Llama-3-8b-Instruct и моей агентной системы получить скоры на HumanEval уровня Deepseek-Coder-34B в зерошоте, что было очень даже неплохо. Одним из неожиданных результатов экспериментов, который я получил, заключался в том, что если в качестве всех моделей использовать мелкие модели (например, Llama-3-8b-Instruct), а агента, пишущего план оставить большим (например, Llama-3-70b-Instruct), то качество решения задач было сильно выше, чем если план писала такая же маленькая модель. Так можно было не только сэкономить много денег, но и сэкономить много времени. 80% результата делалось 20% компьюта, если можно так выразиться. К сожалению, проект никуда не пошёл, а я ушёл в AIRI писать статьи. Ризонеров тогда ещё не было, а если и были, то довольно слабые — их надо было очень долго ждать, а качество ответов, хоть и превышало качество ответов не ризонеров, но разрыв всё ещё был не таким колоссальным, как сейчас. Тогда я активно использовал Mistral: хоть модели и были хуже аналогов по качеству ответов, мне высокое качество в 95% запросов было и не нужно. Инференс у Mistral был основан на Cerberas, тпс исчислялся в тысячах токенов в секунду, а ответы на простые вопросы (напиши мне аргпарс/ванлайнер на баше/рецепт ризотто) я получал мгновенно. Speed matters when execution is delegated. Сейчас парадигма кодинга с ллм "задал вопрос — использовал ответ для решения задачи" отошла на второй план, заменившись "дал задачу — получил решение через 20 минут — проверил ответ", так что напрямую скорость инференса тут не так важна. Ну да, генерация будет не 20 минут, а 10 или 5, но на самом деле нет такой большой разницы, всё равно между запросами можно успеть сходить налить себе кофе и в очередной раз пролистать главную HackerNews. Приятно, но не больше — а с учётом ухудшения качества ответов, вероятность, что спустя пять минут придётся всё переделывать, велика. К чему я это всё — вчера вышла Codex-5.3-Spark, которую крутят на Cerberas. Это уменьшенная версия 5.3 (предположу, что ~200-500B параметров — потому что самая большая модель, доступная на Cerberas это Qwen-235B, а конкретный размер зависит от поддержки квантизации чипами), которая генерит со скоростью 1000 токенов в секунду. Она сильно хуже, чем Codex-5.3 (Spark-xhigh ~= 5.3 Low как по качеству, так и по времени генерации), имеет контекст в 128k токенов и не поддерживает мультимодальность. В комментах на HN пишут, что модель слабая и код пишет сильно хуже даже 5.2, но мне кажется, что смысл модели не в этом. Если у нас есть большая и умная модель, пишущая планы и верифицирующая решения быстрой и относительно глупой модели поменьше, то мы можем ускорить решение задач практически без потери качества и автономности. Codex-5.3 генерит подробный план на сжатом псевдокоде, Codex-5.3 Spark его реализует, 5.3 валидирует результаты и отправляет Spark править решение. Это не только сэкономит деньги, но и ускорит процесс реализации. Своего рода спекдек, но для агентов. Что забавно, об этом же явно думают и OpenAI. Вместо "мы сделали новую модель, которая займёт парето-фронтир по цене-качеству", как это было на релизе GPT-5, они хвастаются скоростью инференса. То есть, они меняют selling proposition с дешевизны на скорость и это круто. Осталось только настроить агентскую джиру и выдать медленной Codex-5.3 рой быстрых джун