Впервые в истории люди оказываются дешевле софта Аналитики из a16z свели данные по затратам на ИИ в компаниях и нарисовали вот такие интересные картинки. Если кратко, они посчитали, что в топ-1% компаниях распределения расходы на ИИ-токены в расчете на одного сотрудника практически сравнялись с средней годовой зарплатой инженера. При этом за последнее время рост был экспоненциальным, так что при таком векторе развития к концу года инженеры уже будут сильно проигрывать LLMкам в зарплате. Забавно, правда? Нам-то обещали, что будет наоборот. И это речь только про явные затраты. Если копнуть глубже, то оказывается, что помимо затрат на токены ИИ также генерирует множество новых рабочих мест: второй график показывает, что компании с высокой интенсивностью использования ИИ за 2 года после внедрения нарастили штат на +10,2%, тогда как компании с низкими расходами на ИИ остались практически на месте, штат почти не изменился. (Но это всего лишь корреляция, которая может объясняться и другими факторами.) www.a16z.news/p/the-next-ai-goldrush-tokens-loops

Да, кстати по вышеизложенным причинам не будет никакого единорога из одного человека (вернее может парочка и будет, но это не будет системным явлением), а многие проекты с ИИ-агентами передохнут.  Ну и самое интересное, что крупные LLM на самом деле не имеют такого большого барьера на вход, как всем кажется сейчас, потому что через 2-3 года будет много достаточно дешевых моделей с вполне приемлемым качеством для большинства задач. Эти модели будут развернуты компаниями или в собственном облаке, или локально на компьютерах. Производителям LLM останется только ниша, в которой клиентам нужны будут самые качественные и продвинутые модели. Вообщем я изложил свою точку зрения. А вы сами решайте, слушать меня или нет. #economicsforstartups

Короче, у нас за более чем десятилетнюю карьеру клоунов в интернете сохранилось примерно сотня сценариев с ютуба, а так же больше тысячи рекламных постов в телеге. Эксперты в каментах, ставлю вам амбициозную задачу — спрогнозировать, че будет, если мы возьмем какую-нибудь тупую модельку и сделаем на ее основе цифровой слепок сознания ехтримсоде. Ведь всегда приятно поболтать с кем-то таким же умным как ты. Че как лучше к решению задачки подойти, какую модельку брать за базовую, как подготовить данные (тупо простыню текста скидывать или мутить чето типа [инструкция -> вывод])? Я заколебался писать рекламу руками, хочу чтобы за меня делал это нейроехтримкод. А обычные модели не могут в достаточной степени подражать нашему стилю писанины.

В своих выступлениях Андрей Карпаты рассказывает о том, что он начал разрабатывать программы, выстраивая агентный цикл (Loop Engineering). Это интересная механика, которую я примерно полгода назад пытался использовать в своем оркестраторе. Идея в том, чтобы не говорить ИИ, что делать конкретно, а вместо этого выстроить цикл постепенного написания и улучшения кода. Эдакий эволюционный подход. На самом деле все, кто серьезно занимаются разработкой с помощью ИИ, рано или поздно приходят к этой идее, так как ИИ довольно специфично работает с механизмом внимания (attention) и страдает от разных "эффектов" - потеря информации в середине контекста (lost-in-the-middle), ослабление фокуса на ранних инструкциях, излишнее якорение (anchoring bias) и накопление ошибок (error accumulation), когда модель достраивает решение вокруг уже сгенерированного кода, даже если там есть проблема. Из-за этого модель может пропускать важные детали, даже если указать на них явно. При этом ИИ способен находить отклонения и ошибки если запустить его повторно. Поэтому запуская модель в цикле можно получить нормальный результат. Но есть несколько проблем. Во-первых, большое потребление токенов. Например, средний цикл на 8-10 часов использует от 30 до 60 млн токенов. Если брать токены через API, то получается довольно дорого. Во-вторых, в длинных циклах агент начинает "дрейфовать", постепенно уходя в сторону от поставленной задачи. Проблема в том, что критерии приемки сложно сформулировать так, чтобы они покрывали все детали - сосредоточившись на одном аспекте, упускаешь другие. Даже если проводить многоступенчатые проверки, остается проблема "2 из 3" - когда ты не можешь закрыть все требования одновременно и вынужден идти на компромисс. Чем длиннее цикл, тем сильнее этот эффект. Поэтому я пошел другим путем: вместо того чтобы отказываться от циклов, я делаю их максимально короткими. Плюс ограничиваю количество итераций, а для вариативности решений запускаю несколько агентов с разными системными промптами параллельно, оркестрируя их через общий чат для сбора и сравнения результатов. Коммуникация в чате помогает понять не только "что" делают агенты, но и "почему" они это делают. Кроме чата каждый агент производит артефакты, которые далее могут использовать другими агентами. Если интересно, напишу отдельный пост про агентный харнес, который я использую. Понятно, что с позиции OpenAI, Anthropic и других разработчиков LLM методы, которые способствуют большему потреблению токенов, имеют большую привлекательность - в конце концов, их бизнес-модель строится на продаже токенов. Но для небольших исследований и малого бизнеса подходы с дроблением задач и короткими циклами - куда более эффективный метод, позволяющий сохранить качество кода, не сжигая бюджет и не допуская дрейфа агентов. Мне кажется, что сейчас ключевой навык инженера - не просто умение писать промпты, а способность декомпозировать задачу и настраивать агентную оркестрацию с короткими циклами так, чтобы каждый шаг давал предсказуемый результат. Это и есть та инженерия, которая нужна бизнесу. Но это на словах, на практике доверять агентам пока рано.

