Постоянная открытая память для многих агентов LLM: как документ о передаче управления в сети 6G Обеспечивает проблему «холодного старта» агента.

Прекратите передавать строки подсказок между агентами. Как использовать β-VAE и управляемый MLP для сохранения контекста при передаче управления.

Делиться

Юмористический, но реалистичный обзор ILCP для агентов — β-VAE компрессор, транспорт в стиле Xn, гейтированный МЛП-проектор и до смешного простого осознания того, что я уже решил эту же самую минимальную проблему для хэндоверов 6G. V1 на стороне агента — это проводка; квитанции в этом посте — это квитанции из статей о 6G , должном образом помеченные, потому что честный подход к изложению — это главная цель этой серии.

Это четвертая часть — заключительная — серии статей «Производственный уровень агентского результата».каждая часть использовала один вид резервной работы на конвейере агента LLM. В первой части была устранена избыточная предварительная обработка (не следует читать один и тот же документ дважды). Во второй части было устранено избыточное ожидание (не следует ставить в очередь пять агентов по одному). В конце концов были устранены избыточные обращения к ЦП (не следует перенаправлять каждое извлечение данных на графический процессор). В четвертой части (эта статья и последняя) используются резервные перестроения контекста — аналог того, как агент изменения скрытого состояния каждый раз, когда речь идет о новом специалисте. в следующем:В многоступенчатой ​​системе передачи данных от агента A к агенту B каждый раз, когда управление переходит от агента A к агенту B, получатель выдает скрытое состояние агента A и поддерживает контекст из строк подсказок. По своей схеме это тот самый «холодный старт после передачи управления», который создает пользовательское оборудование (UE) при перемещении между двумя базовыми станциями (от источника к целям), когда целевая базовая станция заново придумывает состояние повторного использования для каждого пользователя.

Решение:сжать повторяющееся состояние отправителя в крошечный скрытый полезный груз, передать его на этапе передачи и позволить получателю повторно использовать его в качестве префикса для мягкой подсказки вместо увеличения всего текста. Тот самый принцип «вычислить один раз, распределить общее состояние», который последовательно повторяется с каждой частью, теперь применяется на разных этапах обработки, а не в рамках одного конвейера.В венском тесте 4G/5G метод ILCP полностью обеспечивает переключение между сетями (0,0% против 6,5% в базовом режиме без переключения, 22,6% в базовом режиме с Transformer), восстанавливается на основе определения на +5,1 pp в среднем/+13,3 pp в пике и работает от начала до конца со скоростью 7,7 мс p99 на каждом решении по переключению на той же видеокарте GTX 1080, что и в остальных тестах этой серии. по радиосети 6G, а не к данным агентов LLM. Версия V1 на стороне агента в этом посте ( ilcp-for-agents ) — это проводка: компрессор β-VAE, транспортный модуль, проектор MLP с гейтированием и жгут проводов Qwen2.5-7B, а ее показатели на стороне агента — это будущая явная идея. Я отказываюсь выдавать данные RAN для данных LLM, даже если соблазн велик. Серия завершает цикл.

Вкратце:В настоящее время агенты многошагового LLM передают контекст в виде строк. Агент A завершает рассуждения, суммирует их в текст-подсказку, агент B считывает этот символ с нуля — кэш-ключ-значение приемника, внимание шаблона и любые частичные вычисления, выполненные агентом A, выбрасываются. В этой версии агента проблемы «холодного старта» после переключения, из-за которого возникают базовые станции 5G/6G, когда UE (мобильное устройство) перемещается между двумя базовыми станциями: целевая базовая станция повторно создает рекуррентное состояние для каждого UE и должна восстановить его с нуля. Мы решили эту проблему с помощью метода, называемого индуктивным сохранением латентного контекста (ILCP): β-VAE сжимает 128-мерное состояние GRU в 128-байтовую латентную полезную нагрузку, передавая ее по стандартному интерфейсу 3GPP Xn, а затем управляемый MLP проецирует ее в пространство для включения станции при переключении. При тестировании сети 4G/5G в протоколе ILCP переключения между сетями по принципу «пинг-понг» (0,0% против 6,5% в базовом варианте без переключения), формируется точность определения текущей цепи после переключения на +5,1 пп в среднем/+13,3 пп в пике в окне 50–250 мс после переключения и работает со скоростью 7,7 мс p99 на одном решении на одной видеокарте GTX 1080. Эта часть переносит тот же самый протокол переключения агентов LLM: ilcp-for-agentsучится сжимать объединенное скрытое резюме, передает его через переключатель точки и проецирует обратно в префикс программного запроса на стороне приемника. V1 — это схема подключения (PyTorch, Qwen2.5-7B-Instruct, β-VAE, управляемый MLP, внутрипроцессная передача, упрощенная метрика точного совпадения). Вклад здесь заключается в воздушной переноске, а не в цифрах.

