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