Сколько VRAM нужно для Whisper и других ASR-моделей

Whisper large-v2 в fp16 занимает 4.42 ГиБ видеопамяти при обработке одного потока. Это измеренное значение из бенчмарка в README faster-whisper: RTX 3070 Ti на 8 ГБ, CUDA 12.4, beam_size=5. Веса модели в этой точности — 2.89 ГиБ.

Разрыв в полтора гигабайта расходуется до того, как обработан первый сэмпл. Дальше расход растёт не от длины файла, а от числа потоков в батче: каждый добавляет около 224 МиБ.

Ниже — таблица по всей линейке Whisper, формула для расчёта под свой батч и сравнение с Parakeet, Canary и GigaAM.

Что считали и откуда взяты числа

Размеры весов взяты из карточек моделей на Hugging Face и пересчитаны из числа параметров. Геометрия моделей — из config.json в тех же репозиториях. Измеренный расход видеопамяти — из README faster-whisper: 13 минут аудио, RTX 3070 Ti 8 ГБ, CUDA 12.4, beam_size=5 во всех строках. Заявленные минимумы памяти для не-Whisper моделей — из карточек NVIDIA NeMo, где они сформулированы как требование к RAM. Все числа сняты 30 августа 2026 года.

Про large-v2 и large-v3

Замеры в README сняты на large-v2, а не на large-v3. Эти две модели совпадают по геометрии: 32 слоя энкодера, 32 слоя декодера, d_model 1280, 1550 млн параметров. Отличия v3 — 128 мел-каналов вместо 80 и один дополнительный токен в словаре. На расход видеопамяти это влияет на доли процента.

Версия при этом подписана везде: в таблицах с замерами стоит large-v2, в расчётных — large-v3. Если вырвать из статьи отдельную строку, привязка к версии останется в ней самой.

Единицы измерения

Размеры файлов на Hugging Face — десятичные гигабайты, 10⁹ байт. Размеры весов в статье пересчитаны из числа параметров в двоичные единицы: ГиБ и МиБ.

С замерами расхода сложнее. В README faster-whisper колонка подписана «VRAM Usage», а значения записаны как 4525MB — то есть формально это десятичные мегабайты. Но nvidia-smi, torch.cuda и CTranslate2 отдают такие величины в мебибайтах, и подпись «MB» у этих инструментов обычно означает MiB. Дальше в статье значения из README читаются как мебибайты — это допущение, а не документированный факт.

Если трактовать подпись буквально, все производные числа сдвигаются вниз: 4525 MB — это 4.21 ГиБ вместо 4.42, постоянная надстройка падает с 1.53 до 1.32 ГиБ, а цена одного потока в батче — с 224 до 213 МиБ. Выводы статьи от этого не меняются: официальная колонка требований остаётся завышенной, а порядок величин — тем же.

Формула расчётных строк

Часть значений в статье не измерена, а посчитана. Расчёт идёт по объёму cross-attention KV-кеша — ключей и значений, которые декодер строит из выхода энкодера один раз на сегмент и держит до конца генерации:

KV = 2 × слои_декодера × 1500 × d_model × 2 байта

Число 1500 — это max_source_positions, длина выхода энкодера для одного 30-секундного окна. Двойка в начале — раздельно ключи и значения, двойка в конце — два байта на элемент в fp16.

Что в расчёт не входит

Обучение и файн-тюнинг: там на параметр уходит на порядок больше памяти, разбор арифметики есть в справочнике по VRAM для обучения. Инференс на CPU. Сборки под TensorRT и NIM — у них своя схема выделения памяти. Диаризация вынесена в отдельный раздел, потому что это второй стек моделей.

Ограничения

Измерения faster-whisper сняты на одной карте потребительского класса. На картах с другим объёмом памяти аллокатор ведёт себя иначе: PyTorch и CTranslate2 резервируют пулы с запасом, и на 80 ГБ показания nvidia-smi будут выше при той же полезной нагрузке.

Размер CUDA-контекста зависит от версии драйвера и от того, сколько ядер подгружено. Полтора гигабайта надстройки — это значение для конкретной связки, а не константа.

Единицы в README подписаны как MB, а прочитаны здесь как MiB. При буквальной трактовке подписи надстройка составляет 1.32 ГиБ, а не 1.53, и на столько же сдвигается каждое производное число ниже.

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

Веса: нижняя граница для линейки Whisper

Веса — единственная часть расхода, которую можно посчитать точно. Количество параметров взято из README openai/whisper.