(Небольшие колебания, прежде чем мы начнем: я подошел к этой серии статей с инженерной точкой, связанной с сетями RAN 5G/6G. Аспекты телесвязи в частях 1, 2 и 3 были аналогиями. Эта часть перестает быть аналогией. Механизм, который я применяю агентам LLM, — это тот самый механизм, написанный теми же соавторами, который закрывает холодный старт после хэндовера в сетях радиодоступа 6G. Это кульминация серии. Есть целый раздел, посвященный упоминанию — раздел 7 — но именно поэтому эта статья существует в таком виде.)

Архитектурная модель — держите ее открытой во время чтения.

Агент A Контекст → маскированный средний пул → β-VAE-кодер → z (32-dim скрытый) → внутрипроцессная TransportPayload → β-VAE-декодер + шлюзованный MLP → K токенов памяти → torch.cat в встраивание вопроса агента B → жадный decode

Всё, что приведено ниже, — это лишь комментарий к одному фрагменту этой строки.

1. Признание: я решил эту проблему еще до того, как узнал о ней.

В третьей части мы перешли к нескольким абсурдным мерам, чтобы наши тензоры оставались именно там, где они и находятся: на кремниевом кристалле. Написав собственные источники CUDA для поиска Top-K, мы устранили остаточные обращения к ЦП, которые тормозят работу агентного алгоритма RAG. Философия была абсолютной — как только графический процессор вычисляет богатое многомерное состояние, вы его не перемещаете и уж точно не уничтожаете. И все же, как только этот высокооптимизированный метод поиска завершает свою работу и дает эстафету следующему специалисту в вашем конвейере, стандартные рамки для того, чтобы вы делали именно это. Мы обеспечиваем состояние наших тензоров ценой своей жизни внутри одного узла, чтобы добровольно выбросить его в мусор, просто перейдя через этап логического вывода.

Вы : «Агент А, прочтите этот 50-страничный отчет, составьте краткое изложение и передайте его агенту Б для проверки фактов».

Агент А: «Конечно. Загрузка модели. Чтение отчета. Объединение контекста. Привлечение внимания к 47-му абзацу. Формирование собственного мнения. ✅»

Графический процессор работает 30 секунд.

Агент А : «Готово. Вот краткое изложение на 200 токенов, которыми я очень горжусь».

Вы : «Отлично. Пересылаю агенту Б.»

Агент А : «Подождите, а как именно вы перенаправляете?»

Вы : «…в виде строк? В задании?»

Агент А: «Хорошо. Значит, вы отправляете Агенту Б мою цепочку. Не мое скрытое состояние. Не мое внимательное внимание к прочитанным 50 страницам. Не тот факт, что 47-й абзац оказался необычайно объёмным. Не ту выверенную уверенность, которую я накопил. Просто цепочку».

Вы : «Да, так это и работает».

Агент А : «Круто. Круто, круто, круто. Веселись, Б. 👋»

Агент Б : «Здравствуйте, я прекрасный новорожденный без состояния. Загрузка модели. Чтение строк Агента А с нуля. Создание контекста. Объединение данных. Формирование мнений. ✅»

Графический процессор тратит еще 30 секунд на выполнение, по сути, ту же самую работу, которую только что закончил агент А.

Вы : «…есть ли способ пропустить второй этап формирование контекста и расчет внимания?»

Агент Б: «Какое второе прочтение?»

Вот так, под крышкой, выглядит каждый «многоагентный рой», которого я когда-либо видел. Каждая передача данных представляет собой узкое отверстие, которое видно через эти данные, и состояние отправителя не может протиснуться. Получатель получает выходной текст и восстанавливает контекст из текста — это самая затратная операция, которая обычно выполняет преобразователь, и именно от этой операции мы трижды пытались отучить вас в рамках одного цикла обработки данных.

Забавно, но я уже писал об этой проблеме раньше, только не в отношении агентов LLM.

В 2026 году мы с соавтором опубликовали статью под названием «Индуктивное сохранение латентного контекста: преодоление холодного старта после переключения в сети радиодоступа 6G». В ней используется мобильный телефон (также называемый пользовательским оборудованием или UE), перемещающийся между базовыми станциями 5G/6G (также называемыми gNB). При каждом переключении целевой gNB выбрасывается рекуррентное состояние для каждого UE, хранящееся в исходной gNB, и повторно элемент создает скрытое состояние для каждого UE в закрытом gNB. Затем модель прогнозирования на внешней стороне должна восстановить это состояние на основе нескольких радиоизмерений, передаваемых после переключения, пока UE уже находится в движении. В статье это называется холодным стартом после переключения. Вам это ничего не напоминает?

Теперь прочтите этот абзац из раздела, посвященного авторам статьи, с упрощенной терминологией: «Мы рассматриваем рекуррентное состояние каждого пользователя как переносимый сетевой контекст. Чтобы решить практическую проблему, связанную с небольшим размером стандартного межсотового сообщения, мы показываем, что 128-байтового дифференциального обновления достаточно для сохранения качества прогнозирования 128-мерного состояния ГРУ на границе хэндовера. Предложенный нами протокол ILCP сжимает скрытое состояние с помощью β-вариационного автокодировщика, передавая его по стандартному интерфейсу 3GPP Xn и проецирует его в пространстве станции станции gNB в момент хэндовера с помощью обученного, управляемого многослойного перцептрона (MLP)».

