Artificial Intelligence

LLM-стек в продакшене: что реально работает в середине 2026 года

By Anurag Verma•June 5, 2026

Стек LLM в продакшне: что реально работает в середине 2026 года

Продакшн-системы на основе LLM пересекли черту, о которой большинство материалов по ИИ ещё не успело написать: сами модели больше не являются главной сложностью. Получить хорошее completion от Claude 3.5 Sonnet или Gemini 2.0 Flash сегодня -- это базовый минимум. Настоящая инженерная задача -- всё, что вокруг модели: эффективность инференса, качество retrieval, надёжность агентов и контроль затрат при тех объёмах запросов, которые генерируют реальные агентные нагрузки.

Я запускаю LLM-функциональность в продакшне последние восемнадцать месяцев, и стек изменился существенно. Вот что я знаю наверняка по состоянию на июнь 2026 года.

Слой инференса: vLLM победил -- пока

Если вы хостите модели самостоятельно, выбор фреймворка для инференса имеет большее значение, чем принято считать. Три серьёзных варианта -- vLLM, SGLang и TensorRT-LLM -- и у каждого своя ниша. vLLM -- правильная отправная точка почти для любой команды. Он поддерживает наибольший диапазон моделей, не требует шага компиляции и стабильно выдаёт конкурентоспособную пропускную способность за счёт PagedAttention и непрерывного батчинга. SGLang вырывается вперёд на нагрузках с общим префиксом, где важно время до первого токена, -- например, в RAG-пайплайнах, которые добавляют один и тот же длинный системный промпт к каждому запросу. TensorRT-LLM оправдывает сложность настройки только тогда, когда у вас зафиксирована конкретная модель на месяцы вперёд и нужно выжать максимум токенов в секунду при больших нагрузках.

TGI от HuggingFace официально переведён в режим поддержки. Сам HuggingFace теперь рекомендует vLLM или SGLang. Думаю, это однозначный сигнал.

Производственная стек-архитектура для серьёзных развёртываний состоит из трёх уровней: движок инференса на ускорительном оборудовании, обслуживающий слой, отвечающий за маршрутизацию и API-контракты (LiteLLM или Envoy AI Gateway), и уровень оркестрации на базе Kubernetes с KEDA для автомасштабирования. Инженеры теперь работают в рамках следующих целевых показателей производительности: TTFT не более 300 мс для стандартных нагрузок и межтокенная задержка в десятки миллисекунд.

Стоимость: математика изменилась, проблема осталась

Цены на API упали примерно на 80% с 2025 по 2026 год. Производительность уровня GPT-4 теперь обходится примерно в $0,40 за миллион токенов по сравнению с $30 за миллион в начале 2023 года. Это выглядит как решённая проблема, пока не принимаешь во внимание, что агентные системы делают на самом деле: одна пользовательская задача может породить от 50 до 200 вызовов LLM. Дешёвая цена за токен очень быстро превращается в дорогую цену за задачу.

Техники, которые реально дают результат, -- это кэширование промптов (сокращает затраты на ввод до 90% при повторяющихся контекстах), квантизация FP8 в сочетании с Flash Attention 3 и спекулятивным декодированием, а также умная маршрутизация запросов, отправляющая более простые подзадачи меньшим и дешёвым моделям. Спекулятивное декодирование стоит тщательно профилировать: оно использует небольшую черновую модель для генерации токенов-кандидатов, которые основная модель проверяет параллельно, однако если скорость принятия падает ниже примерно 0,5 токена за шаг, вы добавляете накладные расходы, а не снижаете их.

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

RAG: проблема по-прежнему в поиске

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

Гибридное извлечение, сочетающее плотный векторный поиск с BM25 и последующим перерасчётом с помощью cross-encoder, является текущим базовым стандартом для производственных систем. Чистый векторный поиск уступает в точности при запросах, требующих высокой точности результатов. Граф-усиленное извлечение набирает популярность в областях со структурированными связями между сущностями. И вопрос управления источниками знаний, а именно кто отвечает за актуальность фрагментов, дедупликацию и контроль качества, является продуктовым решением, которое инженерные команды раз за разом пытаются отложить, пока это не обернётся проблемой.

Агенты и MCP: стандарт, который прижился

Model Context Protocol от Anthropic, представленный в конце 2024 года, стал доминирующим стандартом для подключения инструментов к LLM-агентам. OpenAI приняла его в марте 2025 года и впоследствии объявила об устаревании Assistants API с запланированным прекращением поддержки в середине 2026 года. Это сочетание вынудило экосистему прийти к единому стандарту. Cursor, Cline и большинство серьёзных сред разработки на основе агентов теперь ожидают MCP-совместимых серверов инструментов.

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

Наблюдаемость: больше не опционально

Langfuse был приобретён ClickHouse в январе 2026 года, и это многое говорит о направлении рынка: конвейеры трассировки нуждаются в базах данных, способных справляться с объёмами записей, которые генерируют продакшн-агенты. Ведущие платформы в этой области -- LangSmith (оптимальный выбор для стеков на базе LangChain), Langfuse (лучший вариант для самостоятельного развёртывания) и Arize Phoenix (наиболее сильный в рабочих процессах с интенсивным использованием RAG).

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

Галлюцинации: метрика, а не бинарная оценка

Галлюцинации по-прежнему остаются главным препятствием для высокорисковых производственных развёртываний. Важный сдвиг в 2026 году состоит в том, что команды в большинстве своём перестали рассматривать их как бинарный результат «прошёл/не прошёл» и начали измерять как частоту. Обнаружение с использованием LLM-в-роли-судьи позволяет выявить от 60 до 75% галлюцинированных ответов в зависимости от дизайна промптов. В задачах с заземлением на извлечённые данные в хорошо спроектированных системах частота падает ниже 2%. Стандартом стали гарды реального времени, которые проверяют выходные данные перед отправкой и направляют помеченные ответы на проверку, хотя задержка обнаружения в 200--500 мс создаёт реальную нагрузку на бюджеты латентности.

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

Что это означает для стека

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