Модель	Параметры	fp16	int8
tiny	39 M	0.07 ГиБ	0.04 ГиБ
base	74 M	0.14 ГиБ	0.07 ГиБ
small	244 M	0.45 ГиБ	0.23 ГиБ
medium	769 M	1.43 ГиБ	0.72 ГиБ
large-v3	1550 M	2.89 ГиБ	1.44 ГиБ
large-v3-turbo	809 M	1.51 ГиБ	0.75 ГиБ
distil-large-v3.5	756 M	1.41 ГиБ	0.70 ГиБ

Расчёт сходится с тем, что лежит в репозиториях. Файл model.safetensors у openai/whisper-large-v3 весит 3.09 ГБ, то есть 2.88 ГиБ. Конвертированный под CTranslate2 model.bin у Systran имеет тот же размер. У turbo в формате CTranslate2 — 1.62 ГБ, ровно 809 млн параметров по два байта.

Отдельно стоит отметить fp32: тот же large-v3 в полной точности занимает 6.17 ГБ, вдвое больше. Загружать его так для инференса смысла нет, но transformers по умолчанию выберет именно fp32, если не передать torch_dtype.

Официальная таблица завышает требования вдвое

README openai/whisper даёт колонку «Required VRAM»: ~1 ГБ для tiny и base, ~2 ГБ для small, ~5 ГБ для medium, ~10 ГБ для large, ~6 ГБ для turbo. Измеренный расход этой колонке не соответствует.

Реализация	Точность	large-v2, замер	«Required VRAM» из README
openai/whisper	fp16	4.60 ГиБ	~10 ГБ
transformers (SDPA)	fp16	4.84 ГиБ	~10 ГБ
whisper.cpp (Flash Attention)	fp16	4.03 ГиБ	~10 ГБ
faster-whisper	fp16	4.42 ГиБ	~10 ГБ
faster-whisper	int8	2.86 ГиБ	~10 ГБ

Ближайшее к заявленному измеренное значение отличается от него вдвое. Разброс между четырьмя разными рантаймами при этом — 0.8 ГиБ, то есть дело не в реализации.

Наиболее вероятное объяснение: колонка описывает поведение оригинального кода 2022 года, где веса грузились в fp32, а окно нарезки и кеш не были оптимизированы. Это гипотеза — в README нет ни методики замера, ни железа, на котором он сделан. Практический вывод от неё не зависит: планировать карту по этой колонке значит переплачивать за вдвое больший объём памяти.

Куда уходит полтора гигабайта сверх весов

Вычтите веса из замера, и останется постоянная надстройка:

Точность	large-v2, замер на одном потоке	Веса large, 1550 M	Разница
fp16	4.42 ГиБ	2.89 ГиБ	1.53 ГиБ
int8	2.86 ГиБ	1.44 ГиБ	1.42 ГиБ

Разница почти не меняется при смене точности — 1.53 против 1.42 ГиБ. Это признак того, что она не связана с моделью. Сюда входит контекст CUDA, который создаётся при первом обращении к карте, воркспейсы cuBLAS и cuDNN, буферы мел-спектрограммы и активации энкодера.

Следствие прямое: на карте с 4 ГБ памяти large в fp16 не запустится, хотя веса занимают меньше трёх гигабайт. В int8 запустится с запасом в гигабайт. На карте с 6 ГБ работают оба варианта, но батч в fp16 будет упираться в потолок почти сразу.

То же самое проявляется при загрузке любой модели: если OOM происходит до первого прямого прохода, дело в весах и надстройке, а не в батче. Разбор того, как читать числа из текста ошибки, есть в статье про CUDA out of memory.

Каждый параллельный поток стоит 224 МиБ

В README faster-whisper есть две пары строк, различающихся только батчем. Все четыре значения — замеры на large-v2, из них выводится цена одного потока:

Точность	batch_size=1	batch_size=8	Разница на 7 потоков	На поток
fp16	4525 МиБ	6090 МиБ	1565 МиБ	223.6 МиБ
int8	2926 МиБ	4500 МиБ	1574 МиБ	224.9 МиБ

Два числа расходятся на 1.3 МиБ, хотя веса в этих строках хранятся с разной точностью и различаются вдвое по объёму. Значит, квантование весов на эту часть расхода не влияет вообще.

Проверим гипотезу расчётом. У large 32 слоя декодера и d_model 1280, выход энкодера — 1500 позиций. По формуле cross-attention KV-кеш на один поток:

2 × 32 × 1500 × 1280 × 2 = 245 760 000 байт = 234.4 МиБ

Расчёт даёт 234.4 МиБ, замер — 223.6 МиБ. Расхождение 4.6% укладывается в округление аллокатора; точная причина в README не разобрана. Совпадение порядка и величины означает, что масштабирование батча упирается именно в кеш ключей и значений энкодера, а он хранится в fp16 независимо от точности весов.

