BlackboxBook/book/24_landscape_2026.md

ГЛАВА 24. ЛАНДШАФТ 2026: REASONING, MOE, SLM, ДЛИННЫЙ КОНТЕКСТ И ЭКОНОМИКА INFERENCE

---

Продуктовые названия в этой главе меняются быстрее, чем принципы из предыдущих двадцати одной. Поэтому относитесь к ней как к снимку индустрии на апрель 2026 года: полезному для ориентации, но не заменяющему чтение текущих model docs и pricing pages.

---

24.1. Чистый Transformer больше не единственный ответ

Что изменилось

С 2017 года Transformer оставался базовой архитектурой почти для всех сильных LLM. Но к 2025-2026 стало ясно: главный bottleneck никуда не делся. Self-attention по-прежнему дорог по длине последовательности, а длинный контекст, multimodality и agent loop'ы резко увеличили нагрузку на inference.

Иными словами, индустрия не отказалась от Transformer, а перестала считать его единственной формой большого языкового интеллекта.

Направление	Что даёт	Цена компромисса
Transformer + FlashAttention / KV-оптимизации	Сильное in-context learning, зрелый tooling	Высокая стоимость длинного контекста
MoE	Больше параметрической памяти при умеренном inference-cost	Более сложная маршрутизация
SSM / Mamba	Линейную работу с длинными последовательностями	Слабее точечный retrieval
Гибриды	Компромисс между точностью attention и эффективностью SSM	Больше архитектурной сложности

SSM и гибриды

State Space Models и Mamba не «убили Transformer», но заставили пересмотреть вопрос: обязательно ли каждую задачу решать полным attention по всему префиксу? Ответ оказался отрицательным. Jamba2 (AI21, январь 2026) — наследник первого гибрида Jamba (2024) — показал, что комбинация Transformer, SSM и MoE работает на production-уровне: Apache 2.0, 256K контекст, SSM-Transformer архитектура с state passing для обобщения контекстной длины. Два размера: 3B (dense) и Mini (52B total / 12B active, MoE). Mamba-2 (Dao & Gu, ICML 2024) подкрепил теоретический фундамент: SSD-фреймворк показал, что SSM и attention — точки на одном континууме (structured state space duality).

Практический вывод для инженера простой:

• если вам нужен лучший ecosystem fit, зрелые API и сильное in-context behavior, вы всё ещё живёте в мире Transformer;
• если вам нужны длинные контексты и дешёвый inference, смотрите на hybrid/MoE/open-weight направление внимательнее, чем год назад.

---

24.2. MoE перестал быть экзотикой

Почему MoE прижился

Mixture of Experts решает простую инженерную проблему: как увеличить объём параметрической памяти модели, не активируя все параметры на каждом токене.

Это как заменить одного универсального консультанта на большую команду специалистов с умным диспетчером (подробнее о MoE и хранении знаний — в Главе 2). Важно не только то, сколько экспертов у вас есть, но и сколько из них реально вызываются на каждый токен.

Публично подтверждённые ориентиры

Модель	Всего параметров	Активных на токен	Что важно
Mixtral 8x7B	46.7B	12.9B	Ранний массовый MoE-сигнал
DeepSeek-V3 / V3.2	671B	37B	Fine-grained MoE + MLA (Multi-head Latent Attention). V3.2 — текущая production-версия (128K, thinking/non-thinking)
Qwen3-235B-A22B	235B	22B	Соединил open weights, reasoning-mode и агентность
Qwen3.5-397B-A17B	397B	17B	Гибрид: Gated DeltaNet + Attention + MoE. Open-weight, мультимодальный, February 2026. Наследник Qwen3-235B; активная доля уменьшилась при увеличении total
Llama 4 Scout	109B	17B (16 экспертов)	10M context, open-weight, нативная мультимодальность
Llama 4 Maverick	400B	17B (128 экспертов)	1M context, open-weight, нативная мультимодальность
GLM-5.1	744B	~40B (точное число не раскрыто в model card)	Open-weight frontier MoE (MIT); DSA-архитектура
MiniMax M2.7	не раскрыто	не раскрыто	Self-evolution: модель участвует в собственном RL-обучении
Gemma 4 (26B)	26B	3.8B (A4B)	Нативная мультимодальность, Apache 2.0

Что это значит в реальных системах

MoE даёт три практических следствия:

1. Больше знаний при меньшей активной цене токена.
2. Более выраженную специализацию по доменам и паттернам.
3. Новый класс ошибок маршрутизации. Иногда модель знает факт «в целом», но router не активирует лучший набор экспертов для конкретного контекста.

Поэтому MoE делает модель одновременно мощнее и менее интуитивной. Вы выигрываете в quality-per-dollar, но проигрываете в простоте ментальной модели.

К апрелю 2026 MoE перестал быть архитектурой только для гигантских моделей. Gemma 4 показала, что MoE работает и в компактном сегменте: вариант 26B-A4B активирует всего 3.8B параметров на токен, оставаясь мультимодальным (edge-варианты E2B и E4B работают на смартфонах, 26B-A4B рассчитан на consumer GPU и выше). GLM-5.1 от Zhipu — 744B MoE с ~40B активных параметров — стал одним из первых open-weight моделей, заявленных на уровне frontier-class в задачах кодирования. Диапазон MoE расширился: от 2B на телефоне до 40B активных в дата-центре.

---

24.3. Reasoning-модели: compute на инференсе стал самостоятельным рычагом

Новая логика масштабирования

В 2020-2023 индустрия в основном масштабировала обучение: больше параметров, больше данных, больше GPU-часов. В 2024-2026 она начала столь же агрессивно масштабировать инференс.

Это и есть test-time compute: модель тратит дополнительный вычислительный бюджет на размышление, проверку гипотез, повторные попытки и инструментальные шаги.

