Меня зовут Илья, я основатель сервиса для генерации изображений ArtGeneration.me, блогер и просто фанат нейросетей. А еще я сам собрал портативную версию Qwen3-TTS под win11 и успел её как следует протестировать.

Главная особенность системы в том, что она умеет не только озвучивать текст готовыми голосами, но и клонировать любой голос по короткому образцу, а ещё создавать новые голоса по текстовому описанию.

И всё это с нативной поддержкой русского языка.

Как это работает

В основе Qwen3-TTS лежит End-to-End архитектура с дискретным многоканальным токенизатором речи (12.5 Гц, 16 слоёв). В отличие от традиционных систем, которые работают по цепочке "текст → фонемы → звук" и теряют информацию на каждом этапе, здесь всё обрабатывается одним махом.

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

Работает очень быстро даже на старшей модели 1.7B.

Поддерживаемые языки

Qwen3-TTS работает с 10 языками:

• Китайский (включая пекинский и сычуаньский диалекты)

• Английский

• Японский

• Корейский

• Немецкий

• Французский

• Русский

• Португальский

• Испанский

• Итальянский

Возможности

Синтез с готовыми голосами (CustomVoice)

9 встроенных голосов разных типов — молодые и зрелые, мужские и женские. Можно управлять эмоциями и стилем речи через текстовые инструкции.

Создание голоса по описанию (VoiceDesign)

Описываете словами, какой голос нужен — модель его генерирует. Например: "молодой женский голос, игривый, с высоким тоном". Лучше работает если писать промпты на голос на английском.

Клонирование голоса (Voice Clone)

Загружаете аудио от 3 секунд — получаете синтез этим голосом. По бенчмаркам качество клонирования превосходит ElevenLabs и MiniMax по показателям сходства спикеров. Оно и правда веского качества, уровень VibeVoice, но гораздо легче по ресурсам.

Multi-Speaker режим

Создание диалогов и подкастов с несколькими спикерами одновременно (до 4 голосов).

Можно эмулировать разговор между друзьями, актерами, персонажами из игры, все теперь ограничивается только вашей фантазией.

Кому пригодится

Создателям контента — озвучка роликов, подкастов, стримов.

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

Аудиокнигам — разные голоса для персонажей.

Автоматизации — голосовые уведомления, IVR-системы, ассистенты.

Как попробовать

Онлайн-демо

Тут в демо меньше возможностей и нет локализации, но тоже отлично работает.

Hugging Face Demo — https://huggingface.co/spaces/Qwen/Qwen3-TTS

Официальный GitHub

Можно попробовать установить самостоятельность с гитхаб, но это потребует опыта и навыков.

GitHub: https://github.com/QwenLM/Qwen3-TTS

API

Официальное API от Alibaba для production-интеграции.

Ссылка: https://www.alibabacloud.com/help/en/model-studio/qwen-tts-realtime

Портативная версия

Я с каналом Нейро-Софт подготовил улучшенную портативную сборку Qwen3-TTS Portable PRO, видео выше как раз из неё и записаны. А еще там:

• Русифицированный интерфейс

• Установка в один клик (install.bat)

• 50+ готовых голосов в комплекте

• 700+ дополнительных голосов для скачивания из интерфейса

• Multi-Speaker режим до 4 спикеров

• Поддержка NVIDIA GPU и CPU

Скачать: https://github.com/timoncool/Qwen3-TTS_portable_rus

Системные требования

• NVIDIA GPU с 8+ ГБ видеопамяти (или CPU, но медленнее)

• Windows 10/11 64-bit

• 16 ГБ оперативной памяти

• 20 ГБ свободного места на диске

Текущие ограничения

• Ударения иногда расставляются неправильно

• С длинными текстами могут быть проблемы

• Инструкции для VoiceDesign лучше писать на английском

Распакуйте в корень диска (путь без кириллицы), запустите install.bat. Модели скачаются при первом запуске. А если будут сложности в установкой в посте в канале найдете версию с уже установленным env (окружением).

Я рассказываю больше о нейросетях у себя на YouTube, в телеграм и на Бусти. Буду рад вашей подписке и поддержке. Ну и на канал Нейро-Софт тоже подпишитесь, чтобы не пропустить полезные репаки. Всех обнял и удачных генераций!

