Длинный контекст в open‑source моделях 2026 и обвязка под него

Я Владимир Лушин, делаю ИИ‑агенты и инструменты для работы с кодом. Статья, вроде, серьёзная, но с пуделями. Так уж вышло, что дрессировка собаки объясняет внимание в LLM понятнее любых формул с softmax.

В карточках свежих open‑source моделей везде написано «1 млн контекста». Внутри при этом точно читается совсем другое количество токенов: GLM-5.3 выбирает для каждого шага 2048 токенов из истории, DeepSeek‑V4-Pro — 1024 сжатых блока, а у Qwen3.8 и Kimi K3 всю историю целиком видит лишь каждый четвёртый слой.

Для агента это быстро становится вполне практической проблемой: правило из AGENTS.md к сотому вызову инструмента тихо перестаёт работать, и «ну вот же оно, в контексте!» уже не аргумент. Я полез разбираться, как устроено внимание в открытых моделях 2026 года и что с этим делать в обвязке, чтобы агент не забывал правила к середине сессии.

Примечание:

• Все свежие открытые модели читают длинный контекст выборочно. Три семейства: разрежённое top‑k (GLM-5.x, DeepSeek‑V4, MiniMax M3), гибриды «3 линейных + 1 полный» (Qwen3.5–3.8, Kimi K3, GLM-5.3-Flash), скользящее окно + глобальные слои (Gemma 4).

• Гарантированно точно читаются только последние сотни токенов. Всё остальное должно либо «выиграть отбор» по релевантности, либо дожить в сжатом виде.

• У большинства моделей качество ломается где‑то в районе 128–256 тыс., а Kimi K3 с компактизацией на 300 тыс. обгоняет саму себя с полным окном в 1 млн.

• Обвязке важнее, куда положить текст, чем что в нём написать. Лучше всего работают чистка старого вывода инструментов, поиск по запросу вместо «залить всё», постепенное раскрытие, состояние вне окна, повтор правил в конце.

• А то, что нельзя нарушать никогда, закрывайте хуками и правами доступа, вниманию такое доверять не стоит.

Сразу поясню: часть конфигураций я читал прямо из config.json на Hugging Face, часть — из карточек и техотчётов. Где данные вторичные, я это помечаю. А всё про «что модель читает» я вывожу сам из архитектуры, разработчики такого нигде не заявляли.

На пальцах: как модель вообще читает контекст?

Человек читает слева направо и ставит закладки. У модели закладок нет. На каждом шаге генерирования каждый слой заново выбирает, на какие из прошлых токенов смотреть и насколько сильно, и этот выбор называют вниманием.

Допустим, в начале сессии агенту сказали: «не трогай migrations/». Через 300 тысяч токенов он пишет команду rm -rf …. Чтобы правило сработало, в момент генерирования этой команды хотя бы часть слоёв должна «дотянуться» до той строчки в начале и дать ей заметный вес. Дотянется или нет — уже вопрос вероятности.

Теперь представьте часовое занятие с кинологом. В самом начале он сказал пуделю: «фу, с земли ничего не брать». Потом были десятки команд: сидеть, лежать, рядом, ко мне, снова сидеть. И вот на земле лежит кусок колбасы, а в голове у пуделя в основном последнее «гуляй!». Угадайте, кто теперь жуёт колбасу.

Пудели ещё вернутся, поэтому сразу словарик.

Теперь немного матчасти. Полное внимание считает вес для каждой пары «текущий токен — прошлый токен», и на 1 млн токенов это квадрат по стоимости. Платить его никто не хочет, поэтому в 2026 году полное внимание во всех слоях на всём окне почти никто не делает.

Физически прошлое хранится в KV‑кеше: ключи и значения для каждого токена в каждом слое. Если кеш сжимают (меньше голов, латентное пространство, слияние соседних токенов), то часть деталей пропадает ещё до того, как модель решит, куда смотреть.