Для остальных моделей линейки расчёт даёт следующие значения. Геометрия взята из config.json соответствующих репозиториев:

Модель	Слои декодера	d_model	KV на поток, расчёт
tiny	4	384	8.8 МиБ
base	6	512	17.6 МиБ
small	12	768	52.7 МиБ
medium	24	1024	140.6 МиБ
large-v3	32	1280	234.4 МиБ
large-v3-turbo	4	1280	29.3 МиБ
distil-large-v3.5	2	1280	14.7 МиБ

Обратите внимание на turbo и distil. Энкодер у них тот же, что у large-v3, — 32 слоя и d_model 1280. Отличается только глубина декодера, и именно она определяет цену потока.

Расчёт под свой батч

Формула для планирования: веса + 1.5 ГиБ (1.53 для fp16, 1.42 для int8) + (батч − 1) × цена потока. Для large в fp16 первые два слагаемых дают 2.89 + 1.5 = 4.39 ГиБ против измеренных 4.42 ГиБ: расхождение 0.03 ГиБ укладывается в округление самой надстройки. Дальше прибавляется по 224 МиБ на поток — это замеренная величина, а не расчётная.

batch_size	large-v3, fp16	large-v3-turbo, fp16
1	4.42 ГиБ	3.01 ГиБ
4	5.08 ГиБ	3.09 ГиБ
8	5.95 ГиБ	3.21 ГиБ
16	7.70 ГиБ	3.44 ГиБ
32	11.20 ГиБ	3.89 ГиБ
64	18.20 ГиБ	4.81 ГиБ

В колонке large-v3 строки для батча 1 и 8 измерены на large-v2, остальные посчитаны по формуле. Вся колонка turbo — расчёт: замеров с батчем для turbo в README нет.

Практический вывод для планирования карты. На 24 ГБ large-v3 в fp16 доходит до батча 64 с запасом. Turbo при том же батче укладывается в 5 ГиБ, то есть влезает в карту на 8 ГБ. Разница между моделями по весам — 1.4 ГиБ, а по расходу на батче 64 — уже 13.4 ГиБ.

Не только Whisper: Parakeet, Canary, GigaAM

Whisper — не единственный вариант и на многих задачах не лучший. Три альтернативы с тем, что о памяти и скорости сказано в их карточках:

Модель	Параметры	Архитектура	Заявленный минимум памяти по карточке	RTFx
parakeet-tdt-0.6b-v3	600 M	FastConformer-TDT	от 2 ГБ	3332.74
canary-1b-v2	978 M	FastConformer + Transformer	от 6 ГБ	749
GigaAM-v3	220–240 M	Conformer, CTC и RNN-T	не указано	не указано
whisper-large-v3	1550 M	Transformer	4.42 ГиБ, замер	—

Про колонку с минимумом. В карточках NVIDIA формулировка дословно такая: «At least 2GB RAM for model to load» у Parakeet и «At least 6GB RAM for model to load» у Canary. Там сказано RAM, а не VRAM, и привязка к видеопамяти явно не сделана. Для Whisper в этой колонке стоит измеренное значение из README faster-whisper: собственная колонка «Required VRAM» в README openai/whisper даёт ~10 ГБ, и выше показано, что она завышена вдвое.

Глубину энкодера и декодера карточки указывают только для Canary: 32 слоя FastConformer-энкодера и 8 слоёв Transformer-декодера. У whisper-large-v3 — 32 и 32.

RTFx — во сколько раз обработка быстрее реального времени. Значения взяты из карточек NVIDIA со ссылкой на Open ASR Leaderboard, где прогон выполняется на серверном железе, а не на RTX 3070 Ti, с которой сняты замеры памяти в этой статье. Сравнивать колонку RTFx с колонкой памяти напрямую нельзя: это разные методики и разные карты. В карточке Whisper такой метрики нет, поэтому ячейка пустая. У Parakeet пропускная способность выше, чем у Canary, в 4.5 раза при том, что параметров в ней меньше в 1.6 раза.

Нижняя граница по весам

Карточки NeMo не дают разбивки расхода, но веса считаются так же, как для Whisper — число параметров на два байта:

Модель	Параметры	Веса в fp16
parakeet-tdt-0.6b-v3	600 M	1.12 ГиБ
canary-1b-v2	978 M	1.82 ГиБ
GigaAM-v3	224 M	0.42 ГиБ

Для GigaAM взято 224 M — столько параметров даёт файл весов на 449 МБ при двух байтах на параметр. Карточка указывает диапазон 220–240 M.

