AI в проде

Что почитать про LLM в проде: подборка с Хабра

Неделя про границы: что агенту можно, кто это проверяет и как ловить код, который модель просто придумала.

1. Как я ловлю галлюцинации LLM в коде: пайплайн проверок в CI - вызов несуществующей функции в «домашнем» стиле прошёл ревью и тесты на одной платформе, а упал только в ночном билде. Цепочка проверок вокруг сборки, которая ловит выдуманный код, и во что она обходится.
https://habr.com/ru/articles/1096132/

2. ИИ-агенту разрешили не больше 100 единиц. Три корректных ALLOW дали итог 120 - лимит 100, три заказа по 40, каждый прошёл авторизацию, а в ERP 120. Почему проверять надо итоговое состояние, а не отдельный вызов.
https://habr.com/ru/articles/1095622/

3. Tool calling в Go: почему вызов модели ещё не разрешение выполнить команду - валидный tool call не значит, что операцию можно выполнять. Разбор на примере ассистента поддержки SaaS, где права проверяет код, а не модель.
https://habr.com/ru/articles/1096036/

4. Как мы запускали агента в CI по расписанию - opencode-cli в GitLab CI на обычных раннерах в Docker: сначала отлаживаешь скилл локально, потом заворачиваешь в джобу. Пример с разбором прогона автотестов, упор на то, чтобы это было безопасно.
https://habr.com/ru/articles/1096674/

5. Как мы внедряли LLM в модерацию Авито - регламент до 200 страниц, и выбор между RAG, «всё в контекст» и промптом, собранным по регламенту. Что пришлось достроить вокруг модели, чтобы она выдержала прод.
https://habr.com/ru/companies/avito/articles/1095230/

6. Оценка агентных систем - как собрать пайплайн оценки, чтобы видеть, улучшила новая фича качество агента или только ощущения от него.
https://habr.com/ru/articles/1096406/

7. Слепой краш-тест 27 LLM осени 2026 (GPT-6, Opus, Алиса): кто сломал JSON, проглотил инъекцию и влетел на 152-ФЗ - 27 моделей под слепыми кодами через один 6-шаговый пайплайн, таблица юнит-экономики и исходники с логами на GitHub. Полезно перед выбором модели под конкретный пайплайн.
https://habr.com/ru/articles/1096934/

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

#LLM #Хабр

llm-d 1.0: инференс LLM в Kubernetes дорос до второго дня

20 октября на PyTorch Conference вышел llm-d 1.0. Это Kubernetes-native стек для распределённого инференса поверх vLLM и SGLang, проект в CNCF Sandbox, больше 500 контрибьюторов из 25+ организаций. Собран из того, что у многих уже стоит: Gateway API, LeaderWorkerSet, Dynamic Resource Allocation, Prometheus, OpenTelemetry.

Prefix-aware роутинг и разделение prefill/decode были и раньше. В 1.0 добавили то, что нужно для эксплуатации:
- flow control с приоритетами и честной очередью по тенантам. При перегрузке роутер держит запросы у себя, а не забивает и без того загруженные бэкенды. По умолчанию всё работает как FIFO, так что ничего не поменяется, пока сами не включите;
- hot standby для роутера, чтобы при раскатке маршрутизация не пропадала;
- DisaggregatedSet: prefill и decode обновляются как одно целое, запрос идёт на пару только когда обе стороны раскатаны и совместимы;
- конфиг API стал v1, обещают не ломать его между релизами;
- для агентов session-aware роутинг (разговор держится на реплике, где уже лежит его KV-кеш) и previous_response_id из Responses API, чтобы агент не гонял всю историю заново.

Самая интересная цифра в анонсе от IBM Research: до 3000 одновременных coding-агентов на 544 H100, prefix-cache hit около 98%, примерно $0,11 за миллион токенов. Это их замер на их нагрузке, но порядок показательный: у агентов почти весь трафик это повторяющийся контекст, и кеш решает.

Если вы сейчас держите vLLM за обычным Service с round-robin, я бы начал с роутинга по префиксу, это самый дешёвый выигрыш.

Источники:
https://llm-d.ai/blog/llm-d-v1.0-state-of-the-art-inference-ready-for-day-2
https://github.com/llm-d/llm-d/releases

#LLM #Kubernetes #инференс

Muse Spark Open от Meta: 816B, но не Apache

15 октября Meta выложила веса Muse Spark Open. Это MoE на 816B параметров, из них 42B активных на токен, контекст до миллиона токенов. На вход принимает текст, картинки, аудио и видео, на выход текст. Обучали под агентный код: рефакторинг на много файлов, долгие сессии отладки, вызов тулзов.

Что важно тем, кто сам поднимает инференс:
- чекпоинты в BF16 и NVFP4. BF16 весит около 1,5 ТБ, в Transformers его запускают на 4 нодах по 8 H200, NVFP4 помещается в одну ноду B200;
- поддержка с первого дня в vLLM, SGLang, TensorRT-LLM, llama.cpp и MLX;
- Meta отдельно показывает запуск на двух Mac Studio с M5 Ultra по 512 ГБ unified memory.

