Стек LLM в 2026 году: модели, инференс, инструменты и компромиссы

Если в 2026 году вы делаете реальный ИИ-продукт, вопрос «брать OpenAI или Anthropic?» уже не стоит. Эта постановка устарела на два года. Вы принимаете десятки решений по всему многослойному стеку, и большинство из них имеют значение.

Эта статья — взгляд практикующего архитектора на стек LLM в 2026 году: что находится на каждом уровне, на какие компромиссы вы идёте и куда движется отрасль. Это статья, которую мы сами хотели бы прочитать до того, как совершили все ошибки, которых можно было избежать.

Уровни

Стек, грубо говоря, выглядит так:

┌────────────────────────────────────┐
│       Application Layer            │  Your product / agent / workflow
├────────────────────────────────────┤
│   Orchestration / Frameworks       │  LangGraph, CrewAI, custom, direct
├────────────────────────────────────┤
│   Prompt + Context Management      │  Prompt templates, context engineering
├────────────────────────────────────┤
│   Retrieval / Memory               │  RAG, vector stores, structured memory
├────────────────────────────────────┤
│   Tool / MCP Layer                 │  Tool calling, MCP servers, function APIs
├────────────────────────────────────┤
│   Model Layer                      │  Specific model selection, routing
├────────────────────────────────────┤
│   Inference Layer                  │  Hosted APIs, self-hosted, edge
├────────────────────────────────────┤
│   Observability / Evals            │  Logging, tracing, eval suites
└────────────────────────────────────┘

На каждом уровне есть несколько жизнеспособных вариантов. Выбор на одном уровне ограничивает варианты на других. От ранних решений трудно отказаться: выбор модели влияет на выбор инференса, а тот — на выбор оркестрации.

Пройдёмся по каждому из них.

Уровень 1: модельный слой

Модели в 2026 году группируются по нескольким уровням, и выбор между ними — самое значимое решение в системе на уровне отдельного вызова.

Флагманские рассуждающие модели. Режимы «размышления» текущих флагманов — GPT-5.5 с рассуждением, Claude Opus 4.8 с adaptive thinking, Gemini 3.1 Pro thinking — плюс отдельные рассуждающие модели вроде DeepSeek R1. Отлично справляются с многошаговыми задачами, математикой, кодом, сложным анализом. Дорогие ($3-30 за миллион входных токенов, за выходные заметно больше), медленные (5-60 секунд). Применяйте их, когда узкое место — качество рассуждения.

Флагманские модели общего назначения. GPT-5.5, Claude Sonnet 5, Gemini 3.1 Pro. Отлично справляются с большинством интеллектуальной работы, быстрые (2-5 секунд), умеренно дорогие ($2-5 за миллион входных токенов). Дефолтный выбор для качественных ответов, видимых пользователю.

Модели среднего уровня. Claude Haiku 4.5, Gemini 3.5 Flash, средний уровень OpenAI. Хороши для простых и средних задач, быстрые (1-2 секунды), дешёвые ($1-2.50 за миллион входных токенов). Массово используются в продакшене для классификации, извлечения, простой генерации.

Маленькие / бюджетные модели. Самые младшие актуальные уровни провайдеров (например, Gemini 3 Flash Preview) и небольшие open-source-модели. Достаточно для узких структурированных задач. Очень дёшево ($0.50-1 за миллион входных токенов), очень быстро (<1 секунды). Применяйте для роутинга, скоринга, batch-обработки.

(Прайс-листы сверены 2026-07-07 со страницами цен провайдеров; уровни сдвигаются — перед цитированием перепроверьте.)

Специализированные модели. Embedding-модели, реранкеры, vision-модели, голосовые модели, модели под код. Дешевле универсальных на профильных задачах и обычно лучше. Всегда рассматривайте их для соответствующей задачи.

Open-source-фронтир. Llama 4, DeepSeek V3 / R2, Qwen 3, Mistral Large. Хостятся у провайдеров инференса (Groq, Together, Fireworks) или поднимаются самостоятельно. По цене и качеству конкурируют с закрытыми фронтир-моделями на многих задачах; отстают на некоторых (особенно на длинных цепочках рассуждений).

