Подобряване на скоростта и цената при Qwen3-TTS: Оптимизациите на Nari Labs

Публикувано от Svetni.me Editorial на 22 август 2026 г.

Подобряване на скоростта и цената при Qwen3-TTS
Изображение: Svetni.me / ИИ генерирано изображение

В публикация на корпоративния си блог [1], Nari Labs споделя детайли за своите инфраструктурни оптимизации при обслужването на модела Qwen3-TTS (конкретно версията 1.7B CustomVoice, базирана на Qwen3). Постигнатите резултати демонстрират 10 заявки в секунда (RPS) с 95-ти персентил (p95) време до първото звучене (TTFA) под 50 милисекунди на един единствен NVIDIA H100 SXM графичен ускорител, като същевременно се запазва непрекъснатостта на аудио потока в реално време [1].

Системата постига производителност от приблизително 630 символа в секунда при 10 RPS. Това се равнява на около $2 за 1 милион символа при пълно натоварване, използвайки инстанция с H100 (при цена от $4.29 на час).

Инфографика на оптимизациите при Qwen3-TTS
Изображение: Svetni.me / ИИ генерирана инфографика

Бенчмаркинг и съществуващи решения

Екипът на Nari Labs сравнява своето решение с четири други популярни енджина за обслужване на модели: vLLM-Omni, SGLang-Omni, VoxServe и M*. Тестовете са проведени в продължение на пет минути с Poisson разпределение на заявките, симулирайки реално натоварване. Оценката на генерираното аудио се извършва с помощта на Speech-to-Text системата на Deepgram.

Резултатите показват, че стандартните конфигурации на повечето енджини имат значително поле за подобрение. Например, vLLM-Omni и VoxServe показват първоначален p95 TTFA съответно 277.883 ms и 315.064 ms при 1 RPS. Дори след допълнителни настройки на размера на блоковете от аудио рамки (frame accumulation tuning), само VoxServe и решението на Nari Labs успяват да паднат под 50 ms при 1 RPS. При натоварване от 6 RPS обаче, всички конкурентни решения надвишават 100 ms p95 TTFA, докато Nari Labs запазва стабилност и ниска латентност [1].

Архитектурни оптимизации

Архитектурата на Qwen3-TTS е съставена от три основни модула за йерархично генериране на кодбук токени:

  1. Talker: Предвижда първия токен за всеки аудио кадър.
  2. Code Predictor: Генерира останалите 15 токена за кодбука.
  3. Codec (Кодек): Преобразува токените във вълнови форми (waveform samples).

Вместо да оптимизира всеки модул поотделно, Nari Labs променя фундаментално начина на тяхното координиране.

1. Премахване на водещата тишина (Leading Silence Trimming)

Първоначално генерираният PCM поток често съдържа десетки милисекунди тишина преди същинската реч. Добавено е динамично изрязване, което анализира кратки RMS времеви прозорци за засичане на началото на речта. Тази стъпка сама по себе си подобрява TTFA с около 80 ms, макар да не ускорява самата инференция на модела [1].

2. Унифициран планировчик (Unified Scheduler)

Повечето съществуващи имплементации обединяват Talker и Code Predictor в една неделима задача, докато Кодекът се изпълнява отделно. Инженерите от Nari Labs разделят всички три модула в независими задачи и ги поставят под контрола на един унифициран планировчик (unified scheduler), концепция, вдъхновена от енджина M*.

Тази декомпозиция позволява на планировчика гъвкаво да пренарежда задачите според тяхната спешност. Използва се приоритетна политика: заявките, които все още не са започнали възпроизвеждане на аудио, получават висок приоритет (за минимизиране на TTFA). Вече започналите потоци стават спешни само когато наближат крайния срок за възпроизвеждане на следващия фрагмент (deadline), предотвратявайки прекъсвания (underruns).

3. Предварително заделяне в CUDA Graph

Code Predictor-ът е авторегресивен трансформър, който изпълнява фиксиран брой стъпки (15) за всеки кадър. Тази регулярна структура е използвана за предварително заделяне на KV кеша и обхващане на целия цикъл на генериране като единен CUDA Graph. В допълнение е имплементирано специализирано Triton ядро за внимание (attention kernel), оптимизирано за краткия, ограничен контекст на модула.

4. Инкрементално декодиране с кеширане на състоянието

Кодекът на Qwen3-TTS е базиран на Transformers и CNN (конволюционни невронни мрежи). Наивният подход изисква повторна обработка на цялата история на кадрите при всяко обновяване, което е неефективно. Nari Labs внедрява Кодек, базиран на кеш на състоянието. Всяка заявка запазва контекста на трансформъра и конволюционното състояние. Инкременталното декодиране използва повторно този кеш и обработва само новопристигналите кадри, избягвайки повторното възпроизвеждане на пълната история.

За да се запази нисък първоначалният TTFA, първият аудио фрагмент се генерира чрез пълно декодиране, след което системата превключва към кеширано инкрементално декодиране. Размерът на фрагментите (chunk size) се увеличава динамично по време на сесията, за да се подобри ефикасността на групирането (batching) и натоварването на графичния процесор.

5. Избягване на CPU-GPU синхронизации

Управлението на партиди е допълнително оптимизирано чрез кеширани CUDA графики за предефинирани размери. Също така се избягва ненужната синхронизация между централния (CPU) и графичния (GPU) процесор. Например, проверката за край на генерацията (EOS token) се отлага до момента, в който модулът реално позволява приключване, освобождавайки CPU-то да подготвя следващи задачи без изчакване. Решението поддържа и поточен вход (input streaming) за по-ранно стартиране на синтеза.

С тези промени, Nari Labs демонстрира значителен напредък в мащабирането и ефективността на TTS системите от следващо поколение.

Източници:

[1]: Pushing the Speed-Cost Frontier for Qwen3-TTS - Nari Labs