0xShug0

@Jinyu_Chai AAudio models have audio.cpp, a single framework for running 130+ audio models locally, much faster than Python. Many components are abstracted and reused across models. 0xShug0/audio.cpp

audio.cpp: An all-in-one, pure C++ inference engine for audio models, powered by ggml (3.8k stars) What it does All text below is quoted directly from the project README. >An all-in-one, pure C++ inference engine for audio models, powered by ggml. Supports TTS, STT, VAD, voice conversion, music generation, and more, with highly optimized performance. No Python dependency. Highlights: - Parity. Strong parity tooling against Python reference paths. - Performance. Performance-focused execution, reusable sessions, and batch-style offline inference. Optimized for CUDA. - Portability. A portable native stack centered on ggml, with CUDA, HIP/ROCm, Vulkan, Metal, and CPU backends behind shared CLI and server entry points instead of Python-only deployment paths. - Pipelines. Experimental JSON pipeline support for higher-level multi-step workflows. - Audio Utilities. Built-in denoise, enhancement, resampling, and STFT/ISTFT utilities for real production-style task paths. >Runs on Windows, Linux, and macOS, with support for NVIDIA, AMD, Apple Silicon, and CPU-only machines. Repository 0xShug0/audio.cpp Repository stats |Metric|Value| |:-|:-| |Stars|3,839| |Forks|466| |Last release|v0.9.3 (2026-10-26)| |Languages|C++ 87.5%, Python 8.8%, Svelte 1.4%| |Contributors|134| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|@claude (67 commits), @cursoragent (2 commits)| |AI co-authored commits|Claude: 72, Cursor: 2| Main contributor |Field|Value| |:-|:-| |GitHub|@0xShug0| |Commits to this repo|625 (top contributor)| |Bio|Ex Princeton network/security researcher, now AI.| |Followers|85| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.