Одну важную вещь я поймал на днях с AI консилиумами: когда вы просите консилиум дать свое мнение по определенному вопросу, то важно правильно ограничить видимость агентов; в противном случае - они прочитают факт/вывод в папке проекта и выдадут один и тот же, уже известный ответ. И тогда вся идея разнообразия мнений разбивается о стенку Что у меня произошло: Я в течение 4 дней исследовал одну проблему на пару с дружбаном - why-tree, просмотр сессий и тп. И на какой-то из итераций с консилиумом я заметил, что они стали оперировать фактами, которые им не должны были быть известны. Тут можно было подумать, что они или гении, или нагаллюцинировали... Начал копать и заметил, что у некоторых участников подозрительно много вызовов тулов —> выяснилось, что поскольку у них были тулы, чтобы читать файлы - то они решили, прежде чем дать свое мнение, почитать все что есть в проекте, ну и наткнулись на этот контекст, а далее уже было достаточно сложно их мнение "разнообразить". К слову, цитата из моего поста 3 года назад:

В Empatika Open, посвященной моему обучению в Stanford, я рассказывал про неприятный феномен групповых обсуждений, когда участники фокусируются на общем знании, теряя уникальное знание каждого. Как снизить вероятность такого поведения?

Собственно, именно таким неосторожным загрязнением (contamination) контекста мы и можем предопределить однообразие мнений участников консилиума - как человеческих, так и AI. Как лечится? 1) можно ограничить тулы, что даете субагентам (не давать им читать файлы) 2) явно попросить закарантинить файлы, которые им не должны быть доступны 3) давать разные задачи участникам - "опровергни", "найди чего не хватает", "перепроверь цифры", "скажи, что тебя переубедит" Attention is all you need 😉 P.S. Скилл я, разумеется, по мотивам проапдейтил, но пару седых волос точно прибавилось