Как рассказал Пётр Козлёнков, руководитель службы информационных технологий PVS-Studio, открытое ПО имеет длинную историю как в инженерной, так и в производственной инфраструктуре: от операционных систем (Linux) до систем управления базами данных (PostgreSQL). Доверие к таким решениям складывается из практических механизмов: прозрачности, воспроизводимости и коллективного аудита. Например, OpenSSL, ядро Linux и PostgreSQL регулярно проходят независимые проверки, включая исследования университетов и консалтинговых компаний.

Алексей Варлаханов, руководитель отдела прикладных систем Angara Security, считает, что Open Source заслуживает доверия, прежде всего, благодаря прозрачности исходного кода, что позволяет проводить независимый аудит безопасности и модифицировать продукт под конкретные нужды организации.

«Один из ключевых аргументов в пользу OSS-продуктов – любой желающий может посмотреть исходный код, пересобрать его, провести аудит с помощью инструментов статического, композитного или динамического анализа. Всё это снижает вероятность возникновения скрытых бэкдоров, неочевидных шпионских функций или недокументированных механизмов сбора данных, к примеру, телеметрии», — рассказал Пётр Козлёнков, руководитель службы информационных технологий PVS-Studio.

Возможность изучить исходники на предмет уязвимостей выгодно отличает OSS от проприетарного кода, защищенного политиками вендоров.

Как рассказал генеральный директор Swordfish Security Александр Пинаев, продукты с открытым исходным кодом пользуются доверием разработчиков, поскольку его безопасность можно проверить. Инженеры могут самостоятельно просканировать исходный код или заказать проверку у ИБ-специалистов. С проприетарным кодом это не всегда возможно, так как компании чаще всего не поставляют исходный код вместе с продуктом.

С точки зрения доверенности и безопасности, наличие свободных компонентов является большим плюсом, поскольку возможности их исследования значительно выше, чем проприетарных, отметил Алексей Смирнов, председатель совета директоров «Базальт СПО». К тому же, благодаря доступности исходного кода в его исследовании принимает участие большое сообщество разработчиков.

Широко известны OSS-проекты, такие как Linux, Nginx, Kubernetes, OpenSSH, которые выбирают из-за ряда преимуществ и используют повсеместно крупные коммерческие компании. Эксперты считают, что эти программы являются более надёжными, чем многие проприетарные аналоги.

«Идея о том, что OSS-продукты более уязвимы – миф. Действительно, есть риски, связанные с качеством управления проектом, атаками на цепочку поставок и отсутствием централизованной ответственности, но корректное управление ими делает использование OSS-продуктов более безопасным», — отметил Пётр Козлёнков, руководитель службы информационных технологий PVS-Studio. 

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

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

Мой GitHub - https://github.com/prog-time

Идея проекта

Большинство Open Source-проектов создаётся не с целью прямой монетизации, а ради социального признания. К таким показателям можно отнести звёзды на GitHub, лайки и подписчиков в социальных сетях. Эти метрики позволяют получить внешнюю оценку проделанной работы и, в определённой степени, повысить свою заметность на рынке.

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

Исходя из этого, я рекомендую начинать с проектов, которые полезны вам лично. В таком случае у вас появляется естественная мотивация поддерживать и развивать проект, даже если внешняя обратная связь минимальна.

Отдельное внимание стоит уделить масштабу проекта. Оптимальное время разработки до первой MVP-версии не должно превышать 1–2 недель. Более длительный цикл без ощутимого результата значительно повышает риск выгорания и потери интереса к проекту.