Это нижняя граница. Прибавлять к ней измеренные 1.5 ГиБ как готовое число нельзя: надстройка выведена для связки faster-whisper и CTranslate2, а NeMo работает поверх PyTorch, где размер пулов аллокатора и набор подгруженных ядер другие.

Формула цены потока сюда тоже не переносится. Она опирается на 1500 позиций выхода энкодера — фиксированную длину 30-секундного окна Whisper. У FastConformer с полным вниманием длина выхода растёт вместе с входом, поэтому расход зависит от длительности записи, а не только от батча. Разбор этой зависимости — ниже, в разделе про длинное аудио.

Русская речь: GigaAM

Файл весов на ветке main весит 449 МБ, что соответствует примерно 224 млн параметров в fp16 — в семь раз меньше, чем у large-v3. По данным карточки модели, средний WER на русском составляет 8.4% у варианта RNN-T и 9.2% у CTC против 25.1% у Whisper-large-v3.

Источник этих чисел стоит назвать точно. Это замер разработчика модели на его собственном наборе доменов, часть которых внутренние: callcenter, natural speech, disordered speech. Независимого русскоязычного лидерборда, сопоставимого с Open ASR Leaderboard, для этой пары моделей нет, так что перепроверить цифру сторонним прогоном не на чем.

Порядок разрыва при этом такой, что он меняет расчёт целиком. Если задача — русская речь, 449 МБ весов против 3.09 ГБ дают запас даже на карте 4 ГБ: надстройка того же порядка, что у Whisper, оставит около двух гигабайт свободными. Величина надстройки для NeMo и PyTorch отдельно не измерялась, поэтому это прикидка, а не расчёт. Whisper в такой постановке нужен, только когда язык заранее неизвестен.

Длинное аудио: где расчёт перестаёт работать

У Whisper память не зависит от длины файла. Метод transcribe() читает файл целиком и обрабатывает его скользящим окном по 30 секунд, выполняя предсказание на каждом окне отдельно. При одном и том же батче часовая запись и тридцатисекундная дают одинаковый пик — меняется только время обработки.

У моделей NeMo это не так. В карточке parakeet-tdt-0.6b-v3 указано: полное внимание держит аудио до 24 минут на A100 80GB, локальное внимание — до 3 часов. То есть память там растёт с длиной входа, и на карте меньшего объёма граница сдвигается вниз.

Практическое следствие: под длинные записи с Parakeet и Canary нужно либо включать локальное внимание, либо резать вход самому по VAD. Под Whisper резать не нужно — он режет сам.

Диаризация складывается с транскрипцией

Если в пайплайне есть разделение по говорящим, на карте одновременно живут два стека. В README whisperX для large-v2 с beam_size=5 заявлено потребление меньше 8 ГБ — это только транскрипция. Модели pyannote для сегментации и эмбеддингов добавляются сверху.

Порядок действий здесь важнее параметров. Если запускать диаризацию отдельным процессом после того, как транскрипция завершилась, пики двух стеков перестают складываться и становятся последовательными. На карте с 12 ГБ это разница между рабочим пайплайном и падением на середине файла.

Тот же приём работает и при выравнивании слов: модель выравнивания загружается после того, как основная выгружена. Если разносить процессы неудобно, снижайте batch_size — по расчёту выше каждый снятый поток large-v3 освобождает 224 МиБ.

Что оказалось неожиданным

Официальная колонка требований завышена вдвое. README openai/whisper заявляет ~10 ГБ для large. Четыре независимые реализации показывают от 4.03 до 4.84 ГиБ в fp16. Причина в README не документирована.

Квантование не уменьшает цену батча. Переход с fp16 на int8 экономит 1.45 ГиБ на весах и ровно ноль на масштабировании: 223.6 против 224.9 МиБ на поток. На больших батчах выигрыш от квантования размывается — при батче 64 это 1.45 ГиБ экономии против 14 ГиБ, которые занимает кеш.

Модель в семь раз меньше даёт втрое меньше ошибок. GigaAM-v3 на 220–240 млн параметров показывает на русском WER 8.4% против 25.1% у large-v3 на 1550 млн — по замеру разработчика на его собственных доменах. Размер модели не переносится между языками: Whisper тратит ёмкость на многоязычность, GigaAM — на один язык.

Обрезка декодера эффективнее квантования. У turbo декодер урезан с 32 слоёв до 4. Веса при этом упали в 1.9 раза, а расчётная цена потока — в 8 раз. При батче 32 turbo требует 3.89 ГиБ против 11.20 ГиБ у large-v3.

