# EAGLE в SGLang: как проверить draft checkpoint для конкретного target

Draft checkpoint для EAGLE в SGLang нужно сопоставлять с конкретной target моделью и выбранной реализацией метода.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/sglang-eagle-draft-contract/
Language: ru

Draft checkpoint для EAGLE в SGLang нужно сопоставлять с конкретной target моделью и выбранной реализацией метода. Произвольная маленькая LLM не заменяет обученный для этого механизма артефакт. Перед нагрузочным тестом проверьте происхождение draft, ревизии и параметры дерева кандидатов. Иначе успешная загрузка файлов может скрыть неверное сочетание, а неудачный запуск будет ошибочно объясняться общей нехваткой памяти или неисправностью speculative decoding.

## Чем отличается контракт EAGLE

В [документации SGLang](https://docs.sglang.io/docs/advanced_features/speculative_decoding) отдельно описаны EAGLE, EAGLE3 и STANDALONE. Это не взаимозаменяемые названия для любой дополнительной модели. Draft должен соответствовать ожидаемому target и способу передачи промежуточной информации. Сохраните model card или release описание, из которого следует такое соответствие. Не подставляйте артефакт только потому, что он имеет похожий размер или tokenizer: совпадение одного свойства не подтверждает всю структуру взаимодействия и поддерживаемый путь исполнения в установленном runtime.

## Зафиксируйте конфигурацию дерева

Число speculative шагов и ветвление определяют, какие кандидаты проверяет target. В [server arguments](https://docs.sglang.io/docs/advanced_features/server_arguments) следует сверить параметры и draft revision для текущей версии. Изменение дерева — самостоятельный эксперимент, а не невидимая часть обновления checkpoint. Сначала добейтесь корректного минимального запуска с зафиксированным сочетанием. Затем меняйте один параметр, сохраняя фактические настройки. Не считайте конфигурацию из чужого benchmark готовой рекомендацией для иной GPU, модели, batch composition и длины ответа.

## Пример карточки совместимости

Создайте карточку с полями target repository, target commit, draft repository, draft commit, method и tree settings. Добавьте источник заявления о совместимости и результат локальной проверки. Для отрицательного контроля можно проверить отказ конфигурации с неподходящим артефактом в изолированной среде, не отправляя рабочие запросы. Такой тест подтверждает понятную диагностику, а не право использовать случайную пару. Отдельно сохраните tokenizer files и то, должен ли draft использовать их из своего repository или из target согласно выбранной реализации.

## Разберите результат измерения

После функциональной приемки сравните обычную target с EAGLE на одинаковых prompts и правилах остановки. Запишите acceptance и полную задержку, а также память и конкурентные запросы. Большая доля принятых кандидатов полезна для понимания механизма, но не заменяет end-to-end результат. Если latency ухудшилась, исследуйте стоимость построения и проверки дерева. Если ответы отличаются по структуре, вернитесь к контракту модели и шаблона, а не продолжайте подбор параметров ради красивого коэффициента ускорения.

## Что сохранять при обновлении

Версионируйте карточку пары и fixtures вместе с движком. При изменении target не предполагайте, что прежний EAGLE draft остается допустимым; проверьте соответствующее официальное описание и повторите приемку. Укажите, какие режимы sampling и batch были реально исследованы, без расширения вывода на непроверенные случаи. Пакет должен позволять восстановить предыдущую совместимую пару целиком. Практическое решение может состоять в отключении speculation для части нагрузки, если ее стоимость не оправдывается. Это нормальный результат проверки, а не свидетельство поломки метода и не основание придумывать универсальную производительность по названию checkpoint или числу кандидатов.

## Связанные материалы

[SGLang или vLLM: как сравнить движки на одной модели](/ru/journal/sglang-vs-vllm-serving/); [Воспроизводимый стек инференса: как сохранить результат GPU-пилота](/ru/journal/software-stack-reproducibility/).