Если заменить «исходный gNB» на «агент A», «целевую gNB» на «агент B», а «радиоизмерения» на «токены этой подзадачи», то получится архитектура, о которой идет речь в этом посте. Та же статья, тот же автор, просто область применения другой.

Вклад этой статьи лежит не в самом методе — методе, уже описанном в статье. Вклад этой статьи состоит из в парламентах: взятия ILCP и его настройки для многошаговых агентов LLM, с начала до конца, в небольшом репозитории PyTorch, который вы уже видели. Квитанции, которые вы показываете в разделе 5, — это квитанции из статей, в блоках передачи данных 6G, правильно помеченные.

2. Зачем вообще нужен «холодный старт» агента? (краткий курс за одну минуту)

Если вы уже настроили многоступенчатый агентный конвейер, пропустите этот раздел. Для всех остальных — краткая версия.

Многошаговый агент — это не одна модель, отвечающая на один вопрос. Это несколько специализированных моделей, поочередно выполняющих одну и ту же задачу. Маршрутизатор определяет намерение, планировщик декомпозирует задачу, механизм извлечения получает контекст, логический анализатор выполняет собственно мыслительную работу, механизм проверки безопасности анализирует выходные данные, финализатор записывает ответ. Каждый из них представляет собой отдельный прямой проход, часто это отдельная модель, иногда отдельный процесс.

Между любыми двумя из этих прямых проходов управление прекращается. И вот тот грязный секрет, который большинство агентских фреймворков скрывается за удобными диаграммами: при каждом переходе от маршрутизатора к получателю выводится текст. Не скрытое состояние, не кэшировать ключ-значение, даже не вектор — а именно текст. Классификация намерений превращается в строковый токен. План задачи планировщика преобразуется в JSON-объект. Выбранные фрагменты извлеченного устройства преобразуются в объединенное контекстное окно. Цепочка мыслительного логического элемента превращается в блок «мысль:». Каждый переход от маршрутизатора к получателю — это круговой путь токенизатора.

Это звучит неплохо, пока не посчитаешь. Стандартный технологический процесс обработки данных сложными переходами по длинному общему контексту будет токенизировать и повторно загружать один и тот же исходный материал четыре раза. Три из этих операций чтения ничего не принесли. Маршрутизатор уже знал, планировщик уже знал, логическая система уже знала. Четвертая операция чтения оценивается для проверки безопасности, и проверка безопасности повторяется еще раз для финализатора.

Если это звучит как проблема SwarmKV из части 1, то она и есть — только повернутая на 90 градусов. В первой части речи шла о N агентах, читающих ~60>один и тот же документ в рамках ~60>одногосильного> запуска конвейера. В этой части речи идет о агентах, читающих <сильных>накопленный контекст друг другасильных> на <сильных>разныхсильных> этапах обработки информации. Другая структура, та же основная сложность: получатель отбрасывает сложное вычисленное состояние и поддерживает его с нуля из строк подсказок. Это холодный старт после передачи, облеченный в оболочку Python.

3. Идея «просто передайте скрытую информацию через точку передачи» (и почему это сложнее, чем кажется)

Суть предложение просто:

1. Пока Агент А жив, преобразуйте его рабочий контекст в единый вектор консолидированного фиксированного размера sAs_AsA​.
2. Сжимайте sAs_AsA с β-VAE в крошечный скрытый zzz, скажем, из 32 чисел с плавающей запятой. Это 128 байт по 32-битной памяти.
3. Пересечение границы вручную — площадь, которая пересекает траекторию прыжка.
4. В агенте B декодируйте zzz и спроецируйте его через многослойный перцептрон с клапанами в памяти K векторов в собственном пространстве вложений агента B.
5. добавьте эти K векторов перед векторными представлениями токенов и разрешите B корректировать жадное декодирование. B никогда не будет повторно считывать контекст A как текст.

Это принцип «вычисли один раз, передай расширенное состояние» — тот же принцип, что и в частях 1–3, но применяемый в разных аспектах, а не в рамках одной конвейера. Единственная причина, по которой для этого требуется больше 30-строчного скрипта PyTorch, заключается в том, что три скучные проблемы сразу же ломают наивный подход.Наиболее очевидный ответ — «весь кэш-ключ-значение». Агент А его создал; просто передайте ему Агенту Б. Однако факт в том, что кэш-значение ключа — это объект, определения из контекста, модели, токенизатора, квантования, конфигурации RoPE, реализация механизма внимания, количество слоев, количество заголовков, соотношение GQA, n_ctx и точного хеша GGUF/safetensors. Передайте кэш-ключ-значение от процесса, работающего с моделью X, процесса, работающего с моделью Y, и вы получите бинарный блок, который получатель не сможет интерпретировать. Пункт в дорожной карте SwarmKV V1, касающийся ограничения, связь с кэшем ключ-значение на диске, существует именно для того, чтобы выполнить эти инварианты явными; до тех пор, пока любая идея «совместного использования ключа-значения между кэшами» должна согласовывать словарь из семи совпадающих полей, прежде чем байты начнут что-либо значить.

