GPU для LLM: память, задержка и проверенный запуск

GPU выполняет много однотипной работы параллельно. Пользовательская операция включает также работу CPU и перенос данных. Если ускоренный фрагмент занимает малую часть запроса, даже быстрое вычислительное ядро GPU (kernel) мало меняет полное время ответа.

SIMD задаёт одну операцию над несколькими элементами вектора; SIMT описывает группу программных потоков с собственным состоянием. Маска активности выбирает участвующие элементы или потоки. Эти модели помогают понять выполнение, но сами по себе не задают число вычислительных блоков GPU.

В выбранной модели CUDA warp содержит 32 потока. Последний неполный warp не становится отдельным маленьким устройством. Если потоки одного warp расходятся по ветвям, активные подмножества выполняют соответствующие участки; число полезно занятых lanes может уменьшиться.

Совпадение warp не разрешает обмениваться данными без нужной синхронизации. Independent Thread Scheduling меняет допустимые предположения о ходе потоков; warp-примитив с корректной маской не заменяет барьер всего блока. Правила CUDA не задают размер группы у произвольного другого ускорителя.

Occupancy — доля активных групп warp на потоковом мультипроцессоре SM относительно доступного максимума. Высокое значение не доказывает скорость приложения. При сравнении измеряют завершённую операцию: асинхронный запуск kernel может вернуть управление CPU раньше окончания вычисления.

FP16 и BF16 хранят по 16 бит, то есть по два байта на значение. У FP16 5 бит порядка и 10 дробных бит, у BF16 — 8 и 7. BF16 даёт более широкий диапазон. Между 1 включительно и 2 не включительно шаг BF16 равен 1/128, а FP16 — 1/1024. Переход FP16 → BF16 не сокращает объём плотных данных вдвое.

Тензорные блоки выполняют поддержанные варианты матричного умножения с накоплением. Форматы входов и накопителя могут отличаться. Нужны подходящие форма матриц, размещение и kernel библиотеки; наличие Tensor Core в названии устройства не доказывает, что конкретный запуск использует этот путь.

У квантованного артефакта фиксируют метод, упаковку кодов, группировку, шкалы и оставшиеся тензоры другого dtype. Ровно 7 млрд значений по 4 бита занимают 3,5 млрд байт кодов против 14 млрд байт по два байта. Это учебное отношение объёмов кодов 4:1, без обещания такого же сокращения всей VRAM.

Weight-only квантование не меняет автоматически KV-cache. Поддержка метки INT4 тоже недостаточна: backend должен читать точную схему и выполнять её операции. AWQ использует активации для выбора масштабирования весов; калибровка метода и оценка качества готового сервиса — разные проверки.

Сравнивайте численные режимы на одинаковых заданиях, входах и параметрах генерации. Проверьте качество, память, prefill и decode. Число операций для sparse-режима нельзя подставлять вместо dense-режима; ни эта цифра, ни разрядность кодов не задают универсального ускорения ответа.

Драйвер, CUDA runtime, toolkit и библиотеки выполняют разные роли. Compute capability описывает аппаратные возможности выбранной GPU и не является номером CUDA. Версия установленного toolkit не сообщает автоматически версию драйвера, с которым выполнится процесс.

Сверяют целевую архитектуру бинарного кода, наличие применимого PTX и направление совместимости версий. Универсальный номер минимального драйвера из названия модели GPU не выводят. Проверяют точное сочетание драйвера, runtime, библиотек, dtype и kernels на принимаемом устройстве.

Артефакт запуска шире весов: нужны конфигурация архитектуры, tokenizer, chat template, параметры генерации и runtime. Для фиксации комплекта можно принять локальный список файлов и их дайджестов. Тот же файл весов при другом шаблоне диалога может получить иной вход и дать иной результат.

Safetensors — контейнер тензоров. Его свойства не дают разрешения исполнять сопутствующий Python-код или доверять остальным файлам пакета. Совпавший хеш подтверждает выбранные байты, а качество модели и допустимость исполнения проверяют отдельно.