Из этого следует:

• Одна модель не подходит для всех вызовов вашей системы. Роутинг обязателен ради экономии (см. Уровень 5).
• Фронтир сдвигается каждый квартал. Стройте так, чтобы менять модели, а не привязываться к ним.
• Open-source теперь реально жизнеспособен для многих продакшен-сценариев, а не только для экспериментов.

Уровень 2: слой инференса

Где на самом деле работает ваша модель?

Закрытые API-провайдеры — OpenAI, Anthropic, Google. Быстрейший путь к запуску, лучшие модели, наивысшая надёжность. Вы платите премию и принимаете их модель данных и безопасности.

Провайдеры open-source инференса — Groq, Together AI, Fireworks, Replicate. Запускают открытые модели с разной настройкой. Часто куда быстрее, чем self-hosted; конкурентные цены. (Этот рынок быстро консолидируется — нескольких провайдеров эпохи 2024 года уже не существует; проверяйте жизнеспособность вендора, прежде чем на него завязываться.)

Cloud-native — AWS Bedrock, Azure OpenAI, Google Vertex. Оборачивают закрытые и открытые модели в auth, биллинг и комплаенс вашего облака. Необходимы во многих корпоративных контекстах.

Self-hosted — vLLM, TGI, SGLang, LMDeploy на собственных GPU. Самая низкая стоимость за токен на масштабе. Самая высокая операционная сложность. Обычно стоит рассматривать, только когда расходы на инференс достигают высоких единиц тысяч евро в месяц (см. статью про self-hosted vs hosted для расчётов точки безубыточности).

Edge / on-device — Apple Intelligence, MediaPipe, ONNX, GGUF-модели через Ollama или llama.cpp. Бесплатно за вызов, но возможности модели ограничены. Всё чаще годятся для узких сценариев.

Компромиссы:

• Задержка имеет значение: голосовые агенты и диалоговый UX требуют быстрого первого токена. Здесь доминируют Groq, Cerebras и on-device.
• Пропускная способность имеет значение для пакетной обработки: если вы обрабатываете миллионы записей, вам нужна высокая пропускная способность, а не низкая задержка.
• Комплаенс имеет значение: GDPR, HIPAA, SOC 2 нередко диктуют, какими провайдерами и регионами вы можете пользоваться.
• Вендор-риск имеет значение: зависимость только от одного провайдера — единая точка отказа. Мультипровайдерность — это гигиена.

Типичный паттерн 2026 года: хостинговые закрытые модели на самые качественные пользовательские запросы, хостинговый open-source — на массовую дешёвую работу, on-device — на узкие чувствительные к задержке фичи. Self-hosting — только когда масштаб и экономика оправдывают операционную нагрузку.

Уровень 3: инструменты и MCP

Сами по себе LLM мало на что способны. Они становятся полезными, когда могут вызывать инструменты — функции, которые вы определяете и которые дают им доступ к данным, API и действиям.

Нативный function calling. Каждая крупная модель поддерживает структурированное API для вызова функций. Вы определяете функции через JSON-схемы; модель решает, когда их вызвать; вы выполняете вызов; вы возвращаете результат.

MCP (Model Context Protocol). Стандартизированный протокол (введён Anthropic, теперь широко принят, в том числе OpenAI, Cursor и другими) для серверов инструментов. MCP-сервер выставляет инструменты; MCP-клиент (LLM-агент) к ним подключается и пользуется. Развязывает реализацию инструментов от конкретной модели.

Прямые интеграции. Для специфичных сценариев с высокой нагрузкой (конкретный CRM, конкретная база данных) часто проще написать прямой адаптер, чем универсальный MCP-сервер.

Тренд 2026 года понятен: MCP побеждает в роли стандарта. Большинство новых разработок инструментов должны ориентироваться на MCP. Прямые интеграции остаются полезными для путей, чувствительных к производительности.

Несколько реалий внедрения:

• Описания инструментов имеют огромное значение. Плохо описанный инструмент не будет использоваться правильно. Docstring-и инструментов нужно писать как промпты.
• Количество инструментов имеет значение. Модели с доступом к 50+ инструментам работают хуже, чем с 5-10 релевантными. Агрессивно курируйте.
• Обработка ошибок имеет значение. Ошибки инструментов нужно передавать модели в структурированном виде, чтобы она могла адаптироваться.
• Авторизация — это сложно. Многопользовательская система, где у LLM разные права для разных пользователей, нетривиальна. Не позволяйте LLM принимать решения об авторизации; делайте это в обёртке инструмента.

Уровень 4: извлечение и память

LLM нужны данные, на которых их не обучали. Это слой retrieval.

Векторные базы. Pinecone, Weaviate, Qdrant, Chroma, PostgreSQL с pgvector, Turbopuffer. Хранят эмбеддинги; обслуживают запросы ближайших соседей. Зрелые, понятные. Дефолт для семантического поиска.

Гибридный поиск. Сочетает векторный поиск с классическим keyword-поиском по BM25. Ловит и семантические, и лексические совпадения. Объединение через Reciprocal Rank Fusion. Инструменты: Elasticsearch, OpenSearch, Vespa.

Графы знаний. Neo4j, Memgraph, кастомные triple store. Для данных с богатыми связями. Используются в архитектурах graph RAG. Больше работы на построение, обычно выше качество в доменах, где много связей.

Специализированные RAG-платформы. LlamaIndex (теперь зрелый), абстракции LangChain RAG, Haystack. Высокоуровневые фреймворки для типовых паттернов.

Реранкинг. Cohere Rerank, Voyage, кастомные cross-encoder. После начального retrieval реранжируем топ-кандидаты более дорогой моделью ради точности. Обычно качество retrieval растёт в 2-3 раза.

Память. Для агентов и диалогов — структурированные слои памяти: Mem0, Letta (бывший MemGPT) или кастомные. Различайте кратковременную (текущий диалог), среднесрочную (недавние темы) и долгосрочную (устойчивые факты о пользователе/аккаунте).

Архитектурный вопрос: где этот слой живёт?

• В приложении: вызов LLM обёрнут в retrieval-логику, которую пишет ваша команда.
• На уровне MCP: retrieval выставлен как инструменты.
• Как сервис: отдельный retrieval-сервис, к которому обращаются ваши приложения.

Для монолитных одно-продуктовых систем «в приложении» нормально. Для многопродуктовых организаций отношение к retrieval как к сервису (с единообразным качеством и политиками) окупается.

Уровень 5: инжиниринг промптов и контекста

В 2026 году «prompt engineering» в основном синоним «context engineering» — управления тем, что попадает в контекстное окно каждого вызова.

Компоненты:

Промпты. Часто шаблонизированные с переменными. Хранятся в системе контроля версий. Тестируются оценочными наборами. Считаются кодом.

Управление промптами. Инструменты вроде Promptfoo, Langfuse, PromptLayer или собственные системы. Версионирование, A/B-тестирование, откаты. (Helicone и аналогичные LLM-прокси относятся к слою наблюдаемости ниже, а не сюда — две категории легко спутать.)

Контекстная стратегия. Решения о том, что включать в каждый вызов:

• Системный промпт (стабильный, задаёт поведение).
• Извлечённые знания (динамические, из RAG).
• История диалога (управляемая, часто сжимается при росте длины).
• Few-shot-примеры (выбираются динамически под запрос).
• Описания инструментов (фильтруются до релевантных).
• Текущий запрос пользователя.

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

Использование длинного контекста. Окна на 1M токенов — стандарт текущих флагманов (Claude, GPT-5.5, Gemini). Они работают, но «context rot» — реальность: качество просаживается на длинных входах, даже когда модель технически их поддерживает. Используйте длинный контекст аккуратно; не сваливайте туда всё подряд только потому, что можно.

Уровень 6: оркестрация

Как координировать многошаговые рабочие процессы на LLM и агентов?

Прямое API. Просто напишите цикл сами на Python или TypeScript. Лучше всего для простых случаев и для понимания того, что на самом деле происходит.

LangChain / LangGraph. Широко используется. LangGraph (state machine для агентов) существенно повзрослел. Тяжёлые абстракции, кривая обучения, но мощно.

