# Внимание vllm-metal: граница повторного использования слоёв и состояния запросов

Почему в анонсе vllm-metal разделены повторно используемые операции токенов и внимание с границами запросов: ретроспектива архитектуры обслуживания.

Автор: Редакция Retrivium
Language: ru
Разбор опубликован: 2026-11-03
Дата события: 2026-09-22
Первоисточник новости: https://vllm.ai/blog/2026-09-22-vllm-metal-v0-28-0
Канонический URL: https://retrivium.ai/ru/retrospectives/retro-vllm-metal-attention-replacement/

Перенос движка инференса не обязательно требует выбора между полной переписью и полным повторным использованием. Архитектура vllm-metal предлагает более содержательную границу. Через историю систем обслуживания видно различие: операция может потреблять представление текущего токена либо дополнительно учитывать, какому запросу принадлежит история. Именно семантика операции, а не только название библиотеки, определяет требования к интеграции.

## Путь к событию

- 2023-09-12: [Efficient Memory Management for LLM Serving with PagedAttention](https://arxiv.org/abs/2309.06180).

- 2023-12-12: [SGLang: Efficient Execution of Structured Language Model Programs](https://arxiv.org/abs/2312.07104).

- 2026-09-22: [Announcing vllm-metal: Concurrent Serving on AppleSilicon](https://vllm.ai/blog/2026-09-22-vllm-metal-v0-28-0).

## Страничная память изменила требования к интерфейсу внимания

Ранняя работа PagedAttention отделила логическую историю запроса от непрерывного физического размещения. SGLang стал другим предшествующим примером выполнения с учётом состояния. Эти ссылки не устанавливают прямого происхождения конкретного ядра Metal из указанных реализаций. Их историческая значимость состоит в том, что системы обслуживания оптимизировали переменное состояние запросов ещё до анонса плагина. Наша интерпретация такова: новому вычислительному backend потребовалось сохранить эту семантику обслуживания, а не просто воспроизвести знакомый одиночный вызов модели через другую библиотеку ускорителя. Успешное вычисление тензоров должно сочетаться с правильной принадлежностью истории и состоянием каждого обслуживаемого запроса.

## Повторное использование зависит от контракта операции

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

## Правдоподобного ответа недостаточно для проверки интеграции

Рассмотрим условную смешанную группу несвязанных диалогов с разной длиной истории. Ответ может выглядеть естественно даже при нарушении границы контекста. Поэтому предлагаемый тест должен сравнивать контролируемые истории, изоляцию и продолжение диалога, а не только факт завершения генерации. Retrivium не сообщает о проведении такого теста. Пример объясняет, почему проверка backend требует больше одиночного вопроса. Самое трудное предположение может касаться принадлежности контекста, потребляемого операцией, а не заметной читателю беглости ответа. Для сервиса правильность такой принадлежности является частью результата вычисления, хотя непосредственно в тексте она обычно не показывается.

## История раскрывает разделение ответственности

Релиз можно прочитать как свидетельство более независимой организации обслуживания и выполнения тензорных операций. Это архитектурная интерпретация, а не обещание одинаковой поддержки функций на всех платформах. Планировщик способен сохранять общий жизненный цикл запроса, пока backend реализует необходимые для него операции. При сбое такое разделение помогает поставить точный вопрос: неверно ли описан жизненный цикл, неправильно ли переведено его представление или нарушен контракт выполнения? Ясные интерфейсы позволяют рассматривать эти варианты по отдельности, а не скрывать их за успешным запуском сервера, загрузкой весов и внешне убедительным первым ответом модели.

## Связанный технический контекст

Технические предпосылки подробнее разобраны в материалах [непрерывному объединению запросов](/ru/journal/continuous-batching/) и [воспроизводимости программного стека](/ru/journal/software-stack-reproducibility/).