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

Если в 2026 году вы делаете реальный AI-продукт, вопрос «брать 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 году группируются по нескольким уровням, и выбор между ними — самое значимое решение в системе на уровне отдельного вызова.

Флагманские reasoning-модели. GPT-5 в reasoning-вариантах, Claude 4 Opus с extended thinking, o3, Gemini 3 Pro с thinking, DeepSeek R2. Отлично справляются с многошаговыми задачами, математикой, кодом, сложным анализом. Дорогие (€2-15 за миллион входных токенов, больше за выходные), медленные (5-60 секунд). Применяйте их, когда узкое место — качество рассуждения.

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

Модели среднего уровня. GPT-5 Mini, Claude 4 Haiku, Gemini 3 Flash, Mistral Medium. Хороши для простых и средних задач, быстрые (1-2 секунды), дешёвые (€0.10-0.50 за миллион токенов). Массово используются в продакшене для классификации, извлечения, простой генерации.

Маленькие / nano-модели. GPT-5 Nano, Claude Haiku Lite, Gemini Flash Lite, открытые модели поменьше. Достаточно для узких структурированных задач. Очень дёшево (€0.02-0.10 за миллион токенов), очень быстро (<1 секунды). Применяйте для роутинга, скоринга, batch-обработки.

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

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

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

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

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

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

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

Провайдеры open-source инференса — Groq, Together AI, Fireworks, Anyscale, Replicate, OctoAI. Запускают открытые модели с разной настройкой. Часто куда быстрее, чем self-hosted; конкурентные цены.

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.
• Пропускная способность имеет значение для batch: если вы обрабатываете миллионы записей, вам нужна высокая пропускная способность, а не низкая латентность.
• Комплаенс имеет значение: 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: retrieval и память

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: prompt- и context-инжиниринг

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

Компоненты:

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

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

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

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

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

Использование длинного контекста. В 2026 году доступны окна на 1M токенов (Gemini, GPT-5). Они работают, но «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.

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

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

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

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

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

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

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

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

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

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

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

Уровень 8: evals

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Качество vs стоимость vs латентность

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

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

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

Build vs buy

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

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

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

Open-source vs закрытое

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

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

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

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

Латентность vs глубина reasoning

Reasoning-модели (o3, Claude с extended thinking) меняют латентность на качество на сложных задачах. Иногда оно того стоит; иногда пользователь не может ждать 30 секунд.

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

Длинный контекст vs RAG

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

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

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

Агенты vs воркфлоу

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

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

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

User → Application (React/Next.js)
    ↓
API gateway / auth
    ↓
LLM Service (your wrapper)
    ↓
  Router (small model or heuristic)
    ├→ Simple tasks: GPT-5 Mini or Claude Haiku
    ├→ Standard tasks: Claude 4 Sonnet or GPT-5
    ├→ Hard tasks: Claude 4 Opus or o3
    └→ 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 недель опытной командой. Операционная стоимость: от низкой до средней в зависимости от трафика.

Что я видел сломанным

Паттерны провалов, которые встречаются раз за разом:

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

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

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

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

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

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

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

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

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

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

Что, я ожидаю, изменится

Заглядывая на 12-18 месяцев вперёд:

• Open-source закроет ещё больше разрывов. Жду, что open-source-фронтир окажется в пределах 10-20% от закрытого на большинстве задач — при кардинально меньшей цене.
• Стоимость инференса продолжит падать. Цены за токен падают в 5-10 раз в год. Архитектуры, сегодня финансово неподъёмные, становятся жизнеспособными.
• Агенты становятся надёжнее. Лучше обращение с длинным контекстом, лучше использование инструментов, лучше самокоррекция. Продакшен-сценарии для агентов расширяются.
• MCP становится повсеместным. Каждый инструмент в 2027 году будет достижим любым AI-агентом через MCP. Огороженные сады проигрывают.
• On-device дорастает. AI в телефонах и ноутбуках добирается до достаточного качества для многих задач. Гибридные on-device/облачные архитектуры становятся обычным делом.
• Стандартизация растёт. Сегодняшние кастомные архитектуры станут стандартизированными. Меньше кастомной сантехники, больше фокуса на дифференциации.

Главное

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

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

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

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