Определите полезный результат, прежде чем искать пропускную способность
При взаимодействии измеряйте ожидание первого токена и ожидание полного ответа. Для офлайн-корпуса измеряйте время, необходимое для получения всех ожидаемых выходных данных. В обоих случаях задайте правило приёмки: точность на известных ответах, качество ранжирования или проверенное извлечение полей. Синтаксически корректный JSON всё ещё может содержать неверный ответ.
Разделяйте ожидание в очереди, обработку и полный путь, наблюдаемый вашим клиентом, когда ваши инструменты это позволяют. Внутреннее измерение движка имеет не те же границы, что измерение приложения. Документация метрик vLLM различает, в частности, ожидание, первый токен и общую длительность: сохраняйте это различение в своих записях, каким бы ни был выбранный движок.
Технические источники: vLLM — метрики запросов и задержки
Преобразуйте ваши запросы в критерии выбора
Подготовьте короткие, обычные и длинные входные данные со стабильными идентификаторами. Сохраните модель, токенизатор, шаблон диалога и параметры генерации. Считайте реально переданные токены, включая историю и документы, добавленные приложением. Записывайте отдельно запрошенный батч, отправленный параллелизм и запросы, фактически обрабатываемые одновременно: это не обязательно одни и те же числа.
| Вход, который нужно зафиксировать | Измерение и единица | Последствие для выбора |
|---|---|---|
| Полный промпт и лимит вывода | Входные и выходные токены на запрос | Проверить длинные случаи и ответы, обрезанные по лимиту |
| Одновременные запросы и темп поступления | Активные, ожидающие и завершённые запросы | Определить устойчивую нагрузку при требуемой задержке |
| Точность, квантование и кэш | Пиковая память на GPU, в байтах или Gio | Отбросить настройки, выходящие за пределы памяти на планируемой нагрузке |
| Правило качества и эталоны | Принимаемые выходные данные / ожидаемые выходные данные; бизнес-метрика | Сравнивать только варианты, соответствующие одному и тому же критерию |
| Границы замера времени | Первый токен, полный ответ или корпус: секунды | Сравнивать длительности с одинаковыми границами |
| Хронометраж до полученных файлов | Общее окно в часах или днях | Затем выбрать тариф на 3, 7 или 30 дней |
Измерять память с учётом контекста и параллелизма
Для авторегрессионной модели, которая генерирует по одному токену, кэш KV хранит состояния внимания. Его размер зависит от модели и сохраняемых токенов. Динамический кэш может расти во время генерации; статический кэш резервирует максимальный размер. Некоторые слои со скользящим окном ограничивают этот рост. Поэтому проверяйте планируемые длины и параллелизм с той стратегией, которая реально используется.
Квантизация весов и квантизация кэша — это два разных решения. Например, bitsandbytes заменяет некоторые линейные слои на квантованные версии; это не описывает все выделения памяти в вашем запуске. После смены точности заново проверяйте память и качество, а не предполагайте, что весь пик снизится в той же пропорции.
В PyTorch отдельно фиксируйте пик выделенных тензоров и пик памяти, зарезервированной аллокатором. Не складывайте их. Указывайте измеряемый GPU и единицу измерения: 1 ГиБ соответствует 2³⁰ байт. Эти счётчики не обязательно отражают всё использование устройства. Папка памяти подробно описывает их ограничения.
Технические источники: Hugging Face Transformers 5.17 — стратегии кэша KV · Hugging Face Transformers 5.17 — квантизация bitsandbytes · PyTorch 2.14 — управление памятью CUDA и счётчики
Измеримый тест на 300 документах
Пример для выполнения на вашем разрешённом корпусе: извлечь дату, сумму и категорию из 300 документов. Проверьте ожидаемые значения, уточните обработку отсутствующих полей и задайте порог приёмки до теста. Число документов описывает протокол; никакое время, оценка или пропускная способность не предполагаются.
- Зафиксируйте 300 идентификаторов, ревизию модели, промпты, лимиты токенов и правило парсинга. Длинные документы должны оставаться идентифицируемыми в итоговом отчёте.
- Выполните базовый прогон с одним запросом за раз. Разделяйте загрузку, прогрев и измерение; сохраняйте предсказания и ошибки по каждому документу.
- Затем увеличивайте только один параметр: batch для пакетной обработки или параллелизм для движка запросов. Сохраняйте те же входные данные и критерии качества.
- Для каждого прогона фиксируйте длительность, пик памяти, число найденных идентификаторов без дублей и принятые выходные данные. Повторяйте измерения и сохраняйте исходные значения вместе с их разбросом.
- Если какой-то вариант не удался, зафиксируйте причину: память, усечение, формат или качество. Уменьшенный batch или повтор — это решение, которое нужно задокументировать, а не ошибка, которую нужно скрыть.
Технические источники: IteraGPU — подробный протокол сравнения при эквивалентном качестве
Использовать ресурсы IteraGPU Lab v1 в правильных границах
Ноутбук и его сопутствующий скрипт предлагают расчёт весов и измерение на небольшой синтетической сети. Их код измерения был выполнен на локальной RTX 5070 с PyTorch 2.11.0 на небольшой конфигурации в float32. Этот тест проверяет данный сценарий запуска; он не измеряет ни LLM, ни кэш KV, ни GPU из каталога на ваших запросах.
Используйте ноутбук, чтобы понять счётчики, а затем измерьте свою реальную нагрузку в её окружении. Протокол качества и таблица сырых данных служат для подготовки сравнения. Выходные данные распространяемого ноутбука и строки результатов в CSV остаются пустыми; процедура не устанавливает ни модель, ни драйвер. Прочитайте требования в README перед запуском.
- Ноутбук по памяти IteraGPU Lab v1
Расчёты и небольшая синтетическая сеть для понимания измерения памяти.
- Протокол качества для заполнения
Фиксированные входные данные, приёмка выходных данных и сравнение тестов.
- Пустая таблица сырых данных
Одна строка на каждый реальный прогон, с параметрами, измерениями и вердиктом.
- Требования и ограничения IteraGPU Lab v1
Инструкции и точные границы уже выполненного локального теста.
Перейти от измерений к предложению
Ваша памятка по выбору должна объединять совместимое окружение, память на карту, контекст, параллелизм, достигнутое качество и измеренные сроки. Сравните конфигурации, отвечающие этим критериям, а затем тарифы на 3, 7 и 30 дней по полному графику: подготовка, обработка, оценка, возобновления и экспорт. Калькулятор в разделе benchmarks использует целый тариф и реально проверенные полезные корпуса.
Сохраняйте эту памятку и версии кода в своём журнале. Вы сами выбираете свои программы и способы обработки; IteraGPU не проводит проверку содержимого ваших файлов, промптов или вычислений. Выбор окружения при заказе выражает вашу потребность в подготовке: он не является доказательством того, что ваша модель уже была установлена или протестирована.
Практические вопросы
Достаточно ли 24 ГБ для моей модели инференса?
Объём в 24 ГБ сам по себе не позволяет ответить, не зная модель и нагрузку. Проверьте вместе веса, выделения под выполнение, контекст и одновременные запросы. Конфигурация должна доводить длинные случаи до конца с требуемым качеством; один лишь размер файла или оценка весов этого не доказывают.
Какую пропускную способность нужно сравнивать для офлайн-корпуса?
Сначала сравните время, необходимое, чтобы завершить и оценить один и тот же корпус. Если вы публикуете пропускную способность, укажите число принятых полезных выходов, учтённое время и ошибки. Пропускная способность в токенах в секунду без длины ответа и контроля качества не позволяет развести две конфигурации.
Требует ли превышение памяти смены GPU?
При превышении памяти сначала нужно определить настройку и вход, которые его вызвали. Вы можете рассмотреть batch, параллелизм, длину или точность, сохраняя цель проекта. Любое сокращение, меняющее обрабатываемые документы или ожидаемые ответы, требует новой проверки качества; больше памяти может потребоваться, если эти ограничения нужно сохранить.
Проверяет ли предоставленный notebook моё приложение инференса?
Предоставленный notebook не проверяет ваше приложение: он измеряет небольшую синтетическую сеть и объясняет счётчики памяти. Задокументированный локальный тест касается только этого случая. Ваше приложение должно быть оценено с его моделью, входами, окружением и собственными критериями приёмки, прежде чем делать выводы о ёмкости или производительности.