И да, число «1 млн контекста» в карточке говорит только о том, сколько токенов влезет на вход. Сколько из них модель учтёт точно на конкретном шаге — отдельный и куда более грустный вопрос.

На практике всё зависит от того, как инструкция из обвязки доезжает до момента генерирования и где по дороге теряет вес.

Зоопарк внимания 2026: три семейства

Я свёл свежие открытые модели в одну таблицу, и полного внимания по всему окну в каждом слое нет ни у кого. Экономят все, только по‑разному.

У всех трёх большинство слоёв видит либо отобранное, либо сжатое прошлое.

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

1. Разрежённое внимание: «читаю только релевантное»

Маленький «индексатор» дёшево оценивает всю историю и отдаёт полному вниманию только top‑k самых похожих на текущий шаг токенов или блоков. Попал в top‑k — тебя прочитают точно. Не попал — ну, на этом шаге тебя просто нет.

• GLM-5.3 вышел в августе 2026 и, по карточке, сидит на той же базе, что GLM-5.2: все улучшения — дообучение. В конфигурации: DSA с index_topk 2048, MLA (латент 512 + 64 на RoPE), 78 слоёв, max_position_embeddings 1 048 576 без YaRN.

• Главное поменялось ещё в GLM-5.2: окно выросло с ~200 тыс. (у GLM-5.1) до 1 млн, и появился IndexShare — один индексатор на четыре разрежённых слоя, в 2,9 раза меньше FLOPs на 1 млн. То есть четыре слоя подряд смотрят на один и тот же набор токенов.

• В техотчёте GLM-5 есть показательное сравнение на 128 тыс.: разрежённое внимание выигрывает на поиске иглы (97,0 против 95,5 у плотного), но проигрывает на многошаговом HotpotQA (63,0 против 66,3). Один факт модель находит нормально, а вот связать несколько далёких ей уже тяжелее.

• DeepSeek‑V4 делает то же самое, но поверх сжатого кеша. Слои CSA сжимают KV в 4 раза и берут top‑k 1024 (у Pro) или 512 (у Flash), слои HCA сжимают в 128 раз и читают всё плотно, плюс везде есть окно из последних 128 токенов и обучаемые sinks. Контекст 1 млн через YaRN ×16, KV‑кеш на 1 млн — 10% (Pro) и 7% (Flash) от V3.2.

• DeepSeek‑V4.1-Flash (сентябрь 2026, дата по вторичному источнику) добавил CSA2 с иерархическим индексатором и FP4 KV: постоянный кеш — примерно 1/8 от V4-Flash. Карточка советует max_tokens не меньше 256 тыс.

• MiniMax M3 отбирает целыми блоками: MSA для каждой группы GQA‑голов берёт top‑k блоков и считает по ним точное внимание. В примере ядра — блоки по 128 и 16 лучших; для самой M3 эти числа официально не подтверждены.

2. Гибриды: «три линейных слоя на один полный»

Линейный слой (Gated DeltaNet, KDA, Mamba) вообще не хранит токены и всю историю переписывает в состояние фиксированного размера. Примерно как конспектировать всю пару на одном листе А4: к концу старое уже затёрто свежим. Точную память о далёких токенах держат только редкие полные слои.

• Вся линейка Qwen от Qwen3-Next до Qwen3.8 строится из блоков «3 Gated DeltaNet + 1 Gated Attention». У Qwen3.8–2.4T‑A95B это 92 слоя, из них всего 23 полных, и в каждом только 4 KV‑головы. Механизм внимания от версии 3.5 к 3.8 при этом не трогали, весь прирост — за счёт обучения.

• Нативный контекст у всех Qwen 3.5–3.8 — 262 144 токена, до ~1 млн только через YaRN ×4. В каждой карточке предупреждение: статический YaRN может ухудшить короткие тексты, включайте его, только когда нужно.

