Иллюзия "одной нейросети"
NB: Сразу укажу, что эта статья — результат моих собственных размышлений, реального инженерного опыта, экспериментов и разбора большого массива профильных работ. Разные ИИ использовались для поиска данных, структурирования и финальной редактуры этого лонгрида — так что за ровный слог тапками просьба не кидаться.
Как устроены промышленные ИИ-конвейеры, почему универсальные открытые харнесы упёрлись в потолок и какая архитектура — от ядер чистых рассуждений 380B–500B в NVFP4 до резидентного компилятора — нужна для реальной инженерии
Введение: что скрывается за неравномерным пульсом флагманских API
При плотной работе с закрытыми флагманскими системами от OpenAI, Anthropic или Google трудно не заметить характерную рваность их отклика. На один вопрос сервис мгновенно выдаёт страницу текста. На другом — замирает на десять–пятнадцать секунд с индикатором размышления, выводит ответ порциями, берёт длинную паузу посреди решения, после чего резко меняет тон и выдаёт точную инженерную справку с выверенными цифрами и компилирующимся кодом.
Сами по себе микрозадержки стриминга ещё ни о чём не говорят. На публичном кластере темп выдачи токенов постоянно плавает из-за вытесняющего непрерывного батчинга (continuous batching), отбраковки черновиков в спекулятивном декодировании и очередей маршрутизации в разреженных MoE-моделях. Но когда многосекундные паузы систематически предшествуют скачку в качестве фактологии и сочетаются с уже открыто задокументированными серверными механизмами облачных платформ — динамическим поиском инструментов, исполнением кода оркестрации в скрытых контейнерах и серверным сжатием контекста, — складывается однозначная картина.
За фасадом современных флагманских API больше нет «одной умной нейросети». Упершись в математические и аппаратные пределы изолированных трансформеров, индустрия ушла от нейросетевого пуризма и выстроила вокруг языковых моделей гибридный вычислительный конвейер.
Восприятие этой архитектуры сильно искажено бизнес-моделью самих игроков:
Профильные ИИ-лаборатории (OpenAI, Anthropic) строят капитализацию на вере рынка в автономную «думающую модель», поэтому вся алгоритмическая обвязка у них максимально спрятана за единым эндпоинтом.
Инфраструктурные гиганты (Google) десятилетиями опирались на детерминированные поисковые индексы, графы знаний, распределённые песочницы Borg и компиляторы. В их системе координат языковая модель изначально выступает лишь вероятностным интерфейсом и генератором эвристик внутри классического системного стека.
К концу 2026 года именно второй взгляд точнее всего описывает физическую реальность. Надёжность системы на длинной дистанции определяется не весами в вакууме, а связкой мощной модели с детерминированным серверным контуром управления — супер-харнесом (от англ. harness — упряжь, испытательный стенд, среда оркестрации).
В этой статье мы последовательно разберём четыре ключевых вопроса:
Почему локальные CLI-агенты деградируют при переключении на открытые модели? Покажем, почему просадка качества в терминальных клиентах вроде Claude Code, Codex CLI или OpenCode вызвана не «глупостью» открытых весов, а потерей серверного конвейера и выходом модели из родной среды RL-обучения.
В какой потолок упёрлись открытые харнесы и протокол /v1/chat/completions? На данных свежих аудитов исходного кода и осенних бенчмарков 2026 года разберём, почему дефицит серверных CPU и памяти DDR5 не позволил открытым лабораториям раздавать серверный комбайн бесплатно, а попытка сообщества выехать на текстовых обёртках и облачных MCP-сниппетах (Context7, Exa) забуксовала на сложной инженерии.
Почему на ускорителях класса B300/GB300 назревает возврат к крупным плотным (Dense) моделям 380B–500B в формате NVFP4? Посчитаем в байтах и флопсах, как вынос энциклопедической статики в таблицы Engram, сжатие KV-кэша до сотен мегабайт и параллельный поиск по дереву переворачивают экономику шины HBM в окне средних батчей и требуют двухконтурной архитектуры (GPU-вычислитель + выделенный CPU-сервер харнеса).
Какой программный стек нужен самому конвейеру? Разделив три уровня кода — от одноразовых скриптов фильтрации до ядра оркестратора, — объясним, почему высокочастотная верификация невозможна без нативно многопоточных компилируемых платформ, резидентных тайп-чекеров, CoW-песочниц и строгого протокола Token-In-Token-Out.
1. Историческая развилка: от символьного ИИ к догме «Горького урока»
В 1970–1990-х годах в искусственном интеллекте безраздельно доминировал символьный подход (Good Old-Fashioned AI, GOFAI) и экспертные системы логического вывода. Инженеры проектировали графы знаний, базы правил и алгоритмы поиска по дереву состояний: A*, минимакс, метод ветвей и границ. Главным козырем таких систем был стопроцентный детерминизм и формальная доказуемость — они по определению не умели галлюцинировать. Однако к девяностым годам это направление надорвалось под собственным весом по двум причинам:
Хрупкость на неструктурированном входе. Невозможно написать конечный набор правил if-then-else, который надёжно переводил бы живой человеческий язык с опечатками, многозначностью и недосказанностью в строгие логические предикаты.
Комбинаторный взрыв эвристик. В проектах масштаба Cyc исследователи десятилетиями вручную вводили миллионы аксиом здравого смысла. Когда счёт правил шёл на сотни тысяч, они начинали противоречить друг другу, а ветвление дерева вывода обгоняло возможности любого процессора.
Глубокое обучение и архитектура Трансформера (2017) сняли проблему нечёткого восприятия. Следом, в 2019 году, Ричард Саттон опубликовал знаменитое эссе «Горький урок» (The Bitter Lesson): любые попытки человека вручную зашить в систему алгоритмы поиска, структуру знаний и формальные ограничения в долгую проигрывают грубому масштабированию вычислений и сквозному обучению единой сети (end-to-end).
На следующие пять лет этот тезис превратился в индустриальную догму. Внешние индексы, парсеры и верификаторы записали во временные «костыли», искренне полагая, что с ростом кластеров безошибочное алгоритмическое мышление самозародится внутри матриц весов.
2. Три фундаментальных предела изолированной нейросети
К 2025–2026 годам, когда индустрия перешла от генерации коротких справок к инженерным задачам на сотни взаимосвязанных шагов, выяснилось, что одиночный трансформер упирается в три жёстких ограничения математики и компьютерной архитектуры.
Предел первый: накопление ошибки в разомкнутом контуре и лавина тупиков
Возьмём в качестве верхней теоретической оценки чистую авторегрессию в разомкнутом цикле — без внешней проверки инвариантов. Даже если на одном логическом шаге модель права с вероятностью 99% (p = 0.99), при независимом накоплении ошибки шанс пройти без сбоя цепочку из N шагов падает экспоненциально (P = p^N):
на 10 шагах — 90.4%;
на 100 шагах — 36.6%;
на 500 шагах — 0.66%.
Разумеется, модели с RL-посттренингом на цепочках рассуждений сглаживают это падение за счёт текстовой самопроверки по ходу вывода. Но без внешнего детерминированного оракула нейросеть слепа к собственным системным заблуждениям: одна тихая ошибка в допущении или типе данных на десятом шаге обесценивает четыреста последующих.
Наглядную анатомию этого распада дала совместная работа исследователей Нанкинского университета, ETH Zurich и Лондонского университета по нейросимвольной верификации системного ПО (Neuro-Symbolic Proof Generation for Scaling Systems Software Verification, симпозиум USENIX OSDI '26, июль 2026). При формальном доказательстве базовой теоремы о знаковом переполнении машинных слов (sofl_test) из микроядра ОС seL4 в среде Isabelle/HOL дообученная модель сгенерировала 8 445 шагов-кандидатов. Внешняя символьная фильтрация показала, из чего на самом деле состоял этот поток:
44.2% предложенных шагов вели в семантические дубликаты уже пройденных состояний (их отсекал двунаправленный решатель SolveDirect);
52.3% из оставшихся состояний содержали контрпримеры и были математически недоказуемыми тупиками (их отбраковали генератор случайных тестов QuickCheck и реляционный SAT-решатель Nitpick/Kodkod).
В сумме почти три четверти — 73.4% — сырых предложений модели отсеивались до глубокого раскрытия дерева, сберегая львиную долю вычислений. Базовые модели без предметного дообучения даже с поиском по дереву набирали на теоремах seL4 около 0.0–0.1%, чистое SFT-дообучение поднимало планку до 57–60%, а полный нейросимвольный контур с автопочинкой тактик и вызовом решателя Sledgehammer довёл долю доказанных теорем до 70.4% даже на крошечной Qwen3-1.7B и до 77.6% на старших дообученных моделях.
Предел второй: матрица весов как дорогая и ненадёжная база данных
В классическом трансформере (включая разреженные архитектуры Mixture-of-Experts) нет нативного примитива поиска по ключу. MoE масштабирует условные вычисления, но всё равно вынужден симулировать извлечение статических фактов через тяжёлые матричные умножения. Группа ETH Zurich строго доказала в работе Provable Benefits of In-Tool Learning for Large Language Models (arXiv:2508.20755), что объём фактов, запоминаемых внутри весов (in-weight learning), линейно зажат числом параметров и страдает от взаимной интерференции. Напротив, обучение компактной схеме внешнего запроса (in-tool learning) после фазового перехода — «грокинга» логики обращения к индексу — открывает безошибочный доступ к сколь угодно большой базе фактов.
В январе 2026 года DeepSeek и Пекинский университет перевели этот вывод в плоскость системной архитектуры, представив модуль Engram (Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models, arXiv:2601.07372). Механистический анализ через LogitLens и CKA вскрыл парадоксальный факт: обычные трансформеры тратят несколько ранних слоёв внимания и FFN исключительно на «сборку» статических именованных сущностей и устойчивых языковых штампов. Это сжигает дефицитную память HBM и крадёт эффективную глубину сети у настоящей логики.
Добавив на отдельных слоях (например, 2-м и 15-м) прямое хеш-извлечение статических N-граммных эмбеддингов за O(1) со сжатием словаря на 23% через NFKC-нормализацию и контекстным гейтированием, авторы открыли U-образный закон распределения разреженности: чистая MoE систематически проигрывает гибриду, в котором 20–25% разреженного бюджета отдано под статическую память. При строго равном числе параметров и FLOPs модель Engram-27B обошла MoE-27B не только в эрудиции, но и в чистом мышлении:
Фактология: MMLU +3.4, CMMLU +4.0;
Логика, код и математика: BBH +5.0, ARC-Challenge +3.7, HumanEval +3.0, MATH +2.4;
Удержание длинного контекста: Multi-Query NIAH вырос с 84.2% до 97.0%, а Variable Tracking — с 77.0% до 89.0%.
Так как адреса в таблице Engram детерминированно зависят только от входных токенов, вынос 100-миллиардной таблицы (~200 ГБ) из видеопамяти в обычную хостовую DDR5 с упреждающей подгрузкой по шине PCIe замедлил генерацию менее чем на 2.8–3%. К сентябрю 2026 года этот приём стал промышленным стандартом: в модели DeepSeek-V4.1-Flash (arXiv:2609.19969) в паре с 552B-бэкбоном штатно работает модуль условной памяти Engram на 196B параметров, асинхронно подгружаемый из памяти хоста без потери темпа декодирования.
Предел третий: линейное засорение контекста и отсутствие инструкции RET
В привычном чат-интерфейсе языковой модели нет аналога процессорной инструкции RET — возврата из функции с автоматической очисткой локального стекового фрейма. Инженерная команда Anthropic ещё в ноябре 2025 года (Introducing Advanced Tool Use) показала масштаб бедствия: при подключении полусотни корпоративных MCP-серверов одни лишь определения их JSON-схем съедают около 72 000 токенов до первой реплики пользователя, а каждый сырой ответ инструмента (простыня файла или поисковой выдачи) навечно дописывается в линейный лог диалога. К двадцатому шагу до 90% окна контекста и KV-кэша забито отработанным информационным шлаком, который размывает внимание модели.
Суть на пальцах: изолированная нейросеть на сложных задачах генерирует до трёх четвертей тупиковых или дублирующихся ходов, тратит ранние слои и дорогую видеопамять на вспоминание шаблонных фраз и уже к двадцатому шагу тонет в мусоре от собственных промежуточных вызовов.
3. Как устроен закрытый облачный комбайн и почему обманываются пользователи Claude Code
Чтобы обойти эти три предела, западные облачные платформы выстроили вокруг своих моделей эшелонированный серверный конвейер. К 2026 году большинство его узлов уже прямо описано в документации API Anthropic и OpenAI:
Динамический поиск схем (Tool Search, документировано). Вместо свалки всех JSON-описаний в системном промпте работает серверный индекс с флагом отложенной загрузки defer_loading. Подгрузка 3–5 нужных инструментов по требованию экономит 85% контекста на схемах и поднимает точность работы с большими пакетами MCP с 49% до 74% (и с 79.5% до 88.1% на старших моделях).
Программная оркестрация в скрытых контейнерах (Programmatic Tool Calling, документировано). В серверных песочницах Anthropic (code_execution) и хостед-рантаймах OpenAI модель не прогоняет каждый промежуточный вызов через свои веса, а пишет короткий одноразовый скрипт-координатор. Контейнер сам в цикле опрашивает API, фильтрует массивы данных в собственной оперативной памяти и возвращает в контекст модели только сжатый вывод — давая +11% точности на поисковых задачах и экономя 24% входных токенов.
Серверное удержание состояния и расчистка памяти (документировано). Флагманские платформы ушли от безликого чата к хранению непрерывного скрытого состояния рассуждений между шагами. У OpenAI это связка previous_response_id и зашифрованных блоков encrypted_content в протоколе /v1/responses; у Anthropic — криптографически подписанные блоки мышления и серверные механизмы context editing / compaction, автоматически вычищающие старые tool_result по заданным порогам.
Двухфазный поиск и адаптивная верификация (реконструкция пайплайна). Гонять тяжёлый поиск по дереву с компиляцией на каждый копеечный запрос в онлайне разорительно. Поэтому основную массу поискового дерева лаборатории «выжигают» офлайн на этапе гигантского агентного RL-посттренинга с компиляторами и контейнерами, впечатывая навыки выхода из тупиков в поток скрытых токенов рассуждения, а в рантайме адаптивно расширяют бюджет проверок только на сложных ветках и дорогих тарифах.
Незнание этой серверной кухни породило массовую методологическую ошибку среди пользователей локальных терминальных агентов — Claude Code, Codex CLI, OpenCode, Aider или Cline.
Типичный сценарий выглядит так: разработчик ставит на ноутбук Claude Code, работает через родной API Anthropic и видит отличную цепкость на крупном репозитории. Затем он переключает этот же (или похожий открытый) терминальный клиент на открытую модель через сторонний провайдер, видит распад логики на двадцатом шаге и выносит вердикт: «Клиент у меня на машине тот же самый — значит, открытые веса безнадёжно слабы».
Те, кто смотрел трафик терминальных агентов через mitmproxy, обычно возражают: «Подождите, ведь CLI-клиент локально вызывает bash и ripgrep на моём ноутбуке и шлёт на сервер обычные JSON-запросы!» Всё верно — и свежий аудит исходного кода одиннадцати ведущих кодинг-агентов (Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents, arXiv:2609.00006, июль–сентябрь 2026) это блестяще подтвердил. Четыре из одиннадцати препарированных систем в этом исследовании — фирменные вендорские клиенты (Claude Code, Codex CLI, Gemini CLI, Mistral Vibe), и внутри их клиентского кода обнаружился точно такой же ручной асинхронный цикл с ripgrep и tree-sitter, без какого-либо клиентского поиска по дереву.
Секрет превосходства закрытых связок живёт не в локальном бинарнике CLI, а в двух вещах по ту сторону сокета:
Серверная память и непрерывность мышления. Даже обслуживая локальный CLI, родное облако держит горячий префиксный кэш, сохраняет сквозное скрытое состояние рассуждений между вызовами локальных утилит, управляет серверным compaction и подставляет собственные поисковые и контейнерные инструменты.
Жёсткая коэволюция (co-design) весов и родного харнеса. Закрытая флагманская модель на этапе агентного RL провела тысячи GPU-лет именно внутри проприетарного окружения своего клиента. Её веса буквально вросли в конкретные сигнатуры редактирования файлов, формат diff-патчей, системные промпты со множеством условных веток и штатные коды ошибок.
Подключая стороннюю открытую модель к чужому тонкому клиенту по урезанному текстовому API, вы одновременно отключаете серверную подсистему памяти и выбрасываете модель в чужеродную среду (out-of-distribution), под которую её никто не учил.
Суть на пальцах: классические бенчмарки «голых» моделей в 2026 году потеряли смысл. Мерить качество весов в отрыве от родного для них харнеса и серверной памяти — всё равно что оценивать процессор по тактовой частоте отдельно от кэша и материнской платы.
4. Инфраструктурный кризис 2026 года и потолок «универсальных» открытых харнесов
Возникает логичный вопрос: почему ведущие открытые лаборатории Китая (DeepSeek, Alibaba/Qwen, Moonshot/Kimi, Z.ai/GLM) не развернули точно такой же серверный супер-харнес для всех пользователей своих копеечных публичных API? Ответ кроется в жёсткой аппаратной экономике 2026 года.
Переход от чат-ботов к агентам перевернул баланс серверного железа. Эпоха кластеров с пропорцией CPU к GPU порядка 1:4–1:8 закончилась: планирование, оркестрация десятков тысяч песочниц, компиляция и работа индексов целиком легли на универсальные процессорные ядра. Профилирование агентных нагрузок (Towards Understanding, Analyzing, and Optimizing Agentic AI Execution: A CPU-Centric Perspective, arXiv:2511.00739) показало, что обработка инструментов на CPU съедает до 88–90% сквозной задержки агентного шага и до 44% динамического энергопотребления.
Отраслевая статистика Arm и TrendForce за весну–осень 2026 года зафиксировала последствия этого сдвига: потребность дата-центров в процессорных ядрах взлетела вчетверо — с 30 до 120 млн ядер на гигаватт мощности, сдвинув целевое соотношение CPU:GPU к 1:1–1:2 и растянув сроки поставок серверных процессоров до 25–30 недель. Одновременно переброска кремниевых фабрик на выпуск маржинальной HBM и скупка серверной DDR5 гиперскейлерами под пулы контекста взвинтили цены на DRAM более чем на 400% с 2024 по конец 2026 года (по оценкам J.P. Morgan Global Research и Omdia).
В условиях экспортных ограничений раздавать столь дорогой CPU/DRAM-контур всему миру по демпинговым ценам невозможно. А попытка включить тяжёлый серверный комбайн только в закрытом платном облаке тут же разрушает паритет с открытыми весами — мы уже увидели первые симптомы этого расхождения в августе 2026 года у Alibaba, чей флагманский облачный Qwen3.8-Max (мультимодальный, с контекстом 1M) заметно разошёлся по возможностям с выложенным под кастомной лицензией текстовым чекпоинтом Qwen3.8-2.4T-A95B (262K контекста).
Поэтому большую часть 2025–2026 годов открытые лаборатории делали ставку на разделение труда: мы даём сильные веса и дешёвые токены, а клиентскую обвязку построит мировое сообщество. DeepSeek даже подняла официальный эмулятор api.deepseek.com/anthropic для прозрачного запуска своих моделей внутри Claude Code и активно поддерживала интеграции с OpenCode, Cline и Aider. Для повседневной разработки эти инструменты сделали огромное дело, однако на задачах глубокой системной инженерии сторонние «универсальные» харнесы упёрлись в три конструктивных предела — что к концу лета 2026 года вынудило саму DeepSeek выпустить превью собственного модульного каркаса @DeepSeek-ai/dsh.
Предел 1. Линейный цикл while(true) и отсутствие резидентного семантического графа
Упомянутый аудит одиннадцати кодинг-агентов (arXiv:2609.00006) вместе со сравнением шестёрки главных открытых платформ (OpenCode, Cline, Goose, OpenHands, Pi, Mini-SWE-Agent) наглядно показывает их потолок. Да, современные клиенты давно отказались от наивного векторного RAG по коду в пользу детерминированных утилит — ripgrep, glob, синтаксической разметки через tree-sitter или точечных вызовов LSP, а в OpenHands и @deepseek-ai/dsh появился событийный журнал сессии (Event Sourcing). Но сам контур управления в них остаётся плоским однопроходным циклом без верифицируемого ветвления:
В OpenCode это буквальный while(true) поверх SQLite, возвращающий от субагентов плоскую строку <task_result> и ловящий зацикливание (doom_loop) лишь при трёх побайтово совпавших вызовах подряд.
В Pi (pi-mono) — намеренно минималистичный цикл на ~790 строк кода без планировщика и верификатора.
Команды по умолчанию выполняются прямо в хостовой ОС без изолированных Copy-on-Write снапшотов, а переполненное окно сжимается обычным LLM-пересказом, безвозвратно теряющим точные сигнатуры типов и инварианты.
Процессуальные бенчмарки 2026 года подвели под этой архитектурой черту. На корпусе ContextBench (arXiv:2602.05892, 1 136 задач в 66 репозиториях с осенними прогонами 2026 года) выяснилось, что усложнение чисто текстового скаффолдинга почти не улучшает точность отбора контекста: модели гребут лишний код с низким Context F1 и теряют до 40% уже найденных ключевых фрагментов. А в октябрьском двухстадийном тесте Doc2Harness (arXiv:2610.20344, октябрь 2026), проверяющем соблюдение сквозных межмодульных контрактов самого рантайма на 328 сценариях, даже сильнейшие модели проваливают почти половину проверок (лучший результат — 53.05%, а у открытых флагманов уровня GLM-5.3 и DeepSeek-V4.1-Flash — 40–42%).
Предел 2. Подмена локального графа знаний облачными сниппетами (Context7 и Exa)
Стоит задаче выйти за пределы локального grep и потребовать точного знания десятков внешних библиотек и межпакетных контрактов, как открытые харнесы (включая базовую поставку @deepseek-ai/dsh, где сторонние MCP-памяти по умолчанию отключены) начинают опираться на внешние облачные поисковики — документационный сервис Context7 от Upstash и веб-поиск Exa. Октябрьские инструментальные замеры 2026 года (бенчмарк Upstash на 44 свежих изменениях API 2026 года, тесты WebCode и независимый рейтинг AgentTesting от 31 октября 2026) вскрыли жёсткую вилку этой связки:
Неприятный выбор между медленными квотируемыми сниппетами и быстрой сетевой свалкой. Базовый поиск Exa отвечает быстро (0.3–0.6 с в режимах fast/Lite, тогда как глубокий агентный поиск занимает 4–15 с), но вываливает в контекст в среднем по 5 000–8 600 токенов сырых веб-страниц на один вопрос. Context7 на порядок экономнее по токенам (медиана — 828 токенов), но добавляет 3.7–4.3 секунды сетевой задержки на один поисковый запрос (и около 5 секунд в классической двухшаговой схеме), жёстко квотирован на бесплатном тарифе и закрыт для локального self-hosting без корпоративной лицензии.
Версионное отравление контекста (context rot). Открытый веб-поиск не знает версий из вашего lock-файла. В тесте на 44 обновлённых API 2026 года лишь 18.2–25.0% выдач Exa содержали исключительно актуальные сигнатуры, а около 20% загруженных страниц несли устаревший и удалённый API — из-за чего модель втрое чаще выдавала заведомо нерабочий код (7.3–8.0% прямых ошибок на WebCode против 2.3% у Context7).
Слепота на многошаговых связях (multi-hop reasoning). Context7 отсекает чужие сайты, но возвращает узкую нарезку из нескольких коротких Markdown-кусков: в сквозном октябрьском прогоне AgentTesting агенты с Context7 успешно довели до конца лишь 11 сессий из 24 (а с Exa — 9 из 24), регулярно теряя соседние разделы гайдов по миграции. Но главное — текстовый поиск физически не умеет ходить по графу типов. Чтобы проследить цепочку из пяти вложенных интерфейсов между пакетами, модели приходится пять раз угадывать поисковую строку и ждать сеть, тогда как резидентный граф AST/SCIP в оперативной памяти сервера проходит эти пять указателей за доли миллисекунды.
Предел 3. Ловушка наименьшего общего знаменателя /v1/chat/completions
Чтобы одним кодом поддерживать 75+ облачных и локальных провайдеров, универсальные клиенты (OpenCode, Cline, адаптер pi-ai) общаются с моделями через старый stateless-протокол /v1/chat/completions — хотя сама OpenAI для агентных задач давно ушла на stateful-контракт /v1/responses, а DeepSeek для линейки V4/V4.1 вообще отказалась от Jinja-шаблонов чата в пользу специализированного Rust/Python-энкодера deepseek-recipe. Цепляние за старый чат-эндпоинт бьёт по агенту сразу в трёх точках:
Амнезия цепочки рассуждений между ходами. В многошаговых вызовах инструментов прокси и шаблоны /v1/chat/completions регулярно отрезают или ломают поле reasoning_content прошлых шагов. После каждого вызова утилиты модель теряет собственный внутренний план и заново додумывает его по сырому логу — притом что одно лишь сохранение непрерывного состояния мышления в /v1/responses, по замерам OpenAI, сразу добавляет +5% на агентном тесте TAUBench.
Нарушение принципа Token-In-Token-Out (TITO) и дрейф BPE. Чат-протокол гоняет по сети строки текста вместо точных массивов token_ids. Как показала инженерная команда Hugging Face в мае 2026 года (Agentic RL: Token-In, Token-Out Done Right), декодирование ответа в текст, склейка с выводом инструмента и повторная токенизация из-за краевых эффектов BPE-слияний меняют идентификаторы токенов на стыках сообщений. Этот тихий дрейф инвалидирует префиксный KV-кэш, уводит модель в чужие для неё последовательности токенов и делает невозможным честное RL-дообучение на собранных траекториях.
Отсутствие контроля над KV-деревом и оверхед на микро-решениях. Через плоский HTTP-чат нельзя разветвить или точечно сбросить отработанную ветку KV-кэша на GPU. Более того, к выходу осенних релизов vLLM v0.32–0.33 (где появились отдельные быстрые эндпоинты /v1/systemone и /v1/decisions под неавторегрессионные классификационные головы) стало очевидно: свыше 65% обращений внутри развитого агентного пайплайна — это мгновенные микро-решения (маршрутизация, скоринг релевантности, проверка стоп-условий), гонять ради которых тяжёлый генеративный цикл чата просто бессмысленно.
Суть на пальцах: ставка на универсальную совместимость со старым текстовым протоколом /v1/chat/completions и внешними сниппетными MCP превратила массовые открытые клиенты в отличных помощников для локальной рутины, но отрезала им путь к глубокой многошаговой инженерии.
5. Какое нейросетевое ядро нужно комбайну: нижний порог ёмкости и инструментальный претрейн
Прежде чем проектировать серверное железо, важно не качнуться в обратную крайность и не решить, будто строгий харнес позволит закрывать любые архитектурные задачи крошечной моделью на 7–30 миллиардов параметров.
Высокий результат компактных моделей вроде Qwen3-1.7B на теоремах seL4 из работы OSDI '26 не должен обманывать: он получен внутри замкнутого формального языка Isabelle/HOL после узкого дообучения на однотипных состояниях, а при удлинении цепочки доказательства авторы сами зафиксировали просадку и необходимость старшего планировщика. В реальной системной разработке — где нужно одновременно удерживать распределённую архитектуру, нетривиальные инварианты конкурентности, семантику десятков смежных модулей и коварные краевые случаи, — малым моделям физически не хватает ёмкости внутренних представлений. Даже идеальный фильтр верификаторов бесполезен, если генератор гипотез ни разу не предложит структурно глубокий ход.
Эволюция открытых моделей в 2025–2026 годах чётко прорисовала как этот нижний порог, так и расслоение моделей на два эшелона:
Первая волна открытых агентных флагманов — DeepSeek-V3.2 (671B общих / 37B активных), Qwen3-Coder-480B-A35B, GLM-4.5/4.7 (355B / 32B) и Kimi K2 (1.04T / 32B, arXiv:2507.20534) — закрепила базовый стандарт MoE класса 300B+ с узким горлышком в 30B–40B активных параметров на токен.
Вторая волна середины–осени 2026 года разделилась по назначению. Скоростные рабочие лошадки для дешёвого массового трафика (DeepSeek-V4.1-Flash с 8B активных на prefill и 16B на decode, Qwen3.8-Flash-Next со 125B общих и 6B активных) пошли по пути предельного ужатия активных весов. Зато старшим флагманам тяжёлого синтеза — DeepSeek-V4-Pro (1.6T / 49B активных, arXiv:2606.19348), GLM-5.3 (753B / 40B), Qwen3.8 Max-класса (2.4T / 95B активных) и Kimi K3 (2.8T / 104B активных) — чтобы пробить потолок сложного планирования, пришлось в полтора–три раза нарастить активные параметры на токен (вплоть до 95B–104B), раздув общий пул экспертов почти до трёх триллионов.
При этом к нейросетевому ядру внутри промышленного супер-харнеса предъявляются два качественно новых требования, отличающих его от прежних «всезнающих» чат-гигантов:
Полная очистка дорогих весов в HBM от энциклопедического балласта. В старой парадигме львиная доля из триллионов параметров расходовалась на неточное заучивание редких фактов, старых версий SDK и языковых клише. В гибридной архитектуре низкоуровневая статика языка уходит в таблицы Engram на 100B–400B параметров в дешёвой памяти DDR5/LPDDR5X (как 196B Engram в DeepSeek-V4.1-Flash или 51B N-граммных таблиц в Qwen3.8-Flash-Next), а точная документация и структура кода живут в резидентных индексах харнеса. Каждый гигабайт HBM освобождается под чистое композиционное мышление, абстрактный синтез и декомпозицию.
Эпистемический рефлекс массового параллельного вызова инструментов с претрейна. Большинство старых моделей работают с инструментами неуклюже — дёргают их по одному в медленном последовательном цикле или срываются на угадывание фактов по памяти, — потому что tool use приклеивали к готовой текстовой сети в самом конце поверхностным SFT. Когда модель на протяжении 20–45 триллионов токенов претрейна заставляют вспоминать факты из собственных весов, привычка галлюцинировать при нехватке данных въедается намертво. В зрелом пайплайне (заложенном в масштабных инструментальных средах Kimi K2/K3 и контурах «мышления с инструментами» DeepSeek-V4) диалог со внешней средой формируется с базовых стадий обучения: столкнувшись с неизвестным контрактом, модель рефлекторно выбрасывает веер из 10–20 ультракомпактных параллельных запросов к графу кода, компилятору и индексу знаний, собирает точные ответы через служебные токены и строит ход на твёрдой почве.
6. Архитектурный разворот на Blackwell Ultra (B300): ренессанс крупных плотных моделей 380B–500B в NVFP4
Если сложить описанные выше сдвиги в одно уравнение — вынос статики в Engram, передачу справочных знаний харнесу, сжатие кэша контекста и переход от линейного чата к параллельному поиску по дереву, — проявляется неожиданный системный вывод. Те самые технологии, которые выросли внутри экосистемы разреженных сетей, подрывают безальтернативность ультра-разреженных MoE в инженерном сегменте и открывают дорогу возвращению крупных плотных (Dense) и высокоактивных моделей масштаба 380B–500B параметров в формате NVFP4.
Вспомним, почему в 2024–2025 годах после Llama-3.1 405B и коммерчески тяжёлой GPT-4.5 индустрия списала полутриллионные плотные трансформеры со счетов в пользу MoE с активацией 3–5%:
Энциклопедический налог: пока все знания мира хранились в матрицах FFN, для высокой эрудиции требовалось 1–2.8 триллиона весов, и активировать их на каждый токен было безумием.
Раздутый KV-кэш: при обычном GQA в BF16 контекст 128K на модели класса 400B съедал десятки гигабайт видеопамяти на одну сессию, вытесняя веса на многокарточные связки.
Отсутствие аппаратного FP4: в 8- и 16-битных форматах модель на 400B–500B весила от полутерабайта до терабайта и требовала целого узла ускорителей.
К осени 2026 года все три барьера рухнули одновременно.
Во-первых, отпала нужда держать в HBM 96% «спящих» экспертов ради кругозора
Мультитриллионные гиганты вроде Kimi K3 (2.8T при 104B активных) или Qwen3.8 Max-уровня (2.4T при 95B активных) требуют полтора терабайта дорогой кластерной HBM, где в каждый такт времени 96% весов простаивает, работая пассивной ассоциативной картотекой. Когда статика языка вынесена в хостовую DDR5 через Engram, а документация и граф символов лежат в RAM сервера харнеса, эти полупустые терабайты больше не нужны.
Для глубокого же синтеза дискретный роутер MoE всегда оставался вынужденным компромиссом: он режет внутреннее представление между изолированными экспертами и теряет тонкие междисциплинарные пересечения, если нужная комбинация признаков не прошла через узкое сито top-k. В очищенной от информационного мусора плотной модели масштаба 380B–500B все 100% параметров в HBM работают на каждом токене как единая полносвязная вычислительная ткань — давая ту глубину одношагового синтеза, ради которой в MoE пришлось раздувать модели до 2.5–2.8 триллионов весов.
Во-вторых, сжатие KV-кэша уменьшило след контекста с десятков гигабайт до сотен мегабайт
Гонка за дешёвый миллионный контекст в Китае привела к радикальному сжатию состояния внимания. В DeepSeek-V4.1-Flash (arXiv:2609.19969) архитектура Compressed Sparse Attention 2 (CSA2) объединила межслойное переиспользование глобального кэша и разреженных индексов, динамический пересчёт локального скользящего окна (SWA Bounded Replay) и хранение основного кэша в FP4 (E2M1 с поблочным скейлом E4M3). В результате постоянный след KV-кэша в HBM сжался до 890 байт на токен на всю модель — это около 114 МБ на 128K контекста и менее 1 ГБ на миллион токенов.
Параллельно развивается ветка гибридов 3:1 и 5:1 с линейным рекуррентным вниманием (Gated DeltaNet в семействе Qwen3.6/3.8, Kimi Delta Attention в Kimi K3), которая тоже укладывает длинный контекст в пару гигабайт. Однако для супер-харнеса с поиском по дереву здесь есть критическая системная деталь: страничный разреженно-латентный кэш уровня CSA2/MLA позволяет ветвить и отсекать десятки параллельных гипотез за O(1) без копирования общего префикса, тогда как рекуррентная матрица состояния линейного внимания мутирует на каждом токене in-place. Чтобы откатывать спекулятивные черновики и ветвить дерево на линейном внимании, приходится сохранять и восстанавливать тяжёлые слепки состояния в узлах дерева (именно ради этого в vLLM под Kimi-K3 пришлось внедрять специальные ядра RecoverSSM). Поэтому чистый страничный кэш типа CSA2/MLA для поискового дерева оказывается конструктивно идеальным напарником — и при объёме 1–3 ГБ он практически перестаёт конкурировать с весами за видеопамять.
В-третьих, NVIDIA B300 (Blackwell Ultra) изменила геометрию укладки весов
Посчитаем укладку строго по байтам, без маркетинговых округлений. Одиночный ускоритель NVIDIA B300 несёт 288 ГБ памяти HBM3e (после вычета серверного резерва ECC реально доступно 279 ГБ в модулях GB300 и 270 ГБ на воздушных платах HGX B300) и выдаёт 15 PFLOPS плотных (dense) вычислений NVFP4 — в полтора раза больше, чем B200, причём весь прирост пришёлся именно на плотную математику (sparse-пик остался прежним — 20 PFLOPS), а блок специальных функций экспоненты для ускорения softmax во внимании удвоился до 10.7 ТЭксп/с.
Сам формат NVFP4 занимает не 0.5 байта, а 4.5 бита (0.5625 байта) на вес за счёт 8-битного скейла FP8 E4M3 на каждый микроблок из 16 чисел. С учётом того, что в промышленных рецептах нативного FP4-обучения (arXiv:2509.25149, arXiv:2610.24343) эмбеддинги, lm_head, нормализации и 10–15% наиболее чувствительных слоёв оставляют в BF16/FP8, честная средняя плотность чекпоинта составляет 0.58–0.60 байта на параметр:
На одной карте B300 (270–279 ГБ доступной HBM3e): буквальные 500B параметров весят ~290–300 ГБ и в одиночный чип впритык не входят. Зато плотное ядро масштаба 380B–420B параметров (~220–248 ГБ весов) целиком ложится на один GPU B300 вместе с буферами CUDA и сжатым до 1–3 ГБ многоветочным KV-кэшем CSA2.
На спаренном модуле GB300 Superchip (2x B300 = 558 ГБ доступной HBM3e): полноразмерный плотный гигант на 500B–750B параметров (290–440 ГБ весов) свободно размещается в едином когерентном домене NVLink 5 (1.8 ТБ/с), напрямую связанном по шине NVLink-C2C (900 ГБ/с) с процессором Grace и его ~480 ГБ памяти LPDDR5X — куда идеально встаёт таблица Engram на 200B–400B параметров. Многоузловой сетевой трафик экспертного параллелизма (All-to-All), отъедающий у кластерных MoE от 50% до 90% времени шага (arXiv:2510.05497), исчезает как класс.
Главный эффект: как окно батчей дерева поиска (M = 128–512) переворачивает шину памяти в пользу Dense
Инженер инференса тут же задаст проверочный вопрос: «Да, плотные вычисления на B300 выросли до 15 PFLOPS, но полоса пропускания HBM3e осталась прежней — 8 ТБ/с! Разве плотная модель не задохнётся на чтении памяти? И почему тогда сама DeepSeek в V4.1-Flash сжала активацию до 8B/16B вместо выпуска плотной 400B?»
Ответ кроется в том, что на графике Roofline для ускорителя B300 существуют три принципиально разных эксплуатационных режима, зависящих от числа одновременно обрабатываемых токенов M. Отношение пиковых вычислений к полосе памяти на B300 составляет 15 PFLOPS / 8 ТБ/с = 1 875 FLOPs/байт. Поскольку каждый параметр NVFP4 весом 0.5625 байта выполняет 2 * M операций на пачке из M токенов, точка перегиба Roofline лежит на отметке M ~ 528 токенов.
Посмотрим, как ведут себя MoE и Dense в каждом из трёх режимов:
Режим 1. Линейный чат одного пользователя (M = 1..8 на узел). Узкое место B300 — полоса памяти HBM (8 ТБ/с). Здесь безоговорочно выигрывает разреженная MoE: плотная 400B читает 235 ГБ ради одного токена (~25–30 tok/s), тогда как лёгкая MoE читает только активных экспертов и выдаёт 180–250 tok/s.
Режим 2. Дерево поиска супер-харнеса на одном узле (M = 128..512, то есть 32–64 ветки по 6–8 draft-токенов). Мы попадаем прямо в зону излома Roofline (M ~ 528). Здесь выигрывает плотная (Dense) 380B–500B NVFP4: мелкозернистая MoE из-за фрагментации роутинга всё равно вычитывает почти 100% экспертов из HBM, а Dense за то же самое время чтения памяти утилизирует мощь 15 PFLOPS на глубокий синтез.
Режим 3. Публичное мульти-тенантное облако и холодный prefill 100K+ (M = 2048..8192+, сотни чужих сессий сразу). Ускоритель упирается в вычислительный пик (FLOPs-bound). Здесь выигрывают ультра-лёгкие MoE (V4.1-Flash 8B/16B, Qwen3.8-Flash 6B): при тысячах независимых запросов решает дешевизна FLOPs на токен — именно под этот облачный конвейер и создаются Flash-линейки.
Именно второй режим (M = 128–512) — это рабочий пульс выделенного инженерного супер-харнеса. Когда система решает одну тяжёлую задачу, она не цедит одну тонкую нитку текста, а на каждом шаге параллельно раскрывает 32–64 ветки дерева поиска поверх общего префиксного KV-кэша и комбинирует их со спекулятивным многотокенным драфтером (уровня DSpark или MTP на 6–8 токенов), подавая на верификацию в GPU плотную пачку из M = 256–512 токенов-кандидатов.
Внутри этого окна вступает в силу закон, строго выведенный исследователями AMD в марте 2026 года как неравенство qs и «двойной штраф MoE» (The qs Inequality: Quantifying the Double Penalty of Mixture-of-Experts at Inference, arXiv:2603.08960):
Что происходит с MoE при M = 256–512 (фрагментация переиспользования весов). В работе AMD коэффициент q (q ~ 3–5) означает множитель эквивалентного качества: чтобы сравняться по глубине с плотной моделью на 400B, разреженной MoE нужно около 100B активных параметров (то есть монстр класса Qwen3.8-Max 2.4T или Kimi K3 2.8T, который физически не лезет без целого 8-карточного сервера). Если же взять равную по памяти MoE-400B с 384 экспертами и топ-6 активацией (~30B–35B активных), то на пачке из M = 256 токенов из разных веток и черновиков роутер заденет в среднем 1 - (1 - 6/384)^256 ~ 98.2% всех экспертов (а при M = 512 — 99.97%!). Видеокарте всё равно придётся прокачать через шину 8 ТБ/с практически все 230 ГБ весов, заплатив сверху штраф за перестановку активаций и рваные групповые GEMM (настолько болезненный, что в TensorRT-LLM под Blackwell для таких пачек ввели режим DENSEGEMM, в лоб умножающий всех экспертов с последующим маскированием), но получив на выходе интеллект уровня 32B-активации при простаивающих на 90% тензорных ядрах.
Что даёт плотная (Dense) модель 380B–420B NVFP4 на одной B300 (или 500B+ на GB300). Плотная модель читает свои 230–240 ГБ весов ровно один раз без единой перестановки памяти. При M = 256 она выполняет ~205 TFLOPs (загружая около 45% пика 15 PFLOPS), а при M = 512 (~410 TFLOPs) выходит прямо к гребню Roofline. С поправкой на реальный КПД ядер (MFU/HFU ~70–75%), работу драфтера и внимание по 64 веткам один полный шаг укладывается в 38–45 миллисекунд. Это означает прокачку 8 000–12 000 токенов-кандидатов в секунду, что после отбраковки несовпавших хвостов спекулятивного черновика (при типичном коэффициенте принятия 0.60–0.70) даёт 5 000–8 000 чистых верифицированных токенов в секунду — причём каждый из них рождён в полносвязном 400-миллиардном ядре уровня мультитриллионных флагманов.
Уходит в прошлое и запретительная цена обучения таких ядер. Рецепты стабильного претрейна напрямую в NVFP4 с преобразованиями Адамара на градиентах, двумерным блочным скейлингом 16x16 и несмещённым оцениванием градиентов (arXiv:2509.25149, arXiv:2610.24343) уже ускорили обучение плотных моделей на кластерах Blackwell в 1.7–1.9 раза относительно FP8. А предложенная в arXiv:2603.08960 двухстадийная схема позволяет недорого обучить по FLOPs гигантского 2.5T MoE-учителя в кластере, а затем дистиллировать его очищенное от статики логическое ядро в компактную плотную (или «полуплотную» с активацией 150B–250B) NVFP4-модель специально под одноузловые комплексы с супер-харнесом.
Суть на пальцах: в одиночном чате (M = 1) и в гигантском публичном облаке на тысячи чужих запросов (M = 4096+) правят разреженные MoE. Но в инженерном окне M = 256–512, где один узел B300/GB300 крутит параллельное дерево поиска под одну сложную задачу, MoE теряет преимущество по памяти из-за разброса экспертов, а плотная модель 380B–500B в NVFP4 превращает простаивающие терафлопсы в кратно более глубокий шаг синтеза.
7. Двухконтурная аппаратная топология: зачем супер-харнесу отдельный CPU-сервер
Когда понятны и математика нейросетевого ядра, и объём символьных проверок вокруг него, вырисовывается физическая архитектура промышленного комплекса. Для его работы нужен мощный многоядерный процессорный узел (уровня старших Ryzen Threadripper PRO или серверных AMD EPYC на 32–64+ ядра), 128–512 ГБ быстрой памяти DDR5 и массив NVMe на несколько терабайт.
Важно сразу отсечь популярное заблуждение: этот процессорный сервер нужен вовсе не для того, чтобы крутить на CPU саму нейросеть со скоростью два токена в секунду. Напротив, комплекс строго разделяется на два физических контура, каждый из которых занимается своей стихией.
Контур 1 — Вычислитель весов и послойная память Engram
Единственная работа первого контура — на полной скорости прокачивать матричное ядро рассуждений широкими пачками веток и спекулятивных черновиков (M = 128–512) в строгом режиме Token-In-Token-Out. Он принимает и возвращает сырые массивы token_ids и logprobs без какого-либо рендеринга строк, обслуживает лёгкие классификационные головы микро-решений (/v1/systemone, /v1/decisions) и выставляет наружу прямые примитивы управления префиксным деревом KV-кэша (fork, pin, evict).
Таблицы условной памяти Engram (200–400 ГБ) живут прямо в хостовой памяти этого же GPU-узла — на шине PCIe Gen6 или в когерентной LPDDR5X процессора Grace по NVLink-C2C. Выносить Engram по обычной сети нельзя: асинхронная подгрузка эмбеддингов на ранних и средних слоях трансформера обязана укладываться в микросекундное окно вычисления соседних блоков.
Контур 2 — Выделенный CPU-сервер супер-харнеса
Все 32–64 ядра CPU и сотни гигабайт DDR5 второго контура целиком отданы детерминированной логике, которая работает между пакетными шагами GPU:
Удерживает в горячей RAM полные версионные базы знаний: скомпилированные точно под ваш lock-файл индексы исходников и документации всех зависимостей, поисковые движки Tantivy/BM25 и, главное, резидентный семантический граф целевого репозитория (AST, таблица символов и граф вызовов уровня SCIP). Многошаговый обход пяти вложенных контрактов здесь занимает не 20 секунд сетевых гаданий, а доли миллисекунды по указателям в памяти.
Управляет параллельным поиском по дереву состояний поверх иммутабельного журнала токенных траекторий, склеивает семантические дубликаты, пакует выжившие ветки в плотные батчи под GPU и мгновенно отсекает тупики.
Крутит на всех ядрах пул резидентных верификаторов: in-memory компиляторы, тайп-чекеры, раннеры property-based тестов и SMT/SAT-решатели, параллельно переваривающие веерные запросы нейросети.
Важное примечание о физике сети для гибридного облака. Если команда не покупает собственные B300/GB300 в офис, а арендует GPU-контур у облачного провайдера, оставлять CPU-сервер харнеса под столом за домашним или офисным интернетом нельзя. Когда сам шаг проверки дерева на GPU длится ~40 миллисекунд, сетевой пинг RTT = 25–40 мс между офисом и дата-центром сожжёт половину производительности впустую на ожидании пакетов. В правильной гибридной схеме выделенный 64-ядерный CPU-сервер харнеса арендуется в том же дата-центре (зоне доступности) в одной сети с GPU-узлом (RTT < 0.5 мс), а на ноутбуке разработчика остаётся только лёгкий терминальный или IDE-интерфейс.
8. Программный стек конвейера: три уровня кода и двухконтурная верификация
При обсуждении языков программирования для ИИ-инфраструктуры люди постоянно спорят о разных этажах здания. Чтобы снять кажущееся противоречие между питоновскими скриптами в облачных песочницах и требованием жёсткой статической компиляции, нужно чётко разделить три разных уровня кода:
Уровень А — Одноразовые клей-скрипты фильтрации (Programmatic Tool Calling)
Когда модель генерирует пятистрочный скрипт внутри изолированного контейнера, чтобы параллельно опросить десяток API-ручек, отфильтровать JSON по полю и вернуть одно агрегированное число, лёгкий скриптовый синтаксис или компактный типизированный DSL совершенно оправдан. Такой код живёт сто миллисекунд, не хранит состояния и уничтожается сразу после ответа.
Уровень Б — Целевой язык разрабатываемого продукта (под фильтром верификаторов)
Когда же конвейер проектирует и меняет сложную систему на сотни тысяч строк, выбор языка целевого проекта напрямую определяет пропускную способность дерева поиска.
Здесь необходимо чётко различать два эшелона отсева ошибок:
Первый эшелон — структурная и типовая верификация (1–2 мс в памяти). Весной 2025 года исследователи ETH Zurich и UC Berkeley в работе Type-Constrained Code Generation with Language Models (arXiv:2504.09246) разобрали структуру ошибок компиляции у открытых моделей и выявили жёсткую пропорцию: чисто синтаксический брак составляет лишь 6% ошибок компиляции, тогда как 94% приходятся на ошибки системы типов (несуществующие методы и поля, несовпадение сигнатур аргументов, нарушение контракта возвращаемого значения, необработанный null). Контекстно-свободные JSON-грамматики не видят контекстно-зависимых правил типизации. На динамическом Python или нетипизированном JS эти 94% поломок проскакивают в рантайм и роняют песочницу лишь спустя десятки секунд прогона тестов. Напротив, языки с богатой статической и алгебраической системой типов (Rust, OCaml, строгие режимы TypeScript, современная типизированная Java, а для критических ядер — Lean и Isabelle) позволяют отстреливать весь этот пласт галлюцинаций за пару миллисекунд прямо на AST в оперативной памяти (в самой работе ETH/Berkeley типовой префиксный автомат сократил ошибки компиляции сразу на 52–75%). Неслучайно именно строго типизированный TypeScript к 2026 году закрепился на первом месте на GitHub с рекордной долей принятых ИИ-пулреквестов (44.1%).
Второй эшелон — семантическая верификация и «проблема оракула» (микросекундные песочницы + контракты). Честно зафиксируем инженерную реальность: успешно скомпилированный код на Rust или TypeScript вполне может содержать дедлок, гонку данных или нарушать бизнес-логику. Более того, если обычные unit-тесты с конкретными примерами пишет та же самая нейросеть, которая только что написала багованную функцию, она легко воспроизведёт своё слепое пятно и в тесте. Поэтому в зрелом супер-харнесе за мгновенным фильтром типов следует контур проверки инвариантов: генеративный фаззинг и property-based тестирование (проверяющие математические свойства вроде идемпотентности, обратимости сериализации или сохранения баланса на тысячах случайных входов), дифференциальные прогоны против эталонных реализаций, проверка контрактов (pre/post-conditions) через SMT-решатели (Z3) и жёсткая фиксация высокоуровневых спецификаций человеком.
Уровень В — Ядро самого сервера супер-харнеса
Наконец, сам оркестратор дерева состояний, резидентный граф символов и брокер песочниц физически не могут строиться на однопоточном событийном цикле JS или интерпретируемом Python с GIL, тяжёлым клонированием мутабельных структур (deepcopy) и непредсказуемыми паузами сборщика мусора.
То, что первые открытые харнесы вроде OpenCode или превью @deepseek-ai/dsh написаны на Node.js/TypeScript — объяснимый компромисс первого поколения ради быстрого притока контрибьюторов. Но крайне показательно, что самой Microsoft ради 10-кратного ускорения пакетной проверки типов на больших репозиториях пришлось переписать компилятор TypeScript 7.0 (проект Corsa / tsgo, релиз GA 8 июля 2026 года) с JavaScript на компилируемый многопоточный Go с разделяемой памятью — причём в самом июльском релизе 7.0 программный in-memory API даже не успели стабилизировать, отложив его до осенней ветки 7.1. Для промышленного 64-ядерного сервера харнеса естественным фундаментом становятся нативно многопоточные компилируемые языки с предсказуемой укладкой памяти — Rust, C/C++ или современная Java.
Соединение этих трёх уровней опирается на три системных инварианта:
Резидентные in-memory демоны вместо консольных компиляторов. Тайп-чекер и анализатор перестают быть внешними CLI-утилитами, которые раз в минуту с нуля парсят тысячи файлов с диска. Внутри сервера харнеса они висят постоянно в RAM, держат горячий инкрементальный граф типов и проверяют дельты AST от десятков параллельных веток за 1–2 миллисекунды на всех ядрах.
Сквозной Copy-on-Write от оперативной памяти до ФС и баз данных. В RAM диспетчера узлы дерева состояний строятся на персистентных иммутабельных структурах (structural sharing), позволяя ветвить и откатывать контекст за O(1) переключением указателей. А на уровне семантических прогонов в песочницах тот же принцип реализуют Linux-неймспейсы поверх OverlayFS в tmpfs, снапшоты Btrfs/ZFS и MVCC-движки БД — клонируя и сбрасывая окружение ветки за микросекунды без копирования гигабайт файлов.
Каузальная гигиена префиксного дерева KV-кэша в контуре TITO. Крупные массивы данных передаются между инструментами по типизированным дескрипторам внутри памяти харнеса, вообще не заходя в окно нейросети. А расчистка памяти самой модели от тупиковых веток и прочитанных справок выполняется исключительно отсечением листовых поддеревьев префиксного KV-кэша. Попытка «вырезать» отработанный кусок из середины линейного кэша со сдвигом позиционных углов RoPE не только вносит ошибку вращения, но и оставляет каузально отравленный хвост: ведь все последующие токены на стадии prefill уже вычислили свои векторы K и V с учётом внимания к удалённому тексту и без честного пересчёта продолжают нести его фантомный след.
Суть на пальцах: промышленный супер-харнес — это компилируемый многопоточный сервер, где in-memory тайп-чекеры за миллисекунду выкашивают 94% некомпилируемого брака, property-тесты в микросекундных CoW-песочницах ловят семантические баги, а память GPU остаётся математически чистой за счёт строгого TITO и отсечения тупиковых листьев KV-дерева вместо «хирургии» посреди контекста.
Заключение
Десятилетний спор между классическим символьным подходом и чистым нейросетевым скейлингом завершился их инженерным синтезом. Ставка на то, что одна монолитная матрица весов заменит собой алгоритмы поиска, графовые индексы, системы типов и компиляторы, разбилась о физику памяти и экспоненциальное накопление ошибки — точно так же, как упёрлась в потолок попытка догнать закрытые облачные конвейеры при помощи тонких однопоточных обёрток поверх /v1/chat/completions и медленных сниппетных поисковиков.
При этом само вынесение памяти и проверок наружу запускает тектонический сдвиг внутри нейросетевого контура. Как только языковая статика уходит в таблицы Engram в хостовой DDR5, точная фактология переезжает в резидентные графы харнеса, а KV-кэш сжимается до сотен мегабайт, исчезает историческое оправдание для хранения в HBM полутора терабайт «спящих» экспертов MoE. В инженерном режиме параллельного поиска по дереву (M = 128–512) на ускорителях класса B300 и GB300 бывшее узкое место шины памяти оборачивается триумфом крупных плотных и высокоактивных ядер масштаба 380B–500B в NVFP4, где каждый прочитанный байт весов работает на глубину мысли.
Зрелая архитектура инженерного ИИ на рубеже 2026–2027 годов стоит на двух равноправных опорах:
Нейросетевой сопроцессор чистого рассуждения — освобождённое от справочного мусора ядро класса 380B–500B в NVFP4 на компактном узле B300/GB300 с послойной памятью Engram на шине PCIe Gen6 / NVLink-C2C и страничным кэшем уровня CSA2. Обученное с претрейна веерному параллельному запросу инструментов, оно отвечает за семантический парсинг нечётких требований, архитектурную интуицию и пакетную генерацию нетривиальных гипотез.
Детерминированный серверный супер-харнес на соседнем 64-ядерном CPU-узле с сотнями гигабайт DDR5 — резидентные AST/SCIP-графы кода, диспетчер дерева состояний, микросекундные CoW-песочницы, in-memory компиляторы и генеративные верификаторы инвариантов. Он служит безошибочной долговременной памятью и жёстким фильтром реальности, который не выпускает вероятностный шум наружу.
Работа с промптами и контекстом в этом мире никуда не исчезает, но перестаёт быть шаманским подбором фраз в окне чата. Она превращается в классическую системную инженерию — проектирование бинарно-токенных протоколов, иерархий памяти и формальных верификаторов вокруг мощного вероятностного ядра.