Видимость GPU проверяет лишь часть пути. Зафиксированный набор версий должен загрузить нужную модель и выполнить характерные операции; проверка готовности сервиса отдельно показывает готовность принимать трафик. Ни перечисление устройств, ни одна успешная проба не заменяют нагрузочную приёмку.

У дискретной GPU локальная память отличается от оперативной памяти узла. Внутри GPU глобальная память, shared memory блоков и регистры имеют разные области использования. HBM — организация локальной DRAM с широким интерфейсом, а не название shared memory каждого вычислительного блока.

Ёмкость определяет объём хранимых данных; bandwidth — объём переноса за время. Большая HBM не доказывает более быструю модель. Скорость чтения локальной памяти также не становится скоростью связи GPU с другой GPU или с CPU.

Unified addressing даёт согласованное адресное пространство, но не один физический пул с одинаковой стоимостью доступа. Unified Memory может перемещать страницы; page fault и передача расходуют время. Возможность адресовать данные сверх локального объёма не доказывает, что модель работает с прежней задержкой.

Effective bandwidth считают как сумму полезных байтов чтения и записи, делённую на время завершённой операции. Задайте границу и синхронизацию замера. Пиковая паспортная величина служит потолком определённого интерфейса. В байте восемь бит; объём полезных данных и объём фактических транзакций памяти тоже могут отличаться.

Соседние обращения потоков могут объединяться в транзакции. Неудачная раскладка переносит лишние данные, а повторный тест из cache измеряет другой путь, чем холодная DRAM. Latency одного доступа и суммарная bandwidth также не взаимозаменяемы.

У CPU↔GPU и GPU↔GPU могут быть разные физические пути. У PCIe важны поколение и фактическая ширина соединения; у peer transfer — доступность нужной пары устройств и топология. Возможности одной пары не доказывают возможности всех пар узла.

Успешный peer access даёт способ доступа между устройствами, но не превращает две VRAM в одну локальную область без затрат. Программный runtime должен явно поддерживать размещение данных и обмен для выбранной модели.

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

Передача входа и результата может занять заметную часть операции даже при быстром kernel. Отдельно измерьте полезный сценарий целиком и расходы обмена. Подбор числа GPU должен учитывать эту стоимость вместе с памятью и вычислением.

Веса — подготовленные параметры модели. В обычном инференсе они используются для вычисления, а не обновляются на каждом ответе. KV и token IDs относятся к состоянию запроса; их изменение не означает обучение модели на разговоре.

Для ровно 8 млрд отдельно хранимых значений по два байта объём плотных весов равен 16 млрд байт: 16 GB, около 14,90 GiB. Считают уникальные сохранённые значения, учитывая совместное использование одних весов разными операциями. Это один компонент бюджета, без KV, рабочих буферов и возможных копий при загрузке.

Tokenizer связан с конкретной моделью: он превращает текст в token IDs по своим правилам. Токен не обязан быть словом; BPE обучает слияния частей, но не описывает каждый tokenizer. Число символов нельзя делить на постоянный коэффициент для точного допуска запроса.

Сначала применяют реальный chat template и специальные токены, затем считают полный вход. В учебном лимите 4096 токенов вход 3072 уже включает эту упаковку; резерв на новые токены 1024 исчерпывает остаток. Добавление ещё одного разделителя сверх входного бюджета меняет допустимость запроса.

max_new_tokens ограничивает новые токены, а не задаёт всю длину контекста. При превышении нельзя незаметно считать усечение эквивалентным запросом. Поддержку более длинной позиции, качество на ней и достаточный KV-бюджет проверяют отдельно; увеличение одного runtime-параметра не доказывает все три свойства.

В prefill модель обрабатывает доступный входной префикс и формирует K/V для последующего использования. Вычисления последней входной позиции дают распределение для выбора первого выходного токена; не нужно заранее приписывать ему ещё один полный проход по всему входу.

Обычный авторегрессионный decode использует уже доступный префикс для выбора следующего токена. Новые токены одной цепочки зависят от предыдущих. KV избавляет от повторного получения старых K/V, но attention всё ещё читает нужное состояние; cache не отменяет стоимость длинного контекста.