Как это выглядит в продуктах

• OpenAI развивает серию GPT-5.x (от GPT-5 до GPT-5.4): reasoning теперь интегрирован как параметр reasoning_effort (от none до xhigh), а выделенные reasoning-модели (o1, o3, o4-mini) постепенно уступают место unified-линейке.
• DeepSeek-R1-Zero продемонстрировал, что reasoning-способности могут возникать через чистое RL без человеческих reasoning-траекторий. Полная модель DeepSeek-R1 дополнительно использует cold-start SFT и многоэтапное RL. Работа опубликована в Nature (vol. 645, 2025) — первая статья об LLM-reasoning в журнале такого уровня. Ключевой метод — GRPO (Group Relative Policy Optimization; подробнее — Глава 19, §19.5): без reward-модели, без reference-модели, оценка на уровне группы. Open-weight, reasoning-паттерны дистиллируются в меньшие модели.
• Anthropic в актуальных docs делает ставку на Claude Opus 4.6 с extended thinking и adaptive thinking.
• Qwen3 публично разделяет thinking и non-thinking mode.
• Google двигает Gemini в сторону reasoning + multimodality, при этом модельная линейка уже живёт в поколениях 3.x и 2.5 одновременно.
• Anthropic Claude Mythos Preview (7 апреля 2026, Project Glasswing): самая мощная модель Anthropic на момент объявления — SWE-bench Verified 93.9 % (против 80.8 % у Opus 4.6), Terminal-Bench 2.0 82.0 %, GPQA Diamond 94.6 %. Выпущена в формате gated preview с фокусом на оборонительную кибербезопасность: модель нашла тысячи zero-day уязвимостей в основных ОС и браузерах. Не «слишком опасна для релиза», а целенаправленно направлена на защиту критической инфраструктуры совместно с партнёрами (AWS, Microsoft, Google, NVIDIA, CrowdStrike и др.).

Важная оговорка

Когда люди говорят: «reasoning-модель внутри себя делает Tree of Thoughts», они обычно описывают внешне наблюдаемое поведение, а не полностью раскрытую внутреннюю механику. Для инженера это принципиально:

• reasoning-mode полезен;
• но он не отменяет внешнюю декомпозицию, тесты, tool use и verifier loop;
• а скрытый reasoning нельзя считать audit trail.

Reasoning-модели 2026 года принесли с собой два побочных эффекта, которые стоит рассмотреть здесь же: safety gating и agentic-first дизайн.

Следующий frontier: latent reasoning и геометрия процесса

В 2025–2026 research-сцена показала, что test-time compute не сводится к тому, что «модель пишет себе больше текста». Coconut исследует continuous latent reasoning: часть промежуточных шагов выполняется в непрерывном скрытом пространстве, без декодирования каждого шага в слова. Это обещает лучший planning и backtracking там, где текстовый CoT слишком рано фиксирует одну ветку поиска.

Параллельно развивается геометрический взгляд на reasoning: вместо чтения только текстового следа исследователи анализируют траекторию residual stream, её изгибы и устойчивые инварианты. Для production это пока не готовая техника, но стратегический вывод важен: в ближайшие годы reasoning-модели, вероятно, будут различаться не только объёмом скрытого CoT, но и тем, в каком внутреннем носителе они выполняют промежуточное вычисление.

Safety gating: новая реальность релизного цикла

Claude Mythos — первый публичный случай, когда frontier-модель выпускается с архитектурным ограничением доступа не из-за конкуренции, а из-за реального risk profile. Anthropic вложила $100M в usage-кредиты для партнёров и $4M в OSS-пожертвования, но широкий API-доступ отложен до выработки safeguards.

Для инженера это означает конкретный сдвиг:

• Способность модели и её доступность — теперь разные оси. Лучшая модель по бенчмаркам может быть недоступна через стандартный API.
• Архитектура production-системы должна учитывать, что модельный tier может измениться не только по цене, но и по policy.
• Gated release — вероятно, станет нормой для моделей с dual-use capabilities (кибербезопасность, биохимия, автономное управление).

OpenAI пошёл по аналогичному пути: GPT-5.4 классифицирован как High cyber capability в рамках Preparedness Framework и развёрнут с расширенным стеком кибербезопасности. OpenAI также публикует CoT controllability eval — метрику того, насколько модель может скрывать свои рассуждения (у GPT-5.4 этот показатель «low», что позитивно для безопасности; GPT-5.4 System Card, 2026). Safety gating перестаёт быть прерогативой Anthropic и становится индустриальной нормой.

Agentic-first: модели, спроектированные для действий

В 2024–2025 агентность была надстройкой: модель обучалась на тексте, а затем к ней прикручивали tool use и agent loop. В 2026 году ситуация изменилась — ряд моделей проектируется agentic-first:

• Qwen 3.6-Plus (Alibaba, 1 апреля 2026) явно позиционирован как «Towards Real World Agents»: усиленный agentic-кодинг, решение задач на уровне репозитория, frontend web development без human-in-the-loop.
• Claude Mythos с результатом 77.8 % на SWE-bench Pro — бенчмарке значительно сложнее SWE-bench Verified (Opus 4.6 падает с 80.8 % до 53.4 %) — решает автономно почти четыре из пяти незнакомых production-задач на реальных кодовых базах.
• Grok 4.20 (xAI) — текущий флагман с 2M context window, мультимодальный (текст + изображение); аудио и видео — через отдельные API платформы xAI. Reasoning always-on. Предыдущая версия Grok 4.1 (ноябрь 2025) заявлялась как одна из лидеров LMArena Text на момент выхода.
• GLM-5.1 от Zhipu заявлен на frontier-уровне в задачах кодирования с open-weight доступом.
• MiniMax M2.7 — первая публичная модель с акцентом на self-evolution: участвует в собственном RL-обучении в рамках внутреннего контура самоэволюции, строит и итеративно улучшает собственные agent harness. 97 % compliance на 40 сложных навыках. API-only; архитектура и размер не раскрыты публично.