В ILCP V1 намеренно сделан скучный выбор: не используется значение кэш-ключа, используется краткое изложение того, что было реализовано в виде кэш-значения ключа. Единый объединенный вектор скрытого состояния неустойчив к моделям версий, но не катастрофически — это лишь незначительно (hidden_size,) числа с плавающей запятой, и если агент A и агент B используют одну и ту же базовую модель, то значение этих чисел с плавающей запятой однозначно. Из src/agents/qwen_encoder.py :

 @staticmethod def Masked_mean_pool(last_hidden: torch.Tensor, focus_mask: факел.Тензор) ->torch.Tensor: """ Утвержденный пул V1: средние векторы токенов последнего слоя с заполнением, замаскированным до нулевой массы. Деление на необработанное количество токенов (без нормализации L2) сохраняет сигналы величины относительно уверенности и насыщенности, которые пул единичных норм будет стирать до узкого места VAE. """ iflast_hidden.dim() != 3: поднять ValueError("last_hidden должен быть (batch, seq, dim)."), если внимание_mask.dim() != 2: поднять ValueError("attention_mask должно быть (batch, seq).") маска = внимание_маска.unsqueeze(-1).to(dtype=last_hidden.dtype, устройство=last_hidden.device) summed = (last_hidden * маска).sum(dim=1) lengths = Mask.sum(dim=1).clamp(min=1.0) возвращает сумму/длиныкод>

Мы предпочитаем замаскированное среднее значение скрытым состоянием последнего слоя. Комментарий четко описывает выбранный нами подход: мы не проводим L2-нормализацию на выходе, потому что величина несет полезный сигнал о достоверности и насыщенности, который учитывается с использованием единой нормы стер бы. Узкое место β-VAE, расположенное ниже по потоку, определяет, что сохранить, а что отбросить, а не слой пулинга.

Задача Б: Насколько малым может быть полезный груз, чтобы он был конкурентоспособен для использования?

Единый скрытый вектор из 7B-моделей имеет размер <код>(4096,)код>числа с плавающей запятой — шестнадцать килобайт. Это подходит для демонстрационных примеров в процессе работы, но как только передача становится реальным сетевым сообщением, шестнадцать килобайт на каждой передаче уже не бесплатны. Весь аргумент в части радиосвязи сводится к тому, что 128-байтового дифференциального обновления достаточно для сохранения предсказательного качества 128-мерного состояния GRU, поскольку состояние GRU существует на низкоразмерном многообразии, соответствующем задаче, и β-VAE может найти это многообразие во время совместного обучения с ограничением потерь. Агент использует аналогичный архитектурный вариант. Из src/compressor/beta_vae.py :

 class BetaVAE(nn.Module): """ Полностью связный β-VAE, работающий с объединенными в пул скрытыми состояниями LM. Почему полностью связный вместо сверток: входные данные уже представляют собой один вектор на выборку (замаскированный средний пул с течением времени), поэтому конв-слои будут добавлять накладные расходы на параметры без использования пространственной локальности, как ядро CUDA на сетках. """ def __init__( self, input_dim: int, latent_dim: int, скрытый_dim: int, beta: float = 1.0, ) -> Нет:

Два кодировщика возвращают μ и logvar по отдельности, поскольку их объединение ограничило бы кривизну; прием репараметризации сохраняет дифференцируемость выборки; Дивергенция Кульбака-Лейблера в замкнутой форме является стандартным аналитическим ожиданием при диагональном гауссовском кодировщике. Ничто из этого не является новой работой со стороны VAE, Хиггинса и др. (2017) и Кипф и Веллинг (2016) проделали основную работу десять лет назад, и комментарии в коде ясно указывают на то, что ничто из этого не претендует на это. Вклад заключается в том, что вы прикрепляете VAE, а не в сущности VAE.

В этом же файле есть небольшой вспомогательный файл, созданный исключительно для честного освещения событий:

 def latent_payload_bytes(latent_dim: int, dtype: torch.dtype) -> int: """ Отчет передается размер полезной нагрузки в байтах для квитанций README (не предполагается, что 128-байтовая телекоммуникационная нагрузка соответствует выравниванию элемента torch.dtype; это аналог внутрипроцессной передачи """ # torch.finfo/element_size дает ширину в байтах для плавающих типов dtype, используемых в z-тензорах. если нет, dtype.is_floating_point: поднять ValueError("latent_payload_bytes ожидает плавающий тип dtype для z.") width = torch.tensor([], dtype=dtype).element_size() return int(latent_dim) * int(width)