CrewAI. Многоагентный фреймворк, ориентированный на агентов с ролями. Стартовать проще, чем с LangGraph; менее гибкий.

Агенты LlamaIndex. Особенно сильны в рабочих процессах с интенсивным RAG.

OpenAI Agents SDK. Проще, более opinionated, оптимизирован под модели OpenAI.

Anthropic Claude SDK. Аналогично; оптимизирован под Claude.

Своя реализация. У зрелых команд, выпускающих продакшен-агентов, кастомная оркестрация распространена — фреймворки навешивают издержки (налог на абстракцию, сложность дебага, постоянная смена версий), которые перевешивают пользу.

Паттерн 2026 года: прототипировать на фреймворке; переписать в кастомный код для продакшена. Фреймворки помогают вам обнаружить паттерны; когда они вам ясны, прямой код проще и надёжнее.

Уровень 7: наблюдаемость

Серьёзные LLM-приложения невозможно запускать без наблюдаемости. Любая продакшен-система требует:

Трейсинг. Каждый вызов LLM зафиксирован: timestamp, модель, вход, выход, задержка, стоимость, успех/неудача. Деревья для многошаговых трейсов.

Учёт стоимости. На вызов, на фичу, на пользователя. Расходы большие и неограниченные; без учёта вы узнаёте о них в конце месяца.

Мониторинг качества. Автоматические проверки качества на выборке продакшен-трафика. Алерты на просадки.

Сбор пользовательской обратной связи. Лайки/дизлайки, явный фидбек, неявные сигналы (rate ретраев, отказ от использования).

Дебаг. Когда что-то сломалось, нужно видеть всю цепочку вызовов. У упавшего агентного запуска много возможных точек отказа.

Инструменты: LangSmith, Helicone, Arize, Phoenix, Braintrust, Weights & Biases, Datadog LLM Observability. У каждого свои сильные стороны; выберите один рано и держитесь его.

Для маленьких команд: даже простая Postgres-таблица с одной строкой на вызов LLM даст 80% того, что нужно. Переходите на инструмент, когда масштаб или потребности в фичах это оправдают.

Уровень 8: оценка качества

Самый важный отдельный слой для серьёзной продакшен-работы.

Офлайн-оценки. Определённый датасет; ожидаемые выходы; скоринг. Гоняются перед деплоем изменений. Ловят регрессии. (Подробно разбирали на среднем уровне.)

Онлайн-оценки. Выборка продакшен-трафика, оцениваемая автоматически (LLM-as-judge) или через пользовательские сигналы. Ловят дрейф.

Оценки перед деплоем. Перед выкаткой любого изменения промпта или модели гоняется оценочный набор, результаты ревьюятся. Становится частью CI.

Таксономия оценок. Разные оценки под разные заботы:

• Поведенческие: делает ли он то, что мы ожидаем?
• Безопасность: отказывает ли там, где должен?
• Качество: насколько хорош выход?
• Робастность: как он держит удар адверсариальных входов?
• Стоимость/задержка: укладываемся ли в бюджет?

Инструменты: Promptfoo, Braintrust, LangSmith, кастомные наборы. Всему есть место; Promptfoo — простейший старт.

Уровень 9: прикладной слой

Здесь живёт ваш конкретный продукт. Решения этого уровня:

Агент или рабочий процесс. Агенты (LLM в цикле с инструментами) мощные, но их сложнее сделать надёжными. Рабочие процессы (фиксированная последовательность вызовов LLM) проще и часто достаточны. По умолчанию — рабочий процесс; к агентам тянемся, когда они реально нужны.

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

Single-tenant или multi-tenant. Требования к изоляции клиентских данных тянут за собой значимые архитектурные решения.

On-prem или облако. Комплаенс, безопасность или стоимость могут затолкать вас on-prem. Операционная сложность намного выше.

Крайние случаи. Галлюцинации, prompt injection, злоупотребления. Продакшен-системам нужны защитные ограждения. Не выкатывайте без них.

Компромиссы, которые имеют значение

Несколько компромиссов, о которых стоит говорить вслух:

Качество, стоимость, задержка

Фундаментальный треугольник. Обычно вы можете оптимизировать два; третий ухудшается.

• Высокое качество + низкая задержка = дорого.
• Низкая стоимость + низкая задержка = ниже качество.
• Высокое качество + низкая стоимость = высокая задержка (пакетная обработка или рассуждающие модели).

Выбирайте приоритеты под задачу. Не пытайтесь оптимизировать все три сразу; этот путь ведёт к посредственности по всем фронтам.

Разрабатывать или покупать

На каждом слое можно собирать самому или покупать.

• Build: больше контроля, больше поддержки, больше затрат (время инженеров), дифференцирующие возможности.
• Buy: быстрее старт, меньше контроля, постоянный вендор-риск, недифференцирующие возможности отдаются на сторону.

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

Открытые модели против закрытых

Реальность 2026 года: open-source-модели конкурентоспособны на многих задачах. На некоторых они лучше (быстрее, дешевле). На других (длинные рассуждения) закрытые фронтир-модели по-прежнему ведут.

Факторы решения:

• Требования к качеству. На самом передовом крае любой задачи закрытые модели всё ещё выигрывают.
• Стоимость на масштабе. Open-source self-hosted дешевеет при высоком объёме.
• Privacy/комплаенс. Self-hosted на вашей инфраструктуре часто обязателен для чувствительных данных.
• Кастомизация. Файнтюнинг, кастомное обучение требуют open-source.
• Операционная ёмкость. Закрытые API операционно тривиальны; self-hosted — серьёзная работа.

Большинство продакшен-систем в 2026 году гибридны — закрытое на одни вызовы, открытое на другие, на основе расчёта по каждому вызову.

Задержка против глубины рассуждения

Рассуждающие уровни (GPT-5.5 thinking, Claude с adaptive thinking) меняют задержку на качество на сложных задачах. Иногда оно того стоит; иногда пользователь не может ждать 30 секунд.

Паттерн: маршрутизировать простые запросы на быстрые модели, сложные — на рассуждающие модели. Решение принимает роутер (маленькая модель или эвристика).

Длинный контекст против RAG

Можно набить контекст в модель (используя миллион токенов окна) или извлекать релевантные куски (через RAG).

• Длинный контекст: проще, без retrieval-инфраструктуры, но дорого за вызов, и «context rot» реален.
• RAG: дешевле за вызов, больше настройки, качество retrieval — отдельная инженерная задача.

Зрелый ответ 2026 года: обычно RAG для продакшена; длинный контекст — для прототипов, отдельных разовых задач или там, где качество retrieval настолько плохое, что retrieval только всё портит.

Агенты против рабочих процессов

Обсуждалось выше. По умолчанию — рабочие процессы; агенты — когда гибкость реально нужна. Многие «агентные» системы, которые мы видим, должны быть рабочими процессами.

Эталонная архитектура 2026 года

Чтобы всё это стало конкретным, вот как выглядит типичная продакшен-система для среднего SaaS-продукта с ИИ-функциями:

User → Application (React/Next.js)
    ↓
API gateway / auth
    ↓
LLM Service (your wrapper)
    ↓
  Router (small model or heuristic)
    ├→ Simple tasks: a mid-tier model (Claude Haiku 4.5 class)
    ├→ Standard tasks: Claude Sonnet 5 or GPT-5.5
    ├→ Hard tasks: Claude Opus 4.8 or a reasoning tier
    └→ Special: vision/voice/embedding specialists
    ↓
Tool layer (MCP servers + direct integrations)
    ↓
Retrieval layer (Pinecone + hybrid + reranker)
    ↓
Observability (Helicone or LangSmith)
    ↓
Eval suite (Promptfoo, runs in CI)

Стоимость на активного пользователя в месяц: обычно €1-10 в зависимости от интенсивности. Инженерные усилия на построение: 6-12 недель опытной командой. Операционная стоимость: от низкой до средней в зависимости от трафика.

Что обычно ломается

Паттерны провалов, которые раз за разом повторяются в продакшен-стеках LLM:

Паттерн 1: одна модель на всё. Перерасход бюджета, проблемы с качеством. Лечится роутингом.

Паттерн 2: нет наблюдаемости. Нельзя ни дебажить, ни измерять, ни улучшать. Лечится ранним инструментированием.

Паттерн 3: нет оценок. Качество тихо уплывает. Лечится оценками с первого дня.

Паттерн 4: vendor lock-in на фреймворк. Отладка LangChain или CrewAI становится работой на полный день. Лечится отказом от фреймворков, пока они не экономят больше, чем стоят. Переписывайте в прямой код, когда паттерны ясны.

Паттерн 5: строите инфраструктуру, которую надо было купить. Кастомная векторная БД? Скорее всего, потерянное время. Кастомная наблюдаемость? Скорее всего, потерянное время. Покупайте товарные слои.

Паттерн 6: покупаете инфраструктуру, которую надо было построить. Отдаёте промпты сторонней системе. Отдаёте оценки. Это ваш конкурентный ров; владейте им сами.

Паттерн 7: игнорирование prompt injection. Продакшен-система без очистки пользовательского ввода. Большой риск; смягчайте рано.

Паттерн 8: доверие агентам в высокорисковых сценариях. LangGraph-агент, который одобряет возвраты без участия человека. Когда-нибудь это пойдёт не так. Добавляйте human-in-the-loop для значимых действий.

Паттерн 9: оптимизация не того. Оптимизировать стоимость инференса, когда суммарная стоимость определяется временем инженеров. Или оптимизировать задержку, которой пользователи не замечают. Меряйте то, что реально важно.

Паттерн 10: нет плана на множество провайдеров. Когда (не если) у вашего основного провайдера случается сбой — вы лежите. Держите запасной вариант настроенным.

Три ставки с датой (проверьте в середине 2027-го)

Прогнозы дёшевы; датированные и опровержимые — нет. Три ставки, в которых мы готовы публично ошибиться:

1. EU-хостинг инференса достигает практического ценового паритета для моделей среднего уровня к середине 2027 года. Суверенные европейские мощности быстро вводятся в строй, а надбавка относительно US-региональных эндпоинтов всё время сокращалась. Если паритет случится, наша дефолтная рекомендация для GDPR-чувствительных нагрузок переключится с «гибрид с вымарыванием чувствительных данных» на «EU-хостинг по умолчанию». Уверенность: умеренная.

2. Слой фреймворков продолжает консолидироваться; слой протоколов продолжает выигрывать. За последние 18 месяцев Microsoft слил два своих агентных фреймворка, а OpenAI вернул отдельный продукт с браузерным агентом обратно в ChatGPT, тогда как MCP прошёл путь от анонса до кросс-вендорного дефолта. Мы держим интеграционные усилия в протоколах (MCP, structured outputs), а фреймворк оркестрации — заменяемым. Уверенность: высокая.

3. Роутинг на маленькие модели перестаёт быть оптимизацией и становится дефолтной архитектурой. Если цены флагманов удержатся, а маленькие уровни продолжат улучшаться, «флагман на всё» будет звучать так же, как «bare metal на всё» звучит для облачного инженера. Уверенность: высокая для чувствительных к затратам SME.

Чего мы сознательно не прогнозируем: рейтингов моделей. Любой конкретный рейтинг, напечатанный здесь, устарел бы раньше следующей даты ревью этой страницы.

Постройте архитектуру правильно

Стек LLM в 2026 году — реальный, многослойный, и выбор имеет значение. Выигрывают команды, которые:

• Понимают весь стек, а не только участки, которых касаются.
• Делают явные компромиссы (качество, стоимость, задержка) под каждый вызов.
• Строят то, что дифференцирует; покупают то, что нет.
• Инструментируют с первого дня (наблюдаемость, оценки).
• Остаются подвижными (model-portable, мультипровайдерные).

Проигрывают команды, которые выбрали одного вендора, захардкодили его API, никогда не инструментировали, никогда не измеряли — и теперь обнаруживают себя с дорогой, хрупкой и не поддающейся улучшению системой.

Постройте архитектуру правильно. Всё остальное даётся проще.