GLM-5 здесь важен как конкретный шаблон agentic-first модели: long-horizon поведение поддерживается не одним только prompt format, а сочетанием DSA для длинного контекста, асинхронной RL-инфраструктуры и последовательного pipeline Reasoning RL -> Agentic RL -> General RL. Это хороший ориентир на 2026 год: frontier-агентность всё чаще рождается не «после» базовой модели, а вшивается в саму схему её обучения.

Practical implication: при выборе модели для агентного контура теперь стоит проверять не только общие бенчмарки (MMLU, GPQA), но и agentic-специфичные: SWE-bench, Terminal-Bench, WebArena, agent loop completion rate. Модель с лучшим IQ не обязательно лучший агент.

Новый рубеж: long-horizon сессии. В 2024–2025 агентные бенчмарки фокусировались на коротких задачах (один баг, один файл). В 2026 году GLM-5.1 продемонстрировал sustained optimization: оптимизация vector DB за 600+ итераций и 6000+ tool-вызовов, 8-часовая автономная сборка Linux-десктоп-окружения. MiniMax M2.7 прошёл 100+ автономных циклов «проанализируй ошибки → модифицируй scaffold → оцени → оставь/откати», улучшив внутренние метрики на 30 %. Это переход от «агент решает задачу» к «агент ведёт проект» — и он требует пересмотра termination conditions, бюджетов и мониторинга (см. раздел 10.6).

Практический смысл

Если задача сложная, цена ошибки высока, а latency терпима, то в 2026 вопрос уже не «какая модель больше?», а «как распределить compute между моделью, sampling, verifier и tools?». Это и есть взрослая версия prompt engineering.

---

24.4. SLM и edge-first парадигма: «больше — лучше» больше не аксиома

Что произошло

До 2025 года индустрия двигалась в одном направлении: больше параметров, больше данных, больше GPU. В 2026 году стало ясно, что для большинства production-задач это избыточно. Маленькие специализированные модели (Small Language Models, SLM) — от 0.8B до 8B параметров — стали production-ready и в ряде сценариев превосходят frontier-модели при доле их стоимости.

Это не удешевление ради удешевления. Это архитектурный сдвиг: вместо одной дорогой модели на все задачи — гибридный стек, где SLM решает рутину, а frontier-модель подключается только для сложных кейсов.

Что стало возможным

Модель	Параметры	Ключевые свойства	Источник
Phi-4-mini-instruct (Microsoft)	3.8B	Reasoning-лидер в мини-классе, 128K контекст, MIT	HuggingFace, 2025
Gemma 4 E2B / E4B (Google)	2B / 4B	Нативная мультимодальность (текст + изображение + аудио), работают на смартфонах и edge-устройствах (Pixel, Chrome, NVIDIA Jetson Orin Nano), Apache 2.0	Google DeepMind, апрель 2026
Qwen3.5-0.8B (Alibaba)	0.9B (мар. 0.8B)	Мультимодальный (image-text-to-text), компактнейшая модель с production-качеством	HuggingFace, февраль 2026
SmolLM3-3B (HuggingFace)	3B	Dual-mode reasoning (/think и /no_think), 128K контекст, полная рецептура обучения, Apache 2.0	HuggingFace, 2025
GPT-5.4-nano (OpenAI)	не раскрыто	Reasoning-capable nano-модель, $0.20/$1.25 за 1M токенов — одна из самых дешёвых frontier-class SLM	OpenAI, март 2026

Почему это важно для инженера

1. Экономика routing. Типичный production-контур в 2026 году: маршрутизатор направляет большинство запросов в SLM (классификация, extraction, валидация формата, простая генерация) и только сложные — в frontier-модель (рассуждения, длинный контекст, мультишаговое планирование). Конкретная пропорция зависит от продукта, но порядок экономии — десятикратный.

2. Latency. SLM на 3–4B параметров отдаёт первый токен за 20–50 мс на consumer GPU. Frontier-модель через API — за 500–2000 мс. Для real-time UX и agent loop разница критична.

3. Privacy и edge-deployment. Gemma 4 E2B работает на смартфоне, Phi-4-mini — на ноутбуке. Данные не покидают устройство. Для healthcare, финтеха и enterprise с strict data residency это не удобство, а требование.

4. Дистилляция и специализация. Маленькие модели обучаются на выходах frontier-моделей (дистилляция) и дотачиваются на домен (LoRA, QLoRA). Результат: качество, близкое к frontier-модели, при радикально меньшей стоимости inference.

Экстремальная эффективность: низкобитное квантование

Отдельное направление — агрессивная квантизация. Microsoft BitNet b1.58 (Ma et al., 2024) показал, что 1.58-битные (тернарные: {-1, 0, 1}) весовые представления могут работать в языковых моделях без катастрофической потери качества. Это теоретически позволяет запускать модели на устройствах, которые раньше не были целевой платформой: микроконтроллеры, edge-серверы без GPU, мобильные чипы.

На апрель 2026 низкобитный inference пока не стал мейнстримом, но направление показывает: порог вхождения в LLM-inference продолжает снижаться.

Рабочее правило

• SLM — когда задача типовая, latency критична, данные чувствительны, или бюджет на inference ограничен.
• Frontier — когда задача требует сложного рассуждения, длинного контекста, мультишагового планирования или мультимодальности с высоким качеством.
• Гибрид (SLM + Frontier) — когда вы строите production-систему и считаете деньги. Это новый default.

---

24.5. Длинный контекст и мультимодальность стали частью базового API-контракта

