Что вызывает сбои сервинга LLM и как их исправить?
Автоматический перевод
Эта статья была автоматически переведена с оригинальной английской версии.
Сбои сервинга LLM часто возникают из-за нехватки памяти, объёма параллельной работы, который сервис не может обработать, или повторных попыток, заново выполняющих дорогие запросы. Прежде чем менять рантайм, определите, какой ресурс или этап даёт сбой. Успешная загрузка модели не доказывает, что она справится с ожидаемым трафиком.
Сопоставьте симптом с данными
| Симптом | Какие данные проверить первыми | Какое изменение протестировать |
|---|---|---|
| Ошибка нехватки памяти GPU | Веса, выделение памяти под KV, активации, длины запросов | Меньший активный батч, меньшие ограничения длины или поддерживаемая квантизация |
| Латентность растёт без ошибок | Использование KV, вытеснения, ожидающие запросы | Меньше одновременно допускаемых запросов или больше мощности, подтверждённой измерениями |
| Медленный первый токен | Очередь, токенизация, префилл, сетевые задержки | Исправить медленный этап; протестировать префилл по частям, если фазы мешают друг другу |
| Нагрузка растёт после тайм-аутов | Число повторных попыток и работа, которая ещё выполняется | Ограниченные повторные попытки и отмена работы, результат которой уже не нужен |
Память для весов и память для KV — отдельные ресурсы. Модель 70B в FP16 требует примерно 140 GB только для значений весов. При обычной организации кэша для полного аттеншна одна последовательность Llama 3.1 70B длиной 128K токенов добавляет 40 GiB данных KV в FP16 без учёта накладных расходов рантайма. Ни одно из этих чисел само по себе не описывает полную потребность в памяти.
Проверьте вытеснения, прежде чем увеличивать очередь
Когда места для KV недостаточно, движок сервинга может вытеснять запросы. vLLM V1 обычно заново вычисляет вытесненную работу, что увеличивает латентность, даже если API в итоге успешно отвечает. Сопоставьте число вытеснений с длинами промптов, активными последовательностями и использованием KV.
Сократите допускаемый объём работы или измените тестируемое распределение памяти. Прежде чем увеличивать использование памяти GPU, убедитесь, что для остальных выделений памяти по-прежнему хватает места. Перемещение повторно используемых данных KV в память CPU или на диск также добавляет передачи данных; оно не гарантирует, что слишком большой активный запрос поместится в память.
Ограничьте повторные попытки
Повторяйте запросы после временных сбоев в пределах срока и бюджета повторных попыток. Используйте растущие интервалы со случайным разбросом и поручите повторные попытки одному уровню, чтобы повторы на шлюзе и клиенте не перемножались. Рекомендации Google по SRE объясняют, как повторные попытки могут усиливать перегрузку.
Передавайте отмену, когда вызывающая сторона прекращает ожидание, проверяйте остановку генерации и тестируйте это поведение под нагрузкой. Большая вместимость очереди откладывает отказ, но не создаёт вычислительную мощность.
Прочитайте раздел режимы отказа сервинга LLM руководства, чтобы разобраться в связанных понятиях памяти и планирования.