Подборка об RL и ризонинге Рассказываем об улучшении RL для сложных задач, оптимизация в RLVR одной строкой кода (!) и обучении компактной модели для дипресёрча. Reuse your FLOPs: Scaling RL on Hard Problems by Conditioning on Very Off-Policy Prefixes При обучении RL на сложных задачах есть две основные проблемы: 1. Большинство роллаутов — wrong, поэтому положительные примеры для основной части задач не появляются. 2. Сложно дообучать модель, когда так мало положительного сигнала. Улучшение происходит скорее за счёт роста общей «умности» модели на более простых тасках. Авторы предлагают метод Prefix-RL, который как раз направлен на решение сложных задач: 🔴Для них семплируются ответы, и из всех семплов выбирается правильный ответ. 🔴Собираются prefixed problems: промпт + префиксы правильного ответа. 🔴На обучении модель видит исходную задачу и набор prefixed problems и учится продолжать хорошую цепочку. Получается метод, который консистентен с on-policy RL, обладает высоким sample efficiency и может ускорять self-improvement. По замерам авторов, Prefix-RL в сравнении с mid-training SFT + GRPO прокрашивает AIME 2025 больше чем на 12 пунктов при том же компьюте на обучении. Проводят аблейшен на Llama, добавляя в prefixed problems генерации Qwen. Это даёт около +5% при том же компьюте относительно Prefix-RL на prefixed problems инит-модели. Получается что-то похожее на эффективную дистилляцию во время RL. Back-generalization — один из важных выводов статьи. Обучение на цепочках с префиксами улучшает решение задач без них, то есть модель при обучении не попадает в зависимость от подсказок. При этом back-generalization позволяет модели писать начало ответа не той стратегией, что была в префиксах на обучении. Хотя автор сказал, что в агентском обучении аналогичный метод они не пробовали, он хорошо обобщается на агентский сетап: в роли префикса выступает часть траектории. Maximum Likelihood Reinforcement Learning Кликбейт: поменяйте строчку в расчёте advantage, замените std в нормировке на mean в своём RLVR — и всё полетит. Проблема в целом стандартная: GRPO учит модель максимизировать среднюю награду (pass@1), а не вероятность успеха. Из-за этого он «залипает» на лёгких задачах и почти не учится на сложных. В RLVR средний reward — это аппроксимация вероятности правильного ответа (так как награда 0/1). Предлагают взять log p (логарифм вероятности правильного ответа) и разложить его в ряд Маклорена по pass@k — вероятности получить «хотя бы один верный из k независимых семплов». Получается бесконечная сумма вкладов от одной, двух, трёх попыток и так далее с весами 1/k. MaxRL берёт усечение этого ряда до вычислительного бюджета g, то есть размера группы в GRPO. Чем больше семплов N на инференсе, тем выше truncation T ряда и тем ближе к точному ML. Если на пальцах, метод даёт меньше внимания группам, где решаемость уже высокая, и больше смотрит на сложные. MaxRL даёт до 20× прирост эффективности test-time scaling относительно GRPO, Pareto-доминирование по pass@1 и pass@k и лучше масштабируется с данными и вычислениям. Попробовать метод можно дёшево: если уже есть RLVR, достаточно поменять одну строчку в расчёте advantage. Но работ, которые пытаются решить эту проблему, много, и пока непонятно, какая идея окажется лучшей. DR Tulu: Reinforcement Learning with Evolving Rubrics for Deep Research Популярный постер на конференции. Ребята смогли получить лёгкую модель дипресёрча с крутым качеством за счёт генерации и обновления рубрик. Изначально при обучении модели давали небольшое количество хорошо написанных рубрик. После каждой итерации обучения смотрели на изменения в ответах, для них генерировали дополнительные рубрики и джаджем оценивали их качество. При этом генерация рубрик и оценка тоже выполнялись лёгкой моделью. За счёт этого цикла получилось обучить модель собирать больше полезной информации и не галлюцинировать. В итоге сделали лёгкую модель (8B), которая по качеству сравнима с топовыми моделями дипресёрча. Увидели интересное ❣ Даниил Кириллов, Тимофей Смирнов, Иван Дёгтев #YaICML2026 Душный NLP