Что видно по актуальным docs

Семейство	Что заявлено публично	Инженерный вывод
GPT-5.4	1.05M context, 128K output, text + vision + computer use, reasoning_effort. Prompts >272K — 2× input / 1.5× output	Флагман OpenAI (март 2026). Объединяет coding (ex-Codex) + reasoning + native computer use. Mini и nano-варианты для SLM-сегмента
Claude Opus 4.6	1M context	Старые упоминания про 200K для Opus 4.6 больше неверны
Gemini 3.x / 2.5	Google держит несколько актуальных линеек одновременно	Нельзя писать о Gemini как о «одной текущей модели»
Llama 4 Scout	До 10M context, native multimodality	Open-weight long-context больше не ниша
Grok 4.20 (xAI)	2M context, мультимодальный (текст + изображение); аудио и видео через отдельные API xAI	Reasoning always-on
GLM-5.1	200K+ контекст, DSA для эффективного длинного inference	Open-weight (MIT) с sparse attention, снижающим стоимость длинного контекста в 1.5–2×

Главное инженерное уточнение

Advertised context window != effective retrieval quality.

Модель может принять миллион токенов, но это не значит, что она одинаково хорошо извлечёт факт из начала, середины и конца. Lost in the Middle, dilution attention и стоимость prefill никуда не исчезли. Большое окно контекста — это возможность. Надёжность по-прежнему приходится проектировать.

Мультимодальность как новая норма

Текст уже не монополист. В production-системах стало обычным:

• подавать скриншоты интерфейса вместе с текстовым заданием;
• анализировать PDF и изображения в одном запросе;
• использовать voice, image и browser tools как части одного agent loop.

Это не новый раздел рядом с NLP. Это уже обычный интерфейс работы с frontier-моделями.

---

24.6. Diffusion LLM: от исследований к первым production-системам

Все модели из предыдущих разделов — авторегрессивные: генерируют по одному токену за шаг. Диффузионные языковые модели (dLLM) работают иначе: генерируют множество токенов параллельно через итеративное «проявление» из шума, как diffusion-модели в генерации изображений.

Исследовательский фундамент

Два ключевых результата сделали dLLM практичнее:

• MDLM (Sahoo et al., NeurIPS 2024) — Masked Diffusion Language Models: показали, что masked discrete diffusion значительно эффективнее, чем считалось ранее. Приблизились к авторегрессивной perplexity, поддерживают полуавторегрессивную генерацию.
• SEDD (Lou et al., ICML 2024 Oral) — Score Entropy Discrete Diffusion: новый score entropy loss для дискретных пространств. Снижение perplexity на 25–75 % относительно предыдущих diffusion-подходов. Ключевое преимущество: сопоставимое качество при 32× меньшем числе forward pass'ов.

Mercury: первый production dLLM

Mercury 2 (Inception Labs) — первый коммерческий диффузионный LLM, доступный через OpenAI-совместимый API. Основан исследователями, стоящими за Flash Attention и DPO.

• Цена (по данным Inception Labs): $0.25 / 1M input, $0.75 / 1M output — конкурентоспособно с авторегрессивными моделями.
• Платформы: AWS Bedrock, Azure Foundry, прямой API.
• Позиционирование: latency-critical задачи — real-time voice agents, code autocomplete, быстрый поиск. Заявлены Fortune 500 клиенты.
• Mercury Edit 2: компактный dLLM для code editing с минимальной задержкой.

Что это значит для инженера

• Diffusion LLM перешли из чистого R&D в production — но пока в нише, где скорость генерации важнее general-purpose intelligence.
• Gemini Diffusion (Google DeepMind) — «currently available as an experimental demo», не через стандартный API. Подтверждает интерес крупных лабораторий.
• Для агентных систем и задач со сложным reasoning авторегрессивные модели по-прежнему доминируют.
• Если ваш use case — real-time генерация с жёсткими требованиями к latency, Mercury стоит оценить как drop-in замену.

---

24.7. Open-weight и closed models сблизились, но не слились

Что правда

Open-weight модели за два года проделали путь, который раньше занимал поколения:

• DeepSeek-V3.2 (текущая production-версия, 128K, thinking/non-thinking modes) подтвердил, что open-weight MoE — реально frontier-class; DeepSeek-R1 — open-weight reasoning, опубликованный в Nature;
• Qwen3.5 укрепил open-weight направление в reasoning (Apache 2.0); Qwen 3.6-Plus (API-only, 1 апреля 2026) прямо позиционирован для агентных задач и agentic-кодинга;
• Llama 4 сделал multimodal + long-context open-weight ещё более практичным;
• GLM-5.1 от Zhipu (744B MoE, апрель 2026) — конкурирует с Claude Opus 4.6 в задачах кодирования (SOTA на SWE-Bench Pro), но уступает на reasoning- и knowledge-бенчмарках (HLE, GPQA). MIT-лицензия, 744B MoE с DSA-архитектурой для эффективного длинного inference. Первая китайская open-weight модель таких масштабов с полностью открытыми весами на HuggingFace;
• Gemma 4 (Google, апрель 2026) — Apache 2.0, нативная мультимодальность, edge-модели на смартфонах. Google сделал ставку на полностью открытую линейку параллельно с закрытым Gemini.

Примечательно, что Meta пошла по тому же пути, но в обратном направлении. В апреле 2026 года Meta Superintelligence Labs (MSL) — новое исследовательское подразделение Meta — представила Muse Spark (по данным пресс-релиза MSL, апрель 2026), первую модель закрытого семейства Muse. Muse Spark — мультимодальная LLM (текст, изображения, reasoning, генерация кода), спроектированная как «small and fast by design» и развёрнутая в продуктах Meta (WhatsApp, Instagram, Ray-Ban Meta AI). В отличие от Llama, Muse Spark — проприетарная модель с API-доступом только для партнёров. Meta заявила о планах открыть будущие версии, но на момент анонса параметры архитектуры, размер модели и бенчмарки не раскрыты. Таким образом, Meta теперь ведёт два параллельных трека: Llama (open-weight frontier) и Muse (closed, product-first). Для инженера это означает, что при оценке Meta-экосистемы нужно различать две линейки с разными licensing, доступом и deployment-моделями.