• Qwen3.7 в open source не выходил: только API‑версии Max/Plus/Flash. Свежайшие открытые веса — Qwen3.8–27B (Apache-2.0) и 2.4T‑A95B под собственной лицензией.

• Kimi K3 — 69 слоёв Kimi Delta Attention и 24 Gated MLA строго в пропорции 3:1, контекст 1 млн.

• GLM-5.3-Flash скрестил оба подхода: 34 слоя KDA и 11 разрежённых MLA‑слоёв без позиционного кодирования с top‑k 2048. То есть далёкому токену должно повезти дважды: попасть в редкий полный слой и ещё выиграть там отбор. Данные по структуре — из конфига и вторичного обзора.

• Nemotron 3 Ultra (июнь 2026, 550 млрд/55 млрд) — гибрид Mamba-2 с небольшим количеством слоёв внимания (2 KV‑головы).

3. Скользящее окно + глобальные слои: «близкое — всегда, далёкое — иногда»

Локальный слой смотрит только на последние N токенов, глобальный — на всё окно. Gemma 4 держит окно 1024 токена на 12, 26, 31 и 512 млрд на маленьких E2B/E4B, контекст 256 тыс. Точное соотношение локальных и глобальных слоёв в официальной карточке не названо.

Что модель реально видит: четыре зоны контекста

Если свести все три семейства к одной картинке, то контекст агента делится на четыре зоны. Модель самодельная, ни одну конкретную архитектуру она точно не описывает, но с замерами 2026 года сходится неплохо.

Инструкция в середине доживёт до момента действия, только если выиграет отбор — или если обвязка перенесёт её в хвост.

Последнюю команду пудель слышит всегда. Из старых — только те, что похожи на то, что он делает сейчас: видит миску — вспоминает «ждать». А то, что кинолог говорил в начале занятия про всё подряд, сидит в голове как «ну там что‑то было». Даже у самого умного пуделя к концу часа концентрация уже не та.

Хвост, то есть последние сотни токенов, модель видит всегда, в любом из трёх семейств: через скользящее окно, свежее состояние линейных слоёв или локальные слои. Фрагмент, похожий на текущий шаг, может выиграть top‑k и прочитаться точно, если индексатор вообще заметит связь. Всё остальное модель помнит сжато: состояние линейных слоёв, KV со сжатием ×128 у DeepSeek‑V4. Подробности при этом размыты.

Хуже всего приходится середине длинной истории. Туда уезжают старые выходные данные инструментов, прочитанные спецификации и правила, сказанные один раз «когда‑то там». Две теоретические работы 2026 года (2603.10123, 2602.16837) и вовсе утверждают, что U‑образный провал в середине заложен в сами каузальные декодеры.

Что намерили?

Окно в 1 млн работает, но качество плавно проседает с длиной, а у агентов ещё и со временем.

Да, Qwen3-Next — это ещё осень 2025-го. Но схема внимания у Qwen3.5–3.8 та же, а послойных кривых по длине для новых версий Qwen почему‑то не публикует.

• До 32 тыс. Qwen3-Next держит на RULER 98–99, а дальше начинается спуск с графика выше (карточка); у Nemotron 3 Ultra картина та же (техотчёт). Gemma 4 31 млрд на MRCR v2 с 8 иглами даёт 66,4 уже на 128 тыс. (карточка).

• Забавно, что компактизация обгоняет полное окно. Kimi K3 с компактизацией на 300 тыс. набирает 91,2 на BrowseComp против 90,4 с целым 1 млн (карточка). У GLM-5.1 та же история: 79,3 с управлением контекстом против 68,0 без него (карточка).

• Агенты, которые работают с корпусом как с файлами и ищут по нему, на входах от 385 тыс. обходят модель с полным контекстом на 12–68 пунктов (2603.20432).

