При выборе GPU под инференс обычно отталкиваются от объема видеопамяти: поместятся ли в карту веса модели. Однако выполнение этого условия ничего не говорит о том, сколько запросов в секунду выдержит сервис на основе модели.
В работе карта держит не только веса. Каждый обрабатываемый запрос занимает свой KV-кеш, который растет вместе с длиной контекста. Поэтому оставшийся после весов объем памяти задает, сколько запросов обрабатывается одновременно.
Но поместиться мало, запросы еще нужно обработать. Здесь решает уже не память, а время, которое карта тратит на каждый запрос. Складывается оно из двух этапов.
Разберем, как из этих величин считается число карт под заданный поток запросов.
Четыре числа для расчета подходящей карты
Расчет опирается на четыре величины. Две описывают запрос: длина промпта и длина ответа на него. Из них считается, сколько памяти занимает запрос и сколько времени карта на него тратит. Две другие описывают сервис: поток запросов и пороги задержки. На их основе рассчитывается количество запросов, обрабатываемых одновременно.
Значения снимаются с работающего сервиса или с пилотного проекта. Распределение длин промптов и ответов обычно уже есть в логах сервиса, через который идут запросы к модели.
Память: веса и KV-кеш
Расчет проведем на модели Llama 3.3 70B и двух ускорителях: NVIDIA H200 со 141 ГБ видеопамяти и NVIDIA RTX PRO 6000 Blackwell Server Edition с 96 ГБ.
Точность задает объем весов. В FP16 веса модели на 70 млрд параметров заняли бы около 140 ГБ, то есть практически всю память H200, и под KV-кеш не осталось бы ничего. В 96 ГБ RTX PRO 6000 такая модель не помещается вовсе. Поэтому веса берем квантованными, а точность указываем для каждой карты отдельно.
Видеопамять расходуется в основном на веса модели и KV-кеш. Веса занимают фиксированный объем. KV-кеш растет вместе с длиной контекста и числом запросов в обработке.
Кеш на один токен считается по конфигурации внимания модели: 2 × слои × KV-головы × размер головы × байт на значение. Для модели на 70 млрд параметров указаны 80 слоев и 8 KV-голов. Размер головы 128 получается из размерности модели и числа голов внимания. В FP8 выходит 160 КиБ на токен, в FP16 вдвое больше. Формат кеша задается отдельно от формата весов: квантование весов самого кеша не касается.
Посчитаем предел по памяти для запроса с промптом на 8192 токена и ответом на 1024 токена, то есть на 9216 токенов кеша. Кеш берем в FP8 на обеих картах. Веса на H200 тоже в FP8, а на RTX PRO 6000 в FP4: публичный замер для этой карты есть только в FP4.
| Параметр | H200 | RTX PRO 6000 Server Edition |
|---|---|---|
| Видеопамять | 141 ГБ | 96 ГБ |
| Точность весов | FP8 | FP4 |
| Веса Llama 3.3 70B | около 70 ГБ | около 35 ГБ |
| Остается под кеш | около 71 ГБ | около 61 ГБ |
| Кеш на один запрос | 1,51 ГБ | 1,51 ГБ |
| Предел по памяти, одновременных запросов | около 47 | около 40 |
Часть памяти забирают активации и буферы движка инференса, поэтому практический предел ниже расчетного.
Память считается по пиковой длине контекста. Длинный документ в промпте занимает кеш на все время генерации ответа, и сервис останавливается на том запросе, под который места уже не хватило.
Длинный промпт и пропускная способность
Чтение промпта идет до того, как пользователь увидит первый символ ответа. Чем длиннее промпт, тем дольше карта занята этим чтением и тем меньше запросов успевает обработать.
Замеры NVIDIA
NVIDIA замеряла Llama 3.3 70B в режиме TP2 на двух картах H200 SXM 141 ГБ, веса — в FP8. Длину ответа держали на 1024 токенах, промпт меняли. Результаты приведены в выходных токенах в секунду на одну GPU.
| Промпт / ответ, токенов | Выходных токенов в секунду на карту |
|---|---|
| 1024 / 1024 | 2582 |
| 8192 / 1024 | 537 |
| 32768 / 1024 | 120 |
Длина ответа не менялась ни разу, вся разница пришлась на чтение промпта. Промпт вырос в восемь раз, а пропускная способность упала в 4,8 раза. Значит под тот же поток запросов нужно в 4,8 раза больше карт.
Для расчета берут строку замера с длинами, близкими к своим. Если такой строки нет, прогон делают на своих промптах и ответах.
Влияние порогов задержки на пропускную способность
Карта обрабатывает несколько запросов одновременно, объединяя их в батч. Чем больше запросов в батче, тем больше токенов в секунду выдает модель на этой карте. Но каждый пользователь при этом ждет ответа дольше: карта делит время между всеми запросами батча. По данным NVIDIA, с ростом числа одновременных запросов общая пропускная способность растет, а скорость ответа у отдельного пользователя падает.
Поэтому батч нельзя увеличивать бесконечно. Предельный размер батча задается требованием ко времени ответа. Чем жестче это требование, тем меньше запросов проходит через карту за секунду и тем больше карт нужно под тот же поток.
Как измерить пропускную способность на своих данных
Пропускную способность для расчета измеряют на своем стенде, а числа из таблиц NVIDIA можно использовать как ориентир: они сняты без ограничения по времени ответа. Замер идет в три шага:
Полученное число и есть рабочая пропускная способность сервиса, его и подставляют в расчет парка карт.
Расчет числа карт
Замеры публикуются в выходных токенах в секунду, а считать нужно в запросах в секунду. Перевод идет через длину ответа.
Число карт = целевой RPS × длина ответа ÷ пропускная способность карты
Считаем для промпта в 8192 токена и ответа в 1024 токена, это строка 8192/1024 из замера NVIDIA. Цель — пять запросов в секунду. Пропускную способность берем из публичного замера, чтобы показать ход расчета: в своем расчете на ее месте стоит число с собственного стенда.
| Параметр | H200 | RTX PRO 6000 Server Edition |
|---|---|---|
| Точность весов | FP8 | FP4 |
| Выходных токенов в секунду на карту | 537 | 296 |
| Запросов в секунду с карты | 0,52 | 0,29 |
| Карт на пять запросов в секунду | 10 | 18 |
Точность в колонках разная, FP8 против FP4, поэтому между собой они не сравниваются. В FP4 веса модели занимают примерно вдвое меньше памяти, чем в FP8, но точность ответов в такой сборке проверяют на своих данных.
Длина контекста входит в расчет через выбор строки замера. Тот же сервис с промптом в 1024 токена считался бы по 2582 токена в секунду и потребовал бы примерно в пять раз меньше карт.
После расчета по пропускной способности конфигурацию проверяют по памяти. Для этого определяют число одновременно выполняющихся запросов: RPS × среднее время обработки запроса. Затем проверяют, помещается ли такая параллельная нагрузка в память той же конфигурации GPU. Если ограничение по памяти требует больше ресурсов, количество GPU увеличивают. Итоговая конфигурация должна одновременно выдерживать требуемую пропускную способность и нагрузку по памяти.
К расчетному числу карт добавляют запас: на дневные пики и на отказ оборудования. Запас на пики считают по графику нагрузки сервиса. Отказ одного сервера лишает сервис всех его ускорителей, поэтому запас на отказ рассчитывают по серверам: оставшихся карт должно хватить на тот же поток запросов.
GPU-инфраструктура ITGLOBAL.COM
В ITGLOBAL.COM есть два формата аренды ускорителей, и выбор между ними зависит от характера нагрузки.
Облачные серверы с GPU — это виртуальные машины с ускорителями NVIDIA H200 NVL, RTX PRO 6000 Blackwell Server Edition, А100/A800 и А16. Лицензии NVIDIA AI Enterprise включены в услугу. Формат подходит для инференса с переменным потоком запросов.
Выделенные серверы с GPU — это физический сервер целиком для одного клиента. Формат подходит для стабильного потока с жесткими порогами задержки, когда соседние нагрузки на сервере не должны влиять на время ответа.
Серверы размещаются в дата-центрах уровня Tier III в семи странах, в том числе России, Беларуси, Казахстане и Узбекистане.
Итоги
Количество и класс GPU подбирают по реальному профилю нагрузки. Модель должна помещаться в память вместе с KV-кешем и одновременно обеспечивать нужную пропускную способность при заданных требованиях к задержке.
Поэтому итоговую конфигурацию определяют после нагрузочного тестирования на своих промптах и ответах, а публичные замеры производителя используют как ориентир.
Часто задаваемые вопросы
Это промежуточные значения, которые модель сохраняет для каждого обработанного токена, чтобы не считать их заново на каждом следующем шаге. Кеш живет, пока запрос обрабатывается, и растет вместе с длиной контекста. Для Llama 3.3 70B в FP8 это 160 КиБ на токен.
Можно сделать это двумя способами. Сократить контекст, потому что кеш растет вместе с ним. Либо хранить кеш в более низкой точности: его формат задается отдельно от формата весов, поэтому квантование весов сам кеш не уменьшает.
Нет. При одинаковом количестве запросов нагрузка может различаться из-за длины входных данных и ответа, числа одновременно обрабатываемых запросов и требований ко времени ответа. Все эти параметры влияют на расход видеопамяти и производительность GPU.
Весь промпт карта обрабатывает до первого токена ответа. По замерам NVIDIA, промпт длиннее в восемь раз снижает пропускную способность в 4,8 раза.
Не обязательно. Веса занимают фиксированный объем, а KV-кеш растет с числом одновременных запросов. На H200 после весов в FP8 остается 71 ГБ, этого хватает примерно на 47 запросов с контекстом в 9216 токенов.
Публичные замеры дают ориентир для определенной конфигурации и режима нагрузки. В реальном сервисе пропускная способность зависит от длины запросов, требований к задержке, числа одновременных запросов и настроек инференса, поэтому итоговый расчет проверяют на своем профиле нагрузки.
Запас нужен на дневные пики и на отказ оборудования. Отказ одного сервера лишает сервис всех его ускорителей, поэтому запас на отказ рассчитывают по серверам.
Предыдущая статья