Недавно я писал про Beam под Apache 2.0. Здесь другая история: веса под Muse Model License с ограниченными коммерческими условиями. Прежде чем тащить модель в продукт, я бы отдал лицензию юристам, а не полагался на слово «open».

Источники:
https://research.meta.ai/blog/muse-spark-open
https://huggingface.co/blog/meta-muse-spark-open

#LLM #OpenWeights #MoE

Beam от Reflection: 501B под Apache 2.0

Reflection выложила веса своей первой открытой модели Beam на Hugging Face под Apache 2.0, без отдельной «модельной» лицензии с оговорками. Это MoE на 501B параметров, из них 23B активных на токен, контекст около миллиона токенов. Заточена под код и длинные агентные задачи.

Для тех, кто сам поднимает инференс, интереснее комплект поставки. Веса сразу в BF16, FP8 и NVFP4, плюс отдельная драфт-модель для speculative decoding. Поддержка с первого дня в vLLM, SGLang, Transformers и Dynamo, так что кастомный сервинг писать не нужно.

В блоге vLLM есть цифры, которые стоит держать в голове при планировании:
- драфт-голова DFlash2 предсказывает сразу блок токенов, а не по одному;
- на реплее многоходовых сессий с кодом около 88K токенов/с на GPU при 96 параллельных запросах, но при попадании в кэш входных токенов 91–96%.

Последний пункт я бы не пропускал. Для агентов цифры держатся на prefix-кэше, без него пропускная способность будет совсем другой.

Источники:
https://reflection.ai/blog/beam-is-available
https://vllm.ai/blog/2026-10-16-reflection-beam

#LLM #OpenWeights #vLLM

Агент, который собирает агентов, в одном YAML

В CNCF вышел пошаговый лаб по kagent, это Sandbox-проект, где агент — custom resource в Kubernetes. Авторы собирают на kind агента-конструктор: описываешь задачу словами, он пишет манифест Agent и применяет его. Модель локальная через Ollama.

Мне тут интересны три слоя защиты, которые не зависят от промпта:
- toolNames как allowlist: из 22 инструментов модель видит три;
- requireApproval на k8s_apply_manifest, без клика человека ничего не применится;
- RBAC: только read-only плюс запись agents.kagent.dev.

Деталь, которую я бы забрал себе: по умолчанию чарт даёт ServiceAccount инструментов cluster-admin. Это первое, что стоит выключить. И проверить:
kubectl auth can-i create deployments \
--as=system:serviceaccount:kagent:kagent-tools -n kagent
Про модели: qwen2.5 на 7B и 14B ошибались с вызовом инструментов, стабильно справилась qwen3-coder:30b-a3b. И авторы честно предупреждают, что лаб без аутентификации и только для ноутбука.

Источник: https://www.cncf.io/blog/2026/10/12/from-zero-to-agent-builder-running-kagent-on-your-laptop/

#kagent #Kubernetes #AIagents

Не давайте агенту root. Пусть присылает PR

В блоге CNCF дельная колонка мейнтейнера Kairos про то, сколько прав давать ИИ-агенту на проде. Мысль простая. Если агент с root, а от катастрофы его держит только аккуратный AGENTS.md, вы себя обманываете: модель недетерминирована, и гарантий нет.

Что автор предлагает:
- хост иммутабельный (bootc, Flatcar, Kairos), изменения базы идут новым образом, а не пакетами на лету;
- сам агент — обычный короткоживущий workload, изоляция по модели угроз: под, sandboxed-под или VM;
- агент смотрит систему и открывает PR со следующим состоянием, а дальше ревью, тесты, сборка, подпись, релиз.

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

Практический шаг на сегодня: проверьте, что у токена вашего агента в Git нет прав на merge и на .github/workflows.

Источник: https://www.cncf.io/blog/2026/10/08/dont-give-ai-agents-root-make-them-propose-the-next-system-state/

#AIagents #GitOps #PlatformEngineering

80B-модель на ноутбуке с 32 ГБ памяти

На HN всплыл Janas — движок на чистом C для MoE-моделей, которые не влезают в RAM. Веса лежат на диске, нужные токену эксперты читаются с NVMe, а частые остаются в памяти.

Цифры автора с одного ноутбука (Core Ultra 9 185H, встроенная Arc, 32 ГБ). Qwen3-Next-80B весит 48,4 ГБ, то есть больше памяти. Генерация 24 tok/s против 2,8 у llama.cpp, а с draft-моделями до 37. Чтение промпта 62 против 16. На моделях, которые влезают в память, отрыв скромнее: Qwen3-30B-A3B пишет 32 tok/s против 15.

