# ГЛАВА 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](02_where_knowledge_lives_in_the_model.md)). Важно не только то, сколько экспертов у вас есть, но и сколько из них реально вызываются на каждый токен.

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

| Модель | Всего параметров | Активных на токен | Что важно |
|--------|------------------|-------------------|-----------|
| **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](19_fine_tuning_and_post_training.md)): без 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](10_agent_not_chat.md)).

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

Если задача сложная, цена ошибки высока, а 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](21_serving_and_runtime_of_llm_systems.md)). Для экономики inference важен практический аспект: speculative decoding позволяет использовать большую модель при меньшей латентности, что сдвигает точку routing в пользу quality.

### Memory-efficient serving

**PagedAttention** и **vLLM** стандартизировали self-hosted inference, дав **2–4× throughput** через постраничное управление KV-кэшем (подробнее — [Глава 21, §21.2](21_serving_and_runtime_of_llm_systems.md)). Для экономики 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](06_prompt_is_a_protocol.md)).

**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](21_serving_and_runtime_of_llm_systems.md). Для экономики inference важно, что оптимизации для одного часто не помогают другому: PagedAttention улучшает throughput, Prompt Cache улучшает TTFT. Router-архитектура ([глава 20, §20.1](20_llm_application_design_patterns.md)) может направлять простые запросы на меньшую модель, улучшая оба показателя.

### 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](14_llm_system_quality_evaluation.md)), bulk classification, генерация synthetic data для дообучения ([глава 19](19_fine_tuning_and_post_training.md)), 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](19_fine_tuning_and_post_training.md): дистилляция — один из 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. Как начать: от первого промпта до рабочего агентного контура](23_getting_started.md)
- Далее: [Резюме и источники](25_summary_and_references.md)