KoboldCpp 1.124 - YuE2, new TTS models, new image gen models and much more koboldcpp-1.124 a e s t h e t i c This is a huge release that brings a ton of new features! - NEW! - KoboldCpp has now integrated a small subset of popular models from audio.cpp by @0xShug0! This greatly enhances the available built-in Music Gen and TTS Gen capabilities! - Music Gen: The long awaited YuE2 music gen model is supported. Download, save and load one of the following templates: - YuE2, no LLM - Lightest option, only YuE2, bring your own lyrics . - YuE2, small LLM - YuE2 with a small 4B LLM for generating lyrics. (Recommended!) - YuE2, big LLM - YuE2 with a huge LLM for generating lyrics. Only for large GPUs. - TTS Gen: The following TTS models have also been added (ported from audio.cpp) - BreezeTTS 2 [Voice cloning] [Instructions] (Recommended!) - Ming 3.0 TTS [Voice cloning] [Instructions] (Recommended!) - Qwen3-TTS Base [Voice cloning] (Recommended!) - Qwen3-TTS VoiceDesign [Instructions] (Recommended!) - VoxCPM2 [Voice cloning] [Instructions] (Recommended!) - Chatterbox [Voice cloning] - Chatterbox Turbo - CosyVoice 3 [Voice cloning] [Instructions] - Fish Audio S2 Pro [Voice cloning] [Instructions] - Kitten TTS 2 [Voice cloning] - Maya1 [Instructions] - NeuTTS 2E - OmniVoice [Voice cloning] [Instructions] - PocketTTS [Voice cloning] - Soprano 1.1 80M - Supertonic 3 - VibeVoice 1.5B [Voice cloning] - A full directory of supported ported TTS models can be found here - MusicUI has been updated to support YuE2 and the new TTS models. After launching, access it at localhost - MusicUI now has a transcribe tab (use with Whisper models), this can be useful for some of the new TTS models which need reference transcripts. - NEW! - The latest sd.cpp sync brings some exciting new image generation model support (thanks @wbruna) - MOSS Image (Recommended!) - Fibo 2 Edit - Flux 3 Klein - Don't forget the Krea 2 Turbo and Qwen Image 2.1 previously added. - NEW! - AI Horde now supports Chat Completions workers! This is enabled automatically, simply update to the latest KoboldCpp version. This allows the use of jinja, reasoning, tool calls, streaming and vision over AI Horde - you can enable this by toggling chat completions mode in lite.koboldai.net . Special thanks to @tazlin for coordinating this enhancement! - Added a /mcp wizard for KoboldCpp Agent, allows setting up custom MCP endpoints. Also fixed a MCP loader race condition. - Added /paste mode to KoboldCpp Agent to handle multiline text. - Enable CUDA graphs for all architectures, expose upstream lazy loading --lazy-mode and MoE cache --moe-cache-mib, thanks @askmyteapot - Added --paralleltotalcontext, which can be used with --parallelrequests. It allows setting the total KV context pool that concurrent requests share. Defaults to contextsize if unset. Increase this if the incoming batched requests are all very large - big requests will queue if they cannot fit. - Fixed a CPU flash attention bug triggered by -Ofast, also detect file types by content instead of extension (thanks @wbruna) - Now allow a limited amount of cache reuse when in batched (parallel requests) mode - Improved SWA handling for Gemma4 models, with corrected warmup. SWA quality should be a lot better and more consistent when rewinding. - Fixed a potential buffer overflows on loading for a few legacy models. (Thanks @professor-moody and @UNILESS) - Added support for Animated WebP as the default preview for video gen (GIF is still supported, toggle in SDUI settings). AVI remains the default download option. - Allow using tokenizers baked into the text encoder llm for image gen models. An explicit tokenizer.json can still be provided in the clip2 slot. - Added support for TAEQI-tinier as a baked in VAE for Qwen Image 2.1, thanks @madebyollin - Reworked built in WebSearch to give better and longer results in the fetched content - Widen tool random id range - Allow using RPC host tensor cache directory by @mfrederiksen, trigger with --rpccache - Fixed Anthropic api tool handling by @jaeminbird - Mask passwords in terminal load logs by @Yuvraj-Dhepe - Disable async mode for ancient AMD GCN cards on Vulkan - Updated Kobold Lite, multiple fixes and improvements - SSE parser improvements, added /v1/responses support, tool call and websearch improvements - Merged fixes, new model support, and improvements from upstream, including Nemotron 3.5 Bolt 74BA9B, Mistral Large 4, LFM3, Muse Spark and more. Download now at https://github.com/LostRuins/koboldcpp/releases/latest Community Website: https://koboldcpp.net

@Tevsa ich habs getan, noch ein Update, audio.cpp#1081 und es gibt noch deutlich mehr stellen im Code wo man die Performance verbessern kann. schade das der Post mit deinen Screenshots weg ist wollte da heute morgen noch mal ein Auge reinwerfen.

@Tevsa kannst du das testen was ich da wieder für einen Käse gebaut habe? Speziell für AMD GPUs audio.cpp#1060 falls du jemanden kennst der das Testen kann immer ran, KI Werkzeuge zu bauen ist komplex aber spannend. #AI #Audio #futuretech

AudioCpp bekommt großartige Updates. 0xShug0/audio.cpp #Audio #ai #Opensource #cpp

#Opensource #AI #Audio 0xShug0/audio.cpp CC @pcspenden.bsky.social @onecoding.eurosky.social spannendes Projekt.

Bringing 120+ Audio AI Models to ComfyUI in One Custom Node I created ComfyUI-AudioCPP about two months ago, but made pretty much zero progress 😅. Today, a community contributor finally got things moving by implementing the first set of nodes! The goal is to bring the capabilities of audio.cpp into ComfyUI: - All-in-one: TTS, ASR, voice conversion, music generation, audio enhancement, separation, and more through a unified engine. - Broad model coverage: 120+ audio model families, without maintaining separate inference implementations for each. - Unified interface: Many models share the same interface in audio.cpp, so supporting additional models in ComfyUI can come almost for free once the corresponding task nodes are implemented. - High performance: Optimized native C++/GGML inference across CUDA, Vulkan, Metal, CPU, and AMD (experimental), without Python inference dependencies. The initial contribution provides TTS nodes, including voice cloning support. It's still early, and there's plenty of room to expand into other audio tasks and improve the ComfyUI integration. Contributions are very welcome! Whether you want to add nodes, improve workflows, test different models/backends, or help polish the integration, feel free to open a PR! Repo: 0xShug0/ComfyUI-AudioCPP

