Потребление VRAM библиотеками TTS: почему растут требования

Оно напрямую определяет, какой пользовательский флоу вообще получится построить: быстрая озвучка коротких реплик на рабочем ПК, пакетный рендер подкаста, интерактивный голосовой агент или zero-shot клонирование с несколькими референсами.

Разрыв между моделями уже измеряется не процентами. Kokoro-82M может работать на GPU с 2 ГБ видеопамяти, а для Fish Speech S2, Higgs-TTS и сопоставимых систем комфортный продакшен начинается в диапазоне 24 ГБ. Причина не сводится к «модели стали больше». В TTS растут длина контекста, число токенов на секунду аудио, объём KV-кэша, количество стадий конвейера и требования к параллельной обработке запросов.

Для разработчика это меняет приоритеты. Выбирать движок только по демонстрации голоса или benchmark качества — плохая продуктовая логика. Модель должна укладываться в заданные latency, concurrency и стоимость одного успешного ответа. Иначе качественный голос станет дорогим edge-кейсом, который сервис не может стабильно отдать пользователю.

Архитектурный сдвиг: аудио генерируется не как текст

Ранние представления о TTS часто строятся по аналогии с текстовой генерацией: есть текст на входе, есть аудиофайл на выходе, значит нагрузка примерно предсказуема по размеру модели. На практике аудио — существенно более плотный поток данных.

Текстовая фраза «Ваш заказ передан курьеру» содержит несколько токенов. После преобразования в акустическое представление она может превращаться в сотни или тысячи аудиотокенов — в зависимости от кодека, частоты дискретизации, длительности и внутренней архитектуры. Модель должна не только предсказать содержание, но и удержать темп, паузы, интонационный контур, тембр, эмоциональные маркеры и параметры референсного голоса.

Авторегрессионные TTS-системы — например, Bark, XTTS, ChatTTS — создают аудиотокены последовательно. Очередной шаг зависит от уже сгенерированной последовательности. Для этого в видеопамяти сохраняется KV-кэш: промежуточные ключи и значения attention-механизма, нужные трансформеру для обращения к предыдущему контексту.

По мере роста последовательности растёт и этот кэш. В текстовом ассистенте это уже известный источник расходов VRAM. В синтезе речи эффект сильнее заметен, потому что акустическая последовательность длиннее текстовой на порядки.

Условно память при инференсе складывается из четырёх частей:

• весов модели;
• KV-кэша и другого состояния генерации;
• временных тензоров, используемых на этапах расчёта;
• инфраструктурных расходов рантайма: CUDA-контекста, аллокаторов, буферов и памяти фреймворка.

Размер весов — самая понятная часть расчёта. Но именно она часто вводит команду в заблуждение. Модель, которая занимает несколько гигабайт в BF16, не обязана запускаться на GPU с тем же объёмом VRAM. Для реального запроса нужны рабочие буферы, кэш, запас под пиковую нагрузку и память для соседних процессов.

В TTS дефицит VRAM проявляется не в момент загрузки весов, а в момент, когда сервис получает длинный текст, референс голоса и второй запрос одновременно.

Это особенно заметно в продуктах, где пользователь не ограничен короткой репликой. В демо можно синтезировать одну фразу и получить приемлемый RTF. В продакшене приходят абзацы, списки, номера заказов, смешанные языки, нестандартные имена, паузы SSML и параллельные задачи очереди. Каждый такой сценарий увеличивает вероятность OOM или деградации latency.

Почему авторегрессия съедает запас видеопамяти

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

Упрощённо флоу выглядит так:

1. Текст проходит нормализацию и токенизацию. Здесь определяются даты, валюты, сокращения, числа, ударения и языковые переключения.

2. Модель формирует семантические или акустические токены с учётом текста, инструкции и референсного аудио.

3. На каждом шаге авторегрессионный блок обращается к ранее накопленному контексту через KV-кэш.

4. Аудиокодек или вокодер превращает токены в waveform.

5. Сервис собирает сегменты, проверяет длительность, нормализует громкость и возвращает аудио клиенту.

Проблема в том, что память на шаге 3 не является константой. Длиннее реплика — длиннее последовательность. Длиннее контекст или голосовой промпт — больше данных приходится удерживать. Выше параллелизм — больше отдельных последовательностей в памяти.