В документации указано: «Не хватает 128-байтового сетевого полезного груза». Код на стороне агента отказывается предполагать 128-байтовое число, указанное в документе о 6G — он высчитывает груз на стороне агента на основании фактического скрытого dim и dtype при выполнении, поэтому в файле README для агента будет указана правдивая информация. Этот единственный вспомогательный код — это всякая политика «не выдавать номера RAN за номера LLM», состоящая всего из семи строк.Здесь радиотеория и использование LLM немного расходуются, поскольку приемник в этих двух предметах имеет разную форму объекта. В радиотеории приемником является целевая базовая станция, работающая на собственном ГРУ + гетерогенном графовом преобразователе, блок проекции возвращает декодированное скрытое состояние обратно в рекуррентное пространство цели. В агентной версии V1 приемником является замороженный декодер Qwen2.5-7B-Instruct, и блок проекций должен поместить декодированное скрытое состояние в сущность, на которую декодер сможет обратить внимание. Поэтому проектор преобразует скрытое значение в K векторов памяти, которые перемещаются в том же самом векторном пространстве, что и реально встраивания токенов, и является получателем выбора их перед ситуацией. Из src/projector/gated_mlp.py :

 class GatedLatentToMemoryProjector(nn.Module): """ Отображает z € R^{latent_dim} в память € R^{K × model_hidden}. Ворота используют нелинейность SiLU (гладкий ReLU), поэтому градиенты не умирают при отрицательных предварительных активациях, как это было бы с простым сигмовидным вентилем, насыщающимся при инициализации. """

Основная часть представляет собой небольшой многослойный перцептрон (MLP); от него отходят головка вентиляции и головка значения; вентиль обрабатывается сигмоидально, значение остается необработанным, а поэлементное произведение Сохраняет ложные скрытые направления перед окончательным преобразованием в (batch, K, model_hidden). Два пути, одно произведение, одно преобразование. Замечание об использовании вентиля в fp32, даже когда LM работает в bf16, является примечанием эпохи Паскаля: GTX 1080, используемая в качестве канонического эталона для этой серии, не имеет полноскоростного АЛУ bf16, поэтому вентиляция в fp32 — это просто вежливое обращение с оборудованием.

Точное объединение происходит внутри агента. Из файла src/agents/harness.py :

 prefix = torch.cat([memory_tokens.unsqueeze(0), q_embeds], dim=1)

Вот и весь процесс. В начале текущего года в США память токенов; за ними последующего встраивания токенов вопросов. Приёмник декодирует данные из этого префикса, используя inputs_embeds вместо input_idsостальная часть цикла генерирует стандартное жадное декодирование, которое повторно использует кэш-значение ключа так же, как и любой производственный декодер после первого широкого прямого прохода. В разделе 4 описан вариант, как все части соединяются вместе. Представьте это как горизонтальную трубу.

 Шаг 0. Создание компрессора + проектора + транспорта при инициализации механизма (load_ilcp_modules). Шаг 1. Кодирование контекста агента A в объединенную сводку s_A (QwenContextEncoder.pooled_embedding_for_text). Шаг 2. Сжатие s_A до скрытого z с помощью средства кодирования β-VAE μ (BetaVAE.encode). Шаг 3. Упаковка z в a TransportPayload (байты, проиндексированные процессором) (InProcessTransport.pack) Шаг 4. Распакуйте на приемнике и спроецируйте z на K токенов памяти (InProcessTransport.unpack + GatedLatentToMemoryProjector). Шаг 5. Объедините память перед встраиванием вопросов и жадным декодированием. (greedy_generate_from_memory_prefix)

Давайте рассмотрим каждое из них на примере реального кода. Фрагменты кода намеренно сокращаются; полные файлы очень маленькие и привлекают внимание.

Шаг 1 — Контекст агента пула А

Это скучный шаг, который делает, возможно, остальную часть конвейера. Агент A считывает свой рабочий контекст с помощью той же инструкции Qwen2.5-7B-Instruct, которая будет выполняться Агентом B, но вместо декодирования токенов мы просим модель рассчитываем нам скрытый сигнал конечного слоя и объединяем их в один вектор. Из src/agents/qwen_encoder.py :

 @torch.inference_mode() def encode_contexts( self, texts: list[str], max_length: int = 512, ) ->tuple[torch.Tensor, torch.Tensor]: """ Возвращает встраивания в пуле (пакетные, скрытые) и маски внимания, используемые для аудита фигур. torch.inference_mode() полностью отключает учет счетчиков версий по сравнению с no_grad, что немного снижает накладные расходы при очистке тысяч контекстов для построения набора данных компрессора на бюджетном графическом процессоре. """ пакет = self.tokenizer( texts, padding=True, truncation=True, max_length=max_length, return_tensors="pt", ) пакет = {k: v.to(self.device) для k, v в пакете.items()} выходы = self.lm(**batch, output_hidden_states=True, use_cache=False) last_hidden = outputs.hidden_states[-1]pooled = self.masked_mean_pool(last_hidden, пакет["attention_mask"]) returnpooled, пакет["attention_mask"]

один прямой проход с output_hidden_states=True , скрытое состояние последнего слоя, замаскированное среднее значение из раздела 3, на выходе. зор пулинга имеет (batch, Hidden_size) , который для Qwen2.5-7B составляет (1, 4096)на выборку. Этот вектор s_A, о котором говорится в разделе 4 статьи — за исключением случая, когда телефон перемещается между базовыми станциями сотовой связи, тот же вектор строится 128-мерным ГРУ на основе радиоизмерений. Разные датчики, одна и та же роль.