Как понять, нужен ли вашему продукту ИИ (часть 2) В прошлый раз мы рассмотрели подробно, в каких задачах хорошо себя показывают ML, LLM, RAG и ИИ-агенты — удобная сравнительная таблица на слайде 1. Но выбор решения должен исходить из стратегических вопросов. Разберем фреймворк, который помогает точно выбрать подходящую ИИ-технологию или инструмент для вашего контекста. ❌ Частые ошибки при поиске ИИ-решения для продукта: — Выбирать модель раньше, чем продумали работу с данными: какие данные есть, хватит ли их, где они лежат, как получить к ним доступ? Этот этап занимает много времени, и если не оценить заранее его трудоемкость, можно сильно сдвинуть сроки. — Считать, что любая ИИ-функция должна отвечать мгновенно. На самом деле далеко не всегда — например, классификацию пользователей достаточно проводить раз в месяц. Работа в реальном времени резко повышает стоимость решения, поэтому такой режим стоит использовать только там, где он действительно необходим. — Надеяться на решение комплексной задачи одним инструментом. Если загрузить весь объем данных в одну модель, то результат будет в большей или меньшей степени состоять из галлюцинаций. — Запустить и забыть. Модель на проде нужно дообучать и переобучать в случае применения к другим продуктам, даже в схожих контекстах. ✅ Этапы использования ИИ в продукте 1️⃣ Четко сформулируйте бизнес-задачу, которую хотите решить с помощью ИИ. Она должна быть: — актуальна и значима для компании (автоматизация, сокращение времени); — иметь измеримые последствия (деньги, время, ресурсы). Для отслеживания прогресса сразу стоит: — определить ключевую метрику; — нарисовать схему процесса As Is → To Be. 2️⃣ Переведите бизнес-задачу в задачу для ИИ. Классический ML — К какому типу ML-задач относится ваш кейс? — Что будет являться целевой переменной, что модель должна предсказывать? — В чем бизнес-смысл этого предсказания? — На каком этапе бизнес-процесса будет использоваться модельное решение? — Какие математические метрики будут проверять качество модели? Генеративные модели — Какой тип генеративной архитектуры вы используете — LLM (GPT-подобная), diffusion, VAE, GAN или гибрид? — Что именно должна генерировать модель и по каким правилам? — В чем бизнесовая ценность этой генерации? — На каком шаге пользовательского/операционного процесса запускается генерация? — Какими метриками будете мерить качество вывода? 3️⃣ Подготовить данные. — Какие данные планируется использовать для обучения модели? Какие ключевые признаки? — На какую дату признаки должны собираться? Будут ли к этой дате известны показания по всем признакам? — Требуются ли внешние источники данных? — Требуются ли дополнительные действия для сбора данных? — Есть ли ограничения по использованию данных/моделей? — Можно ли отправлять данные за контур компании в вендорское решение? — За какой период (срок наблюдения) собираются данные? — Все ли данные уже есть в промышленных системах, или потребуется дополнительное подключение? 4️⃣ Выберите режим для модели. — Как часто будет работать модель: Batch — раз в день/неделю/месяц. Online — в момент действия пользователя. — Как часто нужно делать предсказание? — Есть ли требования к скорости ответа? 5️⃣ Продумайте внедрение в продукт. — Как модель будет интегрирована в бизнес-процессы и существующую архитектуру? — Требуется ли API или встраивание в существующие сервисы? — Нужно ли менять интерфейсы или бизнес-логику продукта? — Кто отвечает за поддержку и обновление модели после внедрения? — Как будет организована обратная связь от пользователей для улучшения качества предсказания? 6️⃣ Запланируйте регулярный мониторинг. — Какие метрики качества будут отслеживаться? — Как будет происходить мониторинг деградации модели? — Кто отвечает за реакцию на падение качества? — Как часто планируется переобучение модели? — Есть ли процесс аварийного отключения модели и возврата к ручному процессу? — Как будут учитываться требования по безопасности и хранению данных в эксплуатации? 7️⃣ Постройте систему метрик (слайд 5). В ней важно учитывать: — продуктовые метрики — от менеджера продуктов и бизнеса; — ML-метрики — от дата-сайентиста; — метрики связи продукта с ML. Только после этого имеет смысл выбирать между классическим ML, LLM, RAG или агентной архитектурой. И иногда правильным ответом окажется вовсе не генеративный ИИ. По мотивам мастер-класса «Нужен ли вашему продукту искусственный интеллект?» Михаила Войтко на ProductSense’25 💙 VK 🖤 YouTube @productsense

Время измен — Мы верны Claude, — сказал стартапер — А если завтра Gemini станет лучше? — Не станет Ребята из одного нашего стартапа пол-весны вылизывали промпты под Claude, обвязали их костылями и гордились «глубокой интеграцией». Вышел ChatGPT 5.6 — половина нагороженного стала мешать. Пока отдирали — конкурент обогнал их на голом апи. Сейчас время королевской гонки и корона держится у модели в среднем 41 день. С точки зрения венчурного инвестора, это — катастрофа. А вот создателя продукта — чудо. Каждые полтора месяца ты получаешь либо более умный мозг либо тот же, но дешевле. Ни-фи-га не делая, просто меняя одну строчку в конфиге. Это как если бы ключевой сотрудник каждые 40 дней становился вдвое умнее или соглашался на вдвое меньшую зарплату. А ты бы еще выбирал между тремя такими. Поэтому «жениться» на модели — ошибка. Верность в этом браке наказывается. Лучшая стратегия — чемодан у двери. Вывод прост: не влюбляйся в модель — влюбляйся в возможность её бросить. Архитектура, где мозг меняется одной строчкой, сегодня стоит дороже самого мозга.