ChatTTS хорошо показывает этот порог. Для генерации 30-секундного клипа требуется минимум 4 ГБ VRAM. На RTX 4090 модель способна работать с RTF около 0,3: то есть генерировать аудио заметно быстрее его длительности. Но RTF одного тестового запроса не равен пропускной способности сервиса. Если на той же карте держать несколько одновременных сессий, добавлять очереди, логи, GPU-метрики и обработку аудио, запас быстро сокращается.

Для голосового интерфейса это критично. Пользователь не оценивает модель по среднему времени ответа на стенде. Он замечает p95 и p99 latency: задержку в тех сессиях, где запрос попал на длинную реплику, редкий голос, неудачную сегментацию или перегруженный GPU.

Авторегрессия также усложняет стриминг. Технически сервис может отдавать аудио частями, не дожидаясь полного файла. Но для полезного диалогового флоу недостаточно «начать что-то воспроизводить». Нужны стабильный first-audio latency, отсутствие резких стыков между чанками, корректная интонация на границе сегментов и управляемая отмена ответа при barge-in, когда пользователь перебивает ассистента.

Поэтому требования к видеопамяти для локального TTS стоит считать не от формулировки «модель запускается», а от целевого поведения продукта:

Нельзя автоматически считать, что авторегрессионная модель качественнее неавторегрессионной при том же бюджете VRAM. Это разные архитектурные компромиссы. Для части задач скорость, предсказуемость и возможность запустить inference на 2–4 ГБ памяти важнее максимального разнообразия просодии.

Многоэтапный TTS-конвейер: память теряется между компонентами

Современная модель синтеза редко является одним монолитным блоком. Типовой стек разделяет понимание текста, планирование речи, генерацию дискретных аудиопредставлений и декодирование в звук. С точки зрения качества это рациональная декомпозиция. С точки зрения инфраструктуры — новый источник расходов.

Показательный случай — Qwen3-TTS. В его конвейере разделены компоненты Talker и Code2Wav. Такая схема позволяет отдельно работать с речевым содержанием и преобразованием кодов в аудио. Однако при развёртывании частей через независимые движки vLLM появляется неприятная побочная стоимость: каждый процесс поднимает собственный CUDA-контекст, собственные пулы памяти и собственный KV-кэш.

Для версии 0.6B это может приводить к пиковому потреблению до 22 ГБ VRAM. Сам размер модели здесь не объясняет итоговую цифру. Узкое место создаёт способ упаковки сервиса.

Это типичная ловушка команды, которая смотрит только на model card. На бумаге модель лёгкая. В Docker-образе — два процесса. В Kubernetes — отдельные health-check, sidecar для метрик, проксирование. В результате GPU, рассчитанный на несколько воркеров, выдерживает один нестабильный pipeline.

Перед выбором рантайма полезно разобрать не модель, а карту владения памятью:

• какие компоненты действительно обязаны жить на GPU постоянно;
• можно ли разместить этапы в одном процессе и разделить CUDA-контекст;
• нужен ли vLLM именно для этой части TTS-конвейера, или его преимущества по батчингу не компенсируют overhead;
• что происходит с памятью после длинного запроса: возвращается ли она в пул, фрагментируется ли, остаются ли кэши;
• как ведёт себя сервис при отмене генерации и повторной попытке;
• что происходит, если несколько голосов используют разные адаптеры или референсы.

В логах такие проблемы редко выглядят как «архитектурная ошибка». Обычно команда видит скачки CUDA out of memory, падение воркера после серии длинных текстов или непредсказуемое увеличение latency. Корень находится выше: в решении запустить независимые этапы как независимые GPU-сервисы без общего бюджета памяти.

VRAM — это ресурс всего inference-флоу, а не характеристика файла с весами.

Здесь особенно полезна нагрузочная модель, близкая к продуктовой, а не к ML-демо. Не «синтезируйте один абзац десять раз», а соберите распределение реальных запросов: длина текста, среднее число символов, язык, доля voice cloning, частота отмен, пиковая одновременность. После этого измеряйте p50, p95 и p99 по latency, RTF, ошибкам и занятой VRAM.

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

От 160 МБ до 24 ГБ: реальный диапазон локальных моделей

Рынок локального TTS нельзя описывать одной рекомендацией по GPU. На нижней границе есть модели для компактных флоу. На верхней — системы, рассчитанные на богатое управление голосом, сложное клонирование и тяжёлый inference.