Irodori-TTSの7実装を比較する【前編：速度編】 後編はこちら : Irodori-TTSの7実装を同じモデル・入力テキスト・参照音声で動かして比較した。推論ハードウェアはRTX 5090である。CUDAとVulkan、FP32と各実装の実用精度、参照音声のキャッシュあり・なしを分け、推論時間とVRAM使用量を測っている。 MFの実用設定ではirodori-onnxが最速、RFの実用設定では公式Irodori-TTSが最速であった。MFで既存のキャッシュを使ったときの推論時間は、ONNX版103.9 ms、公式版149.3 ms、speech.cpp Vulkan版194.6 msである。speech.cpp Vulkan版は、速度上位3種の中でVRAM使用量が最も小さくなった。 前編では処理段階ごとの速度差と、runtime更新で公式MFが遅くなった原因を調べた結果を紹介する。後編の品質評価はMFで速かった3種を対象に、読みと話者再現性を比較している。 検証コード、設定、集計CSV、グラフは、以下のリポジトリにまとめた。この記事の参照先は2026年10月21日時点のコミットに固定している。 idunafu/irodori-engine-comparison 要約 2026/10/13に各実装のコミットを固定したので最新版の改善が反映されていない可能性がある。 測定環境: RTX 5090 + Ryzen 9 9950X + Ubuntu 24.04 MF: irodori-onnx/CUDAが最速 RF: 公式実装/CUDAが最速 ピークVRAM: speech.cpp/Vulkanが最小 (2,32 GiB) コールドスタート: speech.cpp/Vulkanが最速 使用した精度 公式版: BF16 / FP32(codec) speech.cpp: F16 / FP32(codec) irodori-onnx: FP16 / FP16(codec) 比較した7実装 主比較に使ったのは、2026年10月13日に固定した次の実装である。 ! 一部を除きこの時点でのコミット以降はベンチマークの対象としていない。 実装 対象モデル バックエンド 実用設定のモデル重み Irodori-TTS RF・MF CUDA BF16 audio.cpp RF CUDA・Vulkan F16 speech.cpp RF・MF Vulkan (・CUDA1) F16 sttts-gui RF・MF Vulkan FP32 Irodori-TTS-burn RF・MF Vulkan / WGPU FP32 irodori-onnx MF CUDA FP16 Irodori-TTS-Optimiz RF CUDA BF16 RFはRectified Flow、MFはMeanFlowである。今回はRFを40ステップ、MFを4ステップで動かしている。sttts-guiはLinux用のsttts-sayと同じTTSエンジンを測定対象にした。 モデルとバックエンドの組み合わせは14通りである。それぞれにFP32の共通基準と実用設定を用意し、合計24設定を測定した。sttts-guiとBurnは両方ともFP32なので、測定結果を共有している。 RFにはAratako/Irodori-TTS-v4.1-Small、MFにはAratako/Irodori-TTS-v4.1-Small-MFを使った。GGUFとONNXも同じ公式チェックポイントから変換している。整数への量子化は行っていない。 codecの重みは基本的にFP32である。ONNXの実用設定だけはdecoderがFP16で、参照音声のencoderはFP32である。この違いは後述の速度差にも関わる。 測定環境と条件 ハードウェアとruntime 項目 設定 GPU NVIDIA GeForce RTX 5090、VRAM 32 GB CPU AMD Ryzen 9 9950X、演算スレッド数8 OS Ubuntu 24.04 LTS GPUドライバ 610.57.04 Python 3.10.20 PyTorch 2.10.0+cu128 ONNX Runtime 1.23.2 ネイティブビルド C++はRelease、CUDAアーキテクチャ120、Rustは--release --locked 各実装の環境は分離し、GPUを使う処理は逐次実行している。制御できるTF32は無効にした。環境とビルドの詳細はリポジトリのREADMEにある。 入力文章と生成音声の長さを揃える 入力は日本語20文章である。BOS込みのトークン数で、8〜15、16〜31、32〜63、64〜95、96〜127の5群に分け、各群に4文章ずつ配置した。 主比較では公式RF・FP32で予測した生成フレーム数を全実装に渡し、文章ごとの出力長を揃えている。これにより、ある実装だけ出力音声が短いために速く見えることを避けられる。 参照音声はつくよみちゃんコーパスのVOICEACTRESS100_054.wavである。全実装に同じ10.989958秒・モノラル・48 kHz・PCM 24 bitの音声を渡した。共通の生成条件は次のとおりである。 batch size 1、候補数1、seed 42 RF 40ステップ、MF 4ステップ captionは「自然な日本語で、落ち着いた口調で話す。」 RFはindependent CFG、text / captionが3、speakerが5、適用区間0.5〜1.0、linear schedule 透かし、ストリーミング出力、末尾トリム、追加の無音除去は無効 各実装が自動で予測する生成長を使う比較、出力を8秒に固定して入力長を変える比較、代表文章から2・4・8・16・24秒の音声を生成する比較も、別に測定した。入力文章と生成設定も公開している。 推論時間とキャッシュの測定条件 この記事では主に、モデルをロードしてwarmupした後の通常推論時間を比較する。要求の処理開始から、完成したPCMがCPU上に揃うまでを測る。WAVファイルの保存時間とプロセス間通信は除いている。 各条件で2回warmupし、5回測定した中央値を求めた。主比較の表にはその値をさらに20文章で集計した中央値を載せている。モデルロードと初回推論は新しいworkerを3回起動して別に測っている。 RTFは「推論時間 ÷ 出力音声の秒数」である。たとえば8秒の音声を80 msで生成すると、RTFは0.01になる。表のRTFも各文章で計算した値の中央値である。 キャッシュ条件は次の2つに分けた。 毎回エンコード：参照音声などの条件を要求ごとにエンコードする。 キャッシュあり：登録済みvoiceや参照latentなど、各実装が備えているキャッシュを使う。 キャッシュできる範囲は実装によって異なる。測定のために新しいキャッシュ機構を足すことはせず、それぞれの既存機能を使った。指標の詳しい定義は測定方法にまとめている。 MFの実用設定での比較 4ステップのMFでは、実用設定でONNX版が最速であった。主比較の全20文章、同一生成長での結果を、キャッシュありの推論時間が短い順に並べた。時間はms、VRAMはMiBである。 実装 / backend モデル重み 毎回エンコード↓ キャッシュあり↓ RTF（キャッシュあり）↓ ピークVRAM（キャッシュあり）↓ irodori-onnx / CUDA FP16 146.2 ms 103.9 ms 0.004 5,908 MiB 公式 / CUDA BF16 195.0 ms 149.3 ms 0.007 12,004 MiB speech.cpp / Vulkan F16 239.8 ms 194.6 ms 0.008 2,377 MiB Irodori-TTS-burn / Vulkan FP32 511.8 ms 232.9 ms 0.010 7,606 MiB speech.cpp / CUDA (参考) F16 380.1 ms 322.9 ms 0.014 2,812 MiB sttts-gui / Vulkan FP32 1,323.2 ms 1,153.2 ms 0.049 4,529 MiB 出典：MFの主比較結果、集計CSV。 ONNX版はキャッシュありでは公式版より推論時間が約30.5%短く、速度比で約1.44倍であった。毎回エンコードする条件でも、上位3種の順位は同じである。後述するが、ONNX版はdecoderがFP16であることに注意。 後編の品質比較はこのMFの上位3種、ONNX CUDA・公式CUDA・speech.cpp Vulkanを対象にしている。 RFの実用設定での比較 40ステップのRFでは、公式BF16版が最速であった。こちらもキャッシュありの推論時間で並べている。 実装 / backend モデル重み 毎回エンコード キャッシュあり RTF（キャッシュあり） ピークVRAM（キャッシュあり） 公式 / CUDA BF16 601.1 ms 555.2 ms 0.024 12,000 MiB Irodori-TTS-Optimiz / CUDA BF16 616.5 ms 576.7 ms 0.025 9,264 MiB audio.cpp / CUDA F16 772.6 ms 722.4 ms 0.030 8,056 MiB speech.cpp / Vulkan F16 961.3 ms 915.4 ms 0.042 2,707 MiB audio.cpp / Vulkan F16 1,064.2 ms 977.5 ms 0.041 10,423 MiB speech.cpp / CUDA F16 1,829.6 ms 1,772.6 ms 0.077 3,030 MiB Irodori-TTS-burn / Vulkan FP32 2,263.9 ms 2,015.9 ms 0.090 7,666 MiB sttts-gui / Vulkan FP32 8,347.5 ms 8,180.0 ms 0.344 4,654 MiB 出典：RFの主比較結果。 公式版とOptimiz版は近い値である。speech.cpp Vulkan版は推論時間では4番目であるが、観測ピークVRAMは2,707 MiBに収まった。速度とメモリ使用量で特徴が分かれる。 同じ公式版のキャッシュありで比べると、RFは555.2 ms、MFは149.3 msである。MFはステップ数が少なく、推論全体にかかる時間も短くなった。一方、RFからMFへ変えると、最も時間のかかる処理も変わる。 MFの処理段階ごとの速度差 ONNX版が速い理由を見るため、処理段階ごとの時間を確認した。以下はMF・実用設定・キャッシュありの結果である。 実装 サンプリング DACVAE decode 通常推論 公式 / CUDA 26.2 ms 111.2 ms 149.3 ms irodori-onnx / CUDA 33.1 ms 65.1 ms 103.9 ms speech.cpp / Vulkan 40.8 ms 145.4 ms 194.6 ms サンプリングは条件のエンコード後から最終latentができるまで、DACVAE decodeはそのlatentからPCMが完成するまでである。段階別の値はGPU同期を入れた別実行で測り、通常推論とは独立に比較している。測定結果 サンプリングだけなら公式版の方が速く、PCM完成までではONNX版の方が速くなった。公式版のサンプリングは26.2 msであるが、decodeには111.2 msかかる。ONNX版のdecodeは65.1 msで、ここに大きな差があることが分かった。 MFは4ステップでサンプリングにかかる時間が短いため、codecの処理時間が全体に大きく影響する。 ONNX版の実用設定はdecoderもFP16である。今回速かったのは、TTSモデル本体と音声デコーダーを含めた構成である。 FP32と実用設定の比較 モデルとcodecの重みをFP32にした共通基準では、MFの上位は次のようになった。キャッシュありの通常推論時間である。 実装 FP32基準 実用設定 speech.cpp / Vulkan 199.1 ms 194.6 ms 公式 / CUDA 204.2 ms 149.3 ms Irodori-TTS-burn / Vulkan 232.9 ms 232.9 ms irodori-onnx / CUDA 249.7 ms 103.9 ms 出典：FP32と実用設定の比較表。 FP32ではspeech.cpp Vulkan版が最速である。ONNX版は249.7 msから103.9 msへ大きく短縮し、実用設定で順位が逆転した。 RFにも同じ傾向がある。FP32ではspeech.cpp Vulkan版が951.2 ms、公式CUDA版が1,340.2 msであるが、実用設定ではそれぞれ915.4 msと555.2 msになる。公式版はBF16化による短縮が大きく、speech.cpp Vulkan版はF16化による時間の変化が比較的小さくなった。 ここで揃えているのは重みの精度である。kernel内部のキャストや積算は各バックエンドの実装に従う。この区別は後編でcodecの数値差を調べるときにも出てくる。 キャッシュ・VRAM・初回起動の比較 同じ話者のキャッシュを再利用する MFの上位3種では既存キャッシュを使うと、主比較の推論時間の中央値が約42〜46 ms短縮した。Burnは511.8 msから232.9 msとなり、短縮幅は約279 msである。 Burnはvoice登録のたびにcodec encoderを読み込む構成で、毎回エンコードする条件の参照処理283.9 msのうち、encoderロードが170.2 msを占めている。登録済みvoiceの再利用によって、処理時間が特に大きく短縮した。参照音声処理の測定表 MFの速度上位3種のVRAM使用量 キャッシュありの観測ピークVRAMは、speech.cppは約2.32 GiB、ONNXは約5.77 GiB、公式は約11.72 GiBである。 VRAMはNVMLで10 msごとに観測した。表は推論時の観測ピークである。公式版では、一度扱った長い形状に対応するPyTorch allocatorの確保領域も残る。数値には条件キャッシュとallocatorを含めた実行状態が反映されている。VRAMの測定方法 モデルロードと初回推論 1回だけ起動して使う場合を考え、常駐時の速さに加えて、MF・実用設定のモデルロードと初回推論も測っている。代表文章p09を使い、新しいworkerを3回起動した中央値である。 実装 モデルロード 初回推論 irodori-onnx / CUDA 950.3 ms 543.2 ms 公式 / CUDA 4,151.6 ms 1,009.1 ms speech.cpp / Vulkan 293.2 ms 256.4 ms モデルロードは重み・tokenizer・codecの読み込みからGPUへの配置完了まで、初回推論はロード後の最初の要求である。OSとドライバのキャッシュは保持している。ロード・初回の結果 常駐時の最速はONNX版であるが、この3種ではモデルロードと初回推論が最短なのもspeech.cpp Vulkan版の特徴であった。 入力文章の長さと出力音声の長さの影響 次のグラフは主比較とは別に、出力を8秒に固定して20文章の入力長を変えた結果である。MF・実用設定・キャッシュありで、左が通常推論、右がサンプリング時間である。 今回の入力長の範囲では、多くの実装で処理時間がほぼ横ばいである。出力長を固定すると、文章のトークン数を増やした影響は比較的小さくなっている。 次は逆に、代表文章p09を固定し、出力音声の長さを変えた結果である。 上位3種の通常推論を抜き出すと、次の値になる。各セルはその条件で5回測定した中央値である。 出力長 ONNX CUDA 公式CUDA speech.cpp Vulkan 2秒 29.9 ms 45.6 ms 43.7 ms 8秒 48.2 ms 72.9 ms 87.0 ms 24秒 104.7 ms 150.5 ms 197.7 ms 出典：文章別・条件別CSV。 2秒ではspeech.cpp Vulkan版が公式版より少し速く、8秒・24秒では公式版が速くなる。ONNX版はこの3条件すべてで最速であった。単一の出力長での順位に加え、音声が長くなるにつれて処理時間がどう増えるかも分かる。 自動生成長とspeech.cppの30秒上限 各実装の自動生成長を使う測定では、speech.cppが20文章のうち8文章を30秒上限で拒否した。成功したのは12文章である。同一生成長の主比較は全24設定・両キャッシュ条件で20文章すべて成功している。 全体では3,120条件のうち2,992条件が成功し、128条件がこの自動生成長の上限超過で拒否された。自動生成長の結果を見るときは、成功件数と生成された秒数も併せて確認する必要がある。自動生成長の結果と失敗記録 runtime更新による公式MFの速度低下 主比較を終えた後、2026年10月15日にruntimeの更新前後も測った。エンジンとモデルを固定し、PyTorchを2.10.0+cu128から2.14.1+cu130へ、ONNX Runtimeを1.23.2から1.31.0へ更新した比較である。 公式MFのBF16・キャッシュありでは、同一生成長20文章の推論時間の中央値が150.53 msから167.39 msへ増えた。ONNX MFのFP16・キャッシュありは103.81 msから102.33 msで近い値である。runtime更新のA/B比較 公式MFのどの処理が遅くなったのかを調べると、FP32で動くDACVAEのdecodeにかかる時間が増えていた。 cuDNNだけを入れ替える 24秒分の同じlatentを保存し、同じ入力を各環境のcodecに渡した。 環境 24秒音声のdecode PyTorch 2.10 / CUDA 12.8 / cuDNN 9.10.2 120.91 ms 上と同じ環境でcuDNNだけ9.24.0へ更新 136.57 ms PyTorch 2.14.1 / CUDA 13.0 / cuDNN 9.24.0 136.92 ms cuDNNだけの更新で、runtime全体の更新とほぼ同じ速度低下を再現できた。さらに、最も遅くなったConv1dを取り出し、TTSやcodec全体を読み込まない単層の実験でも確認している。 その層の処理時間は旧環境では0.747 ms、新しいcuDNNでは4.192 msであった。GPUトレース2を見ると、旧環境のSGEMM系kernel 1個から、FFT 21個とGEMV 10個を起動する経路に変わっていた。 今回の速度低下の主因は、cuDNN 9.24がFP32 Conv1dで選ぶ既定アルゴリズムであった。 MF本体のステップ数やテキスト処理から切り離して再現できている。段階別計測と単層実験 アルゴリズムの実測選択を有効にする 専用workerで次の設定を有効にし、畳み込みアルゴリズムを実測して選ばせた。 torch.backends.cudnn.benchmark = True 単層Conv1dはSGEMM系に切り替わり、0.520 msになった。代表文章p09・24秒・MF BF16・キャッシュありの通常推論も、旧環境149.44 ms、新環境164.65 msに対し、実測選択ありでは135.95 msまで短縮した。 新しい形状を初めて処理するときには探索コストがかかる。単層の初回呼び出しは既定設定の約51 msから実測選択ありの約112 msへ増えた。常駐後の処理時間は短くなるが、初回の処理時間は長くなる。回避設定の測定結果 MFモデルをBF16にしていてもcodecはFP32なので、このdecodeの影響は残る。速度を比較するときは、モデルのdtypeに加えて、codecとruntimeの構成も記録しておく意味があった。 速度比較で分かったこと このRTX 5090環境では、MFの実用設定でONNX版、RFの実用設定で公式版が最速であった。MFの速度上位3種には、それぞれ次の特徴がある。 irodori-onnx CUDA：キャッシュあり103.9 ms。PCM完成までの総合時間が最短である。ただし、decoderがFP16である。 公式Irodori-TTS CUDA：MF 149.3 ms、RF 555.2 ms。MFのサンプリング自体も速く、RFでは主比較で最速になった。 speech.cpp Vulkan：MF 194.6 ms、観測ピークVRAM 2,32 GiB。ロードと初回推論も、この3種では最短であった。 結果を処理段階に分けて見ると、MFではcodecの速度が推論全体の時間に大きく影響していた。FP32と実用設定で順位が変わり、runtime更新によってcodecの畳み込み経路も変わる。実装名だけでなく、精度・キャッシュ・出力長・runtimeまで揃えて測ることで、それぞれの特徴がはっきりした。 後編の品質評価ではこのMFの上位3種を対象にし、MFは3実装、RFは対応する公式版とspeech.cppの2実装で、読みと話者再現性を比較した。 後編はこちら : 余談 この記事はベンチマークのリポジトリを基にGPT-6 Proが執筆したものを、yomiyasuを使った上でAstraに推敲させ、人間が読みやすいように人間がさらに修正を加えている。 Zenn特有の記法や技術記事には不慣れなため、アドバイスいただけると幸いです。 脚注 Codexに任せていたらなぜかCUDA版もビルドしてベンチマークしていた。本来は非サポート。 ↩︎ Codexが勝手にやってくれた すごいな ↩︎