💸 Я откатываю свои ИИ-рутины с Sonnet 5 обратно на Opus 4.8 Пару недель назад, как только вышел Claude Sonnet 5, я шустро перевёл на него штук пять своих рабочих рутин. Обещали красиво: лучше, быстрее и почти такой же умный, как Opus, только дешевле. Прошло две недели — и я меняю модель обратно. Сел, разобрался в цифрах, и картина оказалась ровно противоположной обещанной. 1. Скрытая наценка ~30% через токенайзер. Вместе с Opus 4.7 Anthropic сменила токенайзер — тот же текст теперь дробится на до 35% больше токенов, это признаёт даже документация самой Anthropic. Ставка за токен «не менялась» — но платишь-то за количество. С Opus 4.7 это уже проходили: у людей счёт вырос на 27%, хотя на странице цен ничего не поменялось. The Decoder зовёт это паттерном скрытого повышения цен. 2. Дороже за реальную задачу. Независимый замер Artificial Analysis: полный прогон Intelligence Index обошёлся в $2.29 за задачу на Sonnet 5 против $1.97 на Opus 4.8. «Дешёвая» модель по факту вышла дороже флагмана — потому что жрёт ~40% больше выходных токенов и делает втрое больше шагов. 3. Тупее на ровном месте. И это не за «больше ума» — наоборот. Opus 4.8 сейчас — первая модель мира на Intelligence Index (61.4), Sonnet 5 — 53. На агентном кодинге SWE-bench Pro — 69% против 63%. Для рутин это реально сорвавшиеся прогоны и лишние итерации. 4. Заставишь думать — сожрёт больше Opus. Поднимаешь effort, чтобы вытянуть качество, — и Sonnet 5 по стоимости обгоняет Opus 4.8 при сопоставимом результате. А сам Opus 4.8 при этом стал ещё и экономнее: ту же работу делает на 15% меньшим числом шагов и с 35% меньшим числом токенов, чем 4.7. Честно, где Sonnet 5 хорош: простые задачи на низком усилии (суммаризация, классификация, извлечение) и период вводной цены ($2/$10 до 31 августа) — там он реально дешевле. Но мои рутины — многошаговые агентные прогоны, где включаются и токенайзер, и мышление, и лишние итерации. Именно там математика разворачивается против него. Вывод. «Премиальный» ценник Opus 4.8 оказался дешевле в пересчёте на выполненную работу — и умнее. Мораль: считайте стоимость по задаче, а не по ставке за токен. Именно на этой подмене построена вся «экономия». 🎯 НЕЙРО-ПУШКА ● НОВОСТИ И ОБЗОРЫ НЕЙРОСЕТЕЙ

