Префилл и декодирование: почему у инференса LLM две фазы
Автоматический перевод
Эта статья была автоматически переведена с оригинальной английской версии.
Префилл обрабатывает промпт и создаёт его кэш аттеншна. Декодирование использует этот кэш для генерации последующих токенов. Длинный префилл или префилл в батчах может эффективно выполнять крупные матричные операции; декодирование с небольшими батчами часто тратит больше времени на чтение весов и закэшированных ключей и значений.
Это различие помогает инженерам отдельно диагностировать задержку первого токена и медленную генерацию после него.
Определите, какая фаза работает медленно
Обычный авторегрессионный префилл выдаёт логиты, из которых сэмплируется первый выходной токен. Последующие шаги декодирования добавляют по одному токену. Время до первого токена также включает ожидание в очереди, токенизацию, планирование и доставку по сети, поэтому высокий TTFT не доказывает, что сам префилл работает медленно.
| Симптом | Что измерить перед изменением сервера |
|---|---|
| Первый токен приходит позже при более длинных промптах | Время в очереди и длительность префилла по длине входа |
| Последующие токены генерируются медленнее при более длинной истории | Время декодирования и трафик KV cache |
| Новый длинный промпт приостанавливает другие потоки | Итерации планировщика и интервалы между токенами |
| Отдельные серверы тратят время на передачу состояния | Объём передаваемых KV-данных в байтах, пропускная способность и ожидание в очереди |
Префилл повторно использует веса для разных токенов промпта. Реализация всё равно может загружать блоки матриц больше одного раза; она не гарантирует ровно одно чтение каждого веса из HBM. Splitwise описывает, как эти фазы используют разные аппаратные ресурсы.
Что меняет префилл по чанкам
Префилл по чанкам обрабатывает длинный промпт за несколько итераций планировщика. Планировщик, описанный в документации vLLM, сначала допускает выполняющиеся запросы на декодирование, а оставшийся бюджет токенов итерации использует для префилла. Фактический размер чанка зависит от доступного бюджета.
Это может сократить приостановки существующих потоков и одновременно увеличить TTFT нового запроса. Более мелкие чанки также добавляют работу планировщику и повторно читают предыдущее состояние кэша. Sarathi-Serve оценивает этот компромисс; увеличение времени префилла примерно на 25% при чанках по 512 токенов измерили для Yi-34B с тензорным параллелизмом степени два.
Раздельный сервинг, напротив, размещает префилл и декодирование в отдельных пулах GPU. Он позволяет независимо настраивать каждую фазу, но требует передачи KV cache запроса. Проверьте стоимость передачи и загрузку пулов, прежде чем применять такую архитектуру. Чанкинг меняет планировщик; разделение фаз также меняет деплой и коммуникацию.
Инженерное руководство: префилл и декодирование содержит временные диаграммы обоих подходов.