Что не стоит преувеличивать

Неверно писать, что open-source «полностью догнал» closed-source вообще на всех задачах. Корректнее так:

• в ряде engineering-задач, code tasks, routing и приватных deployment-сценариев open-weight уже конкурентоспособен;
• по общей надёжности, product polish, safety surface и managed tooling топовые closed models часто всё ещё впереди;
• выбор между ними всё реже определяется абстрактным IQ модели и всё чаще — требованиями к данным, latency, auditability и цене владения.

Рабочее правило

• Open-weight: когда важны control, privacy, routing, кастомный inference, predictable GPU budget.
• Closed API: когда важны быстрый старт, лучший managed tooling, минимальный ops overhead и top-tier general reliability.
• Гибрид: когда вы всерьёз считаете деньги и строите production, а не демо.

---

24.8. MCP и agent ecosystem стали мультивендорными

Ещё год назад про MCP часто говорили как про «протокол Anthropic». К апрелю 2026 это уже неточно: с 2025 года MCP — проект Linux Foundation (LF Projects, LLC) с независимым Steering Group. Управление протоколом — открытое, не корпоративное.

Сейчас безопаснее формулировать так:

• MCP — open protocol под управлением Linux Foundation, текущая спецификация 2025-11-25;
• Anthropic — ранний драйвер экосистемы, предоставляет нативный MCP Connector в Messages API;
• OpenAI нативно поддерживает MCP в Responses API (type: "mcp"): remote MCP servers, встроенные Connectors для Dropbox, Gmail, Google Drive, MS Teams и др.;
• VS Code/Copilot имеет first-party MCP support;
• Google ADK тоже поддерживает MCP-инструменты;
• Экосистема: 83 000+ звёзд на GitHub, 100+ официальных интеграций, SDK для 10 языков (TypeScript, Python, Java, Kotlin, Go, Rust и др.).

Параллельно Google развивает A2A (Agent-to-Agent) — протокол межагентного взаимодействия. A2A и MCP не конкуренты: MCP — связь «агент → инструмент/данные», A2A — «агент → агент». Существует A2A MCP Server bridge, подтверждающий сосуществование.

Но важная оговорка: «поддерживает MCP» не означает одинаковое поведение везде. Отличаются transports, approvals, sandboxing, trust prompts и способ попадания инструментов в контекст.

Для инженера это означает две вещи:

1. MCP — реальный стандарт интеграции, а не маркетинговый мем.
2. Универсального рантайма всё ещё нет: совместимость нужно проверять по конкретному клиенту.

Tool search: масштабирование экосистемы инструментов

При десятках MCP-серверов и сотнях инструментов передавать все определения в контекст модели — расточительно. GPT-5.4 ввёл tool search: модель получает лёгкий список инструментов и подгружает полные определения по запросу — только для тех, которые собирается использовать. По данным OpenAI, на MCP Atlas (36 MCP-серверов, 250 задач) это значительно снизило потребление токенов при сохранении accuracy.

Это решает конкретную инженерную проблему: по мере роста MCP-экосистемы стоимость включения всех tool-определений в контекст растёт линейно. Tool search превращает O(N) контекстного оверхеда в O(k), где k — количество реально вызываемых инструментов.

Control plane: capability registry и provider adapters

Когда инструментов — сотни, а провайдеров — десятки, между agent loop и конкретными серверами нужна abstraction layer. Без неё агент привязан к конкретным MCP-серверам по имени, а добавление нового провайдера требует правок в логике оркестрации.

Capability registry — centralized directory, где каждый инструмент описан через capabilities: что умеет, какие входы/выходы, какие permissions нужны. Агент ищет не конкретный MCP-сервер, а capability — registry возвращает подходящий сервер. Это та же логика, что service discovery в микросервисах, но на уровне tool definitions.

Provider adapters — абстракция над различиями между remote MCP-серверами, OpenAI Connectors, локальными tools. Агент вызывает unified interface; adapter транслирует в конкретный протокол. Это позволяет заменять провайдера без изменения agent loop.

Defer loading — принципиально важный паттерн при 100+ инструментах: не загружать все tool definitions в context window сразу, а подгружать по запросу. Агент описывает, что ему нужно → capability search → подгрузка definition → tool call. По сути, tool search из предыдущей подсекции — частный случай этого паттерна, реализованный на стороне модели.

A2A: agent-to-agent взаимодействие как production-паттерн

MCP решает связь «агент → инструмент». Но в мульти-агентных системах возникает другой вопрос: как один агент делегирует задачу другому?

Google A2A protocol (2025) формализует этот паттерн. Task lifecycle в A2A: создание задачи → назначение → выполнение → отчёт → завершение. Каждый шаг имеет статус, что позволяет orchestrator-агенту отслеживать прогресс. Artifact exchange: агенты обмениваются не только текстом, но и файлами, structured data, ссылками на ресурсы.

Практический смысл: A2A позволяет строить системы, где агенты из разных организаций и на разных платформах кооперируются через стандартный протокол. Это расширение идеи MCP на уровень agent ↔ agent, а не agent ↔ tool.

Зрелость A2A пока невысока. Но паттерн уже виден в production: внутренний orchestrator-агент делегирует специализированные задачи внешним агентам через API — не обязательно через A2A protocol, но по той же схеме. Существует A2A MCP Server bridge, подтверждающий, что оба протокола работают в одном стеке.

