Вопрос с собеса на NLP agents на 400к в WB 🗿
Мой ученик, проходя на собес в ВБ, получил в лицо такой вопрос: почему при батчинге (пакетной обработке) запросов в LLM растет задержка, но увеличивается общая скорость? Я не могу пройти мимо и не разобраться с такого сочного вопроса, поэтому летсгоу ебать вопрос.
Давайте разберемся, как работает обработка батчем и почему ее используют абсолютно все крупные ИИ-сервисы.
Для этого заглянем внутрь графического процессора (GPU), если упростить, память видеокарты делится на два основных типа:
Чтобы GPU мог что-то посчитать, данные нужно сначала перенести из HBM в SRAM, и здесь мы упираемся в фундаментальную проблему современных LLM: Memory-bound - ситуация, когда скорость пересылки весов модели из медленной HBM в быструю SRAM длится дольше,
чем сами вычисления над этими весами и чип простаивает в ожидании данных 🤔
Когда нам надо сгенерировать следующий токен, чипу нужно прогнать через SRAM все слои модели. Загрузка этих слоев из HBM - самая долгая часть процесса, но так как веса модели одинаковы для всех запросов, мы можем за один такой проход обработать данные сразу для n запросов. В этом и заключается идея батчинга. (см. Картинку 2)
Но почему тогда растет задержка (Latency) для конкретного пользователя?
Когда запросы обрабатываются пачкой, GPU приходится делать больше математических операций за один такт, а также тратить память SRAM на контекст (KV-кэш) сразу нескольких пользователей. Из-за этого время генерации каждого отдельного токена (Latency) немного увеличивается.
Например, без батча Запрос 1 выполнился бы за 5 секунд. А в батче он выполнится за 7 секунд (см. Картинку 3) 😧
Тогда в чем выгода?
Итог: Батчинг заставляет отдельного пользователя подождать чуть дольше (растет Latency), но позволяет видеокарте не простаивать и обслуживать в разы больше пользователей одновременно (растет Throughput).
Мой ученик, проходя на собес в ВБ, получил в лицо такой вопрос: почему при батчинге (пакетной обработке) запросов в LLM растет задержка, но увеличивается общая скорость? Я не могу пройти мимо и не разобраться с такого сочного вопроса, поэтому летсгоу ебать вопрос.
Давайте разберемся, как работает обработка батчем и почему ее используют абсолютно все крупные ИИ-сервисы.
Для этого заглянем внутрь графического процессора (GPU), если упростить, память видеокарты делится на два основных типа:
- HBM (High Bandwidth Memory): Основная видеопамять, она огромная (например, 80 ГБ), но относительно медленная. Проводить вычисления напрямую в ней чип не может.
- SRAM: Сверхбыстрая память прямо внутри самого вычислительного чипа. Она крошечная (около 80 МБ), зато процессор работает с ней мгновенно.
Чтобы GPU мог что-то посчитать, данные нужно сначала перенести из HBM в SRAM, и здесь мы упираемся в фундаментальную проблему современных LLM: Memory-bound - ситуация, когда скорость пересылки весов модели из медленной HBM в быструю SRAM длится дольше,
чем сами вычисления над этими весами и чип простаивает в ожидании данных 🤔
Когда нам надо сгенерировать следующий токен, чипу нужно прогнать через SRAM все слои модели. Загрузка этих слоев из HBM - самая долгая часть процесса, но так как веса модели одинаковы для всех запросов, мы можем за один такой проход обработать данные сразу для n запросов. В этом и заключается идея батчинга. (см. Картинку 2)
Но почему тогда растет задержка (Latency) для конкретного пользователя?
Когда запросы обрабатываются пачкой, GPU приходится делать больше математических операций за один такт, а также тратить память SRAM на контекст (KV-кэш) сразу нескольких пользователей. Из-за этого время генерации каждого отдельного токена (Latency) немного увеличивается.
Например, без батча Запрос 1 выполнился бы за 5 секунд. А в батче он выполнится за 7 секунд (см. Картинку 3) 😧
Тогда в чем выгода?
Без батча: Мы обработали 2 запроса последовательно.
Потратили 10 секунд и получили, допустим, 200 токенов в секунду суммарно.
С батчем: Мы обработали оба запроса параллельно.
Потратили всего 7 секунд вместо 10.
Суммарная скорость системы выросла до 300 токенов в секунду - профит, сучка
Итог: Батчинг заставляет отдельного пользователя подождать чуть дольше (растет Latency), но позволяет видеокарте не простаивать и обслуживать в разы больше пользователей одновременно (растет Throughput).