Клиентское время до первого токена включает подготовку и очередь в согласованной границе, вычисление и доставку. Изолированное время prefill меньше по области измерения. Первый HTTP-байт или служебный role event не обязательно содержит текст ответа.

Network chunk может содержать несколько токенов, часть текста или служебное сообщение; это не один шаг модели. Остановка по EOS отличается от достижения token cap: второй случай может оставить ответ усечённым. Логи должны сохранять причину завершения, а не объявлять любой закрытый stream успешным.

Длина входа влияет на prefill, длина выхода — на число decode-шагов. Нельзя заранее присвоить любому prefill ограничение только вычислениями, а decode — только памятью: batch, модель и реализация меняют результат. Сравнивайте их при фиксированном профиле и состоянии prefix reuse.

При одинаковой геометрии слоёв и равной длине последовательностей плотный KV занимает M=2×L×Hkv×D×T×s×B байт. L — слои, Hkv — головы K/V, D — размер головы, T — сохраняемые токены, s — байты значения, B — последовательности. Множитель 2 означает K и V. При разных длинах без выравнивания и совместного хранения вместо T×B используют сумму длин. В GQA считают головы K/V, а не головы запросов Q.

В примере layers=32, KV heads=8, head dimension=128, tokens=4096, FP16/BF16=2 байта. Одна последовательность требует 536870912 байт K/V, то есть 512 MiB; четыре независимые — 2147483648 байт, или 2 GiB. Это арифметика K/V без общего prefix, sliding window, квантования KV, padding и allocator overhead.

К 16 млрд байт плотных весов из модуля о весах и контексте прибавляют KV, временные буферы операций, служебные структуры, резерв выделения памяти и нужные копии. Даже сумма весов и K/V меньше VRAM не доказывает запуск: пиковые временные расходы и распределение по устройствам ещё неизвестны.

Если квантованы только веса, в формуле KV остаётся фактический dtype cache. Повторное использование prefix и переменные длины могут менять реально выделенную память, но их нельзя вычитать из худшего случая без подтверждённого механизма. Запрошенное число активных sequences задаёт отдельную нагрузку на память.

Суммарную оценку нельзя механически делить на число GPU: раскладка, репликация отдельных тензоров и размещение KV зависят от реализации. Проверяют пик каждого устройства при длинных входах, активных последовательностях и загрузке; окончательный предел одновременно обслуживаемых запросов подтверждают испытанием.

Batch обозначает совместно обрабатываемые последовательности. Одно число batch size не сообщает длины входов и выходов, padding или размер сохранённого KV. Сравнивать две нагрузки можно только с этим профилем и действующим способом размещения последовательностей.

Совместная работа может распределить стоимость чтения весов между последовательностями и увеличить throughput. При этом ожидание набора и конкуренция запросов меняют задержку. Больший batch не означает более быстрый ответ каждому клиенту.

Continuous batching допускает изменение активного набора на границах итераций: завершившиеся запросы освобождают место, а новые могут войти в работу. Это отличается от ожидания конца всего статического пакета. Фактические правила допуска и освобождения KV проверяют у выбранного engine.

Ограничение числа активных запросов не является самостоятельным бюджетом памяти: важны длины и KV. Prefill новых входов может конкурировать с текущим decode. Настройка, дающая больше выходных токенов в секунду, может ухудшить хвост задержек у уже принятых запросов.

Исследование ORCA объясняет механизм iteration-level scheduling; оно не обещает наличие тех же настроек в любом выпуске serving engine. Для приёмки фиксируют версию, правила допуска новых запросов, длины и предложенную нагрузку, затем смотрят совместно память, задержки и завершённую работу.

TTFT измеряют от согласованного начала запроса до первого содержательного токена в выбранной клиентской границе. В неё входят очередь и prefill. В отчёте указывают предложенную нагрузку, условия холодного и прогретого запуска, распределение и ошибки: среднее только по успешным быстрым ответам скрывает часть поведения.