Границы portability и vendor lock-in

MCP обещает портабельность: написал MCP-сервер — работает с любым клиентом. На практике есть трения. Не все провайдеры поддерживают все MCP capabilities — tools, resources, prompts реализованы неравномерно. Remote MCP и local MCP имеют разную модель безопасности и latency. Connectors (OpenAI) — vendor-specific абстракция поверх MCP-like концепций, не полностью совместимая с vanilla MCP.

Отдельный тренд: OpenAI и другие провайдеры начали поддерживать подключение сторонних моделей через unified API. Это позволяет использовать eval и orchestration infrastructure одного провайдера с моделями другого. Но evals и graders могут быть привязаны к формату ответа конкретного провайдера — полной абстракции пока нет.

Рабочее правило: строить agent loop вокруг abstractions (tool interface, model interface) с adapter layer. Не привязываться к vendor-specific conversation objects или proprietary tool formats. Если MCP-протокол покрывает use case — использовать его как transport. Для inter-agent взаимодействия — оценить зрелость A2A и держать fallback на прямые API-вызовы.

---

24.9. Экономика inference стала архитектурной проблемой, а не бухгалтерией

Когда модель использовалась как чат-бот, расходы ещё можно было «не считать по-настоящему». В agent loop'ах это кончилось.

Причина проста: один пользовательский запрос теперь часто превращается в:

• planner call,
• несколько tool calls,
• verifier call,
• retries,
• log/trace overhead,
• иногда ещё и browser/computer-use шаги.

Что реально работает в 2026

Стратегия	Почему работает
Routing	Не все запросы требуют frontier-модель
Prompt caching	Длинные общие префиксы встречаются чаще, чем кажется
Batching / continuous batching	Особенно важно для self-hosted serving
Verifier по риску, а не везде	Иначе вы умножаете cost без пропорционального выигрыша
Self-hosting там, где трафик предсказуем	Позволяет перевести variable cost в controlled infra cost

Что больше не работает

• «Сделаем всё одной дорогой моделью».
• «Если цена за миллион токенов низкая, cost не страшен».
• «Reasoning-модель дороже, но зато не нужна верификация».

Инференс-экономика в 2026 — это уже не про прайс-лист, а про архитектуру распределения вычислительного бюджета.

Speculative decoding

Draft-модель быстро генерирует K кандидатов, target-модель верифицирует их одним forward pass — lossless rejection sampling с типичным speedup 2–3× (механизм подробно разобран в Главе 21, §21.5). Для экономики inference важен практический аспект: speculative decoding позволяет использовать большую модель при меньшей латентности, что сдвигает точку routing в пользу quality.

Memory-efficient serving

PagedAttention и vLLM стандартизировали self-hosted inference, дав 2–4× throughput через постраничное управление KV-кэшем (подробнее — Глава 21, §21.2). Для экономики inference ключевой вывод: если вы разворачиваете open-weight модель, vLLM или его наследник — отправная точка.

Кеширование: три уровня

Кеширование запросов к LLM — одна из самых рентабельных оптимизаций, но важно различать три уровня:

Уровень	Механизм	Когда срабатывает	Экономия
Vendor prompt caching	Reuse KV-кэша для совпадающего prefix	Одинаковые system prompt + начало контекста	Скидка на cached-токены (напр., Anthropic: 90 % скидка на кешированные input)
Attention state reuse	Precomputed KV-states для повторяющихся сегментов	Повторяющиеся prompt templates, system messages	TTFT ↓ 8× (GPU) — 60× (CPU)
Semantic cache	Embedding similarity → поиск в vector store → cache hit	Семантически похожие запросы от разных пользователей	Стоимость ↓ до 10×, latency ↓ до 100×

Vendor prompt caching (Anthropic, OpenAI) работает на уровне prefix match: если первые N токенов нового запроса совпадают с кешированным, KV-кэш переиспользуется. Никакой дополнительной инфраструктуры не требуется — достаточно вынести длинные инструкции в начало промпта (подробнее о стратегии формирования prefix — в Главе 6, §6.6).

Semantic cache (например, GPTCache) работает на уровне приложения: входящий запрос → embedding → поиск ближайших в vector store → если similarity выше порога, вернуть кешированный ответ без вызова модели. Подходит для high-traffic сценариев с повторяющимися вопросами (FAQ-боты, классификаторы). Eviction: LRU, FIFO, LFU.

Prompt Cache (Gim et al., MLSys 2024) — attention state reuse для повторяющихся текстовых сегментов на уровне serving. Ускоряет TTFT: до 8× на GPU, до 60× на CPU.

Метрики inference: TTFT и throughput

Два ключевых показателя serving — TTFT (Time To First Token, определяется prefill-фазой) и decode throughput (определяется decode-фазой) — подробно разобраны в Главе 21, §21.8. Для экономики inference важно, что оптимизации для одного часто не помогают другому: PagedAttention улучшает throughput, Prompt Cache улучшает TTFT. Router-архитектура (глава 20, §20.1) может направлять простые запросы на меньшую модель, улучшая оба показателя.

Batch API: скидка за асинхронность

Оба ведущих провайдера предлагают batch-режим со скидкой 50 % на все модели:

Провайдер	Лимит	Окно	Скидка	Источник
OpenAI	50 000 запросов / batch, 200 MB	24 часа	50 %	Batch API docs
Anthropic	100 000 запросов / batch, 256 MB	24 часа	50 %	Batch Processing docs

Use cases: evaluation pipelines (глава 14), bulk classification, генерация synthetic data для дообучения (глава 19), embeddings. Prompt caching и batch-скидка стекаются.

Правило: если результат не нужен в реальном времени — используйте batch. Для eval pipelines это почти всегда так.

