SchemaFill готовит аргументы вызовов параллельно, но решение оставляет модели

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

Почему аргументы нельзя просто заполнять параллельно

Обычно LLM формирует вызов инструмента токен за токеном: выбирает функцию, пишет ключ первого аргумента, его значение, следующий ключ и так далее. Даже когда схема функции заранее задаёт структуру, модель не может перейти к позднему полю, пока не закончила предыдущие.

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

На BFCL после восьми полей хотя бы одно расхождение появлялось в 49,5% ответов. После третьего вызова доля таких ответов достигала 43,3%. Это не оценка того, выполнится ли функция успешно, а сравнение с исходным ответом модели: прямое параллельное заполнение меняет её решения.

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

Где SchemaFill убирает последовательное ожидание

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

1. Прогноз возможных полей. SchemaFill сопоставляет запрос с описаниями доступных инструментов через BM25 и выбирает вероятные функции. Их публичные схемы подсказывают, какие аргументы можно начать готовить, но не фиксируют будущий вызов.
2. Параллельные черновики. EAGLE-3 генерирует значения для нескольких возможных полей одновременно. Каждая ветвь видит общий запрос и собственный контекст, но не черновики соседних ветвей.
3. Сборка продолжения. Когда подтверждённый поток подходит к нужному месту, SchemaFill соединяет подготовленное значение с именами полей, знаками структуры и фрагментами следующих вызовов.
4. Проверка основной моделью. Модель за один проход оценивает собранную последовательность в реальном контексте. Совпавшие токены становятся частью ответа, а при первом расхождении модель добавляет исправление и отбрасывает остаток кандидата.

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

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

Когда результат меняет планы разработки

На Glaive SchemaFill увеличил пропускную способность в 3,73 раза, а на BFCL — в 4,05 раза относительно последовательной генерации. На BFCL он также оказался в 1,87 раза быстрее EAGLE-3. При жадном выборе токенов итоговые ответы совпадали с результатом обычной последовательной генерации.

Проверку проводили с Qwen2.5-7B-Instruct на Glaive и BFCL при нулевой температуре. В BFCL чаще встречались ответы с несколькими вызовами и большим числом аргументов, поэтому SchemaFill мог готовить не только поздние поля, но и следующие вызовы. В отдельном опыте выигрыш достигал пика на двух-трёх вызовах, а при четырёх начал снижаться: более широкое дерево кандидатов увеличивало работу проверяющей модели.

Работа меняет планы прежде всего у команд, которые управляют собственным контуром генерации. SchemaFill требует планировщика параллельных ветвей, специальных масок внимания, общего кэша состояний и изменённой процедуры проверки. Это не настройка системной инструкции и не замена схемы API.

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

Источники

• SchemaFill: Efficient LLM Tool Calling via Slot-Parallel Speculative Decoding