Нейродайджест за две недели (#122) LLM - LongCat 2.0 — Первая большая LLM на китайских чипах. Meituan выкатили модель на 1.6T параметров, обученную на 50 тысячах ускорителей типа Huawei Ascend. Эмбеддинги занимают 10% весов, а контекст достигает миллиона токенов. - Claude Sonnet 5 — По перформансу модель подтянулась к Opus 4.8. Доступ открыли всем, включая бесплатных пользователей, а на API до конца лета действует промо-прайс. - Снятие ограничений с Anthropic — Эпичная развязка истории с блокировкой Fable 5. В детальном разборе инцидента подтвердилось, что модель нашла уязвимость в Amazon и написала под неё эксплоит. Теперь запросы фильтрует жёсткий классификатор, а доступ к модели полностью вернули. - Muse Spark 1.1 — Meta обновила модель с сильным упором на агентный кодинг и выкатила собственный API, выдавая $20 кредитов новым аккаунтам. - Grok 4.5 — SpaceXAI , при помощи Cursor, дотренировали свою модель на полтора триллиона параметров. Вышло неплохо, модель стоит всего $2/$6 за миллион токенов при небольших контекстах, лишь немногим больше GPT 5.6 Luna. - GPT 5.6 — Sol стала доступна платным юзерам, Terra и Luna — бесплатным. Вдогонку запустили агента ChatGPT Work, публикацию мини-сайтов и объединили Codex с ChatGPT на десктопе. - Продление доступа к Fable по подписке — Anthropic почувствовали конкуренцию с OpenAI и решили оставить Fable по подписке ещё на неделю. Генеративные модели - Comfy MCP — Благодаря интеграции с MCP больше не нужно тонуть в спагетти-пайплайнах: ИИ-агент сам найдёт нужные ноды и соберёт любой воркфлоу. - Muse Image и Muse Video — гибридные модели от Meta для генерации визуала. Muse Image сама пишет код для точной вставки графики, верстает на HTML и сама исправляет косяки. Прочее - Штраф для Google — Компания окончательно проиграла апелляцию в ЕС на $4.68 млрд за принудительную предустановку Search и Chrome на Android. > Читать дайджест #121 #дайджест @ai_newz

Сделал экспресс-тест дешевых облачных моделей для переводов продуктовых отзывов с англ на ру. Очень хороша оказалась Gemma 4 26B на openrouter - по костам значительно эффективнее flash 3.1 lite; по качеству в разы лучше Google Translate (условно-бесплатного). Пример:

The carbon fiber plate in these is snappy! I shaved 15 seconds off my mile pace on the first run. But man, the upper is paper-thin and feels like plastic. I'm worried it will tear if a twig catches it. Definitely a race-day only shoe, not a daily driver. Super pricey too.

google translate:

Пластина из углеродного волокна в них отличная! На первом забеге я сбил свой темп на милю на 15 секунд. Но, черт возьми, верх тонкий, как бумага, и на ощупь напоминает пластик. Я боюсь, что он порвется, если его зацепит ветка. Определенно обувь предназначена только для гонок, а не для повседневного использования. Очень дорогой.

gemma 4 26B:

Карбоновая пластина в этих кроссовках — просто пушка, очень отзывчивая! На первой же пробежке я скинул 15 секунд со своего темпа на милю. Но блин, верх тонкий как бумага и на ощупь как пластик. Переживаю, что порвутся, если зацеплюсь за какую-нибудь ветку. Однозначно кроссовки только для соревнований, а не на каждый день. И цена, конечно, кусается.

31B тоже хорошая, но дороже. flash lite - еще дороже. qwen 3.6 - тоже дорогой. Начал разбираться, читать отзывы - выяснилось что Gemma 4 как раз отлично подходит для одношаговых задач, а ее слабое место - tool calling. Для переводов европейских языков - рекомендую.

😱 Коду не нужна документация!  Когда LLM начали генерировать мне кучу кода, я решил что хорошей идей будет начать вести документацию к этому коду на понятном человеческом языке. Тогда я думал что это поможет мне понять что там написали агенты быстрее и лучше. 🤷‍♂️ В итоге не прокатило  По факту я просто внедрял в систему еще одно тонкое место, за которым нужно следить, которое нужно поддерживать, и, самое главное, которое жрет контекст. 🫠 Тогда я посмотрел на то, как я сам подхожу к изучению и пониманию кода. И оказалось: я просто читаю код. 😅

Когда-то я так разобрался в том как работает Magento, во времена, когда документации к ней практически не было. Я просто открывал исходники и буквально читал как работает этот фрэймворк.

  🤔 И вашему агенту так же не нужна документация. Ему нужен понятный, читаемый и структурированный код.  К такому же выводу пришел и человек со скриншота, Мэт Покок, человек создавший такие скилы как grill-me, to-spec и teach.  Документировать стоит только то, что не описывает код: бизнес домены, архитектурные решения, инфраструктуру и все в таком духе. Экономьте токены, сегодня они не дешевые 😅 Свята место | 10МДК | ВЕБМастер | YHub

Хз как люди пользуется OpenRouter По дурости тестили на нем систему, которая на локалках должна будет работать в контуре клиента, и это такая боль: - низкие лимиты у провайдеров - хрен пойми у кого реально есть поддержка structured output, даже если заявлено - а у кого есть, часто некорректная – натолкнулся на имплементацию с сортировкой ключей в алфавитном порядке 🥴 - нет моделей в целевом кванте - в какой-то момент провайдер просто лег на два часа (а другие не поддерживают норм SO для нужной модели, ага) Да, можно сразу тестить на целевой системе, но а) это нужно получать доступ в контур клиента и б) ждать пока одна его карточка все обработает А у нас autoresearch-like флоу, где агенты в 4 потока эксперименты крутят, нам такое не подходит Короче, надо было сразу арендовать GPU и поднимать там, а не страдать херней. Благо это делается в один промпт (если настроено управление браузером):

Codex, сходи через мой браузер на hf и подними мне vLLM на h200 с <model-name> на <context-len> токенов максимального контекста с <concurrency-num> параллельных запросов. Посмотри в документации и на реддите рекомендации по конфигам и проверь, что мои требования вообще выполнимы или предложи трейдоф

P.s. если нужно часто, установите huggingface_hub и дайте токен админский, чтобы агент через браузер не мучался P.p.s. не забываем потом остановить ноду, а то можно без штанов остаться (если хочется автоматически, юзаем scale_to_zero_timeout=20) Альтернативы: runpod.io, modal.com, cloud.ru (не реклама, а зря) Хз, для кого-то это очевидно, но у нас это первый проект, на котором сошлись локальные модели, отсутствие доступа к железу клиента, и огромный трафик autoresearch подхода