Дистилляция как стратегия снижения стоимости

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

Три подхода, от классического к современному:

1. Soft targets (Hinton et al., 2015): ученик обучается на probability distributions учителя, а не только на hard labels. Classique.
2. Rationale distillation (Hsieh et al., ACL 2023): LLM генерирует не только ответ, но и обоснование → маленькая модель (770M T5) обучается на парах (вопрос, rationale, ответ) → превосходит few-shot 540B PaLM на 80 % данных.
3. On-policy KD для LLM (MiniLLM, Gu et al., ICLR 2024): reverse KL-дивергенция + on-policy optimization. Масштабируется от 120M до 13B. Меньший exposure bias, лучшая калибровка.

Связь с главой 19: дистилляция — один из post-training подходов, но здесь мотивация не quality, а cost — перевод inference-расходов из переменных (pay-per-token к провайдеру) в фиксированные (self-hosted маленькая модель).

---

24.10. Что меняется быстро, а что переживёт этот год

Быстро меняется

• названия моделей и поколений;
• context window и pricing;
• benchmark-лидеры;
• product-level feature matrix;
• способы упаковать agent UX в IDE и чаты.

Остаётся стабильным

• модель по-прежнему надо верифицировать;
• длинный контекст по-прежнему не равен надёжному извлечению;
• tool use по-прежнему лучше галлюцинации о внешнем мире;
• явное состояние и логирование по-прежнему важнее «умного единственного вызова»;
• routing и decomposition по-прежнему дают больше, чем косметический prompt tweaking.

Именно поэтому эта книга вообще имеет смысл: принципы стареют медленнее витрины моделей.

---

Практический вывод

Чек-лист на 2026 год

#	Действие	Зачем
1	Пересмотрите модельный каталог	Удалите устаревшие default choices вроде старых Gemini/Claude tier'ов
2	Проверьте, где вам реально нужен reasoning-mode	Он дорог и полезен не на всех шагах
3	Внедрите routing	Это главный рычаг снижения cost без потери качества
4	Оцените SLM для рутинных задач	Большинство типовых запросов не требуют frontier-модели. Phi-4-mini, Gemma 4 E2B, SmolLM3 — production-ready альтернативы
5	Отделите advertised context от effective retrieval	Иначе 1M токенов даст ложное чувство надёжности
6	Используйте MCP осознанно	Протокол зрелый, но клиентские semantics различаются
7	Оцените open-weight сценарии	Не из идеологии, а по privacy/cost/ops profile
8	Не превращайте pricing snapshot в архитектурный принцип	Цены стареют за квартал, архитектура - нет

Ментальная модель

Лучшее решение 2026 года — не «самая большая модель», а правильно распределённый inference budget. Часть задач решает SLM на устройстве, часть — mini-модель в облаке, часть — reasoning-модель, часть — tool use, часть — verifier. Побеждает не тот, кто купил самый дорогой API, а тот, кто спроектировал самый предсказуемый контур.

Промпт для ИИ: «Напиши Python-скрипт для бенчмаркинга нескольких LLM-моделей на своём eval-наборе. Скрипт принимает JSONL-файл с тест-кейсами и список моделей (например, gpt-5.4, claude-sonnet-4-6, gemini-3.1-pro, llama-4-scout через vLLM). Для каждой модели: прогоняет eval-набор, измеряет accuracy, latency (p50/p95), cost_per_1k_queries, parse_rate, hallucination_rate (через самопроверку). Вывод — сортируемая таблица: модель → accuracy → latency p95 → cost → score (взвешенная метрика). Параметры весов задаются через конфиг. Используй litellm для унифицированного API или прямые SDK. Добавь параллельное выполнение через asyncio.»

Промпт для ИИ: «Напиши TCO-калькулятор (Total Cost of Ownership) для сравнения self-hosted vs API-инференса. Принимает: model_size_B, quantization, requests_per_day, avg_input_tokens, avg_output_tokens, api_price_per_1M_tokens, gpu_cost_per_hour, gpu_count, ops_engineer_salary_fraction. Для API считает годовую стоимость = requests × tokens × price. Для self-hosted считает: GPU cost + electricity + cooling + ops salary fraction + maintenance. Вычисляет break-even point — при каком числе запросов self-hosted становится дешевле. Вывод — таблица и рекомендация. Используй консервативные оценки GPU utilisation (60-70%). Комментарий: "цены проверить на момент использования".»

Задания

1. Аудит модельного стека. Возьмите текущий production-pipeline вашей команды. Для каждого LLM-вызова зафиксируйте: модель, средний input/output в токенах, latency P50/P95, стоимость за 1000 запросов. Постройте таблицу и определите, какие вызовы можно перевести на SLM или mini-модель без потери качества. Ожидаемый результат: конкретный plan с оценкой экономии в $/мес.

2. Сравнение reasoning-режимов. Выберите 20 сложных задач из вашего домена (баг-репорты, аналитические вопросы, code review). Прогоните их через одну модель с reasoning effort none, medium и high (или аналогичные режимы у вашего провайдера). Сравните качество ответов и стоимость. Ожидаемый результат: данные для выбора default reasoning level в вашем pipeline.

3. MCP-интеграция. Подключите один MCP-сервер (например, Filesystem или Git из reference-серверов) к вашему агентному контуру. Замерьте: время на интеграцию, количество tool-вызовов в типичной сессии, долю успешных вызовов. Ожидаемый результат: оценка зрелости MCP для вашего стека и список blockers.

---

Источники