В принятом договоре ITL — интервалы между последовательными выходными токенами при наличии их отдельных отметок времени. Это условие нужно проверить у измерителя. Если клиент видит только порции текста, их интервалы так и называют; постфактум пересчитанное число токенов не восстанавливает индивидуальные моменты выдачи.

Для N выходных токенов, N≥2, TPOT = (tN−t1)/(N−1): интервал от первого до последнего токена делят на число промежутков. Длинная пауза с последующей быстрой пачкой может дать то же среднее, что ровная выдача. Общая выборка интервалов и равный вес каждого запроса отвечают на разные вопросы; среднее локальных p95 не является общим p95.

Производительность требует единицы работы и окна времени. Входные и выходные токены в секунду считают отдельно; число запросов в секунду дополняют длинами. Интенсивность поступления отличается от скорости завершения. Рост очереди не превращает отправленные запросы в обслуженные.

Сравнивают одинаковые tokenizer, входы, параметры генерации и допустимое качество. В предлагаемом протоколе отдельно считают всю работу и работу, уложившуюся в выбранные условия SLO, за то же время; правила отбора задают заранее. Ошибки и усечённые ответы остаются видимыми. Высокий темп непригодных ответов не выполняет приёмку.

Tensor parallelism делит вычисление и данные внутри слоёв между устройствами. Коллективные обмены сохраняют зависимости между частями вычисления; возможность их перекрытия проверяют у реализации. Доля весов не равна всей памяти устройства. Топология и поддержанный способ распределения влияют на результат, поэтому удвоение числа GPU не обещает удвоить скорость.

Pipeline parallelism размещает стадии из разных слоёв на устройствах и передаёт между ними активации. Зависимости одного запроса сохраняются. Заполнение конвейера и свободные интервалы зависят от работы; самые медленные и самые тесные по памяти стадии ограничивают выбранную схему.

При data-parallel inference независимые реплики имеют собственные копии модели и получают разные запросы. Четыре отдельные карты по 24 GiB не размещают автоматически одну модель с объёмом весов 60 GiB: если каждая реплика живёт на одной карте, сумма 96 GiB относится к разным копиям, а не одной общей.

Состояние продолжаемого запроса должно попасть к соответствующей реплике или быть восстановлено корректным способом. Внутри одной реплики могут работать TP/PP; это не то же самое, что четыре полных копии. Для обычного inference не следует автоматически добавлять обучение и синхронизацию градиентов.

Megatron-LM и GPipe дают основания для объяснения видов параллелизма. Их обучающие расписания и результаты не являются контрактом выбранного serving engine. Проверьте поддержку, размещение KV, память каждого устройства, обмены и нагрузочные результаты конкретного выпуска.

Зафиксируйте артефакт и стек, набор заданий, длины входов и выходов, параметры генерации, предложенную нагрузку и предел одновременного обслуживания. Сначала установите допустимое качество ответа. Изменённая модель или tokenizer требуют повторной оценки: прежний результат качества не переносится только по одинаковому числу параметров.

Измерьте TTFT, интервалы, throughput, ошибки и причины остановки одновременно. Разделите холодный запуск и прогретый режим. Из отчёта должно быть видно, входят ли загрузка модели и прогрев в окно, какой prefix cache применён и как считаются неуспешные запросы.

Испытайте длинные контексты и согласованный предел активных sequences, наблюдая каждый GPU. Короткий одиночный запрос не доказывает пиковую память и хвост задержек. Повторение прогона с теми же входами помогает отделить устойчивый результат от случайной удачной серии.

Readiness проверяет готовность к маршрутизации по принятому контракту, но не подтверждает качество и SLO. После выбранного сбоя или замены версии проверьте возвращение готовности и полезную операцию; зафиксируйте судьбу прерванных запросов и повторов. В предлагаемом протоколе отката отдельно задают возвращаемый комплект, способ запуска и проверку после возврата.

Допуск оформляют по фактическим наблюдениям и заранее заданным порогам. Открытые условия — например, неизвестный пик рабочих буферов, отсутствующие отметки времени отдельных токенов или непроверенный длинный контекст — перечисляют явно. Исследование, паспорт GPU и расчёт памяти помогают спланировать тест, но не заменяют его результат.