Команда Nari Labs 19 серпня 2026 року опублікувала технічний розбір того, як вони довели time-to-first-audio (TTFA) своєї моделі Qwen3-TTS 1.7B CustomVoice до позначки нижче 50 мілісекунд на 95-му перцентилі — і водночас утримали собівартість генерації на рівні приблизно $2 за мільйон символів при повному завантаженні одного NVIDIA H100 SXM. Для порівняння: це на порядок дешевше за комерційні API на кшталт ElevenLabs V3 ($100 за мільйон символів) чи Cartesia Sonic 3.5 ($49 за мільйон символів).

Питання, яке варто поставити відразу: чому 50 мілісекунд — це поріг, за який інженерній команді варто битися, а не просто ефектний рядок у блозі? Відповідь проста і водночас незручна для більшості голосових продуктів на ринку: людина починає відчувати затримку в розмові вже за лічені сотні мілісекунд, а сучасний голосовий агент — це ланцюжок з розпізнавання мовлення, мовної моделі й синтезу мовлення, де кожна ланка додає свою частку до загальної затримки. Якщо TTS сама по собі "з'їдає" 300-500 мс до першого звуку, весь агент відчувається як розмова через супутниковий канал зв'язку.

Саме тому кейс Nari Labs цікавий не як черговий рекорд у таблиці бенчмарків, а як приклад того, куди рухається інженерія голосових інтерфейсів: від логіки "згенеруй файл і віддай" до архітектур, які поводяться як стрімінгові системи реального часу — побудовані радше за принципами мережевих проксі й планувальників задач, ніж класичних ML-пайплайнів пакетної обробки.

За даними HackerNews, публікація Nari Labs — команди, що раніше випустила модель Dia з понад 2 мільйонами завантажень і складається з інженерів із досвідом у YC, KRAFTON та NAVER, — потрапила в топ обговорень серед розробників голосових агентів. Це другий великий технічний матеріал команди, у якому фокус зміщено з "якості голосу" на інженерію обслуговування моделі: як узяти вже готову TTS-модель і вичавити з неї латентність, яка донедавна вважалася недосяжною для трансформерних архітектур синтезу мовлення.

Звідки взялася вимога синтезувати мовлення швидше, ніж реагує людина?

Ще кілька років тому TTS проєктувався як offline-задача: текст на вході, повний аудіофайл на виході, і секунда-дві затримки нікого особливо не турбували — озвучені аудіокниги чи подкасти не вимагають миттєвої реакції. Ситуація змінилася з масовим виходом голосових агентів: систем, які ведуть діалог у реальному часі — підтримка клієнтів, AI-компаньйони, голосові асистенти в застосунках. У цьому режимі TTS перестає бути кінцевою точкою і стає ланкою в ланцюжку "розпізнавання мовлення → мовна модель → синтез мовлення", де кожна мілісекунда затримки додається до загальної.

Дослідники розмовної лінгвістики оцінюють середню паузу між репліками співрозмовників у живому діалозі приблизно в 200 мілісекунд — і це орієнтир, з яким фактично змагаються розробники голосових агентів. Якщо асистент відповідає через секунду чи дві після того, як людина замовкла, розмова вже не відчувається природною: користувач починає повторювати питання, перебивати паузу або просто дратується. Тому вимога до TTS у 2026 році — не "згенеруй якісний голос", а "почни говорити раніше, ніж людина встигне подумати, що система зависла".

Проблема в тому, що більшість TTS-архітектур на основі трансформерів історично оптимізували під пропускну здатність (throughput) — скільки символів на секунду система обробляє в батчі, — а не під затримку до першого фрагмента аудіо (time-to-first-audio). Це два різні, часто конфліктні критерії: батчінг заради throughput означає, що запит чекає в черзі, поки набереться достатньо роботи для ефективного завантаження GPU, а це прямо суперечить вимозі віддати перший фрагмент звуку за лічені мілісекунди.

Де тут опинилися конкуренти

Саме в цій точці конфлікту між throughput і TTFA й розгортається вся інженерна робота, описана Nari Labs. Команда зіткнулася з тим, що serving-фреймворки для мультимодальних і аудіомоделей — vLLM-Omni, SGLang-Omni та подібні — успадкували логіку батчінгу з текстових LLM, де черга запитів і накопичення батчу є нормою, а не проблемою, яку варто вирішувати окремо.

Як саме Nari Labs домоглася затримки менше 50 мс під капотом?