Kokoro-82M — важный контрпример тезису «качественный локальный синтез требует топовой видеокарты». В FP16 веса занимают около 400 МБ VRAM, в INT8 — примерно 250 МБ, в INT4 — около 160 МБ. Практический порог запуска — GPU с 2 ГБ. Это не означает, что 2 ГБ подходят для любого сервиса на базе Kokoro: остаются системные расходы и ограничения по параллелизму. Но для desktop-инструмента, локальной озвучки интерфейса или одиночной очереди этого класса достаточно.

F5-TTS представляет другой компромисс. Архитектура Flow Matching не строит аудио строго токен за токеном в том же профиле, что AR-подходы. Для базовой версии ориентир составляет около 2 ГБ VRAM, а квантованный вариант способен работать примерно на 400 МБ. Это делает модель полезной, когда ключевая метрика — доступность на массовом железе, а не максимальная вариативность генерации.

На другом полюсе находятся Higgs-TTS и Fish Speech S2. Для Higgs-TTS с объёмом порядка 5 млрд параметров в BF16 требуется не менее 16 ГБ VRAM для базового синтеза. Для zero-shot клонирования голоса более реалистичен бюджет 24 ГБ. Fish Speech S2, выпущенная в марте 2026 года и содержащая 4,4 млрд параметров, использует двухэтапный авторегрессионный дизайн Slow AR + Fast AR. Минимум для запуска — 12 ГБ, но продакшен-развёртывание также тяготеет к 24 ГБ.

Слово «минимум» здесь требует дисциплины. Минимальные требования обычно означают, что разработчик сможет воспроизвести базовый inference в контролируемом окружении. Они не гарантируют нужный throughput, стабильный пиковый latency, несколько одновременных запросов и работу соседних процессов на той же карте.

Квантование помогает, но не отменяет профиль нагрузки

Квантование — наиболее прямой способ уменьшить давление весов на VRAM. При переходе от FP16 к INT8 и INT4 каждый параметр занимает меньше памяти. Для небольших моделей эффект особенно заметен: Kokoro-82M уменьшается примерно с 400 МБ в FP16 до 250 МБ в INT8 и 160 МБ в INT4.

Но продуктовая ошибка — считать, что коэффициент экономии весов полностью переносится на сервис. Не переносится.

Квантование снижает только часть общего memory footprint. KV-кэш, временные тензоры, буферы декодера и CUDA-overhead никуда не исчезают автоматически. Для AR-модели с длинной последовательностью может оказаться, что после квантования весов главным потребителем всё равно остаётся кэш. Для многоэтапного пайплайна экономия в одном компоненте не устранит дублирование рантаймов.

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

Для голосового продукта такой набор обычно включает:

1. Короткие транзакционные реплики: статусы заказа, напоминания, OTP, суммы, даты.

2. Длинные объяснения: инструкции, ответы поддержки, обучающие фрагменты.

3. Сложную нормализацию: артикулы, номера рейсов, адреса, валюты, проценты.

4. Смешанную языковую речь и заимствования.

5. Тексты с управляемыми паузами и перечислениями.

6. Референсные голоса разной длительности — если есть клонирование.

7. Повторный запуск на одном и том же инпуте для оценки стабильности.

В этом тесте стоит фиксировать не только MOS-подобную субъективную оценку, но и технические метрики: peak VRAM, first-audio latency, полный RTF, долю ошибок, длительность пауз, число перегенераций. Перегенерация — часто недооценённая статья расходов. Если квантизованная конфигурация звучит чуть хуже и редактор чаще нажимает «создать заново», экономия GPU становится номинальной.

Динамическое управление памятью — второй рабочий рычаг. В режиме Low VRAM, используемом, например, в интеграциях AllTalk TTS на базе Coqui, модель выгружается в системную RAM и переносится в VRAM только на время генерации. Постоянное потребление видеопамяти падает, но к каждому запуску добавляется порядка 1–2 секунд задержки.

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

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

• interactive mode — модель резидентно находится в VRAM, ограничен concurrency, приоритет у first-audio latency;
• batch mode — допускается выгрузка, агрессивное квантование, очередь и более высокий RTF;
• studio mode — приоритет у качества и управляемости, а не у экономии памяти;
• fallback mode — при дефиците GPU сервис переключается на более лёгкую модель или ограничивает длину текста.