Шаг 2 — Сжатие до скрытой Z-области

Из файла src/agents/harness.py :

 @torch.inference_mode() def ilcp_memory_from_context(self, context: str, device: torch.device) ->torch.Tensor: """ Конвейер Compress→transport→project возвращает тензор памяти приемника (K, D) на `device`. Использование кодировщика VAE означает μ (а не стохастический образец) стабилизирует задержку нескольких испытаний и сравнения качества так, как развернутая система замораживает стохастичность после калибровки. """ s_a = self.encode_sender_summary(context).to(device) mu, _logvar = self.vae.encode(s_a.unsqueeze(0)) z = mu.squeeze(0) payload = self.transport.pack(z) z_b = self.transport.unpack(payload, device=device) mem = self.projector(z_b.unsqueeze(0)).squeeze(0) return mem

Это весь процесс сжатия → транспортировка → проектирование. В данном документе явно указан критический, хотя и неочевидный, производственный выбор: мы используем среднее значение энкодера на этапе достижения, а не стохастически перепараметризованную выборку. В статье о радиотехнике происходит то же самое при развертывании; стохастичность полезна только во время обучения. Замораживание после изменения — это то, что делает наша поставляемая система с узким отображением VAE, и об этом говорится в комментариях.

Внутри β-VAE encode возвращает среднее значение и логарифм дисперсии; мы разбрасываем логарифм дисперсии, поскольку здесь мы не проводим выборку. Из src/compressor/beta_vae.py :

 def encode(self, x: torch.Tensor) -> tuple[torch.Tensor, torch.Tensor]: """ Сопоставьте пакет суммарных вложений с диагональными гауссовскими параметрами. Возврат logvar вместо std позволяет избежать sqrt во время обучения и улучшает числовую стабильность, когда отклонения становятся крошечными (избегает раздутия деления в закрытой форме KL). """ # Сглаживаем необязательные средние измерения, чтобы кодировщик всегда видел (batch, input_dim). h = self._encoder_body(x) mu = self._enc_mu(h) logvar = self._enc_logvar(h) return mu, logvar

Стандартный кодировщик β-VAE. Два отдельных модуля для μ и logvar существуют потому, что их объединение ограничено кривизной скрытой геометрией, что в комментариях изложено одним предложением, чтобы следующему читателю не приходилось думать. Процесс намеренно четко определен. Хотя в версии 1 агенты A и B используют один и тот же процесс Python, передача данных осуществляется с помощью этапов сериализации/десериализации, чтобы в последующих версиях можно было повторно использовать реальную сеть — gRPC, кольцевые буферы с общей памятью, передачу данных по протоколу — без перезаписи узлов вызова. Из src/transport/in_process.py :

 @dataclass(frozen=True) class TransportPayload: """ Неизменяемый контейнер для скрытого тензора плюс минимальные метаданные для журналов аудита. Замораживание класса данных предотвращает случайную мутацию на месте, которая может привести к десинхронизации квитанций размером в байт между отправляющим и получающим агентом в многопоточных связях. """latent: torch.Tensor dtype_name: strlatent_dim: int def byte_length(self) -> int: """ Вычисление точной сериализованной длины в байтах для таблиц README (torch.save использует Pickle; мы используем необработанные байты). Необработанные смежные байты более честно отражают историю "полезной нагрузки над Xn", чем травление полных тензоров. """ return int(self.latent.numel() * self.latent.element_size())

byte_length()— это аналог функции «128 байт полезной нагрузки по Xn», описанной в статье о радиосвязи на стороне агента. Она вычисляет фактическое количество байтов комиссии на основе фактического тензора, без каких-либо предположений, указанных в характеристиках. В статье о радиосвязи говорится о 128 байтах, поскольку запрос на передачу данных по Xn в стандарте 3GPP имеет строгий лимит размера необязательных элементов интерфейса. На стороне агента такого рода пока ограничений нет, но он настроен на измерение любого размера, который он получит, поэтому, когда он получит реальную сетевую транспортировку, подтверждение будет корректным. class="language-python">def package(self, z: torch.Tensor) ->TransportPayload: """ Отсоединиться от autograd, перейти на промежуточное устройство и записать dtype для обеспечения точности передачи данных. Отсоединение намеренно разрывает график: транспорт — это граница передачи, на которой прекращаются градиенты отправителя. """ z_staged = z.detach().to(self.device).contigious() return TransportPayload(latent=z_staged, dtype_name=str(z_staged.dtype), latent_dim=int(z_staged.shape[-1]), )