• Инструкции выветриваются. В MTAC‑IFBench доля ходов, где соблюдены все ограничения, у GLM-5.2 падает с 27,6% до 2,6% к 9–10 ходу (2609.14992), причём обновить старое ограничение моделям труднее, чем добавить новое.

• С выводом инструментов отдельная беда: по IH‑Benchmark модели ставят system выше user в 85,4% случаев, а user выше выходных данных инструмента — только в 68,6% (2607.25987).

• Хуже длинного шума только похожий: фрагменты‑двойники снижают точность сильных моделей на 30–44% (NoisyBench, модели 2025 года). Для top‑k неудивительно: двойники просто занимают места оригинала.

• И пересказ кода теряет поведение: по пересказу модели ответили на 4 из 45 вопросов о поведении, по исходному коду — на 27 (2607.09691).

Чего я не нашёл, так это нормальных замеров «игла на разной глубине» для моделей 2026 года. Так что про середину у нас теория и косвенные данные. Красивой тепловой карты не будет, сорян.

Сущности обвязки против механизмов внимания

У любой обвязки — Claude Code, Codex, Qwen Code, OpenCode или самописной — примерно один и тот же набор сущностей. Для каждой я смотрел, в какую зону контекста она попадает и дотягивается ли до неё модель в момент действия. В каком файле она лежит, почти не важно.

На схеме это выглядит так:

AGENTS.md тут как кинолог, который сказал «фу» один раз в начале занятия, а хук повторяет его за шаг до колбасы. Намордник сработает, даже если мимо пробежит белка.

Отдельного бенчмарка под «силу» нет, оценка моя, по архитектурам и замерам выше. Главное, на что опирался:

• Файлы вроде AGENTS.md, написанные LLM, меняют успех на −0,5…−2 пункта и удорожают работу на 20–23%; написанные людьми дают +2,4 пункта (2602.11988). OpenAI в Harness engineering пришли к тому же: большой AGENTS.md не сработал, сработала карта на ~100 строк со ссылками на docs/.

• В MTAC‑IFBench правила из файла политики проекта держались лучше, чем те же правила в системном промпте (2609.14992). Но там эти правила не менялись по ходу, а строгое соблюдение всё равно сходило почти к нулю, так что гарантий файл правил не даёт.

• Инъекции через вывод инструментов модели отбивают заметно хуже, чем инструкции снизу в иерархии (68,6% против 85,4%, IH‑Benchmark). Поэтому правила в вывод инструмента не кладём, а сам этот текст лучше явно помечать как данные.

Что реально помогает на длинном контексте?

Почти все рабочие инструменты так или иначе сжимают контекст, выбирают, что в него положить, или перекладывают важное в хвост. Я отсортировал их по пользе на единицу усилий. По пометкам «замер», «вендор» и «фон» видно, на чём держится каждый пункт.

• Чистка. Агент тридцать раз запускал тесты, и в контексте лежат тридцать почти одинаковых журналов. Для индексатора top‑k это тридцать двойников, и свежий журнал может проиграть отбор старому. У Anthropic context editing по умолчанию срабатывает на 100 тыс. токенов и оставляет последние три результата инструментов (документация).

• Поиск вместо заливки. Не надо класть в контекст весь модуль на 200 тыс. токенов «на всякий». rg "PaymentService" + чтение двух файлов кладёт нужное прямо в хвост. Нюанс: на вопросах по кодовой базе простой векторный индекс однажды обошёл grep‑субагента (65,2% против 46,2%), и 41,8% ошибок случились при передаче результата назад (2608.01507). Так что молиться на grep тоже не стоит.

• Повтор в хвосте. В Claude Code хуки SessionStart, PostToolUse и Stop умеют добавлять additionalContext (до 10 000 символов), а после компактизации правила возвращаются через SessionStart с matcher compact (доки). Там же советуют формулировать такой текст фактами, без повелительного наклонения, иначе может сработать защита от prompt injection.