Такое разделение повышает retention лучше, чем попытка обслуживать все интенты одной тяжёлой моделью. Пользователь не должен ждать zero-shot pipeline там, где ему нужен голосовой статус доставки из одной строки.

Контекст, аудиокодеки и скрытая цена длинных запросов

Вопрос «сколько VRAM нужно для генерации речи на ПК» не имеет корректного ответа без параметра длины. Длительность текста меняет не только время рендера, но и профиль памяти. Для AR-моделей это связано с KV-кэшем. Для других архитектур — с размером промежуточных представлений, параметрами батча и устройством кодека.

Аудиокодек переводит waveform в дискретное или непрерывное представление, с которым работает генеративная часть модели. Чем выше временное разрешение и чем больше потоков кодирования используется, тем больше токенов приходится обработать на секунду звука. Сравнивать модели только по числу параметров поэтому недостаточно: разные кодеки и разные способы декодирования создают разный расход памяти на одинаковую минуту аудио.

Точное влияние конкретных кодеков — например, DAC и EnCodec — на VRAM зависит от реализации библиотеки, параметров контекста и режима inference. Универсальную цифру здесь выводить некорректно. Но инженерное следствие ясное: измерять нужно на тех настройках sample rate, codec bandwidth и длины референса, которые попадут в продукт.

Длинный контекст в TTS нужен не всегда. Он оправдан, если модель должна сохранять единый стиль в большом фрагменте, продолжать голос из референса, учитывать инструкцию или поддерживать консистентность повествования. Но для многих диалоговых сценариев длинный контекст — технический долг, а не пользовательская ценность.

В голосовом помощнике лучше работает иной флоу:

• NLU или LLM формирует короткий ответ, достаточный для закрытия интента.
• TTS получает уже нормализованный текст без служебных конструкций.
• Длинные ответы делятся на смысловые блоки до синтеза.
• Первый блок отправляется в генерацию сразу, последующие — с контролируемым prefetch.
• При barge-in дальнейшая генерация отменяется и память освобождается.
• Логи связывают текст, параметры голоса, длительность, VRAM-пик и итоговую пользовательскую реакцию.

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

Как выбирать бюджет VRAM под задачу, а не под маркетинг модели

Практическое решение начинается с формулировки SLA. Нужны не абстрактные «локальный TTS» и «качественный голос», а измеримые ограничения: сколько одновременно запросов должен выдержать сервис, какова максимальная длина реплики, допустим ли прогрев модели, нужен ли cloning, какой p95 first-audio latency приемлем.

Для простой локальной озвучки нет смысла закладывать 24 ГБ «на будущее». Kokoro-82M или квантованный F5-TTS позволяют закрыть значительную часть задач на 2 ГБ VRAM и ниже по фактической нагрузке весов. Это разумный выбор для прототипа, desktop-утилиты, озвучки коротких интерфейсных текстов и ограниченных очередей.

Диапазон 4–8 ГБ выглядит рабочим для более серьёзного локального использования: ChatTTS, Qwen3-TTS 1.7B и аналогичные конфигурации. Но здесь уже нужен нагрузочный тест с целевой длиной аудио и конкурентностью. Карта на 8 ГБ может быть достаточной для одного качественного воркера и оказаться недостаточной для двух параллельных сессий с длинным контекстом.

GPU с 12–16 ГБ открывает тяжёлые AR-модели и расширяет пространство экспериментов. Однако для zero-shot клонирования, многокомпонентных пайплайнов и предсказуемого продакшен-поведении чаще нужен запас в 24 ГБ. Не потому, что меньшие карты «некачественные», а потому, что у сервиса должен оставаться ресурс на пики, перегенерации и реальную очередь.

Итоговая логика проста. Рост требований TTS к видеопамяти создают не только большие веса. Его формируют авторегрессионный KV-кэш, длинные аудиопоследовательности, голосовые промпты, многоэтапные архитектуры и неэффективное разделение компонентов на независимые GPU-процессы.

Выигрывает не команда с самой тяжёлой моделью, а команда, у которой модель соответствует пользовательскому интенту, а VRAM-бюджет рассчитан по реальному флоу. Для одних продуктов это 2 ГБ и быстрый синтез. Для других — 24 ГБ и устойчивое клонирование. Между этими точками нет универсальной конфигурации, но есть измеряемая инженерная задача.