Какую карту брать

Выбор идёт от батча, а не от модели. Модель задаёт стартовое значение, батч определяет наклон.

Объём карты	Что помещается
8 ГБ	large в fp16 до батча 8 (5.95 ГиБ), turbo до батча 64 (4.81 ГиБ)
16 ГБ	large в fp16 до батча 32 (11.20 ГиБ) либо батч 16 вместе с диаризацией
24 ГБ	large до батча 64 (18.20 ГиБ) либо батч 32 плюс pyannote и модель выравнивания
48 ГБ и выше	несколько воркеров на одной карте либо длинное аудио на моделях NeMo

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

Отдельная развилка — считать ли вообще на арендованной карте. Если поток аудио небольшой, платный API обходится дешевле: расчёт точки перелома с ценами и RTF есть в гайде по запуску Whisper на GPU. Общая логика выбора карты по типу нагрузки разобрана в материале о подборе GPU под задачу.

Ограничения расчёта и открытые вопросы

Все измеренные значения происходят из одного источника — README faster-whisper — и сняты на одной карте. Независимой проверки на других поколениях в статье нет.

Расчёт цены потока учитывает только cross-attention KV-кеш. Self-attention кеш растёт с числом сгенерированных токенов и с шириной луча; на коротких сегментах по 30 секунд его вклад мал, но на длинных монологах он проявится.

Что осталось за рамками: поведение при beam_size=1, где кеш лучей не нужен вовсе; расход на Blackwell, где размер контекста CUDA другой; сборки под TensorRT, у которых память выделяется статически на этапе построения движка.

Частые вопросы

Как проверить эти числа у себя?

Запустите модель с нужным batch_size и снимите torch.cuda.max_memory_allocated() после обработки первого файла. Значение из nvidia-smi будет выше на размер зарезервированного пула — сравнивать нужно однородные величины. Для линейки Whisper применима та же логика, что и для KV-кеша у языковых моделей: считается не то, что загружено, а то, что живёт одновременно.

Подходит ли расчёт для vLLM и TensorRT?

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

Сколько нужно для файн-тюнинга Whisper?

Существенно больше: к весам добавляются градиенты, состояния оптимизатора и активации. Порядок величины и формулы приведены в справочнике по VRAM для обучения.

Что выбрать для русской речи при ограниченной памяти?

GigaAM-v3: 449 МБ весов и WER 8.4% против 25.1% у large-v3 — по замеру разработчика модели, независимой проверки на русском для этой пары нет. Whisper остаётся оправданным, когда язык записи заранее неизвестен или нужна работа с редкими языками.

Как ссылаться на эти расчёты?

YouGPU Team, «Сколько VRAM нужно для Whisper и других ASR-моделей», блог YouGPU, 30 августа 2026 года. Исходные измерения принадлежат проекту faster-whisper, геометрия моделей — карточкам на Hugging Face.

Приложение: сводная таблица

Значения в fp16. Итоговые колонки посчитаны как веса плюс надстройка 1.5 ГиБ плюс кеш на дополнительные потоки, из неокруглённых слагаемых — поэтому последний знак может не сойтись при сложении округлённых значений из соседних колонок.

Модель	Веса	KV на поток	Итого, batch 1	Итого, batch 16
tiny	0.07 ГиБ	8.8 МиБ	1.57 ГиБ	1.70 ГиБ
base	0.14 ГиБ	17.6 МиБ	1.64 ГиБ	1.90 ГиБ
small	0.45 ГиБ	52.7 МиБ	1.95 ГиБ	2.73 ГиБ
medium	1.43 ГиБ	140.6 МиБ	2.93 ГиБ	4.99 ГиБ
large-v3	2.89 ГиБ	234.4 МиБ	4.42 ГиБ	7.70 ГиБ
large-v3-turbo	1.51 ГиБ	29.3 МиБ	3.01 ГиБ	3.44 ГиБ
distil-large-v3.5	1.41 ГиБ	14.7 МиБ	2.91 ГиБ	3.12 ГиБ

Строка large-v3 — исключение из этого правила: в ней стоит замер 4.42 ГиБ при батче 1 и замеренная цена потока 224 МиБ, а не расчётные 4.39 и 234.4 МиБ. Так она сходится с таблицей по батчам выше. По чистому расчёту та же строка дала бы 4.39 и 7.85 ГиБ.

Источники: README openai/whisper для параметров, config.json в репозиториях openai/whisper-large-v3, openai/whisper-large-v3-turbo и distil-whisper/distil-large-v3.5 для геометрии, бенчмарк faster-whisper для замеров. Все данные сняты 30 августа 2026 года.