Измерение обработки больших фреймов pipe

Описание

Этот PR представляет собой этап измерения и проектирования для больших фреймов pipe в qwen serve ACP. Он не изменяет полезные нагрузки pipe, ограничения фреймов, поведение EventBus, поведение SDK, публичные поля протокола, флаги CLI, HTTP-параметры запросов или заявленные возможности.

Непосредственная цель — сбор атрибуции с низкой кардинальностью для негабаритных NDJSON-сообщений в pipe, чтобы следующий дизайн sidecar мог использовать реальные распределения pipe.message_bytes вместо предполагаемых пороговых значений.

Текущие ограничения

В настоящее время дочерний pipe ACP не имеет ограничения на количество байт в одном фрейме. Существующие метрики демона записывают pipe.message_bytes только с атрибутом direction, что намеренно обеспечивает низкую кардинальность, но не позволяет понять, какие семейства полезных нагрузок вызывают появление больших фреймов.

SSE-ридеры SDK уже имеют отдельное ограничение буфера в 16 МиБ для доставки в браузер/event-stream. Это ограничение не ограничивает размер фрейма в pipe от демона к дочернему процессу и не объясняет источники фреймов pipe.

Массовое воспроизведение сессии (bulk session replay) в настоящее время имеет ограничение на количество обновлений в 10 000. Оно не имеет ограничения по байтам, поэтому ограниченное количество больших обновлений все равно может создать большой фрейм ответа.

Структура измерений

Новый внутренний NDJSON-наблюдатель получает { direction, bytes, message } после успешного чтения сообщения из pipe или записи в него. Существующие байтовые хуки по-прежнему получают только bytes, сохраняя текущий путь метрик.

Демон записывает существующие счетчики pipe, суммы, максимумы, гистограммные метрики и поля статуса для каждого фрейма. Атрибуция больших фреймов выполняется только при bytes >= 256 * 1024.

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

Логируемые поля ограничены атрибуцией с низким уровнем чувствительности: direction, размер в байтах, порог, тип сообщения JSON-RPC, метод, класс источника, количество обновлений, суммарное количество обновлений и стратегия при достижении лимита, тип обновления сессии, маркер смешанного обновления сессии, имя инструмента, происхождение инструмента, тип сырого вывода, поверхностные максимумы текстовых байт для контента и сырого вывода, ограниченные приблизительные нетекстовые байты сырого вывода плюс маркер ограничения и счетчики подавления rate-limit. Полезные нагрузки, ID сессий, ID клиентов, пути к файлам, промпты и сырой вывод инструментов не логируются.

Гистограмма остается с низкой кардинальностью и сохраняет только direction; такие поля, как method, имя инструмента, обновление сессии и класс источника, не добавляются в качестве атрибутов метрик.

Классы источников

Наблюдатель использует только те классы источников, которые могут быть достоверно определены по форме фрейма:

• session_update_notification: уведомление session/update с params.update.
• load_session_bulk_replay_response: JSON-RPC ответ, содержащий _meta["qwen.session.loadReplay"].
• load_updates_response: JSON-RPC ответ, содержащий result.updates вместе с маркерами ответа загрузки обновлений.
• jsonrpc_request: любой другой JSON-RPC запрос или уведомление с методом.
• jsonrpc_response: любой другой JSON-RPC ответ.
• unknown: всё остальное.

Уровень pipe не может надежно отличить живые фреймы session/update от воспроизведенных, поэтому данное измерение не генерирует поле атрибуции live или replay.

Кандидаты в sidecar для следующего этапа

Вероятной целью для sidecar является большой вывод инструментов, переносимый в tool_call_update, особенно текст в content[] и rawOutput. Последующая реализация должна сохранять небольшое превью или заглушку в обновлении при передаче по сети, помещая полное тело в sidecar, управляемый демоном.

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

Массовое воспроизведение (bulk replay) и qwen/session/loadUpdates требуют отдельной обработки, так как ответ может быть большим из-за множества средних обновлений или нескольких больших обновлений. Поля измерений включают updateCount, summarizedUpdateCount, summarizedUpdateStrategy, maxContentTextBytes, maxRawOutputTextBytes, maxRawOutputApproxBytes и maxRawOutputApproxBytesCapped, чтобы разделять эти случаи без обхода неограниченных массивов обновлений или материализации больших нетекстовых сырых выводов. Когда массивы обновлений превышают бюджет суммаризации, максимальные поля вычисляются на основе детерминированной выборки префикса и суффикса, а не полного сканирования.

Не цели

Этот PR не реализует хранилище sidecar, передачу временных файлов, ограничения фреймов, ограничения байт для replay-ring, обрезку при уплотнении (compaction trimming), ограничения байт EventBus или ограничения байт буфера ACP HTTP binding.

Этот PR не добавляет параметры запроса ?maxFrameBytes или ?maxQueuedBytes, флаг CLI, опцию SDK или возможность (capability). Бюджет памяти и транспорта демона не должен увеличиваться произвольными клиентами.

Этот PR не изменяет публичные схемы событий. Любой будущий протокол sidecar должен быть аддитивным и проходить отдельное ревью.