detach()намеренно препятствовать графу автоградации. Граница передачи — это логическая граница, а не просто перемещение памяти. Градиенты отправителя останавливаются на этой линии; получатель, если захочет, построит свой собственный граф из распакованного скрытого значения. В о радиосвязях, установленных на одной и той же границе интерфейса Xn, по той же причине — базовые станции, источник и цели порождают разные процессы на разных машинах, а кросс-процесс графической автоградации — плохая идея независимо от отрасли. class=»wp-block-prismatic-blocks»> def unpack(self, payload: TransportPayload, device: torch.device | str) -> torch.Tensor: """ Материализуйте z на принимающем устройстве до того, как проектор поднимет его во встраивания в память. clone() предотвращает наложение псевдонимов, если один и тот же объект полезной нагрузки случайно повторно использовался в двух агенты """ return payload.latent.clone().to(device, non_blocking=True)

Приемник материализует объект z на своем собственном устройстве, выполняет функцию clone().Для защиты, чтобы два приемника, один считывающий, и тот же объект полезной нагрузки, не могли положить друг друга на помехи, а затем передать его управляемому MLP. Переадресация управляемого MLP, из src/projector/gated_mlp.py :

 def front(self, z: torch.Tensor) ->torch.Tensor: """ Форма возврата (batch, K, D), подходящая для torch.cat вдоль измерения последовательности с встраиванием токенов. Применение вентиля в float32, даже когда LM работает в bf16, может уменьшить числовой шум на потребительских графических процессорах, в которых отсутствуют полноскоростные ALU bf16 (примечание по аппаратному обеспечению эпохи Паскаля для базовых показателей GTX 1080). """ # Убедитесь, что z имеет ранг 2, чтобы пути пакетного matmul оставались векторизованными. широкие тензорные ядра, если они доступны. if z.dim() != 2: поднять ValueError("GatedLatentToMemoryProjector ожидает z-образную форму (batch, latent_dim).") h = self._trunk(z) Gate = torch.sigmoid(self._gate_head(h)) value = self._value_head(h) # Поэлементное произведение подавляет ложные направления перед преобразованием в токены памяти. mem_ Flat = Gate * value return mem_flat.view(z.size(0), self.num_memory_tokens, self.model_hidden)

Trunk → определение заголовка вентиля и значений заголовка → поэлементное произведение → преобразование в (batch, K, Г)код> . Выход D — это размер скрытого слоя языковой модели, поэтому каждый из K токенов уже находится в пространстве встраивания модели и может быть объединен с реальными векторными представлениями токенов без отдельного слоя объединения пространства.

Шаг 5 — укажите конкатенацию перед определением и выполните жадное декодирование.

Теперь оператор действительно отвечает. Из <кода>src/agents/harness.py :

 @torch.inference_mode() def gredy_generate_from_memory_prefix( lm: nn.Module, tokenizer, embed_layer: nn.Module, Memory_tokens: torch.Tensor, вопрос_подсказка: str, max_new_tokens: int, устройство: torch.device, ) ->str: """ Жадное декодирование, начиная с объединенных мягких подсказок + встраивания токенов вопроса. Цикл чередуется между широким префиксом вперед (первый шаг) и тонкими шагами с одним токеном, которые повторно используют записи кэша KV так, как это делает рабочий декодер после прибытия кадра передачи управления. """ q_batch = tokenizer(question_prompt, return_tensors="pt", truncation=True, max_length=512) q_ids = q_batch["input_ids"].to(device) q_embeds = embed_layer(q_ids) prefix = torch.cat([memory_tokens.unsqueeze(0), q_embeds], dim=1) alert_mask = torch.ones(prefix.shape[:2], device=device, dtype=torch.long) Past = Нет embed_step = создан префикс: list[int] = [] для _ в диапазоне (max_new_tokens): out = lm( inputs_embeds=embed_step, focus_mask=attention_mask, Past_key_values=past, use_cache=True, return_dict=True, ) Past = out.past_key_values logits = out.logits[:, -1, :] next_id = int(logits.argmax(dim=-1).item()) сгенерирован.append(next_id) next_emb = embed_layer(torch.tensor([[next_id]], device=device, dtype=torch.long)) embed_step = next_emb add = torch.ones((1, 1), device=device, dtype=torch.long) alert_mask = torch.cat([attention_mask, add], dim=1) return tokenizer.decode(generated,skip_special_tokens=True)

Один широкий префикс, профессиональный вперед по [memory_tokens, questions_embeds] , а затем стандартное повторное жадное декодирование по одному токену для раз с сным использованием past_key_values . Получатель никогда не токенизирует исходный контекст Агента А. В этом нет необходимости. Информация, которая могла бы быть получена при чтении этого контекста, уже присутствующего в K токенах памяти, спроецированных непосредственно в пространстве встраивания получателя. input_ids и ответы из текста:

 def _format_agent_prompt(context: str, questions: str) ->str: """ Создайте строку холодного запуска, которая заставляет получателя LM перечитать весь контекст агента A. Сохранение стабильного стиля разделителя инструкций между ветвями изолирует эффект ILCP от дрейфа подсказок. """ return ("Вы - агент B. Внимательно прочитайте контекст, затем коротко ответьте на вопрос.nn" f"Context:n{context}nnQuestion: {question}nnAnswer:" )

