GPU-кластеры, RAG и LLM-агенты в production: итоги года с локальной AI-инфраструктурой

Год заканчивается, и у нас есть что сказать. Не в смысле громких выводов - просто первый полный календарный год, когда локальная AI-инфраструктура у нескольких заказчиков работала именно в production, а не в виде презентации на совете директоров. Этого достаточно, чтобы разделить: что работает, что не работает, и где мы просто переоценили скорость.

GPU-кластер: работает, но дорого и требователен к рукам

В июле мы запустили первый production GPU-кластер для инференса LLM - три узла на A100, отечественные серверы, vLLM, Kubernetes. Кластер до сих пор работает, нагрузка реальная, заказчик доволен. Но за полгода накопилось несколько наблюдений, которые стоит зафиксировать.

GPU-память - главный ресурс, не FLOPS. Это звучит банально, но проявляется конкретно: при планировании кластера все смотрят на вычислительную мощность, а узким местом оказывается HBM-память. 70B-модель в fp16 занимает больше 140 ГБ только весами, и когда добавляется KV-cache под реальную нагрузку - цифры становятся некомфортными. Несколько заказчиков, с которыми мы обсуждали расширение, неприятно удивились: «мы думали, четыре A100 - это с запасом».

Сеть между узлами - не экономьте. Это мы говорили в июле, говорим сейчас. 25GbE для межузловой коммуникации при tensor parallelism - это боль. Кто заложил в бюджет нормальную сеть с самого начала - не жалеет. Кто сэкономил - переделывает.

Отечественные серверы работают, но документация - отдельная история. Несколько параметров BIOS, критичных для GPU-производительности, пришлось выяснять через вендорскую поддержку и методом проб. Это не фатально, но время.

RAG: самый зрелый из трёх сценариев

RAG-пайплайн - то, что дошло до production у наибольшего числа заказчиков. Понятная архитектура, понятный эффект, относительно небольшие требования к GPU по сравнению с агентными сценариями. Если у заказчика есть корпоративная база знаний - несколько тысяч документов и выше - RAG закрывает реальную потребность.

Что мы наблюдали за год:

• pgvector вырос. В начале года его воспринимали как «RAG для бедных» - мол, нормальным людям нужен Weaviate или Qdrant. По итогам работы с несколькими инсталляциями: pgvector на хорошо настроенном PostgreSQL закрывает большинство задач до нескольких миллионов векторов без ощутимых проблем. Специализированная векторная база нужна, когда есть конкретные требования к throughput при миллиардах векторов или специфические индексы - а не «для солидности».
• Chunking и re-ranking решают больше, чем выбор модели. Это самый частый урок. Заказчики иногда хотят сменить LLM, думая, что это улучшит качество ответов. Чаще выясняется, что проблема в том, как нарезаны документы или что ретривер достаёт нерелевантные куски. Качество RAG - это прежде всего качество индекса и ретривера.
• Отечественные LLM в RAG - работаемо при подходящих ограничениях. GigaChat и YandexGPT API мы пробовали как замену локальному инференсу. Техническое качество нормальное, но контрактные ограничения для КИИ-заказчиков делают облачные API неприменимыми. On-premise деплой у обоих вендоров - пока пилотная история, не общедоступный продукт.

LLM-агенты: работают в узком периметре, не работают широко

Осенью мы запустили LLM-агента на первой линии helpdesk - он закрывает около 40% тикетов без оператора. Это реальный production-результат. Но важен контекст: агент работает с жёстко ограниченным набором операций (сброс пароля, разблокировка учётки, поиск по KB, эскалация), и этот ограниченный периметр - не временная мера, а принципиальное архитектурное решение.

Попытки расширить агента на более сложные сценарии в этом году давали стабильный результат: PoC работает, production нет.

Почему широкие агентные сценарии зависают на PoC? Несколько причин, которые мы видим одинаково у разных заказчиков:

• Надёжность tool calls при длинных цепочках. Агент на 3-4 шага работает хорошо. Агент на 8-10 шагов с ветвлением начинает ошибаться в местах, которые сложно предсказать заранее. Накопленные ошибки в контексте приводят к решениям, которые технически корректны с точки зрения промпта, но неправильны по смыслу задачи.
• Аудит и ответственность. У заказчиков из КИИ каждое действие агента должно быть объяснимо и аудируемо. Простые операции (сброс пароля) - аудируются нормально. Сложные (агент самостоятельно меняет конфигурацию сервиса) - вызывают вопросы на уровне службы ИБ, и правильно вызывают.
• Качество инструментов имеет значение. Агент хорош настолько, насколько хороши его tool-функции. Плохо написанный инструмент с нечёткими возвращаемыми значениями или плохой обработкой ошибок ломает агента гарантированно.

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

Что осталось за бортом production в 2025

Автономные DevOps-агенты - несколько заказчиков интересовались агентами, которые сами перезапускают сервисы, сами разбираются с алертами, сами делают rollback. PoC сделали. В production не пошли: слишком широкие права, слишком высокие требования к надёжности цепочки решений. Человек в петле остался.

Файн-тюнинг под корпоративный домен - большинство заказчиков хотели дообученную модель. Где дошли до файн-тюнинга - получили прирост на доменных задачах. Но накладные расходы на поддержку собственной модели (хранение, версионирование, переобучение при обновлении документов) оказались выше ожиданий. Несколько заказчиков вернулись к хорошему prompting + RAG вместо файн-тюнинга.

Мультимодальность - были запросы на работу с изображениями в RAG-пайплайне (сканы документов, схемы). Технически это работает, но качество OCR и качество понимания изображений у доступных в периметре моделей оставляет желать лучшего на сложных корпоративных документах.

Итог по состоянию на декабрь

Честная картина такая: GPU-инференс и RAG - рабочие технологии, которые дают измеримый результат при правильной архитектуре и управляемых ожиданиях. LLM-агенты - работают в узком периметре, не работают как универсальный автопилот. Это не разочарование - это нормальная инженерная зрелость технологии.

Инфраструктуру такого рода мы ведём в рамках managed-сопровождения. Если у вас стоит задача не запустить PoC, а понять что именно из этого можно довести до production в вашем контексте - готовы разобраться вместе.