Для вдохновения вы можете посмотреть проекты которые сейчас в тренде на GitHub или подписаться на Topic по интересующему вас направлению (https://github.com/trending).

Выбор аудитории

При создании Open Source-проекта важно заранее определить целевую аудиторию, поскольку от этого решения будет зависеть практически вся дальнейшая разработка.

В общем случае проекты можно условно разделить на два типа:

• проекты для разработчиков;

• проекты для конечных (сторонних) пользователей.

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

Проекты для разработчиков

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

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

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

Проекты для конечных пользователей

Если проект ориентирован на пользователей, не связанных с разработкой (как в моём случае), приоритеты смещаются. Здесь особенно важно уделять внимание:

• производительности и оптимизации;

• качественной и понятной документации;

• простоте установки и быстрому развёртыванию проекта.

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

Наблюдения из практики

По моему опыту, проекты для разработчиков чаще получают звёзды на GitHub, поскольку их аудитория хорошо ориентируется в экосистеме платформы и активно использует такие метрики. Однако подобные проекты сложнее продвигать и выделять среди конкурентов.

Проекты для конечных пользователей, в свою очередь, обычно получают меньше звёзд, но их аудитория охотнее идёт на контакт и более заинтересована в развитии продукта, особенно если он напрямую влияет на их бизнес-процессы.

Начало разработки

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

Если вы разрабатываете библиотеку, имеет смысл ориентироваться на популярные менеджеры пакетов соответствующей экосистемы. Это позволяет пользователям подключать ваше решение к проекту с помощью нескольких команд в терминале, без дополнительной ручной настройки.

Если же проект представляет собой отдельный сервис (как в моём случае), стоит заранее задуматься о контейнеризации. Использование Docker позволяет изолировать зависимости, стандартизировать окружение и значительно упростить процесс установки и запуска проекта.

В процессе разработки проекта tg-support-bot я предусмотрел два варианта установки:

• Полный вариант — развёртывание через docker-compose, включающее все необходимые сервисы: PostgreSQL, PgAdmin, Loki, Grafana, Redis и другие компоненты.

• Упрощённый вариант — установка проекта на обычный хостинг с возможностью подключения внешней базы данных и отключения необязательных сервисов.

При этом важно избегать жёстких зависимостей между контейнерами. Пользователи должны иметь возможность отключать или заменять отдельные сервисы внутри docker-compose без нарушения работоспособности основного приложения.

Линтинг, настройка CI и тесты

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

Code style и линтеры

Для каждого проекта важно определить и задокументировать правила code style. Чем строже и однозначнее эти правила, тем проще поддерживать читаемость кода и единый стиль среди участников проекта.

Также необходимо настроить линтеры, которые проверяют код на:

• синтаксические ошибки и типизацию;

• соответствие имен переменных и функций выбранному стилю;

• распространённые ошибки и потенциальные уязвимости.

Автоматическое тестирование

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

В проекте tg-support-bot я реализовал систему shell-скриптов для автоматизации линтинга и тестирования с передачей дополнительных параметров к инструментам анализа.

Скрипты интегрированы с git-хуками:

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

• Статический анализатор PHPStan проверяет код на ошибки и нарушения типизации;

• Выполняются unit-тесты для изменённых классов;

• Если изменён Dockerfile, запускается Hadolint для проверки Dockerfile;

• Если изменены shell-скрипты, применяется ShellCheck для выявления ошибок и потенциальных уязвимостей.

При push выполняется проверка всего проекта: PHPStan анализирует весь код, запускаются все unit-тесты и линтеры. Это позволяет выявить проблемы, которые могли быть пропущены при коммите.

На этапе CI система повторно проверяет весь проект, что особенно важно для Open Source: сторонние контрибьюторы могут внести изменения, которые нарушат работу проекта.

В случае обнаружения ошибки системы блокирует изменения до исправления ошибок.

Скрипты для git-hooks вы можете посмотреть здесь - https://github.com/prog-time/git-hooks

Таким образом, процесс тестирования делится на три уровня:

1. Локальная проверка при коммите — только файлы, добавленные в коммит.

2. Проверка при push — весь проект для предотвращения глобальных ошибок.

3. CI/CD — полная автоматическая проверка, включая сторонние изменения.

Продуманная система тестирования и линтинга позволяет снизить риски и обеспечивает стабильность проекта, что особенно важно в Open Source-разработке.

Структура GitHub репозитория

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

Структура веток

На своих проектах я использую следующую схему:

• Ветка main является основной. Прямые коммиты в неё запрещены — все изменения вносятся через дочерние ветки.

• Релизные ветки создаются перед планированием релиза. Например, для шестого релиза создаётся ветка release_6. В этой ветке я фиксирую все задачи, которые должны войти в релиз.

• Ветки задач создаются для каждой отдельной задачи из релиза. В наименовании ветки обязательно указывается номер соответствующего Issue. Это строгое правило: ветка с некорректным именем не пройдет проверки CI, и изменения не смогут быть слиты в проект.

Такой подход помогает:

1. Приучиться создавать Issues для любых изменений;

2. Контролировать работу сторонних контрибьюторов;

3. Поддерживать прозрачность процесса разработки.

Структура коммитов

Для упрощения отслеживания изменений я использую shell-скрипты, которые автоматически:

• Добавляют в начало описания коммита номер задачи (issues-62 | update tests);

• Формируют список изменённых файлов с пометками Added, Changed, Deleted.

Пример такого комментария:

Структура релизов

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

• прозрачное ведение истории изменений;

• удобство для контрибьюторов и пользователей;

• облегчение поддержки проекта в долгосрочной перспективе.

Строгая структура веток и коммитов повышает контроль над изменениями, улучшает читаемость истории проекта и минимизирует ошибки при совместной разработке в Open Source.

Документирование

Документирование — один из ключевых аспектов Open Source-разработки. Хорошая документация делает проект доступным для пользователей и контрибьюторов, ускоряет внедрение и снижает количество ошибок при использовании.

Основные элементы документации

1. README.md

   • Основной файл, который видит каждый пользователь на GitHub.

   • Должен содержать:

     • краткое описание проекта;

     • инструкции по установке и настройке;

     • пример использования;

     • ссылки на документацию.

2. CONTRIBUTING.md

   • Описание процесса внесения изменений в проект.

   • Рекомендуется включать:

     • правила создания веток и коммитов;

     • процесс отправки pull request;

     • требования к тестированию и линтингу.

3. CHANGELOG.md

   • Фиксирует историю релизов и внесённых изменений.

   • Формат: версия, дата релиза, исправления, новые функции.

Отдельно хочу выделить раздел Wiki на GitHub...

GitHub Wiki — это встроенный инструмент для более подробной и структурированной документации проекта. В отличие от README, Wiki позволяет создавать несколько страниц, объединённых логической структурой, что удобно для больших проектов.

Использование Wiki целесообразно для расширенной документации: здесь можно описать архитектуру проекта, инструкции по деплою и CI/CD, гайды по использованию библиотек и сервисов, а также рекомендации для контрибьюторов. Важно, чтобы Wiki дополняла README, а не дублировала его, оставляя последний кратким и ориентированным на быструю установку и запуск.

Практические рекомендации

• Документируйте всё ключевое сразу, не откладывая на будущее. Это экономит время и снижает риск потери информации.

• Используйте шаблоны и стандарты (например, Markdown, OpenAPI, DocBlock), чтобы документация была однородной.

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

• Для сторонних пользователей делайте упор на простоту и понятность, для разработчиков — на технические детали и примеры использования.

Взаимодействие с аудиторией

Для успешного развития Open Source-проекта важно активно взаимодействовать с аудиторией и привлекать пользователей из сторонних источников. Это помогает не только продвигать проект, но и получать ценные отзывы для улучшения функционала.

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

В проекте tg-support-bot я создал отдельную группу, где публикую новости, отвечаю на часто задаваемые вопросы и взаимодействую с пользователями.

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

Дополнительно в Telegram-группе я получаю от пользователей идеи для нового функционала и провожу голосования, что позволяет учитывать мнение сообщества при планировании развития проекта.

Таким образом, налаженная коммуникация с аудиторией позволяет объединить пользователей, повысить вовлечённость и создать сообщество вокруг проекта, что является ключевым фактором успешного Open Source-развития.

Популяризация проекта

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

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

Дополнительно полезно публиковать статьи на популярных ресурсах, таких как Хабр или Пикабу, чтобы привлечь новую аудиторию и рассказать о проекте более широкой публике.

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

Заключение

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

Если вам интересно следить за моими проектами и участвовать в их развитии, подписывайтесь на мой GitHub — там вы найдёте все обновления и сможете присоединиться к работе над проектами.