Ключове архітектурне рішення — розбити генерацію мовлення на три незалежні модулі, які в багатьох попередніх пайплайнах виконувалися як один монолітний прохід уперед: Talker (генерує семантичні токени), Code Predictor (передбачає токени аудіокодека, 15 кроків на кожен фрейм) і Codec (декодує токени у звукову хвилю). У реалізації Nari Labs ці три компоненти працюють як окремі задачі під одним планувальником, а не як послідовні стадії одного forward-pass. Це відкриває простір для адаптивного планування: планувальник може пропустити вперед перший чанк аудіо нового запиту, навіть якщо в системі вже є черга інших задач, і лише потім повернутися до батчінгу решти заради ефективності.

Друге рішення — прибрати паузу-тишу на початку згенерованого аудіо, яку модель за замовчуванням вставляла перед першим звуком. Саме собою це дало приблизно 80 мілісекунд виграшу — деталь невелика, але показова: значна частина "затримки" TTS історично була не обчислювальною, а артефактом того, як модель навчили генерувати мовлення.

Третє — CUDA-графи для Code Predictor у поєднанні з Triton-ядрами уваги (attention kernels). Оскільки Code Predictor завжди виконує фіксовану кількість кроків із передбачуваною формою обчислень, його можна "заморозити" в єдиний CUDA-граф і виконувати без накладних витрат на запуск окремих GPU-ядер із Python — це заощаджує мілісекунди, які інакше йдуть на оверхед планування операцій, а не на самі обчислення.

Четверте — кешування стану Codec-модуля між чанками: трансформерний контекст і згорткові (convolutional) стани зберігаються так само, як KV-кеш у великих мовних моделях, тож кодек не перераховує все з нуля для кожного нового шматка аудіо. П'яте — адаптивне розбиття на чанки: маленькі чанки на початку відповіді для мінімальної TTFA, більші — далі за потоком, де вже вигідніше пакетувати обчислення заради throughput. У сукупності це дає систему, де перший фрагмент голосу летить до користувача майже миттєво, а решта відповіді генерується вже в економнішому пакетному режимі.

Чим підхід Nari Labs відрізняється від vLLM-Omni, SGLang-Omni чи комерційних TTS-провайдерів?

За опублікованими бенчмарками, за навантаження в 1 запит на секунду (RPS) конкуруючі serving-рушії показують такий p95 TTFA: vLLM-Omni — 56,8 мс, VoxServe — 49,3 мс, SGLang-Omni — 120,9 мс, M* — 104 мс. Рішення Nari Labs тримається нижче 50 мс уже на цьому рівні навантаження — тобто приблизно на рівні найкращого з конкурентів (VoxServe), а не проривом у рази.

Різниця стає помітною під навантаженням: коли RPS зростає до 6 запитів на секунду, конкуруючі рушії деградують до 100+ мілісекунд p95 TTFA, тоді як система Nari Labs залишається нижче 50 мс. У цьому й полягає практичний сенс усієї архітектурної роботи з плануванням: будь-який рушій може показати гарну цифру на порожній черзі, але саме production-навантаження — момент, де конфлікт між throughput і TTFA проявляється найгостріше. Заявлена пропускна здатність системи — 10 запитів на секунду при 630 символах на секунду.

З комерційними TTS-провайдерами порівняння інше — не за швидкістю, а за вартістю. ElevenLabs V3 коштує $100 за мільйон символів, Cartesia Sonic 3.5 — $49 за мільйон символів, тоді як self-hosted розгортання Qwen3-TTS на H100 SXM за розрахунками Nari Labs виходить приблизно у $2 за мільйон символів — у 25-50 разів дешевше. Але це порівняння вартості лише інференсу на орендованому GPU, без урахування витрат на DevOps, моніторинг, резервування потужностей і інженерні години, які комерційний API вже включає у свою ціну.

Що це дає тим, хто зараз будує голосові агенти?

Найпряміший висновок для практиків: модель Qwen3-TTS і сам serving-шар — відкритий код, викладений у репозиторіях nari-labs/nari-qwen3-tts та nari-labs/benchmarks, тож наведені цифри можна самостійно відтворити, а не приймати на віру. Для команд, що вже мають доступ до H100-інфраструктури (власної чи орендованої), це реальна альтернатива підписці на комерційний TTS-API.

Практичний кейс №1 — голосові агенти підтримки клієнтів. У call-центрі, де AI-агент має підхопити репліку клієнта без незручної паузи, різниця між 300 мс і 50 мс TTFA — це різниця між "розмовляю з ботом, який гальмує" і "розмовляю з кимось, хто відповідає одразу". При обсягах у тисячі одночасних дзвінків собівартість $2 замість $49-100 за мільйон символів стає вирішальним фактором економіки продукту.