当所有 AI 音频项目还在被 Python 环境、依赖地狱和模型拼装拖慢时，有人直接用 C++ + ggml，把语音合成、语音识别、声音克隆、音乐生成塞进了同一套原生推理引擎。 📦 项目档案 项目：0xShug0/audio.cpp 真实星标：⭐ 3598 开源地址：[0xShug0/audio.cpp](0xShug0/audio.cpp) 一句话定位：面向本地 AI 音频的高性能 C++ 推理框架，以 ggml 为底层计算基础，试图让现代音频模型摆脱对 Python 运行环境的依赖，走向轻量化、跨平台与原生部署。 🛠️ 一、真正值得拆解的，是统一推理运行时 传统音频 AI 开发经常面临一个隐性成本：TTS、STT、VAD、声音转换各自依赖不同的代码库、模型格式和运行环境。 audio.cpp 的核心思路，是围绕 ggml 构建统一的原生推理基础设施。 ggml 提供张量运算与底层计算能力，让模型推理可以在 C/C++ 运行时中执行，而不必将 Python 作为生产环境的必需依赖。 但要注意：统一运行时不等于所有模型共享同一套网络结构。不同模型依然需要各自的架构实现、权重加载和算子适配。 真正的工程价值，是减少环境碎片化，让模型能力更容易被嵌入现有应用。 ⚙️ 二、六类音频任务，一套技术底座 ① TTS：文本转语音 将文本生成语音的能力接入原生推理链路。README 特别强调流式生成优化，覆盖 Qwen3 TTS、BreezeTTS2、Higgs Audio、VibeVoice、Fish Audio 等模型。 ② STT：语音转文本 将语音识别纳入统一框架，适合本地转写、会议记录、语音输入等场景。具体识别精度仍取决于所用模型、语言和推理配置。 ③ VAD：语音活动检测 用于判断音频中的语音片段与静音区间，可作为语音助手的前置环节，减少无效音频处理，并帮助构建实时语音交互管线。 ④ 声音转换与音乐生成 进一步覆盖音色转换、音乐生成等任务。这里的关键不是把所有能力混成一个模型，而是让不同模型能力进入更统一的部署体系。 四类任务背后，是一套面向多种音频工作负载的原生推理框架。 三、流式推理，才是最值得关注的性能战场 README 给出了一个非常具体的优化信号：BreezeTTS2 的首次音频输出等待时间预计降低约 85%—90%。 为什么这个指标重要？ 实时语音系统中，用户感受到的延迟不只是模型生成速度，还包括音频预处理、模型初始化、首个音频片段生成及输出调度。 TTFA（首次音频输出时间）直接影响对话是否自然。相比只看整段音频的总生成耗时，降低首包等待时间，往往更能改善交互体验。 不过，85%—90% 是项目针对 BreezeTTS2 给出的优化数据，不应直接外推到所有模型、硬件或完整端到端链路。 另外，README 还提到 ARM CPU 优化，以及面向树莓派等设备的优化方向和 Rockchip NPU 加速。这意味着项目正在关注的不只是高性能桌面，也包括资源受限的边缘设备。 🌍 四、跨平台部署，决定它能走多远 Windows、Linux、macOS，以及 NVIDIA、AMD、Apple Silicon 和纯 CPU 环境，构成了项目强调的硬件覆盖范围。 对开发者来说，这意味着可以探索在不同设备上运行本地音频模型，而不必默认依赖独立的 Python 服务。 但要区分三个概念：支持某个平台、支持某个模型，以及在该平台上达到高性能，并不是同一回事。具体能力仍需核对模型支持矩阵、后端实现和硬件测试结果。 五、它究竟解决了什么工程问题？ 最值得关注的不是功能列表有多长，而是它试图砍掉哪些部署成本： 减少多个 Python 环境与依赖版本冲突。 降低把模型封装成独立服务的工程负担。 为离线语音助手、桌面应用、边缘语音设备提供原生集成路径。 通过流式推理优化，改善部分模型的交互响应速度。 对于想做本地语音 Agent、离线转写、嵌入式语音交互或多模型音频应用的开发者，这种统一运行时值得深入研究。 当然，生产落地还需要验证模型兼容性、内存占用、并发吞吐、许可证及目标硬件上的实际性能。 真正值得收藏的开源项目，不只是让模型跑起来，而是让模型更容易进入真实的软件系统。 audio.cpp 的方向，正是把 AI 音频从零散的模型实验，推向更统一的原生推理基础设施。 🔗 开源地址： [0xShug0/audio.cpp](0xShug0/audio.cpp)