• Компактизация. В API она уже есть «из коробки»: у Claude — серверная с порогом и своими инструкциями для резюме (документация), у OpenAI — compact_threshold или отдельный /responses/compact (документация). Рекомендуемого порога никто, кроме Moonshot, не публикует.

Запрещающих хуков, прав и песочницы в рейтинге нет, и это сделано специально. К контексту они отношения не имеют, это страховка на случай, если остальное подвело, и ставится она всегда.

Как собрать свою обвязку под длинный контекст?

Важное держим там, где модель читает надёжно, остальное — снаружи, и подносим по запросу. Правил из этого вышло десять. Где за правилом стоит замер, а где просто мой вывод, помечаю по ходу.

Верхняя часть схемы вовремя подносит нужное в хвост, нижняя не даёт середине зарасти. А самой нижней полосе на внимание вообще плевать.

1. Задайте окну рабочий бюджет ниже максимума и компактизируйте до него. Для открытых моделей перелом обычно в районе 128–256 тыс., у Kimi K3 официальный ориентир — 300 тыс. из 1 млн. YaRN у Qwen «на всякий» не включайте, нативных 262 тыс. почти всегда хватает.

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

3. Правила пишите так, чтобы их нашёл индексатор. Top‑k отбирает по похожести на текущий шаг, поэтому правило должно звучать как сам шаг, с именами файлов и командами. «Аккуратнее с базой» не найдётся никогда. У «alembic downgrade и правки в migrations/ — только после вопроса человеку» шансы есть. Это мой вывод из архитектуры, прямых замеров я не видел.

4. То, что важно в момент действия, подкладывайте в хвост по событию: выжимку правил каждые N вызовов, цель после компактизации, список дел перед завершением. Формулировать лучше как факты, так советует и документация Claude Code.

5. Выходные данные инструментов отдавайте страницами: начало, конец и путь к полному журналу на диске. Старые результаты чистите редко и пачками, потому что каждая чистка ломает кеш с места правки.

6. Двойников быть не должно: одна актуальная версия файла — одна формулировка правила. Если ограничение поменялось, то прямо напишите, что старое больше не действует. По MTAC‑IFBench обновлять правила моделям тяжелее, чем добавлять новые.

7. Состояние живёт вне окна: журнал сессии только на добавление, файл прогресса, git. При сжатии дословно сохраняйте пути, идентификаторы, действующие ограничения и код. Пересказ кода теряет поведение, и это измерено.

8. Субагентам отдавайте чтение, поиск и проверку, совместную запись лучше не надо. Пусть возвращают адреса вида файл:строка: больше 40% ошибок субагентного поиска случаются как раз на передаче результата.

9. Длинному циклу нужен отдельный оценщик и стоп по метрике. Агенты оценивают свою работу слишком щедро, скептик с чистым контекстом справляется лучше (Anthropic). Если метрика упала ниже исходной, цикл должен остановиться, и никакой новой задачи «почини» он порождать не должен.

10. Гарантии делайте вне модели: запрещающие хуки, права, песочница, защищённая ветка. Выходные данные инструментов помечайте как данные, секреты держите подальше от песочницы.

«Пила» на схеме и есть рабочий бюджет в действии: дошли до порога, сжали, поехали дальше.

Настройки под конкретные модели

Пример: правила в хвост каждые 20 вызовов

Иллюстрация в формате хуков Claude Code (PostToolUse). В других обвязках события называются иначе, идея та же.

#!/usr/bin/env bash
# hooks/rules-tail.sh — каждый 20-й вызов инструмента кладёт выжимку правил в конец контекста
S="$(git rev-parse --show-toplevel)/.agent/state"; mkdir -p "$S"
n=$(( $(cat "$S/tool_count" 2>/dev/null  echo 0) + 1 )); echo "$n" > "$S/tool_count"
[ $((n % 20)) -eq 0 ]  exit 0
jq -n --rawfile c .agent/rules.md 
  '{hookSpecificOutput:{hookEventName:"PostToolUse", additionalContext:$c}}'