Практичний кейс №2 — синхронний переклад і дубляж у реальному часі. Стрімінгова генерація з маленькими початковими чанками дозволяє починати озвучення перекладеної репліки майже одночасно з тим, як перекладач чи LLM-перекладач видає перші слова, замість очікування повного речення.

Практичний кейс №3 — ігрові NPC та AI-компаньйони, де відповідь персонажа має відчуватися як репліка живого співрозмовника, а не як завантаження аудіофайлу. Тут прийом з адаптивними чанками — маленький перший чанк, потім більші — особливо доречний: гравець чує початок фрази миттєво, поки система домовляє решту обчислень у фоні.

Що може піти не так у цій картині швидкості й дешевизни?

Найочевидніша обмеженість — бенчмарки Nari Labs виміряні на власній інфраструктурі й за власними умовами тестування; це не незалежний третьосторонній замір. Планувальник, налаштований під конкретну модель на 1,7 млрд параметрів і конкретне залізо (H100 SXM), може показувати гірші результати на іншому GPU, іншому розмірі моделі чи іншому паттерні навантаження, ніж синтетичні RPS-тести з блогу.

Другий момент — розмір моделі. Qwen3-TTS 1.7B CustomVoice — компактна модель порівняно з тим, що можуть використовувати комерційні провайдери на кшталт ElevenLabs чи Cartesia у своїх пропрієтарних стеках. Швидкість і дешевизна тут можуть означати компроміс із якістю просодії, емоційності голосу чи стабільності на довгих і складних текстах. Команда Nari Labs заявляє, що перевіряла регресію якості, пропускаючи згенероване аудіо через Deepgram STT і звіряючи розпізнаний текст із вихідним, — але це перевірка розбірливості мовлення, а не суб'єктивної природності чи емоційного забарвлення голосу, і незалежного сліпого тестування якості звучання в матеріалі немає.

Третє — TTS часто не є вузьким місцем усього голосового агента. Якщо розпізнавання мовлення (ASR) і мовна модель, яка формує відповідь, разом додають 400-600 мс затримки, економія 50-100 мс на етапі синтезу хоч і корисна, але сама по собі не розв'язує проблему "розмова відчувається повільною". Розробникам варто міряти латентність усього ланцюжка, а не окремо взятого компонента.

Четверте — розрахунок вартості $2 за мільйон символів передбачає повне завантаження одного H100 SXM, тобто GPU працює на 10 RPS практично без простою. У реальному продукті з нерівномірним навантаженням — пікові години, нічні провали трафіку — фактична собівартість символу буде вищою, бо простій GPU теж коштує грошей. Самостійний хостинг також перекладає на команду весь тягар оновлень, масштабування та надійності, який комерційний API бере на себе за визначенням.

Головний практичний висновок цього кейса не в цифрі "менше 50 мс" самій по собі, а в тому, що конфлікт між throughput і TTFA розв'язний архітектурно — через розкладання пайплайну на незалежно керовані задачі під одним планувальником, а не лише через грубу силу заліза.

Висновок AiiN

Технічна робота Nari Labs важлива не тому, що встановлює новий рекорд TTFA — за їхніми ж таблицями, VoxServe вже показував порівнянну цифру в 49,3 мс за низького навантаження. Важливо те, що команда публічно задокументувала, як проектувати serving-шар для стрімінгового аудіо: розділення генерації на незалежно керовані задачі під одним планувальником, адаптивне пріоритезування першого чанка, кешування стану кодека між чанками. Це набір інженерних прийомів, які, найімовірніше, стануть де-факто стандартом для serving-фреймворків мультимодальних моделей — так само, як continuous batching і PagedAttention свого часу стали стандартом для serving текстових LLM.

На горизонті 6-12 місяців варто очікувати трьох речей. По-перше, подібні прийоми планування почнуть з'являтися у vLLM-Omni, SGLang-Omni та інших serving-фреймворках — конкуренція за TTFA під навантаженням надто очевидна, щоб її ігнорувати. По-друге, ціновий тиск на комерційні TTS-API (ElevenLabs, Cartesia) зростатиме в міру того, як компанії з доступом до GPU-інфраструктури рахуватимуть, що $2 проти $49-100 за мільйон символів — це різниця, яка вирішує економіку продукту при масштабі. По-третє, фокус індустрії голосових агентів продовжить зміщуватися від питання "яка модель звучить природніше" до питання "яка архітектура serving-шару дає нижчу й стабільнішу латентність під реальним навантаженням" — бо саме це, а не сама лише якість голосу, зараз відділяє демо від production-системи.