• Vaswani, A., et al. (2017). Attention Is All You Need.
• Gu, A. & Dao, T. (2023). Mamba: Linear-Time Sequence Modeling with Selective State Spaces.
• AI21 Labs. (2024). Jamba: A Hybrid Transformer-Mamba Language Model.
• Snell, C., et al. (2024). Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters.
• DeepSeek-AI. (2024). DeepSeek-V3 Technical Report and official repository.
• Meta AI. (2025). Introducing Llama 4.
• Qwen Team. (2025). Qwen3: Think Deeper, Act Faster.
• OpenAI. (2025). GPT-5 is here and MCP/connectors documentation.
• Anthropic Docs. (2026). Claude models overview and prompt caching documentation.
• Google AI / Google DeepMind. (2026). Gemini API models and Gemini Diffusion pages.
• Google DeepMind. (2026). Gemma 4 model family.
• Microsoft. (2025). Phi-4-mini-instruct on HuggingFace.
• HuggingFace. (2025). SmolLM3-3B.
• Alibaba / Qwen Team. (2026). Qwen3.5-0.8B on HuggingFace.
• Ma, S., et al. (2024). The Era of 1-bit LLMs: All Large Language Models are in 1.58 Bits.
• Anthropic. (2026). Project Glasswing: Deploying AI to defend the world's critical infrastructure. https://www.anthropic.com/glasswing
• Anthropic. (2026). Claude Mythos Preview System Card.
• Zhipu / Z.ai. (2026). GLM-5.1. https://huggingface.co/zai-org/GLM-5.1
• Qwen Team. (2026). Qwen3.6-Plus: Towards Real World Agents. https://qwen.ai/research
• MiniMax. (2026). MiniMax-M2.7: Early Echoes of Self-Evolution. https://www.minimax.io/news/minimax-m27-en
• xAI. (2025–2026). Grok 4.1 / 4.20. https://docs.x.ai/docs/models
• OpenAI. (2026). Introducing GPT-5.4. https://openai.com/index/introducing-gpt-5-4/
• OpenAI. (2026). GPT-5.4 System Card. https://openai.com/index/gpt-5-4-system-card/
• Zhipu AI / Z.ai. (2026). GLM-5.1 Blog. https://z.ai/blog/glm-5.1
• Du, Z., et al. (2026). GLM-5: from Vibe Coding to Agentic Engineering. arXiv:2602.15763.
• Hao, S., et al. (2025). Training Large Language Models to Reason in a Continuous Latent Space. arXiv:2412.06769.
• Shai, A. S., et al. (2024). Transformers Represent Belief State Geometry in their Residual Stream. arXiv:2405.15943.
• Zhou, Y., et al. (2025). The Geometry of Reasoning: Flowing Logics in Representation Space. arXiv:2510.09782.
• Manson, R. (2025). Curved Inference. arXiv:2507.21107.
• Leviathan, Y., Kalman, M., Matias, Y. (2022). Fast Inference from Transformers via Speculative Decoding. arXiv:2211.17192. ICML 2023.
• Chen, C., Borgeaud, S., Irving, G. et al. (2023). Accelerating Large Language Model Decoding with Speculative Sampling. arXiv:2302.01318.
• Kwon, W. et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. arXiv:2309.06180. SOSP 2023.
• Gim, I. et al. (2023). Prompt Cache: Modular Attention Reuse for Low-Latency Inference. arXiv:2311.04934. MLSys 2024.
• GPTCache — https://github.com/zilliztech/GPTCache
• vLLM — https://github.com/vllm-project/vllm
• Hinton, G., Vinyals, O., Dean, J. (2015). Distilling the Knowledge in a Neural Network. arXiv:1503.02531.
• Hsieh, C.-Y. et al. (2023). Distilling Step-by-Step! arXiv:2305.02301. ACL 2023.
• Gu, Y. et al. (2023). MiniLLM: On-Policy Distillation of Large Language Models. arXiv:2306.08543. ICLR 2024.
• OpenAI Batch API — https://developers.openai.com/api/docs/guides/batch
• Anthropic Batch Processing — https://platform.claude.com/docs/en/docs/build-with-claude/batch-processing
• DeepSeek-AI. (2025). DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948. Также: Nature, vol. 645, pp. 633–638, 2025.
• Dao, T. & Gu, A. (2024). Transformers are SSMs: Generalized Models and Efficient Algorithms Through Structured State Space Duality. arXiv:2405.21060. ICML 2024.
• AI21 Labs. (2026). Introducing Jamba2. https://www.ai21.com/blog/introducing-jamba2/
• Inception Labs. (2026). Mercury: The Fastest LLM. https://inceptionlabs.ai/
• Sahoo, S. et al. (2024). Simple and Effective Masked Diffusion Language Models. arXiv:2406.07524. NeurIPS 2024.
• Lou, A. et al. (2023). Discrete Diffusion Modeling by Estimating the Ratios of the Data Distribution. arXiv:2310.16834. ICML 2024.
• xAI. (2026). Grok 4.20. https://docs.x.ai/docs/models
• Model Context Protocol. (2025). MCP Specification. https://spec.modelcontextprotocol.io/ — проект Linux Foundation (LF Projects, LLC).
• OpenAI. (2026). Tools — MCP. https://developers.openai.com/api/docs/guides/tools-connectors-mcp
• Anthropic. (2026). MCP Connector. https://platform.claude.com/docs/en/agents-and-tools/mcp-connector
• Google. (2025). Agent-to-Agent (A2A) Protocol. https://a2a-protocol.org/
• Qwen Team. (2026). Qwen3.5: Towards Native Multimodal Agents. https://qwen.ai/research
• Meta Superintelligence Labs. (2026). Introducing Muse Spark: MSL's First Model, Purpose-Built to Prioritize People. https://about.fb.com/news/2026/04/introducing-muse-spark-meta-superintelligence-labs/

---

Навигация:

• Назад: Глава 23. Как начать: от первого промпта до рабочего агентного контура
• Далее: Резюме и источники