А вот как может выглядеть сам rules.md — сформулирован как факты и словами самой задачи:

— В этом репозитории файлы в migrations/ меняются только после подтверждения человека.
— Тесты запускаются командой make test; полный лог лежит в.agent/logs/.
— Текущая цель записана в.agent/goal.md.

Чек‑лист на один вечер

Восемь пунктов, которые дадут большую часть эффекта. По времени — дольше одной катки, но короче рейда.

• Рабочий бюджет окна записан в конфигурации, и компактизация срабатывает раньше, чем окно переполнится.

• Файл правил уложен в ~100 строк и написан руками, без пересказа того, что видно из кода.

• Вывод инструментов усекается, полная версия пишется на диск.

• Старые результаты инструментов чистятся пачками.

• Выжимка правил и цель возвращаются в хвост хуком, в том числе после компактизации.

• Есть файл прогресса и журнал сессии вне окна.

• Поиск по коду и проверка вынесены в субагенты, которые возвращают адреса, а не пересказ.

• Опасные команды закрыты запрещающими хуками и правами.

Частые ошибки

• «У модели 1 млн, значит компактизация не нужна». Нужна, причём раньше, чем кажется.

• AGENTS.md на тысячу строк, который сгенерировала сама LLM. Дороже и не лучше.

• Правила, которые агент получил через вывод инструмента, например спецификация, прочитанная по ходу. Они уедут в середину и потеряют вес.

• Пересказ вместо адресов при компактизации. «Мы починили авторизацию» без пути к файлу и коммита — ну такое.

• Надежда на промпт там, где нужна гарантия. «Никогда не делай force‑push» в промпте лишь снижает вероятность, а deny‑хук просто не пустит.

Вместо вывода

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

Если бы мне пришлось выбрать из всего этого одну вещь на завтра, то я бы начал с чистки старого вывода инструментов. Скучно и дёшево, зато работает.

Если ваш агент тоже начинает подбирать с земли что попало, напишите в комментах, на каком объёме контекста это случается. Интересно сравнить с числами из статьи.

Источники

Модели и архитектуры

• GLM: GLM-5 (arXiv 2602.15763), GLM-5.1, GLM-5.2, GLM-5.3, GLM-5.3-Flash, блог Z.ai о GLM-5.3-Flash

• Qwen: Qwen3-Next, Qwen3.5–397B, Qwen3.6–35B‑A3B, Qwen3.6–27B, Qwen3.8–27B, Qwen3.8–2.4T‑A95B, QwenLM/Qwen3.8 на GitHub

• DeepSeek: DeepSeek‑V4 (arXiv 2606.19348), конфиг V4-Pro, DeepSeek‑V4.1-Flash

• Kimi K3, MiniMax M3 и MSA (arXiv 2606.13392), Nemotron 3 Ultra, Gemma 4 31B

Исследования длинного контекста

• MTAC‑IFBench (2609.14992) — дрейф инструкций в агентных траекториях

• IH‑Benchmark (2607.25987) — иерархия инструкций

• 2603.20432 — агенты с файлами против полного контекста

• ARC (2607.25066) — адресуемая компактизация

• 2607.09691 — пересказ кода против исходника

• NoisyBench (2601.07226) — отвлекающие фрагменты

• 2603.10123, 2602.16837 — теория провала в середине

• 2608.01507 — векторный поиск против grep‑субагента

• CooperBench (2601.13295) — совместная работа агентов

• AGENTS.md (2602.11988) — эффект файлов правил

• The Complexity Trap (2508.21433) — маскирование вывода, фон 2025

Обвязки и документация

• OpenAI: Harness engineering, compaction

• Anthropic: Harness design for long‑running apps, Managed Agents, context editing, compaction, hooks, skills, advanced tool use