Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Повторную токенизацию истории LLM-сессии можно почти целиком убрать, не меняя последовательность токенов, которую получает модель. Delta Tokenizer сократил медианное время до первого токена в SGLang на 59% для контекста в 100 тысяч токенов, хотя работа не рецензирована и все числа получили сами авторы. Подход переносит повторное использование из вычислений модели во входной слой сервера.
Как повторно использовать токены без ошибки на границе
Агент на каждом шаге отправляет модели всю переписку, хотя обычно добавляет лишь результат инструмента или короткую команду. KV-кэш позволяет модели не обрабатывать общий префикс заново, но обычный токенизатор всё равно превращает в идентификаторы весь текст с первого символа. Чем лучше работает кэш модели, тем заметнее эта работа CPU во времени до первого токена.
Просто приписать новые идентификаторы к старым нельзя. Если первая версия запроса заканчивается на pipe, а следующая добавляет line, токенизатор может собрать pipeline иначе, чем две части по отдельности. На результат также влияют пробелы, группы цифр, специальные маркеры чата и нормализация Unicode.
Delta Tokenizer хранит текст и токены предыдущего шага. При продолжении сессии он повторно кодирует добавленный текст вместе с коротким хвостом истории, сравнивает новый результат со старым и соединяет последовательности только на границе, которую правила предварительного разбиения уже не могут сдвинуть.
Если подходящей границы в выбранном хвосте нет, окно расширяется. Последний запасной вариант — заново обработать добавление и весь текст после ранее подтверждённой границы. Поэтому объём работы обычно зависит от размера добавления, но точность не опирается на фиксированный нахлёст, который может оказаться слишком коротким.
Для нового или отредактированного запроса прежнего состояния нет. Такой текст Delta Tokenizer делит только в местах, где соседние фрагменты независимы по правилам токенизатора, кодирует части на разных ядрах CPU и соединяет результаты. Очередь общая: короткое обновление сессии может пройти между двумя частями длинного запроса, а не ждать завершения всей работы.
Где исчезает задержка
Инкрементальная обработка шага сессии работала примерно в 40 раз быстрее эталонного токенизатора Hugging Face. Ускорение дал прежде всего повторный доступ к прежним токенам: быстрый кодировщик без состояния не устранял зависимость времени от длины истории.
При полном кодировании запроса из четырёх миллионов символов параллельная обработка на CPU дала ускорение в 8,2 раза относительно последовательного варианта. Это относится к началу сессии, изменённой истории и другим запросам, для которых нечего повторно использовать.
Под нагрузкой 99-й процентиль времени до первого токена уменьшился в 23 раза, когда длинные запросы занимали входной слой, но не доходили до модели. Этот процентиль показывает задержку, быстрее которой завершились почти все запросы, и помогает увидеть редкие, но дорогие ожидания в очереди.
Совпадение проверяли не только на отдельных примерах: быстрый кодировщик дал те же идентификаторы, что и эталон, на 41,8 миллиарда полных документов. Это существенно для серверов с кэшем префиксов: даже читаемый после декодирования текст не компенсирует ошибочные идентификаторы, потому что модель получит другой ввод и не найдёт прежний кэш.
Когда стоит менять архитектуру входного слоя
Работа относится прежде всего к агентам с длинной растущей историей и небольшими добавлениями между вызовами. Если сервер уже повторно использует KV-кэш, токенизатор может стать отдельным узким местом: GPU почти не пересчитывает историю, а CPU продолжает проходить её целиком.
Для такого сервиса имеет смысл хранить состояние токенизации по сессиям, направлять продолжения к работнику с нужным состоянием и планировать полные запросы небольшими частями. Прототип подключался к SGLang через адаптер без изменения самого движка, поэтому идея не требует менять модель или формат её токенов.
Проверка охватывала шесть байтовых BPE-токенизаторов, три платформы CPU, веб-тексты, код, многоязычные документы и записи работы агентов. Интеграционные замеры провели с SGLang, Qwen3-8B и gpt-oss-120b. Это широкая проверка для одного прототипа, но выводы относятся к токенизаторам, у которых можно доказать безопасные границы разбиения.
На коротких контекстах выигрыш меньше, потому что полная токенизация и так занимает мало времени. Если каждый длинный документ новый и модель должна полностью обработать его на GPU, задержку определяет уже заполнение KV-кэша: в этом режиме варианты входного слоя укладывались в разницу около 5%.
Практический критерий для пересмотра планов — сочетание длинных повторяющихся префиксов, высокой доли попаданий в кэш и заметного времени CPU до запуска модели. В таком профиле более быстрый кодировщик решает только часть проблемы. Состояние сессии и безопасное планирование частей запроса меняют сам объём повторной работы.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