Путь холодного чтения: прочитан весь отрывок, зарядите все предварительные задания, ответьте. Путь ILCP: получить латентный код, спроецировать его, декодировать по префиксу. Та же задача, два контракта, один из которых проходит второе чтение, а другой — нет. Это V1.

5. Квитанции (из телекоммуникационной газеты, а НЕ от агентов LLM)

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

6G» (Banerjee & Awan, Nokia, Мюнхен, принято публиковать на AI4NextG @ ICML 2026; препринт arXiv:2605.00593v2, июнь 2026 г.). В статье оценивается ILCP на <сильном>тестовом участке Венского драйв-теста 4G/5Gсильного>, представляющая собой многоячеечную, многоуровневую городскую радиотрассу с плотным перекрытием ячеек, 31 событие переключения в отложенном тестовом участке, измерение на каждом шаге с частотой 100 Гц, с 1000-бутстрапными 95% доверительными интервалами для каждого значения. В качестве аппаратного обеспечения выполнения инференции используется одна видеокарта NVIDIA GTX 1080 (8 ГБ), процессор Intel i7-8700K и 16 ГБ оперативной памяти — что, кстати, является тем самым самым эталонным графическим процессором, что и в других моделях этой серии.

Это метрики переключения сети 6G в узлах переключения сети 6G, полученный на основе трассировки переключения. Acc@t=0 означает «выбрала ли модель правильную конфигурационную ячейку в момент переключения?». HOF— это часть событий переключения, в которых предсказанная следующая ячейка неверна. Пинг-понг — это доля переключений, которые были отключены в течение короткого окна — с включением точек зрения в наиболее болезненном режиме, поскольку каждое выключенное переключение — это методическая впустая сигнализация плоскости управления в сети, которая и так имеет тысячу других задач. Базовая модель ZK-HGT (Zero-Knowledge HGT) — это в остальном идентичная повторяющаяся архитектура без ILCP — та же гетерогенная графовая основа, тот же ГРУ, тот же оценщик кандидатов — но с произвольной закономерностью рекуррентного состояния для каждого пользователя при каждом переключении. ZK-HGT — это чистое удаление, которое изолирует эффект сохранения состояния между переключениями; ILCP — это ZK-HGT плюс передаваемый латентный эффект.

Наиболее важным фактором с точки зрения точки зрения является ~60>показатель «пинг-понга» 0,0% для ILCP по сравнению с 6,5% для ZK-HGT и 22,6% для базового направления Transformer. В последующих плотных развертываниях с перекрытием будет малыми сотами именно «пинг-понг», который снижает качество обслуживания мобильной связи. В разделе 5.1 отмечено, что A3/A5 достигает 100% точности на чистоте трассировочного файла только потому, что метки хэндовера в трассировочном файле сами по себе были сгенерированы правилом, проводимым A3/A5, поэтому это сравнение является проверкой адекватности, а не реальным преимуществом. В статье подробно обсуждается, почему невозмущенный показатель A3/A5 следует рассматривать как проявление метода утечки, а не как число, за которое нужно гнаться.

6. «Хорошо, но чем это отличается от префиксного кэширования/RadixAttention/memory RAG?»

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

• Кеширование префиксов vLLM/кэширование сессий TGI.Отлично подходит, если ваш общий префикс ограничивает область действия запроса или сессии. Они кэшируют состояние ключа-значения внутри одной среды выполнения, поэтому последующий запрос из той же сессии не будет повторно заполнять тот же префикс. Они не определяют при передаче данных, когда Агент B представляет собой другую модель, другой процесс, другую машину или даже просто другой llama_context — значение ключа-объекта соответствует локальному контексту. ILCP-для-агентов в своей структуре явно является кросс-процессной переносимой, поскольку операционный объект является изученным резюме в переносимом латентном пространстве, а не ключ-значение объекта в частной памяти движка.
• SwarmKV (Часть 1 эта серии).Ближайший аналог в работах того же автора, но с одним существенным отличием: SwarmKV извлекает один и тот же кэш-ключ-значение по N ветвям, которые используют один и тот же документ в рамках одного запуска конвейера. ILCP-для-агентов работает в обратном направлении — он сохраняет состояние на разных этапах, где задача агента B отличается от задачи агента A. SwarmKV — это «вычисление один раз, распределение в рамках одного запуска». ILCP-for-agents — это «сжатие один раз, передача между этапами». Вместе они охватывают обе проблемы остаточных перевычислений.
• SGLang RadixAttention. Древовидное совместное использование префиксов внутри среды выполнения — прекрасно подходит для удовлетворения запросов с общими фиксами, опять же, в рамках префикса выполнения. Не предназначено для передачи переносимого, связанного с версией модели сводного отчета второго процесса, работающего с другим специализированным агентом.
• Память с расширенным извлечением (RAG).Хранить фрагменты текста в векторной базе данных и извлекать их во время запроса. Полезно, новички передачи — это текст, а это означает, что получателю всех равных пандемий токенизировать и предварительно заполнять данные. ILCP обучает изученный скрытый код, который получатель обрабатывает через inputs_embeds , полностью пропуская токенизатор и предварительное заполнение сохраненного контента на стороне текста.