Попробовать на Linux x86-64:
curl -LO https://github.com/prabanta-dev/janas/releases/latest/download/janas-linux-x86_64.tar.gz
tar xf janas-linux-x86_64.tar.gz && cd janas && ./janas-chat
Только честно: автор сам пишет, что это эксперимент, проверенный на одной машине. Движок забивает свободную память кэшем и читает диск через O_DIRECT, десктоп может уйти в swap. Я бы гонял его на отдельной машине, а замеры делал своим janas-bench, а не верил чужим таблицам.

Источник: https://github.com/prabanta-dev/janas

#LocalLLM #MoE #inference

Пусть агент пишет скрипт, а не дёргает тулзы по одной

Армин Ронахер, автор Flask, написал, зачем в агенте Pi 1.0 появился Codemode. Мысль простая, и мне она кажется правильной. Модель не вызывает инструменты по одному, протаскивая каждый ответ через контекст. Она пишет короткий JS-скрипт, который сам вызывает тулзы, параллелит и фильтрует.

Крутится это в QuickJS внутри WASM-песочницы. Ни сети, ни файловой системы, ни таймеров, память ограничена. Наружу можно только через разрешённые инструменты. Агент обычно сначала щупает 5–10 элементов, а потом пишет скрипт на остальные n.

Выигрыш понятный. Большие ответы MCP не забивают контекст, вызовы собираются через Promise.all (в Pi до 4 параллельно), а состояние между вызовами живёт в store().

Если пишете свой MCP-сервер, вот что я вынес из поста. Отдавайте structured content через outputSchema. Возвращайте данные одной формы, хоть 5 записей, хоть 500. И не надо «экономить токены» на больших батчах, скрипты агента от этого ломаются.

Пробовали уже такой подход?

Источник: https://lucumr.pocoo.org/2026/10/6/codemode/

#AIагенты #MCP #LLM

Поиск по своим runbook'ам, не выходя из контура

Google выпустила EmbeddingGemma 2, открытую модель эмбеддингов под Apache 2.0. Я давно ждал что-то такого размера для внутренних инструментов.

Всего 740M параметров, а если нужен только текст, хватает 270M. Энкодеры картинок и аудио подключаются отдельно, по желанию. На коде прирост заметный, MTEB Code вырос с 68,76 до 78,68. Контекст 8K токенов, в четыре раза больше, чем у первой версии. Запускается через sentence-transformers, vLLM, llama.cpp, Ollama, векторы можно складывать в тот же Qdrant.

Самое практичное, на мой взгляд, — Matryoshka. Вектор режется с 768 до 512, 256 или 128 измерений, экономия места до 6x.

Сценарий напрашивается сам. Семантический поиск по runbook'ам, постмортемам и Terraform-модулям, который работает внутри и ничего не отправляет наружу. Безопасники будут довольны.

Я бы начал с 256 измерений и сравнил с 768 на реальных запросах. Часто разницы почти нет, а индекс втрое меньше.

Источник: https://blog.google/innovation-and-ai/technology/developers-tools/embeddinggemma-2/

#RAG #эмбеддинги #LocalLLM

Что почитать про LLM в проде: подборка с Хабра

Две недели на Хабре по ИИ, отфильтровал то, где есть цифры и конфиги, а не восторги.

1. Как мы запустили ИИ-ревьюера на 4000 PR в день — и какие баги он находит — Яндекс про NeuroReview. Проверка на Opus стоила $3,42, на Qwen $0,041, и в прод пошёл Qwen.
https://habr.com/ru/companies/yandex/articles/1089752/

2. Может ли локальная 27B-модель расследовать продакшен-инцидент как Claude? Две RTX 5090, около 40 прогонов и одна гонка — смогла, но за два часа против двадцати минут и не в каждом прогоне. Честный вывод про стоимость времени.
https://habr.com/ru/articles/1090016/

3. Почему не стоит писать AI-агента с нуля: что скрывается внутри harness — из чего на самом деле состоит агент и почему цикл «запрос → tool call» это только начало.
https://habr.com/ru/articles/1091582/

4. Qwen3.8–27B на двух RTX 3060 12ГБ: как я разогнал OpenCode с ~9 до ~40 токенов/с при 128K контекста — tensor split, Q8 KV-cache и подбор MTP на реальной нагрузке, с итоговой командой запуска.
https://habr.com/ru/articles/1086742/

5. От чата c LLM к полноценному AI-агенту: пошаговая настройка OpenCode — правила проекта, скиллы, MCP. Хороший вход, если пока сидите в чате.
https://habr.com/ru/companies/selectel/articles/1087524/

6. Как запустить Gemma на сервере: сравниваем Ollama и llama.cpp — на одном запросе разница минимальна, под параллельной нагрузкой llama.cpp отрывается.
https://habr.com/ru/companies/selectel/articles/1088372/

7. Гибридный RAG на Налоговом кодексе: восемь находок, семь потерь — как поднять качество базового RAG, прежде чем лезть в GraphRAG и агентов.
https://habr.com/ru/companies/ruvds/articles/1050162/

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

#LLM #Хабр