Today I'm writing about the 0.8.4 release of speech.cpp. The biggest change is that almost every model now comes in smaller files that fit on PCs with little memory.

speech.cpp is an engine that runs speech synthesis, speech recognition and voice activity detection models in C++ (earlier post).

0.8.4 brings four changes:

The biggest is that you can choose the size of each model's file. A smaller type takes this much less memory:

The speed changes differently by model. Qwen3-ASR and Qwen3-TTS get faster the smaller the type, while FastConformer (ReazonSpeech and the others) and Irodori-TTS stay about the same. Below, the time to recognize one utterance:

Both were measured on an Apple M5. This post goes through the accuracy, memory and speed of every model, with numbers.

What changed in 0.8.4

• Quantized files
  • Nine models, all but Silero VAD, come in Q6_K, Q5_K and Q4_K
  • Models that only had an F16 file also come in Q8_0
  • Qwen3-TTS and Qwen3-ASR also get faster in the smaller types
• ReazonSpeech and parakeet-ja now use their Q8_0 file when named alone
  • The accuracy is almost the same as F16, and the memory is close to half
• Fixed Qwen3-TTS's Q5_K and Q4_K stopping with an error partway through synthesis on Vulkan
• The memory peak while a model loads dropped by about 150 to 320 MB
• On the Mac, a program that embeds libspeech no longer has its environment variables changed

Updating

Run the same command you installed with. On Apple silicon Macs and Linux:

curl -fsSL https://raw.githubusercontent.com/nyosegawa/speech.cpp/main/install.sh | sh

On Windows, in PowerShell:

irm https://raw.githubusercontent.com/nyosegawa/speech.cpp/main/install.ps1 | iex

ReazonSpeech (reazonspeech-v2) and parakeet-ja (parakeet-tdt_ctc-0.6b-ja) now use their Q8_0 file instead of F16 when named alone, so the first run after updating downloads the Q8_0 file (0.66 GB). To keep using F16, add :f16 after the name, as in reazonspeech-v2:f16. If you no longer need the F16 file, this removes it:

speech rm reazonspeech-v2:f16

Using a quantized type

Add a colon and the type after the model's name. The first time, the file is downloaded from Hugging Face.

speech asr qwen3-asr-1.7b:q6_k meeting.wav
speech tts qwen3-tts-0.6b:q6_k "It will be sunny in Tokyo tomorrow."
speech serve qwen3-tts-1.7b:q4_k qwen3-asr-0.6b silero-vad

speech models lists the types each model has.

qwen3-tts-0.6b                 q8_0  1.21 GB  yes      synthesis    de en es fr it ja ko pt ru zh
qwen3-tts-0.6b:q6_k            q6_k  0.99 GB  no       synthesis    de en es fr it ja ko pt ru zh
qwen3-tts-0.6b:q5_k            q5_k  0.87 GB  no       synthesis    de en es fr it ja ko pt ru zh
qwen3-tts-0.6b:q4_k            q4_k  0.76 GB  no       synthesis    de en es fr it ja ko pt ru zh

The number in a type is roughly how many bits each weight takes. The smaller the number, the smaller the file and the memory, and the lower the accuracy. How much lower turned out to differ a lot between models.

Choosing a type for each model

First, the short version: what to pick when you want to save memory. How far a model goes down with almost no loss of accuracy differs by model:

The memory and accuracy of each model are in the chart and the table below. The memory is the peak of one recognition or synthesis.

The rest of this section shows the numbers behind that table. Everything was measured with speech-bench on an Apple M5 with Metal; Appendix E has the details.

Japanese speech recognition

The CER on the Japanese test set of Common Voice 8.0 (4,483 utterances). The number after the slash is the CER when other spellings of the same words, such as 「行う」 and 「行なう」, count as correct.

parakeet-ja and ReazonSpeech barely move even at Q4_K, while the memory goes from 1.37 GB to 0.47 GB. If memory is short, Q4_K is a safe pick for both.

Qwen3-ASR stays close to Q8_0 down to Q6_K, and its CER rises at Q5_K and Q4_K. One interesting point: the 1.7B model at Q4_K (1.32 GB) has a lower CER than the 0.6B model at Q8_0 (1.00 GB). If you have another 0.3 GB to spare, the 1.7B model at Q4_K recognizes more accurately than the 0.6B model.

Recognition in English and other languages

parakeet-v3 (parakeet-tdt-0.6b-v3) was measured by WER on 300 English utterances of FLEURS. Its files and memory are about the same as parakeet-ja's.

Speech synthesis

For synthesis, 20 Japanese sentences were synthesized with three seeds, Qwen3-ASR 1.7B transcribed the audio, and the CER was taken against the original text. Each number is the mean of 60 syntheses. The same type moves by a few points from seed to seed, so a difference of one or two points does not say which type is better.

Only Qwen3-TTS 0.6B at Q4_K more than doubled its CER over Q8_0. To shrink the 0.6B model, stop at Q6_K. That said, from what I heard, every quantized version of Qwen3-TTS tends to come out with flatter intonation. That is hard to put into a score, so it's worth trying them and listening for yourself. The 1.7B model at Q4_K stayed within the seed-to-seed spread on average. Still, when I later listened sentence by sentence, it turned a sentence with English words into entirely different words, so the table above suggests Q6_K.

Irodori-TTS (irodori-tts) was measured with 16 steps (the default is 40). Down to Q4_K, its difference from F16 stayed within the seed-to-seed spread. Unlike Qwen3-TTS, the quantized versions kept a normal intonation. On the other hand, effects such as the caption's may have weakened. Both Irodori-TTS models keep the codec that decodes the audio in F32 in every type, so their files shrink less than the other models'.

The MF model got worse in every quantized type. Its F16 CER per seed was 5.31 to 6.30%, and the means of the quantized types (7.35 to 8.35%) fall outside that range. MF makes its audio in four steps, so an error made in one step may survive to the end. MF delivers its first audio in about a fifth of the time Irodori-TTS takes with 16 steps, so the choice comes down to memory versus speed.

The type a name uses alone

The type a model uses when named alone was decided like this:

• A recognition model uses Q8_0 when its CER is within 0.2 points of F16's, with and without other spellings counted as correct
• A synthesis model uses Q8_0 when its mean CER falls within the range of F16's per-seed CERs
• Q6_K, Q5_K and Q4_K are never used, however good their numbers

The third rule is there because a type that does well on this data may still do worse on other recordings or another GPU. If that happened to the type a name uses alone, it would reach everyone who never chose a type. The smaller types are for people who choose them after seeing the numbers above.

With these rules, parakeet-ja and ReazonSpeech changed to Q8_0. parakeet-v3 stays at F16, since its WER rose 0.3 points at Q8_0, and both Irodori-TTS models stay at F16.

Using Qwen3-TTS's Q5_K and Q4_K on Vulkan

Qwen3-TTS's Q5_K and Q4_K need 0.8.4 on Vulkan. With the Vulkan build of 0.8.3 or earlier, these two files stop partway through synthesis with this error:

speech: internal: no token has a finite logit to pick from

The cause is in ggml's Vulkan backend: a value in the middle of the computation went past the largest number F16 can hold (65504) and became infinite. 0.8.4 builds on a ggml with a fix; Appendix A explains the cause and the fix. Q8_0 and Q6_K synthesize correctly on 0.8.3 and earlier too.

To carry this fix, speech.cpp now builds on my fork of ggml (nyosegawa/ggml) instead of the upstream repository. Appendix C describes how the fork is kept.

Memory and speed

0.8.4 also lowers the memory peak while a model loads. 0.8.3 read each tensor from the file into a temporary buffer as large as the largest tensor; 0.8.4 reads 16 MB at a time, so the peak drops by that buffer.

On Vulkan the memory also drops after loading. On an RTX 2080, a Qwen3-ASR 1.7B worker waiting for requests went from 2635 MB to 2325 MB; Appendix D explains why.

For the same type, the speed is the same as 0.8.3, and so is the time to load. On the Mac, 0.8.4 computes exactly what 0.8.3 did: the output of all ten models matched 0.8.3 byte for byte.

Speed by type

The type does change the speed. I measured the time to the first audio and the time to make a second of audio (RTF) for synthesis, and the time from a finished utterance to its text for recognition. The type a name uses alone is 100%. First, the Apple M5:

• Qwen3-TTS and Qwen3-ASR get faster the smaller the type
  • At Q4_K, Qwen3-ASR 1.7B recognizes 27% faster, and Qwen3-TTS makes its audio in about 30% less time
  • Qwen3-TTS's first audio already arrives in 0.04 to 0.06 s, and Q4_K changes it by a few milliseconds
• The three FastConformer models (parakeet-ja, ReazonSpeech, parakeet-v3) and Irodori-TTS run at about the same speed in every type

Qwen3-TTS and Qwen3-ASR read all their weights from memory for every token they make, so smaller weights mean less to read and a faster model. FastConformer and Irodori-TTS process many frames in each computation, so the computing takes longer than reading the weights, which is likely why smaller weights do not make them faster.

I measured the same on an RTX 2080 (Vulkan) under Windows:

The pattern is the same as on the M5. At Q4_K, Qwen3-ASR 1.7B recognizes 25% faster and Qwen3-TTS 1.7B makes its audio in 22% less time, while FastConformer and Irodori-TTS stay about the same. This release's fix changed how Vulkan computes Q4_K and Q5_K, and they are still faster than Q8_0. On the RTX 2080, parakeet-ja and ReazonSpeech are also 10 to 20% slower in F16 than in Q8_0, so using Q8_0 when they are named alone pays off in speed too.

Load time

Smaller types also load faster. I measured it on an Apple M5 with the system's file cache emptied (the first use after starting the computer) and with the file in the cache (later uses).

• The load time shrinks about in proportion to the file
  • The three FastConformer models load in 0.35 s at F16 and about 0.2 s at Q4_K
  • Qwen3-TTS 1.7B and Qwen3-ASR 1.7B take a little over 0.6 s at Q8_0 with the cache empty, and just under 0.5 s at Q4_K
• With the file in the cache, every model loads in about half the time it takes with the cache empty

The M5's SSD is fast, so every model loads within 0.7 s even with the cache empty. The first run after installing, though, also takes about 15 s to prepare Metal's shaders, once.

Summary

• In 0.8.4, every model but Silero VAD comes in types from Q8_0 down to Q4_K
• parakeet-ja, ReazonSpeech, Qwen3-ASR and Irodori-TTS barely change down to Q6_K, and parakeet-ja and ReazonSpeech not even at Q4_K
• If you use Qwen3-TTS's Q5_K or Q4_K on Vulkan, update to 0.8.4

Appendix A: why Q5_K and Q4_K gave NaN on Vulkan

How it showed up

I found it while running the published files one by one on an RTX 2080 under Windows. Only Qwen3-TTS 0.6B synthesized or failed depending on the type. The same files synthesized fine on the Windows CPU and with Metal on the Mac.

ggml's Vulkan backend has environment variables that turn off some ways of computing. Trying them one at a time, synthesis worked only with GGML_VK_DISABLE_MMVQ or GGML_VK_DISABLE_INTEGER_DOT_PRODUCT set. Both stop the backend from computing matrix products with integer dot products.

The block sum of q8_1 goes past F16

When ggml's Vulkan backend computes a matrix product with integer dot products, it quantizes the activations that multiply the weights to a format called q8_1. q8_1 groups 32 values and stores 32 int8 values, an F16 scale d and an F16 sum s. s is about the sum of the 32 activations.

The largest number F16 can hold is 65504, so 32 activations above 2048 in a row make s infinite. LLMs are known to produce very large activations in a few channels (Sun et al., 2024), and somewhere in Qwen3-TTS they reached this size.

Whether s is used depends on the weight type. Q4_K stores a scale d and a minimum m for every 32 weights and writes a weight as w = d·q − m (q an integer from 0 to 15). Writing an activation as a ≈ d_a·r (r an int8), the dot product of 32 of them is:

\sum_i w_i a_i \approx d \, d_a \sum_i q_i r_i \; - \; m \, s, \qquad s = d_a \sum_i r_i

The first term is an integer dot product, and the second uses s. ggml's shader computes Q4_K and Q5_K exactly this way:

return ACC_TYPE(float(cache_b.ds.x) * float(cache_a[ib_a].dm.x) * float(q_sum) - float(cache_a[ib_a].dm.y) * float(cache_b.ds.y));

ggml-org/ggml v0.25.3: src/ggml-vulkan/vulkan-shaders/mul_mmq_funcs.glsl

cache_b.ds.y is s. When it is infinite, the result is infinite or NaN. Q8_0 and Q6_K have no minimum, so they have no second term and never read s, which is why only those two synthesized. Reading the shaders, eight types use s: Q2_0, Q4_0, Q4_1, Q5_0, Q5_1, Q4_K, Q5_K and IQ1_S.

On the CPU, Q4_K quantizes the activations to a different format, Q8_K, which stores its sums as int16 and its scale as F32, so the problem does not arise there.

The fix

For the eight types that use s, the backend no longer computes through q8_1. ggml already does the same for Q6_K on NVIDIA GPUs, and the fix adds these eight types to that condition. Nothing changes for Q8_0 and Q6_K.

A Codex review of the fix found one more problem. Without q8_1, ggml converts the weights back to F16 and computes the product from them. When a matrix product has no precision set, this path sums in F16 and clips results above 65504 to 65504. Qwen3's decoder in speech.cpp sets no precision, so an input whose block sums stay under 65504 but whose products go past it would be clipped after the fix, where it was correct before. So these eight types now sum in F32. The q8_1 path always summed in integers and F32, so the fixed path handles values as large as before.

Test cases

ggml's tests (test-backend-ops) had no case that fails on this problem, so I added two kinds:

• Activations from 2048 to 4096, so that the sum of 32 goes past F16
• Activations from 512 to 1024 and weights from 0.5 to 1, so that the sums fit but the products go past F16

Each runs for Q4_0, Q5_0, Q4_K and Q5_K as a matrix-vector product, a small batch and a large batch. Q4_1 and Q5_1 are left out because the CPU they are compared with also quantizes their activations to q8_1 and returns -inf the same way.

With the fix, Qwen3-TTS synthesizes at Q5_K and Q4_K too, and its Q8_0 output is byte for byte the same as 0.8.3's.

Appendix B: why Metal's Tensor API stays off

On M5 and later chips, ggml's Metal backend computes matrix products with Metal 4's Tensor API. When I ported Irodori-TTS, I found that on the M5 this computation writes past the end of its output (speech.cpp #13). It happens when the number of output columns is 64 modulo 128, and turns the codec's 64-frame windows into noise.

So up to 0.8.3, speech.cpp set the environment variable GGML_METAL_TENSOR_DISABLE while it prepared the devices. But that changes the environment of any program embedding libspeech, and it is not safe while another thread reads the environment. Since I was forking ggml anyway, I tried fixing where it writes and using the Tensor API.

With the write fixed, 3 of speech.cpp's 25 Metal checks failed.

Two runs of the same build give the same values, so this is not sampling noise. Even the check that runs the DiT once (109 cases) showed the median SNR dropping from 59.1 dB to 52.9 dB, and that difference piled up over 40 sampling steps. The cause is an argument ggml passes to the Tensor API's matrix product:

mpp::tensor_ops::matmul2d<
    mpp::tensor_ops::matmul2d_descriptor(
        NRB, NRA, static_cast<int>(dynamic_extent), false, true, true,
        mpp::tensor_ops::matmul2d_descriptor::mode::multiply_accumulate),
    execution_simdgroups<N_MM_SIMD_GROUP_X * N_MM_SIMD_GROUP_Y>> mm;

ggml-org/ggml v0.25.3: src/ggml-metal/kernels/mul_mm.metal

The sixth argument is relaxed_precision, and true allows a faster, less precise computation. Setting it to false passed all 25 checks, and Irodori-TTS's SNR became 14.0 to 64.8 dB, better than without the Tensor API. But now it was slower.

Every model got 22 to 85% slower. With a choice between less precision and less speed, the Tensor API is off by default. ggml already leaves it off by default on chips before the M5, and the fork extends that to every chip. speech.cpp no longer needs to set the environment variable, and the Mac computes exactly what 0.8.3 did.

Appendix C: the ggml fork

The fixes in Appendices A and B both change ggml's source. So speech.cpp's submodule now points at the speech.cpp branch of nyosegawa/ggml (#111).

A fork that drifts far from upstream becomes hard to update. To keep that from happening, the fork follows these rules:

• The branch is an upstream ggml tag, plus one commit of test cases, plus one commit for each fix
• Every fix comes with a test case that fails on its bug
• Moving to a new ggml tag starts with only the test-case commit on the new tag
  • A test case that passes without its fix means upstream ggml has fixed the bug, and the fix is dropped

The Windows machine has no C++ compiler, so running CI with checks=true now also builds ggml's test-backend-ops.exe. Downloading and running it on Windows shows whether a fix is still needed.

Appendix D: why loading takes less memory

0.8.3 read each GGUF tensor into a std::vector and then sent it to the device. That buffer grew to the size of the largest tensor. In the Qwen3 models the largest is the text embedding, 331 MB in Qwen3-TTS and Qwen3-ASR 1.7B. 0.8.4 reads and sends 16 MB at a time (#105).

On Vulkan there is a second saving. ggml's Vulkan backend stages data in a temporary host buffer before writing it to the GPU, and that buffer stays at the size of the largest write until the process ends. Writing a 331 MB tensor at once leaves a 331 MB buffer behind; writing 16 MB at a time leaves 16 MB.

Appendix E: how it was measured

• Mac: Apple M5, macOS 26.2, Metal
• Windows: Windows 11, NVIDIA GeForce RTX 2080, Vulkan SDK 1.4.357.0
• Accuracy and memory of each type: speech-bench, 2026-10-12, M5
• Synthesis CER: the 20 sentences of speech-bench's prompts/speak-ja-JP.json, seeds 1, 2 and 3
  • Qwen3-TTS used the speaker ono_anna, and Irodori-TTS a voice file made from one reference recording
  • Transcribed with Qwen3-ASR 1.7B Q8_0
• Speed: synthesis is the median of the same 20 sentences, seed 1, three rounds. Recognition uses Common Voice's 4,479 utterances on the M5 and its first 100 (99 kept) on the RTX 2080; parakeet-v3 uses English FLEURS, 299 utterances on the M5 and 100 on the RTX 2080
• Memory: the peak memory footprint of one synthesis or recognition with speech (macOS)
• Q6_K, Q5_K and Q4_K quantize 256 values at a time, so a matrix whose rows are not a multiple of 256 stays Q8_0. That applies to Qwen3-ASR 0.6B's encoder (rows of 896) and to FastConformer's prediction network and joint (640)

References

• speech.cpp
  • speech.cpp
  • v0.8.4
  • #105 Load a model's tensors from its file 16 MB at a time
  • #110 Offer every weight type of each model
  • #111 Build on ggml from a fork
  • nyosegawa/ggml speech.cpp branch
• Models (Hugging Face)
  • sakasegawa/Qwen3-TTS-12Hz-0.6B-CustomVoice-GGUF
  • sakasegawa/Qwen3-ASR-0.6B-GGUF
  • sakasegawa/reazonspeech-nemo-v2-GGUF
  • sakasegawa/Irodori-TTS-v4.1-Small-MF-GGUF
• ggml
  • ggml-org/ggml
  • Massive Activations in Large Language Models
  • ggml-org/llama.cpp #12135: Vulkan: Add DP4A MMQ and Q8_1 quantization shader
  • ggml-org/llama.cpp #30105: vulkan: honor FP32 source precision in MUL_MAT_ID
  • deepbeepmeep/kernels #4: MMQ returns NaN when a 32-activation block sum exceeds 65504 (CUDA)
• Measurement
  • speech-bench
• Related
  • speech.cpp
  • speech.cpp #13: Metal on Apple M5 corrupts matrix products whose column count is 64 modulo 128

今日はspeech.cppの0.8.4のリリースについて書いていきます。いちばん大きな変更は、ほぼすべてのモデルにメモリの少ないPCでも動かせる小さなファイルを用意したことです。

speech.cppは音声合成、音声認識、発話区間検出のモデルをC++で動かすエンジンです (前の記事)。

0.8.4で変わったことは大きく分けて次の4つです。

いちばん大きいのは、モデルごとにファイルの大きさを選択できるようになったことです。小さいタイプを選ぶとメモリはこのくらい減ります。

速さの変わり方はモデルによって違います。Qwen3-ASRとQwen3-TTSは小さいタイプほど速くなり、FastConformer (ReazonSpeechなど) とIrodori-TTSはほとんど変わりません。下の図は1発話を認識する時間を比較した例です。

どちらもApple M5で計測した値です。この記事ではモデルごとの精度とメモリと速さを数字で見ていきます。

0.8.4で変わったこと

• 量子化版のファイルを用意しました
  • Silero VADを除く9つのモデルでQ6_K、Q5_K、Q4_Kを選択できます
  • これまでF16のファイルしかなかったモデルではQ8_0も選択できます
  • Qwen3-TTSとQwen3-ASRは小さいタイプにすると速くもなります
• ReazonSpeechとparakeet-jaは名前だけで指定するとQ8_0のファイルを使うようになりました
  • 精度はF16とほとんど同じで、メモリはほぼ半分になります
• VulkanでQwen3-TTSのQ5_KとQ4_Kが合成の途中でエラーになる問題を直しました
• モデルを読み込むときのメモリのピークが150〜320 MBほど下がりました
• Macで libspeech を組み込んだプログラムの環境変数を書き換えなくなりました

更新のしかた

インストールしたときと同じコマンドで更新できます。Apple siliconのMacとLinuxでは次のコマンドを実行します。

curl -fsSL https://raw.githubusercontent.com/nyosegawa/speech.cpp/main/install.sh | sh

WindowsではPowerShellで次のコマンドを実行します。

irm https://raw.githubusercontent.com/nyosegawa/speech.cpp/main/install.ps1 | iex

ReazonSpeech (reazonspeech-v2) とparakeet-ja (parakeet-tdt_ctc-0.6b-ja) は、名前だけで指定したときに使うファイルがF16からQ8_0に変わりました。そのため更新したあとに初めて使うときにQ8_0のファイル (0.66 GB) をダウンロードします。F16を使い続けたい場合は reazonspeech-v2:f16 のように名前の後ろに :f16 を付けてください。F16のファイルがもう要らなければ次のコマンドで消せます。

speech rm reazonspeech-v2:f16

量子化版の使い方

使い方はモデルの名前の後ろにコロンとタイプを付けるだけです。初めて使うときにそのファイルをHugging Faceからダウンロードします。

speech asr qwen3-asr-1.7b:q6_k meeting.wav
speech tts qwen3-tts-0.6b:q6_k "明日の東京は晴れです。"
speech serve qwen3-tts-1.7b:q4_k qwen3-asr-0.6b silero-vad

speech models を実行すると、どのモデルにどのタイプがあるかを確かめられます。

qwen3-tts-0.6b                 q8_0  1.21 GB  yes      synthesis    de en es fr it ja ko pt ru zh
qwen3-tts-0.6b:q6_k            q6_k  0.99 GB  no       synthesis    de en es fr it ja ko pt ru zh
qwen3-tts-0.6b:q5_k            q5_k  0.87 GB  no       synthesis    de en es fr it ja ko pt ru zh
qwen3-tts-0.6b:q4_k            q4_k  0.76 GB  no       synthesis    de en es fr it ja ko pt ru zh

タイプの数字はウェイトの1つの値をおよそ何ビットで表すかを表しています。数字が小さいほどファイルとメモリは小さくなり、そのぶん精度は下がります。ただ、どのくらい下がるかはモデルによってかなり違いました。

モデルごとの選び方

先にメモリを減らしたいときにどれを選べばよいかをまとめておきます。精度をほとんど落とさずに下げられるタイプは、モデルによってこのように違いました。

モデルごとのメモリと精度は次の図と表のとおりです。メモリは1回認識または合成したときの最大の値です。

ここからはこの表のもとになった数字を見ていきます。計測にはすべてspeech-benchを使い、Apple M5のMetalで動かしています。細かい条件はAppendix Eにまとめました。

日本語の音声認識

Common Voice 8.0の日本語テストセット (4,483発話) でCERを計測しました。スラッシュの後ろの数字は「行う」と「行なう」のような表記の違いを正解として数えたときのCERです。

parakeet-jaとReazonSpeechはQ4_Kまで下げてもCERがほとんど動きませんでした。メモリは1.37 GBから0.47 GBまで減るので、このふたつはメモリが足りなければ迷わずQ4_Kにしてよさそうです。

Qwen3-ASRはQ6_KまではQ8_0とほぼ同じで、Q5_KとQ4_Kに下げるにつれてCERが上がっていきます。おもしろいのは1.7BのQ4_K (1.32 GB) が0.6BのQ8_0 (1.00 GB) よりCERが低いことです。メモリにあと0.3 GBの余裕があるなら、0.6Bのまま使うより1.7BをQ4_Kで使うほうが正確に認識できます。

英語などの音声認識

parakeet-v3 (parakeet-tdt-0.6b-v3) はFLEURSの英語300発話でWERを計測しました。ファイルとメモリはparakeet-jaとほぼ同じです。

音声合成

合成は日本語の20文を3つのシードで合成し、その音声をQwen3-ASR 1.7Bで聞き取って元の文とのCERを計測しました。表の数字は60回の平均です。合成は同じタイプでもシードによってCERが数ポイント変わるので、1〜2ポイントの差ではどちらが良いとは言えません。

Qwen3-TTS 0.6BのQ4_KだけはCERがQ8_0の倍以上になりました。0.6Bを小さくしたいときはQ6_Kまでにしておくのがおすすめです。ただわたしが聞いてみたかぎり、Qwen3-TTSはすべての量子化版において抑揚が抑えられたものが生成されやすい傾向にあるように感じられました。このあたりはなかなかスコアにしづらいので、実際使ってみて、聞いてみて確かめてみると良いと思います。1.7BのQ4_Kは平均ではシードによる差の範囲に収まっていました。ただ、あとで1文ずつ聞いて比較したときに英単語の混ざる文がまったく違う言葉になった例があったので、表ではQ6_Kをおすすめにしています。

Irodori-TTS (irodori-tts) は16ステップで合成して計測しました (デフォルトは40ステップです)。Q4_Kまで下げてもF16との差はシードによる差の範囲に収まっていました。こちらはQwen3-TTSとことなり、量子化したものでも声の抑揚はふつうでした。一方でキャプションの効果など薄れている可能性はあります。なおIrodori-TTSは2つのモデルとも音声をデコードするコーデックをどのタイプでもF32のまま持っているので、ほかのモデルほどファイルが小さくなりません。

MFのほうは量子化したタイプがどれもF16より悪くなりました。F16をシードごとに計測したCERは5.31〜6.30%で、量子化したタイプの平均 (7.35〜8.35%) はこの範囲の外にあります。MFは4ステップで音声を作るので、1回の計算で生じた誤差が最後まで残りやすいのかもしれません。MFは最初の音声が届くまでの時間が16ステップで合成したIrodori-TTSの5分の1ほどと短いので、メモリと速さのどちらを取るかで選ぶことになります。

名前だけで指定したときに使うタイプ

名前だけで指定したときにどのタイプを使うかは次のように決めました。

• 認識のモデルでは、Q8_0とF16のCERの差が表記の違いを数えても数えなくても0.2ポイント以内ならQ8_0を使います
• 合成のモデルでは、Q8_0のCERの平均がF16をシードごとに計測したCERの範囲に入るならQ8_0を使います
• Q6_K、Q5_K、Q4_Kは数字が良くても使いません

3つ目は、今回のデータでは良くても別の録音や別のGPUで精度が下がることがありうるからです。名前だけで指定したときのタイプでそうなると、タイプを選んでいない人全員に影響します。小さいタイプは上の数字を見たうえで選んでもらうことにしました。

この決め方でparakeet-jaとReazonSpeechはQ8_0に変わりました。parakeet-v3はQ8_0でWERが0.3ポイント上がったのでF16のままです。Irodori-TTSは2つのモデルともF16のままにしています。

VulkanでQwen3-TTSのQ5_KとQ4_Kを使うとき

Qwen3-TTSのQ5_KとQ4_KをVulkanで使うには0.8.4が必要です。0.8.3以前のVulkan版でこの2つのファイルを使うと、合成の途中で次のエラーになります。

speech: internal: no token has a finite logit to pick from

原因はggmlのVulkanバックエンドにありました。計算の途中の値がF16で表せる最大の値 (65504) を超えて無限大になっていたのです。0.8.4ではspeech.cppが使うggmlに修正を入れています。原因と直し方はAppendix Aに書きました。Q8_0とQ6_Kは0.8.3以前でも正しく合成できます。

この修正を入れるために、speech.cppはggmlの公式のリポジトリではなくわたしのフォーク (nyosegawa/ggml) を使うようになりました。フォークの扱い方はAppendix Cにあります。

メモリと速さ

0.8.4ではモデルを読み込むときのメモリのピークも下がりました。0.8.3はファイルからテンソルを読むときに、いちばん大きなテンソルと同じ大きさの一時バッファを使っていました。0.8.4は16 MBずつ読むので、そのバッファの分だけピークが下がります。

Vulkanでは読み込みが終わったあとのメモリも減りました。RTX 2080でQwen3-ASR 1.7Bのワーカーが待機している間のメモリは2635 MBから2325 MBになっています。理由はAppendix Dに書きました。

同じタイプなら速さは0.8.3から変わっていません。読み込みにかかる時間も同じです。Macでは0.8.3と同じ計算をしていて、10個のモデルの出力が0.8.3とバイト単位で一致しました。

タイプごとの速さ

タイプを変えると速さも変わります。合成は最初の音声が届くまでの時間と音声1秒を作るのにかかる時間 (RTF) を計測しました。認識は話し終えた1発話を渡してからテキストが返るまでの時間です。名前だけで指定したときのタイプを100%として並べています。まずApple M5の結果です。

• Qwen3-TTSとQwen3-ASRはタイプを小さくするほど速くなります
  • Q4_KにするとQwen3-ASR 1.7Bの認識の時間は27%短くなり、Qwen3-TTSが音声を作る時間は3割ほど短くなりました
  • Qwen3-TTSの最初の音声までの時間はもともと0.04〜0.06秒と短く、Q4_Kにしても数ミリ秒しか変わりません
• FastConformerの3モデル (parakeet-ja、ReazonSpeech、parakeet-v3) とIrodori-TTSはどのタイプでも速さがほとんど変わりません

Qwen3-TTSとQwen3-ASRはトークンを1つ作るたびにウェイト全体をメモリから読み込みます。ウェイトが小さいほど読み込む量が減るので、そのぶん速くなります。FastConformerとIrodori-TTSは1回の計算でたくさんのフレームをまとめて処理します。ウェイトを読み込む時間より計算の時間のほうが長いので、ウェイトを小さくしても速くならないのだと考えられます。

WindowsのRTX 2080 (Vulkan) でも同じように計測しました。

傾向はM5と同じです。Q4_KにするとQwen3-ASR 1.7Bの認識の時間は25%短くなり、Qwen3-TTS 1.7Bが音声を作る時間は22%短くなりました。FastConformerとIrodori-TTSはほとんど変わりません。Vulkanでは今回の修正でQ4_KとQ5_Kの計算のしかたが変わりましたが、それでもQ8_0より速いままです。またRTX 2080ではparakeet-jaとReazonSpeechのF16がQ8_0より1〜2割遅く、名前だけで指定したときにQ8_0を使うようにしたことは速さの面でも得になっています。

読み込みの時間

タイプを小さくするとモデルを読み込む時間も短くなります。OSのファイルキャッシュを空にした場合 (PCを起動して初めて使うときなど) と、キャッシュに載っている場合 (2回目以降に使うとき) に分けてApple M5で計測しました。

• 読み込みの時間はファイルの大きさにほぼ比例して短くなります
  • FastConformerの3モデルはF16の0.35秒がQ4_Kでは0.2秒ほどになりました
  • Qwen3-TTS 1.7BとQwen3-ASR 1.7Bはキャッシュが空のときでQ8_0の0.6秒台がQ4_Kでは0.5秒弱になりました
• キャッシュに載っているときはどのモデルもキャッシュが空のときの半分ほどで読み込めます

M5のSSDは速いので、どのモデルもキャッシュが空の状態から0.7秒以内に読み込めます。ただしインストールして最初に動かすときだけは、これとは別にMetalのシェーダーの準備に15秒ほどかかります。

まとめ

• 0.8.4ではSilero VAD以外のすべてのモデルでQ8_0からQ4_Kまでのタイプを選択できるようになりました
• parakeet-ja、ReazonSpeech、Qwen3-ASR、Irodori-TTSはQ6_Kまで下げても精度がほとんど変わりませんでした。parakeet-jaとReazonSpeechはQ4_Kでも変わりません
• VulkanでQwen3-TTSのQ5_KかQ4_Kを使うときは0.8.4に更新してください

Appendix A: VulkanでQ5_KとQ4_KがNaNになった原因

見つけたきっかけ

公開したファイルをWindowsのRTX 2080で1つずつ動かしていたときに見つけました。Qwen3-TTS 0.6Bだけ、タイプによって合成できたりできなかったりしました。同じファイルでもWindowsのCPUとMacのMetalでは合成できます。

ggmlのVulkanバックエンドには一部の計算方法を使わないようにする環境変数があります。1つずつ試すと、GGML_VK_DISABLE_MMVQ か GGML_VK_DISABLE_INTEGER_DOT_PRODUCT を設定したときだけ合成できました。どちらも行列積を整数の内積で計算する方法を止める変数です。

q8_1のブロックの合計がF16を超える

ggmlのVulkanバックエンドは行列積を整数の内積で計算するときに、ウェイトに掛けるActivationをq8_1という形式に量子化します。q8_1は32個の値をひとまとまりにして、int8の値32個とF16のスケール d とF16の合計 s を持ちます。s は32個のActivationを足した値にほぼ等しくなります。

F16で表せる最大の値は65504なので、2048を超えるActivationが32個続くと s は無限大になります。LLMではごく一部のチャンネルにとても大きなActivationが出ることが知られていて (Sun et al., 2024)、Qwen3-TTSでもどこかでこの大きさに達していました。

s を使うかどうかはウェイトのタイプで決まります。Q4_Kは32個のウェイトごとにスケール d と最小値 m を持ち、ウェイトを w = d·q − m で表します (qは0〜15の整数)。Activationを a ≈ d_a·r (rはint8) と表すと、32個分の内積は次のようになります。

\sum_i w_i a_i \approx d \, d_a \sum_i q_i r_i \; - \; m \, s, \qquad s = d_a \sum_i r_i

1つ目の項は整数の内積で計算できて、2つ目の項で s を使います。ggmlのシェーダーでもQ4_KとQ5_Kはこの式のとおりに計算しています。

return ACC_TYPE(float(cache_b.ds.x) * float(cache_a[ib_a].dm.x) * float(q_sum) - float(cache_a[ib_a].dm.y) * float(cache_b.ds.y));

ggml-org/ggml v0.25.3: src/ggml-vulkan/vulkan-shaders/mul_mmq_funcs.glsl

cache_b.ds.y が s です。これが無限大だと結果も無限大かNaNになります。Q8_0とQ6_Kには最小値がないので2つ目の項がなく、s を使いません。Q8_0とQ6_Kだけが合成できたのはこのためです。シェーダーを読むと s を使うタイプはQ2_0、Q4_0、Q4_1、Q5_0、Q5_1、Q4_K、Q5_K、IQ1_Sの8つでした。

CPUでQ4_Kを計算するときはActivationをQ8_Kという別の形式にしています。Q8_Kは合計をint16で、スケールをF32で持つので、この問題は起きません。

直し方

s を使う8つのタイプではq8_1を使う計算をしないようにしました。ggmlはNVIDIAのGPUでQ6_Kを同じように外していて、その条件にこの8つを足しています。Q8_0とQ6_Kの計算は変わりません。

この修正をCodexにレビューしてもらったところ、もう1つ問題が見つかりました。q8_1を使わない場合、ggmlはウェイトをF16に戻してから行列積を計算します。このとき行列積の精度が指定されていないとF16のまま足し合わせ、65504を超えた結果を65504に切り詰めます。speech.cppのQwen3のデコーダは精度を指定していません。そのためブロックの合計は65504以内でも積の結果が65504を超えると、修正前には正しかった値が修正後に切り詰められてしまいます。そこでこの8つのタイプはF32で足し合わせるようにしました。q8_1を使う計算はもともと整数とF32で足していたので、修正前と同じ大きさの値まで扱えます。

テストケース

ggmlのテスト (test-backend-ops) にはこの問題で失敗するケースがなかったので、2種類を足しました。

• Activationを2048〜4096にして、32個の合計がF16を超えるケース
• Activationを512〜1024、ウェイトを0.5〜1にして、合計は超えないけれど積の結果がF16を超えるケース

これをQ4_0、Q5_0、Q4_K、Q5_Kのそれぞれで、行列とベクトルの積と小さなバッチと大きなバッチの3通りで計算します。Q4_1とQ5_1は比較する相手のCPUもActivationをq8_1にしていて同じように -inf を返すので、ケースに入れていません。

修正したビルドではQwen3-TTSのQ5_KとQ4_Kも合成でき、Q8_0の出力は0.8.3とバイト単位で同じでした。

Appendix B: MetalのTensor APIを使っていない理由

ggmlのMetalバックエンドはM5以降のチップでは行列積をMetal 4のTensor APIで計算します。ところがIrodori-TTSを移植したときに、M5ではこの計算が出力の範囲の外まで書き込むことがわかりました (speech.cpp #13)。出力の列数を128で割って64余るときに起きて、コーデックの64フレームのウィンドウがノイズになります。

そのため0.8.3までは、speech.cppがデバイスを準備する間だけ環境変数 GGML_METAL_TENSOR_DISABLE を設定していました。ただこれは libspeech を組み込んだプログラムの環境変数を書き換えることになりますし、ほかのスレッドが同時に環境変数を読むと安全ではありません。ggmlのフォークを作ることになったので、書き込む位置を直したうえでTensor APIを使えないかを試しました。

書き込む位置を直してspeech.cppのMetalのチェックを実行すると、25個のうち3個が失敗しました。

同じビルドで2回実行すると同じ値が出るので、サンプリングのばらつきではありません。DiTを1回計算するだけのチェック (109項目) でもSNRの中央値が59.1 dBから52.9 dBに下がっていて、この差が40ステップのサンプリングで積み重なっていました。原因はggmlがTensor APIの行列積に渡している引数でした。

mpp::tensor_ops::matmul2d<
    mpp::tensor_ops::matmul2d_descriptor(
        NRB, NRA, static_cast<int>(dynamic_extent), false, true, true,
        mpp::tensor_ops::matmul2d_descriptor::mode::multiply_accumulate),
    execution_simdgroups<N_MM_SIMD_GROUP_X * N_MM_SIMD_GROUP_Y>> mm;

ggml-org/ggml v0.25.3: src/ggml-metal/kernels/mul_mm.metal

6番目の引数は relaxed_precision で、true は精度を下げて速く計算してよいという意味です。これを false にすると25個のチェックはすべて通り、Irodori-TTSのSNRは14.0〜64.8 dBとTensor APIを使わないときより良くなりました。しかしその一方で遅くなってしまいました。

どのモデルも22〜85%遅くなります。精度か速さのどちらかを下げることになるので、Tensor APIはデフォルトで使わないことにしました。ggmlもM5より前のチップではTensor APIをデフォルトで使っていないので、フォークではこれをすべてのチップに広げています。これでspeech.cppは環境変数を設定しなくてよくなり、Macの計算は0.8.3と同じになりました。

Appendix C: ggmlのフォーク

Appendix AとBの修正はどちらもggmlのソースを変える必要があります。そこでspeech.cppのサブモジュールをnyosegawa/ggmlの speech.cpp ブランチに変えました (#111)。

フォークは公式のリポジトリとの差が大きくなると更新できなくなります。そうならないように次の決まりで扱っています。

• ブランチはggmlの公式のタグの上に、テストケースのコミットを1つと不具合ごとの修正のコミットを積んだものにします
• 修正にはその不具合で失敗するテストケースを必ず付けます
• ggmlの新しいタグに上げるときは、まずテストケースのコミットだけを新しいタグに載せて実行します
  • 修正なしで通ったテストケースがあれば公式のggmlで直ったということなので、その修正を外します

WindowsのマシンにはC++のコンパイラがないので、CIを checks=true で実行したときにggmlの test-backend-ops.exe も作るようにしました。Windowsではそれをダウンロードして実行すれば、修正がまだ要るかどうかがわかります。

Appendix D: 読み込みのメモリが減った理由

0.8.3はGGUFのテンソルを1つずつ std::vector に読んでからデバイスに送っていました。このバッファはいちばん大きなテンソルの大きさまで大きくなります。Qwen3系ではテキストの埋め込みがいちばん大きく、Qwen3-TTSとQwen3-ASR 1.7Bでは331 MBあります。0.8.4では16 MBずつ読んで送るようにしました (#105)。

Vulkanではもう1つ減る理由があります。ggmlのVulkanバックエンドはGPUに書き込むデータをホスト側の一時バッファに置いてから送ります。このバッファはいちばん大きな書き込みの大きさのまま、プロセスが終わるまで残ります。331 MBのテンソルを一度に書くと331 MBのバッファが残り続けますが、16 MBずつ書けば16 MBで済みます。

Appendix E: 計測の条件

• Mac: Apple M5、macOS 26.2、Metal
• Windows: Windows 11、NVIDIA GeForce RTX 2080、Vulkan SDK 1.4.357.0
• タイプごとの精度とメモリ: speech-bench、2026-10-12、M5
• 合成のCER: speech-benchの prompts/speak-ja-JP.json の20文、シードは1、2、3
  • Qwen3-TTSの話者は ono_anna で、Irodori-TTSは1つの参照音声から作った声のファイルを使いました
  • 聞き取りにはQwen3-ASR 1.7BのQ8_0を使いました
• 速さ: 合成は同じ20文をシード1で3回ずつ合成した中央値です。認識はM5ではCommon Voiceの4,479発話、RTX 2080ではその最初の100発話 (99発話を使用) です。parakeet-v3はFLEURSの英語で、M5では299発話、RTX 2080では100発話です
• メモリ: speech で1回合成または認識したときのpeak memory footprint (macOS)
• Q6_K、Q5_K、Q4_Kは256個の値をひとまとまりにして量子化するので、行の長さが256で割り切れない行列はQ8_0のまま残ります。Qwen3-ASR 0.6Bのエンコーダ (行の長さ896) と、FastConformerのprediction networkとjoint (640) がこれに当たります

References

• speech.cpp
  • speech.cpp
  • v0.8.4
  • #105 Load a model's tensors from its file 16 MB at a time
  • #110 Offer every weight type of each model
  • #111 Build on ggml from a fork
  • nyosegawa/ggml speech.cpp branch
• モデル (Hugging Face)
  • sakasegawa/Qwen3-TTS-12Hz-0.6B-CustomVoice-GGUF
  • sakasegawa/Qwen3-ASR-0.6B-GGUF
  • sakasegawa/reazonspeech-nemo-v2-GGUF
  • sakasegawa/Irodori-TTS-v4.1-Small-MF-GGUF
• ggml
  • ggml-org/ggml
  • Massive Activations in Large Language Models
  • ggml-org/llama.cpp #12135: Vulkan: Add DP4A MMQ and Q8_1 quantization shader
  • ggml-org/llama.cpp #30105: vulkan: honor FP32 source precision in MUL_MAT_ID
  • deepbeepmeep/kernels #4: MMQ returns NaN when a 32-activation block sum exceeds 65504 (CUDA)
• 測定
  • speech-bench
• 関連する記事
  • speech.cpp
  • speech.cpp #13: Metal on Apple M5 corrupts matrix products whose column count is 64 modulo 128

Today I'd like to look at the OpenAI Decisions API, released in beta on October 6, 2026, and see how accurate it is on image recognition tasks, comparing it with good old trained image models, the Responses API, and a coding agent.

The Decisions API takes questions like "Is there a scratch in this image?" or "What type of document is this?" and returns the answer as probabilities instead of text. OpenAI says it is about 10x faster than the Responses API, and positions it for classification and routing.

A classification API sounds like it should work for image recognition out of the box. But image recognition already has a strong competitor: dedicated models trained on labeled data. So I prepared five tasks of different kinds (image classification, multi-label classification, action anticipation, and anomaly detection) and compared six methods on the same test sets.

About the OpenAI Decisions API

Let's start with what the Decisions API is.

You send the Decisions API something to judge (text, images, or both) and a list of questions. For each question, you write the criteria in natural language as instructions, and the model returns each answer as probabilities. The endpoint is POST /v1/decisions, and the only supported model right now is gpt-6-luna.

There are three question types.

Independent questions about the same input can be sent together in one request. For example, you can ask "Is there a scratch?" and "What is the product category?" at once.

The response looks like this. It is a real output from this experiment, where the model picked a bird species out of 200 candidates, with the middle omitted.

{
  "model": "gpt-6-luna",
  "answers": [
    {
      "type": "choice",
      "name": "species",
      "choice": "186",
      "probabilities": [
        {"value": "0", "probability": 0.02},
        {"value": "1", "probability": 0.01},
        ...
        {"value": "186", "probability": 0.38},
        ...
      ],
      "confidence": 0.38
    }
  ],
  "usage": {"input_tokens": 2346, "output_tokens": 0, ...}
}

Notice that output_tokens is 0. The Decisions API doesn't generate text; it only returns probabilities over the candidates.

How is it different from the Responses API?

If all you want is to pick one of a fixed set of candidates, you can do that with Structured Outputs in the Responses API too. Pass a JSON Schema with an enum, and you will never get a value outside the candidates. The difference is in how the answer is produced.

The Responses API does reasoning first, then generates text (JSON) token by token. Raising the reasoning effort makes it think more, but it also takes longer. The Decisions API returns per-candidate probabilities in a single decision, so its latency is shorter.

The other difference is the nature of the probabilities. If you ask the Responses API to "write your confidence from 0 to 1," you'll get a number, but it is a number the model wrote as text. The Decisions API returns a distribution over all candidates, so you can use it directly to set thresholds or pull out the Top-5. How far you can trust these probabilities is something I check later in the article.

Pricing

Pricing is also computed differently from the Responses API. Even with the same gpt-6-luna, the Decisions API only charges for input tokens.

The input price is the same, so if you only need a short JSON back, the difference from the Responses API is small. When the Responses API produces reasoning tokens or long outputs, it costs more. On the other hand, long questions or candidate descriptions increase input tokens for the Decisions API too, so it isn't always cheaper.

What tasks is it good for?

Now that we know how it works, let's think about what it is good for. The official guide lists classification, routing, and prioritization as examples. It also describes a voice-controlled app where the Live API handles the conversation and the Decisions API picks an action such as "go to the next slide" or "do nothing."

These have three things in common.

• The answer fits into a fixed set of candidates, true/false, or one of a few levels
• You want the answer quickly, every time
• You want to use how likely the answer is as a number in later processing

On the other hand, the official guide recommends Structured Outputs or function calling in the Responses API when you want to extract information into JSON with an arbitrary schema, have the model write explanations, or call tools with arguments.

Much of image recognition can be written in this "answer from a fixed set of candidates" form. But the contents vary a lot: telling 200 bird species apart by their feather patterns and deciding whether a person is riding a bicycle need very different abilities. The goal of the second half of this article is to find out which image recognition tasks the Decisions API can handle.

Usage, speed, and cost

Before that, let's look at how to call it and at the speed and cost measured in this experiment.

Usage

In the Python SDK, client.decisions.create(...) is available from 3.26.0. In my experiment code I sent requests with the SDK's generic client.post. Below is the part of the HICO task, which judges relations between people and objects, where 20 actions are asked as predicate questions in one request.

messages = [{
    "role": "user",
    "content": [
        {"type": "input_text", "text": task},
        {"type": "input_image",
         "image_url": "data:image/png;base64," + b64,
         "detail": "high"},
    ],
}]

questions = [
    {
        "type": "predicate",
        "name": f"label_{k}",
        "instructions": f"Does the image show {v}? Judge each interaction "
                        "independently. A person and object merely "
                        "co-occurring is insufficient.",
    }
    for k, v in classes.items()  # e.g. "a person riding a bicycle"
]

result = client.post(
    "/decisions",
    cast_to=dict,
    body={"model": "gpt-6-luna", "input": messages, "questions": questions},
)
scores = [a["probability"] for a in result["answers"]]

For the 200-species bird classification, I made a single choice question with the 200 species names as candidates.

questions = [{
    "type": "choice",
    "name": "species",
    "instructions": task,
    "choices": [{"value": k, "description": v} for k, v in classes.items()],
}]

Images are passed to input_image as base64 data URLs. A single request can include up to 128 images.

Speed

Here is the latency distribution per item across the five tasks.

The numbers are medians. On single-image tasks, the Decisions API returned in 0.3 to 0.9 seconds, about 5 to 11 times faster than the Responses API. On EPIC and LOCO, which take four images, it took 3 to 6 seconds and the gap shrank. The reasoning effort for the Responses API was medium.

Cost

Next are the API cost per 1,000 items and the number of input tokens per request.

Costs are estimates computed from usage. Running 5 tasks x 200 items through both APIs came to about $0.59 in total.

Which API was cheaper flipped depending on the task.

• HICO: the Decisions API costs more
  • All 20 instructions count as input tokens
  • About 4.7x the input tokens of the Responses API
• EPIC and LOCO: the Responses API costs about 1.7 to 4.9x more
  • Reasoning tokens are billed as output

In short, the cost of the Decisions API is decided by how you design the questions, and the cost of the Responses API is decided by how much it reasons.

Comparing on image recognition tasks

Now for the main part. I looked at how well the Decisions API works for image recognition on five tasks.

The five tasks

I picked them so that the required abilities would be as varied as possible. Each test set has 200 items, so I also look at 95% CIs.

The six methods

The image model is google/siglip2-base-patch16-256, and the APIs and the Agent use gpt-6-luna. The APIs and the Agent get no training data, only the candidate names and the prompt. So the SigLIP2 linear probe and FT use labeled data, while zero-shot, the APIs, and the Agent don't.

Only for LOCO, anomalous images can't be used for training, so I replaced the linear probe with "kNN distance to normal samples" and FT with "a teacher-student model trained on normal images only." The APIs and the Agent get three normal samples plus the image to judge.

Overall results

Here are the results for 5 tasks x 6 methods.

The best method differs from task to task. Trained SigLIP2 was best on CUB and HICO, the Responses API on RVL-CDIP and LOCO, and the Agent on EPIC. The Decisions API wasn't first on any task, but it was close to first on HICO and RVL-CDIP, and last on CUB.

With only 200 test items, though, the question is how much the differences in point estimates mean. Let's add 95% confidence intervals (CIs).

On EPIC the CIs overlap almost everywhere, so it's hard to say any method is better. On the other hand, the Decisions API on CUB and SigLIP2 zero-shot on HICO and LOCO clearly stand apart from the rest.

Below, I go through the tasks where the Decisions API was strong, where it was weak, and where it lost to the Responses API.

Where the Decisions API was strong: HICO and RVL-CDIP

On HICO, the Decisions API reached a macro F1 of 74.9%, 9.8 points above the Responses API's 65.1%, and close to the trained SigLIP2 FT (78.8%).

HICO asks for 20 actions to be judged independently, which maps directly onto 20 predicate questions. I had the Responses API write all 20 true/false values in one JSON, and its recall was low at 73.5% (84.7% for the Decisions API), with many missed actions. On mAP, which measures ranking by probability, the Decisions API was the highest at 90.6%.

On RVL-CDIP, the Responses API reached 72.0% and the Decisions API 70.0%, more than 10 points above SigLIP2 trained on 10 images per class (59.5%). The Decisions API matched the Responses API's accuracy at a fifth of the latency.

Where the Decisions API was weak: CUB

On CUB, the Decisions API scored 53.0%, the lowest of the six methods and 14 points below the Responses API's 67.0%. Many of the 200 species can only be told apart by feather patterns or beak shape. The Responses API can narrow down the candidates while putting features into words during reasoning, but the Decisions API has to produce probabilities for 200 candidates in a single decision. I think that is where the gap comes from.

Where the Responses API was strong: LOCO and EPIC

On LOCO, the Responses API had the highest AUROC at 0.871, and the Decisions API reached 0.817.

On structural anomalies such as scratches and stains, the two APIs were about equally accurate. On logical anomalies, where the number or layout of parts is wrong, the Responses API was clearly ahead. To spot these, you need to look at the three normal samples, work out "what should be there, how many, and where," and compare that with the image being judged. The Responses API was better at problems like this, where you have to compare several images and think.

On EPIC, every method had a low Top-1 accuracy of 14 to 24%, and the 95% CIs overlapped heavily, so there was no clear difference between methods.

A side note: choose a better image model

So far I have used SigLIP2 as the shared image model, but switching to a model that fits the target easily raises accuracy, even when you only train a linear layer.

On CUB, training a linear probe on BioCLIP 2.5, which is pretrained on images of living things, with the same 2,000 training images gave 93.0% (SigLIP2 FT: 76.0%). Before choosing an API, look for a pretrained model that fits your target (yes, obviously).

Accuracy and latency

To see accuracy and latency together, I plotted latency on the x-axis and the metric on the y-axis.

The closer to the top left, the faster and more accurate the method. On HICO and RVL-CDIP, the Decisions API is the furthest top-left among the APIs. Trained SigLIP2 runs locally in 20 to 80 ms per item, almost two orders of magnitude faster than the APIs.

The Agent took 10 to 15 seconds per item on every task, and there was no task where it clearly beat the Responses API. It rarely used cropping or resizing, and I saw no improvement worth the extra time.

How far can you trust the Decisions API's probabilities?

Finally, let's check how well the Decisions API's probabilities match actual accuracy (calibration). If 80% of the answers with probability 0.8 are correct, you can use that probability directly to set a threshold.

How far off they were depended on the task and the question type. ECE is the Expected Calibration Error; the closer to 0, the better the probabilities match accuracy.

• predicate
  • HICO: almost on the diagonal, ECE 0.024
  • LOCO: ranks well (AUROC 0.817), but ECE is 0.254
• choice
  • CUB: probabilities come out low (mean 37.3%, accuracy 53.0%)
  • EPIC: probabilities come out high (mean 37.9%, accuracy 19.5%)
  • RVL-CDIP: fairly close (mean 76.6%, accuracy 70.0%)

The Decisions API's probabilities are easy to use for ranking, but whether you can treat their values as accuracy depends on the task. It is safer to check against labeled data before deciding on a threshold.

Choosing a method

Image recognition methods should be chosen not only by accuracy, but also by latency and cost requirements, whether you can prepare training data, and how hard the problem is. First, here are the numbers for the methods compared in this article.

Local methods have no API cost, but you still pay for GPUs and electricity. I ran the Agent on a ChatGPT plan this time, so its cost is the usage converted at API prices. Also, the Agent's "good at" row is an assumption; in this experiment it didn't clearly beat the Responses API on any task.

In practice, methods I didn't compare are also options. Placed by the amount of training data and latency, they look like this.

• When you have little training data
  • kNN on embeddings: register a few images per class and classify; adding a class needs no training
  • Few-shot VLM: pass reference images for each class to the Responses API or similar
• When the volume is high and API cost or latency doesn't fit
  • Distillation: label data with the Decisions or Responses API and train an image model on those labels
  • Cascade: let an image model decide first and send only low-probability items to the API
• When you can't send images to an external API
  • Local VLM: run an open-weight VLM on your own GPUs
• When you have plenty of training data and want a more accurate VLM
  • Fine-tuned VLM: train an open-weight VLM with LoRA or similar

In a cascade, the Decisions API's probabilities can serve as the threshold for deciding whether to call the API. But as we just saw, how far off the probabilities are depends on the task, so the threshold has to be set with labeled data.

Putting it together, the order of decisions looks like this.

• You have plenty of training data
  • Train an image model (start with a linear probe, then FT if needed)
• You only have a few images per class
  • Try kNN on embeddings or a few-shot VLM
• You have no training data
  • If the volume is high, label with an API and distill, or build a cascade
  • If you need answers in about a second, the Decisions API
  • If you can wait a few seconds and need fine details or multi-image comparison, the Responses API
  • If the volume is low and re-checking images or searching helps, the Agent
• You can't send images outside
  • A local VLM, or train an image model

Training an image model has the lowest latency and cost, but as RVL-CDIP showed, it loses to the APIs when training data is scarce and the model doesn't fit the target. If you have no training data and aren't sure, the Decisions API is an easy baseline to start with.

How to improve each method

Every method here was compared with almost default settings, so each still has room to grow.

Training an image model

• Choose a pretrained model that fits the target
  • Like BioCLIP 2.5 in the side note, this had the biggest effect in this experiment
• Add more training data (about 10 per class this time)
• Revisit the FT settings
  • Only 3 epochs this time, so there is room for data augmentation and learning rate tuning

Decisions API

• Optimize the instructions and the description of each choice
  • GEPA is an optimizer that has an LLM reflect on failed examples and rewrite the prompt
  • In DSPy it is available as dspy.GEPA. With the standalone gepa package you write your own evaluation function, so the Decisions API's question definitions could also be optimized
• Narrow down the candidates before asking
  • When there are 200 candidates as in CUB, pass only an image model's Top-10 to choice, or split into two stages, family then species
• Calibrate the probabilities
  • Set thresholds with labeled data, or correct them with temperature scaling
• Pass reference images for each class along with the input (up to 128 per request)

Responses API

• Write it as a DSPy module and optimize the prompt with GEPA
• Raise the reasoning effort (medium this time)
• Narrow down the candidates with an image model first
• Pass reference images for each class as few-shot examples

Agent

• Give it task-specific knowledge with Agent Skills
• Give it a tool to search for reference images
• Let it call a trained image model as a tool, and leave checking the result to the Agent

Summary

• The Decisions API was strong at judging several conditions at once (HICO) and at document classification with little data (RVL-CDIP), and was 1.6 to 11 times faster than the Responses API, but it lost to the Responses API on 200-species fine-grained classification (CUB) and on anomaly detection that requires reading rules from normal samples (LOCO)
• If you have labeled data and an image model that fits the target, training an image model wins on both latency and accuracy; on CUB, a linear probe on BioCLIP 2.5 reached 93 to 94%
• The Decisions API's probabilities are easy to use for ranking, but calibration varies by task, so check them against labeled data before relying on them

Appendix

A. Experimental details

• The image model is google/siglip2-base-patch16-256. Zero-shot uses similarity to text prompts, the linear probe is logistic regression on frozen embeddings, and FT trains the image encoder and classification head for 3 epochs
• The APIs and the Agent use gpt-6-luna. Reasoning effort for the Responses API and Codex Agent was medium; no equivalent setting was given to the Decisions API. Images were sent with detail: high
• For CUB the APIs ran sequentially; for the other tasks each method ran up to 4 requests in parallel. For EPIC and LOCO, the first 2 items were smoke tests and are excluded from latency. Local latency includes image loading, preprocessing, and inference, but not model startup or training
• For CUB, I used 10 images per species from the official train split for training, 5 for validation, and 1 per species from the official test split, 200 in total, as the test set. The APIs and the Agent only got the 200 species names, no bounding boxes or part annotations
• For HICO, I picked 4 actions each for bicycle, horse, cup, book, and chair, 20 labels in total. Of the 200 test images x 20 labels, only the 682 pairs with official positive/negative annotations (393 positive) are evaluated. This is not comparable with official scores on all 600 HICO labels
• For RVL-CDIP, I used 10 images per class for train, 5 for val, and 12 to 13 for test from the public Mini version. OCR results included in the mirror were not given to the models
• For EPIC, I used 4 frames at 7.1, 5.1, 3.1, and 1.1 seconds before the target action starts, and split so that no video is shared between train, val, and test. Of the 20 candidates, 14 appear as correct answers in the test set
• For LOCO, the 200-image test set over 5 categories consists of 100 normal, 50 logical anomaly, and 50 structural anomaly images. Anomalous images were used neither for training nor for threshold tuning. The APIs and the Agent got 3 normal samples, while the two SigLIP2 methods used 60 normal samples per category, so the amount of information differs between methods
• Codex Agent ran in a per-case OS sandbox, and I confirmed that it could be denied reading the directory with the ground-truth labels, rewriting the inputs, and making external network connections from commands

B. What this experiment can't tell you

• This is a small comparison with 200 items per task. It doesn't establish which method is better on the full datasets or in general
• The APIs and the Agent use no labeled data, while the training-based methods do. Internal image processing also differs between methods
• Except for BioCLIP 2.5 in the side note, the image model is the shared SigLIP2, not a dedicated model well tuned for each task. FT is also a small trial with only 3 epochs
• Overlap between pretraining data and test images was not checked for any method
• Costs are estimates from usage and the price list, not checked against invoices

C. Making the Decisions API talk one hiragana character at a time

This one is just for fun. Since a choice can have up to 255 candidates, I wondered whether making every hiragana character a candidate would let it hold a conversation by next character prediction instead of next token prediction, so I built it. Of course, this is not what the Decisions API is meant for.

The mechanism is simple.

• The candidates are 80 hiragana characters, the Japanese comma and period, and <END>, 83 in total
• Put the conversation history and the reply so far into input, and have choice pick the next character
• Append the chosen character to the reply and ask again (stop at <END> or at 50 characters)
• Each candidate's description contains the reply with that character appended

choices: VALUES.map(value => ({ value, description: value === END
  ? `現在の返答 ${JSON.stringify(prefix)} を完成した回答として終了します。`
  : `次の一文字として「${value}」を追加します。追加後の返答は ${JSON.stringify(prefix + value)} です。` }))

The median latency per character is about 250 ms, so the characters come out at about human typing speed. But every request sends the whole conversation and the descriptions of all 83 candidates, which costs about 3,000 tokens per character.

As for the conversation, see the screenshot above. To "Hello, nice to see you again today" it replied "あとでね" ("later"), and when I introduced myself it said "あとでね" again. On the other hand, when I asked whether it remembered my name, it correctly answered "なつき" (Natsuki).

To "Greet me briefly" it replied "ちわ。" ("hey."), and to "Keep writing あ for 50 characters" it obediently kept lining up "あ".

Putting 86 example conversations and every per-character choice in them (1,560 steps) into the context as many-shot examples raised the score on predicting the next character of a half-written reply from 5 to 7 out of 8. Even so, when starting a conversation from an empty reply, it often collapsed into repeating the same character, like "おこごごごご...". Once it picks a strange character, the reply containing it becomes the next input, and I think it can't recover from there.

References

• OpenAI Decisions API
  • Decisions guide
  • Decisions API reference
  • Decisions with voice
  • Changelog (October 2026)
  • Decisions Playground
• Other OpenAI docs
  • Pricing
  • GPT-6 Luna
  • Structured Outputs
  • Prompt caching
• Prompt optimization
  • GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning
  • dspy.GEPA
  • gepa-ai/gepa
• Image models
  • google/siglip2-base-patch16-256
  • imageomics/bioclip-2.5-vith14
• Datasets
  • CUB-200-2011
  • HICO
  • RVL-CDIP
  • EPIC-KITCHENS-100
  • MVTec LOCO AD

今日は2026年10月6日にbetaとして公開されたOpenAI Decisions APIについて、画像認識タスクでどのくらいの精度が出るのかを、昔ながらの画像モデルの学習やResponses API、Coding Agentと比べながら見ていきたいと思います。

Decisions APIは「この画像に傷はある？」「この書類はどの種類？」といった質問を投げると、答えを文章ではなく確率で返してくれるAPIです。OpenAIはResponses APIの約10倍速いと案内していて、分類やルーティングの用途を想定しています。

分類のAPIと聞くと、画像認識にそのまま使えそうに見えます。ただ、画像認識には教師データで学習した専用モデルという強い競合がいます。そこで今回は、画像分類、マルチラベル分類、行動予測、異常検知という性質の違う5つのタスクを用意して、6つの手法を同じテストセットで比べました。

OpenAI Decisions APIについて

まずはDecisions APIがどういうものかを見ていきます。

Decisions APIには、判定対象（テキスト、画像、またはその両方）と、質問のリストを渡します。質問ごとに判定基準を instructions として自然言語で書いておくと、モデルがそれぞれの答えを確率として返します。エンドポイントは POST /v1/decisions で、対応モデルは今のところ gpt-6-luna だけです。

質問には3つの型があります。

同じ入力に対する独立した質問は、1つのリクエストにまとめて投げられます。たとえば「傷があるか」と「商品カテゴリは何か」を一度に聞けます。

レスポンスは次のような形です。今回の実験で鳥の種類を200候補から選ばせたときの実際の出力を、途中を省略して載せています。

{
  "model": "gpt-6-luna",
  "answers": [
    {
      "type": "choice",
      "name": "species",
      "choice": "186",
      "probabilities": [
        {"value": "0", "probability": 0.02},
        {"value": "1", "probability": 0.01},
        ...
        {"value": "186", "probability": 0.38},
        ...
      ],
      "confidence": 0.38
    }
  ],
  "usage": {"input_tokens": 2346, "output_tokens": 0, ...}
}

output_tokens が0になっているところが特徴的です。Decisions APIは文章を生成せず、候補への確率だけを返します。

Responses APIと何が違うのか

固定の候補から1つ選ばせるだけなら、Responses APIのStructured Outputsでも作れます。enum を使ったJSON Schemaを渡せば、候補以外の値は返ってきません。では何が違うのかというと、処理の流れが違います。

Responses APIは、reasoningをしてから、文章（JSON）をtokenごとに生成して返します。reasoning effortを上げれば考える量が増えますが、そのぶん時間がかかります。Decisions APIは1回の判定で候補ごとの確率を返すので、レイテンシが短くなります。

もう1つの違いは、確率の性質です。Responses APIに「confidenceを0〜1で書いて」と頼むと数値は返ってきますが、それはモデルが文章として書いた数値です。Decisions APIの確率は候補全体に対する分布として返ってくるので、閾値を決めたり、Top-5を取り出したりする処理にそのまま使えます。この確率がどこまで信用できるかは、後半で確かめます。

料金

料金もResponses APIとは計算の仕方が違います。同じ gpt-6-luna でも、Decisions APIは入力tokenだけに課金します。

入力の単価は同じなので、短いJSONを返させるだけならResponses APIとの差は大きくありません。Responses APIでreasoning tokenや長い出力が発生すると、そのぶん高くなります。逆に、Decisions APIでも質問や候補の説明が長ければ入力tokenが増えるので、常に安いわけではありません。

どういうタスクに向いているか

さて、仕組みが分かったところで、Decisions APIが向いているタスクを考えてみます。公式ガイドでは、分類、ルーティング、優先度付けが例に挙がっています。また、音声で操作するアプリで、Live APIが会話を受け持ち、Decisions APIが「次のスライドへ進む」「何もしない」といった操作を選ぶ構成も紹介されています。

これらに共通するのは、次の3つの性質です。

• 答えが固定の候補か、true／falseか、levelのどれかに収まる
• 毎回すばやく答えが欲しい
• 答えの確からしさを数値として後段の処理で使いたい

逆に、任意のスキーマのJSONで情報を抽出したり、説明文を書かせたり、引数つきでツールを呼ばせたりする場合は、Responses APIのStructured Outputsやfunction callingを使うように公式ガイドでも案内されています。

画像認識の多くは、この「答えが固定の候補に収まる」形で書けます。ただし中身はいろいろで、200種類の鳥を羽の模様で見分ける問題と、人が自転車に乗っているかを判定する問題では、必要な能力がかなり違います。どういう画像認識タスクならDecisions APIで足りるのかを調べるのが、この記事の後半の目的です。

使い方・速度・費用

その前に、実際の呼び出し方と、今回の実験で測った速度と費用を見ておきます。

使い方

Python SDKでは3.26.0以降で client.decisions.create(...) が使えます。今回の実験コードでは、SDKの汎用の client.post でリクエストを送りました。以下は人と物の関係を判定するHICOタスクで、20個の行動を predicate として1リクエストで聞いた部分です。

messages = [{
    "role": "user",
    "content": [
        {"type": "input_text", "text": task},
        {"type": "input_image",
         "image_url": "data:image/png;base64," + b64,
         "detail": "high"},
    ],
}]

questions = [
    {
        "type": "predicate",
        "name": f"label_{k}",
        "instructions": f"Does the image show {v}? Judge each interaction "
                        "independently. A person and object merely "
                        "co-occurring is insufficient.",
    }
    for k, v in classes.items()  # 例: "a person riding a bicycle"
]

result = client.post(
    "/decisions",
    cast_to=dict,
    body={"model": "gpt-6-luna", "input": messages, "questions": questions},
)
scores = [a["probability"] for a in result["answers"]]

200種類の鳥の分類では、choice 型の質問を1つ作り、候補に200種の種名を並べました。

questions = [{
    "type": "choice",
    "name": "species",
    "instructions": task,
    "choices": [{"value": k, "description": v} for k, v in classes.items()],
}]

画像は input_image にbase64のdata URLとして渡しています。1リクエストに入れられる画像は最大128枚です。

速度

今回の5タスクで測った1件あたりのレイテンシの分布です。

数値は中央値です。画像1枚のタスクでは、Decisions APIは0.3〜0.9秒で返り、Responses APIより約5〜11倍速くなりました。ただし画像を4枚渡すEPICとLOCOでは3〜6秒かかり、差も小さくなっています。Responses APIのreasoning effortは medium です。

費用

次は1,000件あたりのAPI料金と、1リクエストの入力token数です。

料金は usage から計算した概算で、5タスク×200件を両方のAPIで回しても合計約$0.59でした。

どちらが安いかはタスクによって逆転しました。

• HICO：Decisions APIが高い
  • 20個の instructions がすべて入力tokenになる
  • 入力tokenはResponses APIの約4.7倍
• EPIC・LOCO：Responses APIが約1.7〜4.9倍高い
  • reasoning tokenが出力として課金される

整理すると、Decisions APIの費用は質問の設計で決まり、Responses APIの費用はreasoningの量で決まります。

画像認識タスクで比較してみる

ここからが本題です。Decisions APIが画像認識でどこまで使えるかを、5つのタスクで調べました。

5つのタスク

必要な能力がなるべくばらけるように選びました。どのタスクもテストセットは200件なので、95% CIも合わせて見ていきます。

6つの手法

画像モデルには google/siglip2-base-patch16-256 を使い、APIとAgentには gpt-6-luna を使いました。APIとAgentには学習データを渡さず、候補の名前とプロンプトだけを渡しています。つまり、SigLIP2のlinear probeとFTは教師データを使い、zero-shot、API、Agentは使わないという条件の違いがあります。

LOCOだけは異常画像で学習できないので、linear probeを「正常例とのkNN距離」に、FTを「正常画像だけで学習するteacher-student方式」に置き換えました。APIとAgentには、正常例3枚と判定対象1枚を渡しています。

全体の結果

5タスク×6手法の結果を並べると次のようになりました。

一番良い手法がタスクごとにばらばらです。CUBとHICOでは学習したSigLIP2が、RVL-CDIPとLOCOではResponses APIが、EPICではAgentが最高値でした。Decisions APIはどのタスクでも1位にはなっていませんが、HICOとRVL-CDIPでは1位との差が小さく、CUBでは最下位でした。

ただ、200件の評価では点推定の差がどこまで意味を持つかが問題になります。95%信頼区間（CI）を付けて見てみます。

EPICは全体的にCIが重なっていて、どの手法が良いとも言いにくい状態です。一方で、CUBのDecisions API、HICOのSigLIP2 zero-shot、LOCOのSigLIP2 zero-shotなどは、明らかに他から離れています。

ここからは、Decisions APIが強かったタスク、弱かったタスク、Responses APIに負けたタスクの順に見ていきます。

Decisions APIが強かったタスク：HICOとRVL-CDIP

HICOでは、Decisions APIのmacro F1は74.9%で、Responses APIの65.1%を9.8ポイント上回り、学習したSigLIP2 FT（78.8%）に近い値になりました。

HICOは20個の行動を独立に判定する問題なので、predicate を20個並べる形にそのまま合います。Responses APIには20個のtrue／falseを1つのJSONで書かせましたが、recallが73.5%（Decisions APIは84.7%）と低く、行動の見落としが目立ちました。確率によるランキングで測るmAPでは、Decisions APIが90.6%で最も高くなっています。

RVL-CDIPでは、Responses APIが72.0%、Decisions APIが70.0%で、各クラス10枚で学習したSigLIP2（59.5%）を10ポイント以上上回りました。Decisions APIはResponses APIとほぼ同じ精度を、5分の1のレイテンシで出しています。

Decisions APIが弱かったタスク：CUB

CUBでは、Decisions APIは53.0%で6手法の中で最も低く、Responses APIの67.0%とは14ポイントの差がありました。200種の中には、羽の模様やくちばしの形でしか見分けられない種が多くあります。Responses APIはreasoningで特徴を言葉にしながら候補を絞れますが、Decisions APIは1回の判定で200候補の確率を出すので、この差が出たのだと考えています。

Responses APIが強かったタスク：LOCOとEPIC

LOCOでは、Responses APIのAUROCが0.871で最も高く、Decisions APIは0.817でした。

傷や汚れのような構造的異常では、2つのAPIの精度はほぼ同じでした。一方、部品の個数や配置がおかしい論理的異常では、Responses APIのほうがはっきり高くなりました。これを見抜くには、正常例3枚を見て「何がいくつ、どこにあるべきか」をつかみ、判定する画像と見比べなければなりません。こういう複数の画像を見比べて考える問題は、Responses APIのほうが得意でした。

EPICは全手法でTop-1 accuracyが14〜24%と低く、95% CIも大きく重なっていて、手法の差ははっきりしませんでした。

余談：画像モデルを選び直す

ここまでSigLIP2を共通の画像モデルとして使ってきましたが、対象に合うモデルに変えると、線形層だけの学習でもあっさり精度が上がります。

CUBで、生物の画像で事前学習されたBioCLIP 2.5に同じ学習データ2,000枚でlinear probeを学習すると、93.0%になりました（SigLIP2 FTは76.0%）。APIを選ぶ前に対象に合う事前学習モデルを探すのがよいです（あたりまえ体操）。

精度とレイテンシ

精度とレイテンシを同時に見るために、横軸にレイテンシ、縦軸に評価指標をとって並べました。

左上にあるほど、速くて精度が高い手法です。HICOとRVL-CDIPでは、APIの中でDecisions APIが最も左上にいます。学習したSigLIP2はローカルで1件20〜80msなので、APIより2桁近く速く動きます。

Agentはどのタスクでも1件10〜15秒かかり、Responses APIを明確に上回ったタスクはありませんでした。cropやresizeを使ったケースも少なく、かかる時間に見合う改善は見られませんでした。

Decisions APIの確率はどこまで信じられるか

最後に、Decisions APIの確率が実際のaccuracyとどれくらい一致しているか（キャリブレーション）を確かめます。確率0.8の答えの8割が正しければ、その確率をそのまま閾値の設定に使えます。

ずれ方はタスクと質問の型によって違いました。ECEはExpected Calibration Errorで、0に近いほど確率とaccuracyが合っています。

• predicate
  • HICO：ほぼ対角線上で、ECEは0.024
  • LOCO：ランキングはできる（AUROC 0.817）が、ECEは0.254
• choice
  • CUB：確率が低めに出る（平均37.3%、accuracy 53.0%）
  • EPIC：確率が高めに出る（平均37.9%、accuracy 19.5%）
  • RVL-CDIP：比較的近い（平均76.6%、accuracy 70.0%）

Decisions APIの確率はランキングには使いやすい一方、値をそのままaccuracyとして扱えるかはタスクによって違います。閾値はラベル付きのデータで確かめてから決めたほうが安全です。

使い分け

画像認識の手法は、精度だけでなく、レイテンシや費用の要件、学習データを用意できるか、問題の難しさで選ぶ必要があります。まず、今回比べた手法の数字を並べます。

ローカルの手法のAPI料金はなしですが、GPUや電気代はかかります。Agentは今回ChatGPTの利用枠で動かしたので、料金はusageをAPIの単価で換算した値です。また、Agentの「得意な問題」は想定で、今回はどのタスクでもResponses APIを明確には上回りませんでした。

実際には、今回比べていない手法も候補になります。学習データの量とレイテンシで並べると、次のような位置づけになります。

• 学習データが少ないときの手法
  • embeddingのkNN：各クラス数枚の画像を登録するだけで分類でき、クラスの追加にも学習が要らない
  • VLMのfew-shot：Responses APIなどに各クラスの参照画像を一緒に渡す
• 件数が多く、APIの費用やレイテンシが合わないときの手法
  • 蒸留：Decisions APIやResponses APIでラベルを付け、そのラベルで画像モデルを学習する
  • カスケード：画像モデルで先に判定し、確率が低いものだけAPIに回す
• 画像を外部のAPIに送れないときの手法
  • ローカルVLM：オープンウェイトのVLMを自前のGPUで動かす
• 学習データが十分にあり、VLMの精度を上げたいときの手法
  • VLMのFT：オープンウェイトのVLMをLoRAなどで学習する

カスケードでは、Decisions APIの確率をAPIに回すかどうかの閾値に使えます。ただし、先ほど見たように確率のずれ方はタスクによって違うので、閾値はラベル付きデータで決める必要があります。

これらをまとめると、判断の順番は次のようになります。

• 学習データが十分にある
  • 画像モデルを学習する（まずlinear probe、足りなければFT）
• 各クラス数枚だけある
  • embeddingのkNNか、VLMのfew-shotを試す
• 学習データがない
  • 件数が多いなら、APIでラベルを付けて蒸留するか、カスケードにする
  • 1秒前後で返したいなら、Decisions API
  • 数秒待てて、細部や複数画像の比較が必要なら、Responses API
  • 件数が少なく、画像の調べ直しや検索に意味があるなら、Agent
• 画像を外部に送れない
  • ローカルVLMか、画像モデルの学習

画像モデルの学習はレイテンシも費用も最も小さいものの、RVL-CDIPのように学習データが少なくモデルが対象に合わないと、APIに負けます。学習データがなく迷うときは、まずDecisions APIをベースラインにするのが手軽です。

それぞれの手法を改善するには

今回はどの手法もほぼ初期設定のまま比べたので、それぞれまだ伸ばす余地があります。

画像モデルの学習

• 対象に合う事前学習モデルを選ぶ
  • 余談のBioCLIP 2.5のように、今回いちばん効果が大きかった方法です
• 学習データを増やす（今回は各クラス10枚前後）
• FTの条件を見直す
  • 今回は3 epochsだけなので、data augmentationや学習率の調整の余地があります

Decisions API

• instructions と、choice の description を最適化する
  • GEPAは、失敗した例をLLMに振り返らせてプロンプトを書き換えるoptimizerです
  • DSPyでは dspy.GEPA として使えます。単体の gepa パッケージなら評価関数を自分で書けるので、Decisions APIの質問定義も最適化の対象にできそうです
• 候補を絞ってから聞く
  • CUBのように候補が200個ある場合は、画像モデルのTop-10だけを choice に渡したり、科と種の2段階に分けたりします
• 確率をキャリブレーションする
  • ラベル付きデータで閾値を決めたり、temperature scalingで補正したりします
• 各クラスの参照画像を一緒に渡す（1リクエスト128枚まで）

Responses API

• DSPyのモジュールとして書き、GEPAでプロンプトを最適化する
• reasoning effortを上げる（今回は medium）
• 画像モデルで候補を絞ってから渡す
• 各クラスの参照画像をfew-shotとして渡す

Agent

• Agent Skillsでタスク固有の知識を渡す
• 参照画像を検索するツールを持たせる
• 学習した画像モデルをツールとして呼ばせ、Agentにはその結果の確認を任せる

まとめ

• Decisions APIは、複数条件の同時判定（HICO）と少データの書類分類（RVL-CDIP）で強く、Responses APIより1.6〜11倍速い一方、200種のfine-grained分類（CUB）と正常例からルールを読む異常検知（LOCO）ではResponses APIに負けました
• 教師データと対象に合う画像モデルがあるなら、画像モデルの学習がレイテンシでも精度でも有力で、CUBではBioCLIP 2.5のlinear probeで93〜94%に届きました
• Decisions APIの確率はランキングには使いやすいものの、キャリブレーションはタスクによって違うので、ラベル付きデータで確かめてから使うのがおすすめです

Appendix

A. 実験条件の詳細

• 画像モデルは google/siglip2-base-patch16-256 です。zero-shotはテキストプロンプトとの類似度、linear probeはfreezeしたembeddingの上のロジスティック回帰、FTは画像エンコーダと分類ヘッドを3 epochs学習しました
• APIとAgentのモデルは gpt-6-luna です。Responses APIとCodex Agentのreasoning effortは medium で、Decisions APIには同等の指定をしていません。画像は detail: high で渡しました
• APIは、CUBでは直列実行し、他のタスクでは手法ごとに最大4並列で実行しました。EPICとLOCOでは最初の2件をスモークテストとしてレイテンシの集計から除いています。ローカルのレイテンシには、画像の読み込み・前処理・推論を含み、モデルの起動と学習は含みません
• CUBは公式trainから各種10枚をtrain、5枚をvalに使い、公式testから各種1枚の計200枚をテストセットにしました。APIとAgentには200種の種名だけを渡し、鳥のbounding boxや部位のアノテーションは渡していません
• HICOは自転車・馬・カップ・本・椅子について各4行動、計20ラベルを選びました。テスト200枚×20ラベルのうち、公式アノテーションでpositive／negativeが分かる682組（positive 393組）だけで評価しています。HICO全600ラベルの公式スコアとは比較できません
• RVL-CDIPは公開Mini版から各クラス10枚をtrain、5枚をval、12〜13枚をtestに使いました。ミラーに含まれるOCR結果はモデルに渡していません
• EPICは対象行動の開始より7.1、5.1、3.1、1.1秒前の4フレームを使い、train・val・testで同じ動画が混ざらないように分割しました。20候補のうちテストセットで正解として現れたのは14種類です
• LOCOは5カテゴリについて、テストセット200枚を正常100枚、論理的異常50枚、構造的異常50枚で構成しました。異常画像は学習にも閾値調整にも使っていません。APIとAgentには正常例3枚、SigLIP2の2手法には各カテゴリ60枚の正常例を使ったので、手法間で使える情報量は同じではありません
• Codex AgentはケースごとのOS sandboxで動かし、正解ラベルを含むディレクトリの読み取り、入力の書き換え、コマンドからの外部通信を拒否できることを確認しました

B. この実験で言えないこと

• 各タスク200件の小規模な比較です。データセット全体や手法一般の優劣を断定するものではありません
• APIとAgentは教師データを使わず、学習ベースの手法は使います。また、内部の画像処理は手法ごとに異なります
• 画像モデルは余談のBioCLIP 2.5を除いて共通のSigLIP2で、各タスクの専用モデルを十分に調整した比較ではありません。FTも3 epochsの小規模な試行です
• 事前学習データとテスト画像の重複は、どの手法でも確認できていません
• 料金は usage と料金表から計算した概算で、請求書とは照合していません

C. Decisions APIでひらがなを1字ずつしゃべらせる

おまけのあそびです。choice の候補は最大255個なので、ひらがなを全部候補にすれば、next token predictionではなくnext character predictionで会話できるのでは、と思って作ってみました。もちろん、Decisions APIに向いた使い方ではありません。

仕組みは単純です。

• 候補はひらがな80字、読点、句点、<END> の83個
• 会話履歴と、ここまで出た返答を input に入れて、次の1字を choice で選ばせる
• 選ばれた1字を返答の末尾に足して、また聞く（<END> が出るか、50字で止める）
• 各候補の description には、その1字を足したあとの返答を書いておく

choices: VALUES.map(value => ({ value, description: value === END
  ? `現在の返答 ${JSON.stringify(prefix)} を完成した回答として終了します。`
  : `次の一文字として「${value}」を追加します。追加後の返答は ${JSON.stringify(prefix + value)} です。` }))

1字あたりのレイテンシは中央値で約250msなので、人がタイピングするくらいの速さで文字が出てきます。ただし毎回、会話全体と83候補の説明を送るので、1字あたり約3,000 tokenを使います。

会話のほうは、上の画像のとおりです。「こんにちは。今日もよろしくね」には「あとでね」と返され、名乗っても「あとでね」でした。一方で、名前を聞くと「なつき」とちゃんと答えます。

「短くあいさつして」には「ちわ。」と返し、「あを50文字続けて」には素直に「あ」を並べ続けました。

86件の会話例と、そのすべての1字分の選択（1,560段階）をmany-shotとして入れると、書きかけの返答から次の1字を当てる問題は8問中5問から7問に上がりました。それでも、空の返答から会話を始めると「おこごごごご…」のように同じ文字を繰り返して崩れることが多くありました。一度おかしな1字を選ぶと、それを含んだ返答が次の入力になるので、そこから戻れなくなるのだと思います。

こいつ…

References

• OpenAI Decisions API
  • Decisions guide
  • Decisions API reference
  • Decisions with voice
  • Changelog (October 2026)
  • Decisions Playground
• OpenAI その他
  • Pricing
  • GPT-6 Luna
  • Structured Outputs
  • Prompt caching
• プロンプト最適化
  • GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning
  • dspy.GEPA
  • gepa-ai/gepa
• 画像モデル
  • google/siglip2-base-patch16-256
  • imageomics/bioclip-2.5-vith14
• データセット
  • CUB-200-2011
  • HICO
  • RVL-CDIP
  • EPIC-KITCHENS-100
  • MVTec LOCO AD

今日は個人情報がどんどん流出していく時代に、わたしたちは何をすればいいのかを考えていきたいと思います。

今週だけでも

さいきん個人情報の漏洩のニュースが本当に多いです。10月7日から9日にかけては政府機関が相次いで「不正アクセスによる漏洩が続いている」と注意を呼びかけていました。同じ週だけでもスカイチケット(約1,464万件)、ビッグエコー(約872万件)、ブックオフ(最大約643万件)、ローソンID(約216万件)の漏洩が公表されています。これらに登録しているひとはけっこう多そうです。

そこで国内外の漏洩と、流出した情報が悪用された例を集めてみました。

いまどれくらい流出しているのか

東京商工リサーチの集計を見ると、上場企業の100万件以上の漏洩は2025年が1年で6件でした。2026年は10月5日の時点ですでに10件あります。1,000万件以上の漏洩にいたっては2025年までの14年間で3件だったのに、2026年だけで3件起きています。

上場していない会社も含めてこれまでの大きな漏洩と並べるとこうなります。

青が2026年に公表されたものです。「歴代最大級」と言われたベネッセ(2014年)に近い規模の漏洩が今年はいくつも起きています。

何が流出したか

氏名、メールアドレス、電話番号はほとんどの漏洩に入っています。今年は身分証の画像まで流出し始めました。タイムズカーでは運転免許証などの画像が約160万件流出して、金融庁が金融機関に画像での本人確認をやめるよう求めるところまで来ています。

どこから漏洩したか

アプリやシステムの弱点、盗まれたパスワード、ランサムウェア、委託先などが並んでいます。どれも利用者の側ではどうしようもないものばかりで、3分の1は原因も公表されていません。

自分がどれだけ気をつけていても、漏洩は止められません。次は、流出した情報がそのあとどう使われるのかを見ていきます。

流出したら何が起きるのか

ばらばらの情報が1人分にまとまる

1つのサービスから流出するのはその人の情報の一部だけです。ところがメールアドレスや電話番号が同じものをつなげていくと、上のように1人分の詳しい情報がまとまってしまいます。ここから先の例は会社も人物も番号も顔の画像もすべて架空のもので、黄色の部分が流出した情報から分かるところです。

こういう情報を持った相手から次のような連絡が届きます。

「漏洩のお詫び」のメール

プロバイダーのインターリンクを名乗って、こんな感じの偽の「流出のお詫び」メールが実際に送られています。面白いのは(面白くはないんですが)、インターリンク自体は漏洩していないことです。お詫びメールに似せた文面なら、どの会社の名前でも詐欺に使えてしまいます。ちなみにこの秋の大きな漏洩のあとに偽のお詫びメールが届いたという報告はまだありません。

予約番号を知っているメッセージ

2026年5月にはBooking.comでホテルを予約した人にこんなメッセージがWhatsAppで届いています。氏名も予約番号も宿泊日もすべて正しかったそうです。これはさすがに信じてしまいそうです。

「警察」からの電話

ニセ警察詐欺の被害は2025年だけで約1,005億円ありました。トビラシステムズの調査では、本物だと信じた人の54.1%が「相手が自分の情報を知っていたから」と答えています。

顔が見えるビデオ通話

2025年にはAIで作った顔の「警察官」がビデオ通話に出てくる詐欺グループが逮捕されています。ちなみにこの画像の男性もAIで作った架空の人物です。実在の人に見えないように、この記事の人物はわざと3DCG風にしています。

自宅に届く手紙

海外では暗号資産ウォレットのLedgerを名乗る偽の手紙が届いています。日本でも2024年に国民生活センターを名乗る電話とハガキがありました。

どんな手段で来るか

集めた例を数えてみると、いちばん多いのは電話でメールよりも多くなっていました。

顔も声もAIで作れる

試しに左の画像1枚だけを元にして、ビデオ会議に映っているような右の画像を作ってみたら、約20秒でできました。左の画像は会社の役員紹介ページに載っている写真を想定したもので、どちらもAIで作った架空の人物です。ここではわざと3DCG風にしていますが、写真と見分けがつかないような画像も同じくらいの手間で作れます。

実際に香港では偽の上司や同僚が出てくるビデオ会議で約2,500万ドルが送金されています(2024年)。イタリアでは国防相の声をまねた電話で約100万ユーロが送金されました(2025年)。

これから増えそうなこと

AIのサポートがだまされる例も出てきました。Meta AIのサポートをだましてInstagramを乗っ取る手口では、Metaが少なくとも2万225人に通知しています。この場合は本物の利用者には何の知らせも来ないのがつらいところです。

ほかにも自分のAIアシスタントがメールに隠された指示で動かされたり、会話できるAIが一人ひとりに合わせた詐欺電話を大量にかけたりするのは、そう遠くないうちに起きそうだな〜と思っています。

わたしたちにできること

信じるかどうかの決め方を変える

相手が自分の情報を知っていても、顔が見えても、声が家族でも、本物とは限りません。連絡が来たら公式アプリや自分でブックマークしたサイト、カードの裏の電話番号から自分で確かめるのがいちばんです。

届いたリンクや電話番号やQRコードは使わないようにします。「急いで」「誰にも言わないで」「補償が受けられなくなる」と言われたら、いったん手を止めます。警察が電話やビデオ通話でお金の話をすることはありません。職場なら振込先の変更はメール以外の方法で確かめるようにしておくと安心です。

私たちがやれること

すぐできることを大事な順に並べるとこうなります。

1. メールとApple・Googleのアカウントにパスキーか2段階認証を設定します
2. パスワードの使い回しをやめます。パスワードマネージャーを使うのが楽です
3. カードと銀行の利用通知をオンにします
4. 携帯電話会社の契約に暗証番号を設定します
5. 家族と合言葉を決めておきます

Meta AIの件で被害に遭ったのも2段階認証をしていないアカウントでした。1と2をやっておくだけでも、流出した情報だけでは乗っ取られにくくなります。

漏洩のお知らせが来たら

渡す情報を減らす

使っていないアカウントは消して、任意の項目は入力しないようにしておきます。顔や声の入った動画を誰に公開しているかも、一度見直しておくといいと思います。

まとめ

• 漏洩はもう個人では防げないので、流出しても困らない準備を先にしておくのがよさそうです
• 知らない相手からの連絡は中身が正しくても、公式サイトや公式アプリで確かめてから動きます

References

• 政府機関の注意喚起
  • IPA: 不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について
  • JPCERT/CC: 直近で相次いでいる国内組織における不正アクセスに関する注意喚起
  • 個人情報保護委員会: 大規模な漏えい等事案を踏まえた対応について(注意喚起)
• 統計
  • 東京商工リサーチ: 上場企業「個人情報漏えい」、過去最悪ペース
  • 警察庁: ニセ警察詐欺に注意!
  • 警察庁: 令和7年の特殊詐欺の認知・検挙状況等
• 漏洩
  • INTERNET Watch: スカイチケットの個人情報流出
  • INTERNET Watch: ビッグエコーの情報漏洩
  • タイムズカー: 不正アクセスによる個人情報漏えいについて
  • KDDI: ISP事業者向けメールシステムへの不正アクセスについて
• 流出した情報が悪用された例
  • インターリンク: 弊社からのメールを装ったフィッシングメールについて
  • J-CAST: Booking.comの予約情報を使ったWhatsAppのメッセージ
  • ITmedia: 警察官を名乗る詐欺電話の通話録音(トビラシステムズ)
  • 警察庁: 令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について
  • The Block: Ledger confirms physical scam letters requesting seed phrase
  • 国民生活センター: 国民生活センターをかたる電話に注意
  • Construction Management: Arup victim of multimillion deepfake scam
  • StratNews Global: Italian police freeze cash from AI voice scam
  • GIZMODO Japan: MetaのAIサポートアシスタントを悪用したInstagramアカウントの乗っ取り

Today I'd like to write about speech.cpp, the speech synthesis and recognition engine I've been building for voice conversation.

What I built

speech.cpp is a C++ engine that runs speech synthesis and recognition models on ggml. It uses Metal on Mac and Vulkan on Windows and Linux for GPU inference, and can run on the CPU without a GPU.

These are the models it currently supports. I converted their original weights into GGUF files for speech.cpp and uploaded them to Hugging Face.

Speech synthesis models

Qwen3-TTS offers nine preset voices. Irodori-TTS lets you specify a voice with a recording or a description; MF is a good choice when speed matters.

Speech recognition models

Qwen3-ASR can take proper nouns and other context in a prompt. For Japanese, parakeet-ja is fast, while ReazonSpeech transcribes with beam search. I compare accuracy and speed later in the article.

Voice activity detection

It finds the regions of audio that contain speech, for transcribing long recordings in parts or detecting when someone has finished speaking.

Try it

Install

Installation takes one command. On Apple silicon Macs and x86-64 Linux:

curl -fsSL https://raw.githubusercontent.com/nyosegawa/speech.cpp/main/install.sh | sh

On Windows x64, run this in PowerShell (a Vulkan-capable GPU driver is required):

irm https://raw.githubusercontent.com/nyosegawa/speech.cpp/main/install.ps1 | iex

The Linux releases require a CPU with AVX2, FMA and F16C, and glibc 2.34 or later. Without a Vulkan loader, the installer selects the CPU build. Intel Macs need a build from source. See the installation guide for the requirements.

Select a model by name. The first time you use it, speech.cpp downloads it from Hugging Face into your OS's cache directory.

Try it in the browser

The easiest way to get started is to open the demo page:

speech serve --open

The Speak, Transcribe and Live tabs let you select a model and read text aloud, transcribe a recording or audio file, or transcribe your microphone while you speak.

Read text aloud

You can also use the command line. Here is Qwen3-TTS reading Japanese:

speech tts qwen3-tts-0.6b --voice ono_anna --language ja -o out.wav "明日の東京は晴れです。"

Use a voice of your choice

With Irodori-TTS, you can pass a reference WAV file directly to read text in that voice. This example saves the synthesized audio to out.wav.

speech tts irodori-tts-mf \
    --add-voice me=my-voice.wav --voice me \
    -o out.wav "こんにちは。"

If you use the same voice repeatedly, you can also create a voice file once with speech voice. This avoids encoding the reference audio each time you pass in the WAV file.

speech voice irodori-tts-mf my-voice.wav my-voice.voice.gguf
speech tts irodori-tts-mf \
    --add-voice me=my-voice.voice.gguf --voice me \
    -o out.wav "こんにちは。"

Without reference audio, you can describe the voice in words. This example asks for a low, calm male voice speaking slowly:

speech tts irodori-tts-mf --voice none \
    --instructions "低く落ち着いた男性の声で、ゆっくりと読み上げてください。" \
    -o out.wav "明日の東京は晴れです。"

Transcribe audio

Qwen3-ASR can take proper nouns in a prompt:

speech asr parakeet-tdt_ctc-0.6b-ja utterance.wav
speech asr qwen3-asr-1.7b --language ja --prompt "逆瀬川, Codex, Claude" utterance.wav

Transcribe long recordings or a microphone

For long recordings, Silero VAD finds speech regions, which are transcribed separately. With --live, speech.cpp transcribes your microphone while you speak.

speech asr reazonspeech-v2 --vad silero-vad meeting.wav
speech asr reazonspeech-v2 --vad silero-vad --live

Run an HTTP server

The HTTP server accepts requests in the same format as the OpenAI API:

speech serve irodori-tts-mf --add-voice me=my-voice.voice.gguf
curl http://127.0.0.1:8080/v1/audio/speech -H 'Content-Type: application/json' \
    -d '{"input": "明日の東京は晴れです。", "voice": "me"}' -o out.wav

In Python, you can receive PCM as it arrives:

import requests
import wave

with requests.post("http://127.0.0.1:8080/v1/audio/speech",
                   json={"input": "明日の東京は晴れです。", "voice": "me", "response_format": "pcm"},
                   stream=True) as r:
    r.raise_for_status()
    with wave.open("out.wav", "wb") as w:
        w.setnchannels(1)
        w.setsampwidth(2)
        w.setframerate(int(r.headers["X-Sample-Rate"]))
        for chunk in r.iter_content(chunk_size=None):
            w.writeframes(chunk)

Embed it in an application

The HTTP server or worker is usually enough. To embed it directly, use the C API (from the C API documentation):

speech_model * model = NULL;
speech_request * request = NULL;
if (check(speech_model_load("Irodori-TTS-866M-MF-v4.1-F16.gguf", NULL, &model)) &&
    check(speech_voice_add(model, "bright", "bright-young-woman-10s.voice.gguf")) &&
    check(speech_request_new(model, &request)) &&
    check(speech_request_set_text(request, "明日の東京は晴れです。")) &&
    check(speech_request_set_string(request, SPEECH_OPT_VOICE, "bright")) &&
    check(speech_synthesize(request, on_audio, NULL))) {
    /* on_audio receives the audio as it is generated. */
}
speech_request_free(request);
speech_model_free(model);

Why I built it

I'm building ASIST, a voice assistant for the desktop. The hardest part of voice conversation is the wait. In human conversation, the gap between one speaker finishing and the next beginning is around 200 milliseconds (Stivers et al., 2009). When an assistant stays silent for a second, I start wondering whether it heard me.

For Japanese speech, Aratako's Irodori-TTS is wonderful. It reads naturally, and reference audio lets it speak in that voice. But the original implementation is a little slow for real-time conversation.

Windows was particularly painful. My test machine has an RTX 2080 with 8 GB of VRAM, and my attempts to run speech models with Python and CUDA kept running into trouble.

• I couldn't get Qwen3-TTS's official PyTorch package running on Windows.
• The CUDA 13 build of llama.cpp, which I used for recognition, lacked machine code for the RTX 20 series and would not start. The CUDA 12 build worked, but compiling GPU code on its first launch took 28 seconds.

That CUDA and Python setup required an NVIDIA GPU from the RTX 20 series or newer, driver version 580 or later, and several gigabytes of Python environment to distribute.

Each model also ran differently. ASIST used llama.cpp's llama-server for recognition and a worker I wrote for synthesis. llama-server needed two model files, the model and mmproj, a loopback port and its key, and a watchdog to stop it if the app crashed. Its 4,096-token context also meant utterances longer than about 270 seconds failed.

I wanted one engine for both synthesis and recognition, running on the GPU on Mac, Windows and Linux, fast enough for conversation, and producing the same results as the official implementations. First, I will look at how to shorten the wait for speech to begin.

Speech synthesis: start quickly and keep playing

Look at the time to first audio

ASIST splits the language model's reply into sentences and starts reading them as they arrive. It sends one sentence at a time to Irodori-TTS, while Qwen3-TTS receives waiting sentences grouped into at most 300 characters. It can synthesize the continuation while earlier audio plays, so the user's initial wait is for the first sentence to begin. I therefore focus on time to first audio, rather than overall speed measured as RTF, the seconds of computation needed per second of audio.

For the measurements, each implementation read the same 20 texts, including backchannels, short replies, longer explanations and Japanese mixed with English words. I used the same voices and seeds where applicable and took the median. The Appendix gives the details.

How Irodori-TTS works

Irodori-TTS does not emit one token at a time like an LLM. Its Diffusion Transformer (DiT), following Echo-TTS, generates codec latents for the whole text at once: 32-dimensional vectors at 25 Hz, representing 48 kHz audio. The codec converts them into a waveform. A separate model predicts the audio duration before generation.

Because the DiT processes the whole text together, it cannot start speaking partway through. In the official implementation, text preparation, duration prediction, every sampler step and all codec decoding finish before audio is returned.

There are two models, differing in how the DiT turns noise into speech.

The original v4.1-Small is trained with Rectified Flow. It connects noise and speech with straight lines and learns the velocity, how far and in which direction to move, at each point along them. Generation repeatedly predicts that velocity and takes a small step, 40 times. Classifier-free guidance (CFG), which strengthens adherence to text and speaker conditioning, requires three DiT evaluations per step in the first half, making this fairly expensive.

v4.1-Small-MF is distilled from v4.1-Small using MeanFlow. Instead of the instantaneous velocity, it learns the average velocity over an interval. A large step along the instantaneous velocity can leave a curved trajectory, but its average over the interval can take you to the destination. The student learns the teacher's CFG-guided trajectory, so it needs only one DiT evaluation per step and produces audio in four steps. See Irodori-TTS's MeanFlow explanation.

According to the MF model card, simply reducing v4.1-Small to four steps drops speaker similarity from 0.75 to 0.38, while MF preserves 0.74 with four steps. Conversation needs speed, so ASIST uses MF.

Where the official implementation spends its time

I measured the stages of the official MF implementation on M5 with MPS, reading a 33-character Japanese text.

Passing a WAVE reference causes it to be encoded again for every request. Passing the already encoded latents removes that second of work and produces exactly the same audio. The largest remaining cost is codec decoding. With MF reducing the sampler to four steps, the codec takes longer than the DiT.

Ways to make it faster

The breakdown suggests a few approaches. MF already reduces the number of steps, and saved reference latents avoid repeated encoding.

Other people have also written about accelerating Irodori-TTS. Rosso's article profiles a sentence with v4 on an RTX 3080 and finds that GPU dispatch overhead costs more than the DiT computation itself. Recording the DiT in a CUDA Graph removes that overhead, while rounding predicted durations up to a small set of lengths accommodates different sentence lengths. Generating 5.1 seconds of audio drops from 0.90 to 0.30 seconds, and reducing the sampler to eight steps with Sway Sampling brings it to 0.23 seconds.

On Mac, osushi_cr's article uses v2 on an M1 Max with MPS. Reducing 40 steps to eight with Sway Sampling, keeping the model loaded and generating the next sentence during playback brings five sentences from 28.77 to 10.58 seconds. They report that bf16 was slower on MPS and moving the codec to the CPU roughly doubled the time.

Both improve how PyTorch is run. For speech.cpp, I also considered other directions because I wanted the same engine to use GPUs on both Mac and Windows.

Eight-bit quantization could reduce the workload. But in my Irodori-TTS test, CER measured by transcribing 20 synthesized texts rose from 2.99% to 3.81%, with audible degradation too.

Another option is leaving PyTorch for another runtime. ONNX Runtime's CoreML execution provider on Mac is a preview and slows down when input shapes change. Its DirectML execution provider on Windows has entered maintenance mode. MLX runs only on Mac. I chose ggml because I wanted GPU support on both Mac and Windows.

ggml is the C/C++ tensor library behind llama.cpp and whisper.cpp. It has Metal, Vulkan, CUDA and CPU backends, and builds computation graphs on each call, so changing text lengths are manageable. It can be linked into the executable, leaving users with no extra runtime to install.

Finally, there is the option of starting playback before all the audio is ready. The DiT cannot stream its work, but once it finishes, the codec can decode and return audio in pieces. Since the codec is more expensive than the DiT with MF, that should cut the initial wait substantially.

What I did in speech.cpp

I ported MF to ggml, saved reference latents as voice files, and split codec decoding into windows.

Instead of decoding the whole output at once, the codec returns the first 12 frames, or 0.48 seconds of audio, immediately. While those play, it decodes the rest in windows of 24 to 48 frames. Based on the measured speed of previous windows, it chooses the largest window it can finish while the listener still has 0.1 seconds of audio buffered. Slower machines get smaller windows; faster machines get larger ones.

The window boundaries must not change the sound. Decoding ten extra frames on either side and discarding that padding produces the same waveform as full decoding. The output is bit-identical at every supported window size, so a fixed seed produces the same audio even when the machine's speed changes the windows. Most of the decoding now overlaps playback instead of adding to the initial wait.

There is another detail specific to conversation. People often start talking while the assistant is still speaking. If cancelling a sentence leaves the sampler running to completion, the next reply has to wait. I added cancellation checks between sampler steps. After cancelling a 120-character text, the time to first audio for the next reply dropped from 881 to 351 milliseconds.

Streaming Qwen3-TTS one frame at a time

Unlike Irodori-TTS, Qwen3-TTS generates audio tokens one frame at a time, like an LLM. Each frame represents 0.08 seconds of audio and contains tokens from 16 codebooks. The talker, a Qwen3 decoder, emits the first token, and the code predictor fills in the other 15. The codec is causal too, so each completed frame can be decoded and streamed immediately. speech.cpp carries the codec's intermediate state between calls, making frame-by-frame decoding produce almost the same waveform as full decoding. This is the difference from qwentts.cpp that I will compare below.

Comparing implementations

I compared the same 20 texts on M5 with the same reference voice and seed. Every implementation encoded the reference only once. The speech.cpp names are bold, as are the fastest values within each model. Later tables use the same convention.

I also measured on Windows with an RTX 2080 and Vulkan. mlx-audio runs only on Mac, and I did not test the official implementation on Windows, so neither appears here.

The tables measure the time from a synthesis request to the first returned audio, which is not necessarily when the voice begins. Qwen3-TTS 0.6B often generates silence at the beginning of a sentence. Although its first audio chunk arrives in 0.04 seconds, the voice starts roughly half a second later in the median: 0.24–0.48 seconds across four voices, and as much as 1.9 seconds. The official implementation does the same. Reading the same text 20 times with ono_anna gave a median of 0.89 seconds of leading silence. The corresponding figures for 1.7B and Irodori-TTS MF were 0.10 and 0.03 seconds, so their voices begin sooner in conversation.

The official implementation, mlx-audio and audio.cpp return audio only after generating the whole sentence, making their time to first audio equal to the total synthesis time. speech.cpp returns its first decoded window instead. MF's RTF is almost identical to mlx-audio's, 0.174 versus 0.171, so overall throughput is similar; windowed decoding accounts for most of the difference in startup latency. CER is measured by transcribing the synthesized audio with Qwen3-ASR 1.7B. Each implementation generates noise differently, so a single run can vary by several percentage points. audio.cpp does not support MF, so its comparison uses RF with 16 steps.

Keeping playback continuous

A quick start is not enough if playback then stalls. With streamed chunks, each new chunk must arrive before the previously received audio finishes playing. Smaller initial chunks start sooner but leave less time for the next chunk to arrive.

Other implementations handle this differently. The official Qwen3-TTS implementation sends four frames, 0.32 seconds, from the start (Qwen3-TTS Technical Report). This gives more margin against underruns, but the first audio waits for all four frames. CosyVoice increases each chunk by a fixed multiplier that a person selects for the machine's speed. The player can also accumulate more audio before starting, at the cost of extra latency.

speech.cpp's Qwen3-TTS starts small and grows: one frame, one frame, two frames, then four frames at a time.

On both M5 and RTX 2080, generating a frame takes much less than the 0.08 seconds of audio it represents. Starting with a small chunk therefore gives the next chunk time to arrive before the audio runs out. Grouping later frames in fours keeps the number of codec calls close to the original.

I considered adapting the chunk sizes to measured speed. However, changing chunk boundaries also changes waveform values by a tiny, inaudible amount. Choosing boundaries at runtime would make the same seed produce slightly different audio on different runs, so I use a fixed sequence. This describes playing the generated audio as-is, including any leading silence.

I checked continuity by recording when chunks arrived for the same 20 texts and assuming playback began immediately with the first chunk. All 20 texts played without underruns on both M5 and RTX 2080, for Qwen3-TTS 0.6B and 1.7B and Irodori-TTS MF and the 16-step model.

ASIST removes only the nearly silent beginning. Once a sound such as a breath or sigh begins, it preserves everything after it, including pauses. Removing the initial silence also removes time in which later audio could be generated, so the player waits after the first sound arrives until the waiting time plus the received audio duration totals 0.2 seconds. A sentence that already has at least 0.2 seconds buffered while waiting behind the previous sentence starts without an additional delay.

I also ran the same 20 texts in the released ASIST 0.8.0 on M5. With the model already loaded, the median time from synthesis start to the scheduled playback of the voiced portion was 0.40 seconds for Qwen3-TTS 0.6B, 0.25 seconds for 1.7B and 0.26 seconds for Irodori-TTS MF. These values come from the Web Audio playback schedule and exclude speaker and output-device latency.

This makes synthesis fast enough to begin a conversational reply and continue playing it.

Checking against the official implementation, stage by stage

Moving a model to another runtime changes the order and precision of calculations a little. For synthesis, the voice may change; for recognition, the transcription may change. The trouble is that listening alone may not reveal it. Synthesis starts from noise, so the voice already varies from one run to the next, while recognition differences may appear only once in dozens of examples.

For each model I port to speech.cpp, I compare its intermediate stages against the official implementation.

For Irodori-TTS, for example, I compare text processing, the DiT and decoding like this:

1. Run the official implementation in float32 on the CPU with fixed noise, and save each stage's inputs and outputs.
2. Feed the same saved inputs into each stage of the port.
3. Compare the outputs. For numerical data, use SNR to measure how small the error is relative to the signal; for tokens and strings, check exact equality.

The other models follow the same approach with different stages. Qwen3-TTS is compared using greedy decoding without sampling. Recognition models are compared at the audio feature, encoder and decoder stages.

Starting each stage with the same input makes the first divergence easy to find. In CPU float32, every Irodori-TTS stage agrees with the official implementation at an SNR of at least 86 dB. Greedy Qwen3-TTS produces the same 54 frames, and parakeet and ReazonSpeech produce exactly the same transcripts in all the checks. The tables are in the Appendix.

These comparisons also made some differences in other implementations easier to spot.

• llama.cpp's Qwen3-ASR sometimes transcribed differently from the official implementation. Across ten recordings, tested with automatic and explicit language selection for 20 runs in total, 0.6B differed six times and 1.7B four times. Where the official implementation wrote 「群島や湖では必ずしもヨット」, for example, 1.7B wrote 「軍港や湖ではカマザタ寿司もヨット」. The inputs differ in several small ways: the initial system message is missing, the log-mel features have one extra frame, and the final partial second is padded with zeros whose audio tokens are also passed to the model.
• Streaming Qwen3-TTS in qwentts.cpp introduced a trembling noise that did not occur when the same text was synthesized all at once. Qwen3-TTS's codec generates new audio as a continuation of previous audio. Carrying its intermediate state across chunks therefore makes streamed and full synthesis produce almost the same waveform. speech.cpp does this, and I checked that decoding one frame at a time differs from full decoding by an inaudibly small amount, with an SNR of 133 dB.
• CrispASR's ReazonSpeech added 「あっ。」 or 「うん。」 that was not in recordings with silence at their edges, in four of the first ten Common Voice examples. Trimming the silence reduced this to a few of 4,479 examples.
• With audio.cpp's Irodori-TTS codec on Metal, a distorted copy of the voice appeared 14 dB below the voice itself, and nominally silent regions were raised as well.

These are all differences that are hard to catch by listening alone. Conversely, once each stage is checked against the official implementation, I can change the computations for speed and quickly check that the results still agree. Next comes listening to the user.

Speech recognition: getting the port right

Port FastConformer once

The first recognition models I ported were NVIDIA NeMo models. parakeet-tdt_ctc-0.6b-ja for Japanese, parakeet-tdt-0.6b-v3 for 25 European languages, and ReazonSpeech NeMo v2 for Japanese all share the FastConformer architecture. They compute log-mel features, reduce the time dimension by a factor of eight with convolutions, run through 24 Conformer layers, then decode tokens.

Their differences are relatively small:

I therefore ported FastConformer once and made these differences settings in the GGUF file.

The decoding behavior follows NeMo's default transcribe(). parakeet-ja also has a CTC head, but NeMo defaults to TDT, and the two produce different text for some utterances, so I ported only TDT. ReazonSpeech uses the model's configured beam search with width four rather than NeMo's greedy decoder, because greedy decoding sometimes drops punctuation or changes words. Greedy is much lighter, though, so it is available on request. Across 4,483 Common Voice examples on M5, it raises CER from 12.03% to 12.50% while reducing median latency from 0.110 to 0.077 seconds.

Bringing Qwen3-ASR into the engine too

Qwen3-ASR connects an audio encoder to a Qwen3 language model. The language model caches state and emits one token at a time, exactly the work llama.cpp is good at. Initially, I intended to leave Qwen3-ASR in llama.cpp and have speech.cpp handle only FastConformer. There seemed little reason to implement the same thing twice.

But the stage comparisons showed the prompt differences mentioned earlier, with different transcripts in four to six of 20 runs. Utterances longer than about 270 seconds also failed. And keeping llama-server meant ASIST still had a second runtime alongside speech.cpp.

So I changed course and ported Qwen3-ASR too. I had already implemented the Qwen3 decoder for Qwen3-TTS's talker and could reuse it directly. The new work was the audio encoder, whose attention stays within eight-second windows, and prompts matching the official qwen-asr implementation. That includes prefilling the answer with language Japanese<asr_text> when Japanese is specified. With those inputs aligned, the transcripts matched the official implementation.

Once the transcripts matched, I wanted to measure recognition accuracy. But in Japanese, measuring "correctness" brings its own difficulty.

Measuring Japanese transcription while allowing spelling variants

Recognition accuracy is usually measured by character error rate, CER, against a reference transcript. Japanese, however, offers several ways to write the same spoken words. If the reference says 「三十分」 and the transcript says 「30分」, both mean the spoken "thirty minutes," but ordinary CER counts the difference as an error.

As models improve, CER increasingly measures whether they chose the reference's spelling rather than whether they heard the words correctly.

This is not unique to Japanese, and there is research on it:

• Karita, Sproat and Ishikawa (CAWL 2023) expand Japanese references into a lattice of possible spellings before scoring. Human reviewers accepted 95.4% of the variants, and CER dropped by 2.4–3.1 percentage points depending on the task.
• OIWER (ICASSP 2026) uses an LLM to identify spelling variants in Indian languages. Error rates fell by 6.3 percentage points on average and aligned better with human judgments.
• HiKE (EACL Findings 2026) annotates loanwords in an evaluation set of Korean-English code-switched speech.
• Kacprzak and Fraś (2026) report that number normalization alone can move Polish WER by more than two percentage points, exceeding the differences between systems.
• The long-established NIST sclite tool also supports reference alternatives such as { a / b / @ }.

In speech-bench, I now report both ordinary CER and CER allowing accepted spelling variants. Each reference sentence is annotated like this:

• Add kana readings to non-kana text: 明日《あした》, ｜Zoom《ズーム》.
• List alternative spellings that a reading alone cannot express: ［九《く》時《じ》／9時］.
• Allow fillers such as "um" to be omitted: ［えーと／えっと／］.

The transcript is compared with the closest spelling that these annotations permit. The denominator remains the original reference length, so this CER cannot exceed ordinary CER. Homophones with different meanings, such as 機会 (opportunity) and 機械 (machine), remain errors. So do different spoken wordings with the same meaning, such as 3時半 (half past three) and 3時30分 (three thirty).

I published the annotations for the 4,483 Japanese Common Voice 8.0 test examples on Hugging Face as sakasegawa/common-voice-ja-accepted-spellings, under CC0. The included scoring script produces the same error counts as speech-bench across 17,932 transcripts. The audio and reference text must be obtained from their respective distributors and combined with these annotations.

For example, accepting spelling variants lowers Qwen3-ASR 1.7B's CER on Common Voice from 9.25% to 4.56%. Roughly half of what had counted as errors were spelling differences. The following tables show both metrics.

That gave me a benchmark for accuracy. But the newly ported speech.cpp was slower than llama.cpp.

Catching up with llama.cpp

On M5, speech.cpp 0.7.0 decoded Qwen3-ASR 0.6B at 123–132 tokens per second, compared with llama.cpp's 158–165. Decoding accounted for 90% of recognition time, so it needed attention.

I made two changes.

First, flash attention. The Qwen3 decoder had computed attention as two matrix multiplications and a softmax. ggml's ggml_flash_attn_ext computes these together without storing the full scores, which is faster on the GPU. With Metal on M5, attention for 2,000 cached positions fell from 2.62 to 2.20 milliseconds, and for 8,000 positions from 9.59 to 8.10 milliseconds. On the CPU it was slower, rising from 22.1 to 51.2 milliseconds at 8,000 positions. At model load, I therefore check ggml_backend_supports_op and use flash attention only when the GPU backend supports it.

Flash attention divides the work into small blocks and updates softmax incrementally, avoiding a large score matrix in memory (Dao et al., 2022). The CUDA library FlashAttention-2 targets RTX 30-series and newer GPUs, but ggml implements the approach in its own Metal and Vulkan shaders, so it also works on an RTX 2080 with Vulkan.

Second, I reused the computation graph between decoder steps. Building a ggml graph takes time, so it need not be rebuilt while its shape stays the same.

M5 decoding then reached 146–158 tokens per second for 0.6B, alongside llama.cpp's 147–157, and 58–63 for 1.7B, alongside 58–62. On RTX 2080, it became 13–25% faster than speech.cpp 0.7.0.

Here are the Japanese Common Voice 8.0 results, 4,483 examples, on Windows with an RTX 2080. VAD trims the silence at both ends. The second error-rate column allows the spelling variants described above. Latency runs from the request to the returned transcript. I also included NVIDIA's NeMo-Speech.cpp, another ggml implementation of FastConformer.

Qwen3-ASR's accuracy is close to llama.cpp's, with latency 10% lower for 1.7B and 17% lower for 0.6B. parakeet matches CrispASR's accuracy with one-third of the latency. Some of that difference may come from the weights: speech.cpp uses F16 and CrispASR Q8_0.

For ReazonSpeech, NeMo-Speech.cpp was fastest and slightly more accurate. Even comparing greedy decoders, it was 1.6 times faster than speech.cpp. It was also 1.4 times faster on M5 and faster for parakeet-v3, as shown in the Appendix. I plan to investigate the FastConformer difference for a later release. Although CrispASR's ReazonSpeech sometimes adds 「あっ。」 around silence, in these trimmed recordings it was slightly more accurate than speech.cpp's beam search. Common Voice contains read speech; conversational speech may give different results.

llama.cpp is still a little faster in some M5 cases. Across 4,483 Common Voice examples, median latency was similar, but llama.cpp's p90 was 8% shorter. The difference grows with utterance length: for a 25.5-second Japanese utterance, 0.6B took 0.80 seconds in speech.cpp and 0.75 in llama.cpp. Decoding is now comparable, so the difference lies in the audio encoder and prompt processing. llama.cpp uses Metal 4's tensor API for those matrix multiplications; speech.cpp does not. A bug is the reason, as I'll explain next.

A bug I found on M5

Just when the Irodori-TTS port seemed finished, one of 64 M5 samples turned into noise in its latter half. In 「暗証番号は4桁で、8264です。」 ("The PIN has four digits: 8264"), the "8264" ending was buried in static. The same text sounded clean on the CPU and RTX 2080.

The cause was ggml's Metal matrix multiplication. On M5 and newer chips, ggml uses Metal 4's tensor API. Its kernel wrote beyond the output only when the number of output columns was 64 modulo 128: 64, 192, 320 and so on. Those writes corrupted an adjacent tensor, changing the result from run to run.

The noisy sample hit exactly that condition. At the time, codec windows contained 48 frames with ten padding frames on either side. The third window of a 114-frame output covered frames 50–114, exactly 64 frames.

ggml's own test-backend-ops passed because it lacked this shape. Adding 64-column and 192-column cases made the tensor API fail, while disabling it with GGML_METAL_TENSOR_DISABLE=1 made them pass (speech.cpp#13).

There is only so much I can do before ggml itself is fixed. After comparing the same 20 texts on M5, I decided the difference was acceptable—or rather, something I had to accept—so speech.cpp disables the tensor API.

MF's first audio became 0.04 seconds slower, but the corruption disappeared and agreement with the official implementation improved. This is also a major factor in the M5 recognition gap discussed earlier. Once a newer ggml passes these shapes, I intend to enable the tensor API again and remeasure.

Supporting OpenAI Realtime Transcription

So far, I have discussed individual utterances. In practice, I also wanted to transcribe long recordings such as meetings and show text while someone was speaking. Version 0.8.0 adds both.

Whole recordings can lose sentences

While using the demo page, I noticed entire spoken sentences disappearing. The page sent audio in 20-second pieces. When a piece contained three or four sentences, ReazonSpeech sometimes dropped the first two. Official NeMo dropped the same sentences on the same audio, so this was a model characteristic, not a porting error.

I measured it by joining Japanese FLEURS and Common Voice test utterances with 0.3–1.0-second gaps into recordings lasting several minutes, then transcribing them whole and by speech region. The Appendix explains the construction. A sentence counts as dropped when more than half its characters disappear.

The two FastConformer models lose many sentences when given several minutes at once. Qwen3-ASR loses very few, and its CER is even slightly better on whole recordings, 9.80% versus 11.44% on FLEURS. I suspect its LLM decoder benefits from the longer context. ReazonSpeech still loses 46 Common Voice sentences when processed by region because short utterances from different speakers sometimes land in one region; that is a feature of this artificially concatenated test.

I ported Silero VAD to find speech regions, transcribe them separately and join the results. It is a small 1.2 MB model and returns the same sample-level boundaries as the official get_speech_timestamps. Regions end after 0.5 seconds of silence, following OpenAI's default server_vad setting. Short pauses can still produce regions longer than 20 seconds, so I tested maximum region lengths from eight to 30 seconds and selected ten seconds, which gave the lowest average CER.

The HTTP server enables this with the OpenAI transcription API's chunking_strategy. First, start the server with both a recognition model and a VAD model. If the server from the earlier example is still running, stop it with Ctrl+C first.

speech serve reazonspeech-v2 silero-vad

Call it from another terminal using the OpenAI Python SDK:

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:8080/v1", api_key="unused")
with open("meeting.wav", "rb") as f:
    print(client.audio.transcriptions.create(model="reazonspeech-nemo-v2", file=f, chunking_strategy="auto").text)

Showing text while someone speaks

The other addition is live transcription. It follows OpenAI Realtime transcription, so OpenAI clients can use it by changing the endpoint.

During speech, the Realtime API sends text in delta events. These can append text but cannot rewrite earlier text. OpenAI's gpt-live-transcribe also accumulates deltas and replaces the result with the full completed transcript at the end. Each time speech.cpp retranscribes the growing audio, it compares the result with the previous pass and sends only the prefix that agrees in two consecutive passes. Once speech ends, it sends the final transcript in completed.

I measured this on an otherwise idle M5 by streaming audio made from six utterances in real time, three times per model.

About 0.6 seconds of the delay after speech ends comes from waiting to establish 0.5 seconds of silence. Lowering silence_duration_ms shortens it but makes breaths more likely to split utterances. The first text arrives later because two transcription passes must agree.

The command-line --live option transcribes a microphone in the same way. miniaudio is linked into the executable, so there is no SDL2 or PortAudio installation to manage.

ASIST does not use this particular mechanism. It decides when an utterance ends itself, using its backchannel classifier and MaAI's turn-ending predictions. It passes its own completed utterances to the speech.cpp worker.

What bringing everything together gives me

I have discussed synthesis and recognition separately, but putting them in one engine has benefits of its own.

First, there is less to distribute. speech.cpp needs one speech executable and one model file. The Mac executable in version 0.8.2 is about 6.7 MB; the Windows executable is 48 MB because it includes Vulkan shaders. Each model, including its codec, fits in one GGUF file. Releases provide macOS Metal, Windows Vulkan, and Linux Vulkan and CPU builds; the installer selects the appropriate one. Neither CUDA nor Python is required.

Startup is quick too. ASIST loads speech models only when the microphone is enabled, so slow loading would leave the user waiting after switching it on.

I measured the time from process launch until the first request could be accepted on M5, with model files already in the OS file cache.

Every model is called through the same interfaces.

There are four ways to use it:

• The speech command: speech tts reads text, speech asr transcribes audio, and speech voice creates a voice file from reference audio.
• The HTTP server, speech serve: it follows the OpenAI audio APIs, /v1/audio/speech and /v1/audio/transcriptions, and Realtime transcription at /v1/realtime.
• The worker, speech worker: it exchanges JSON Lines over standard input and output. This is what ASIST uses.
• The C API, speech.h: all three interfaces above are built on it.

ASIST now runs both synthesis and recognition through speech.cpp workers and no longer bundles llama-server.

What I ended up with

• Nine synthesis and recognition models, plus Silero VAD, run in one ggml-based engine with a single executable on Mac, Windows and Linux.
• While checking each stage against the official implementation, I reduced Irodori-TTS's time to first audio to 0.25 seconds on M5 and made Qwen3-ASR faster than llama.cpp on RTX 2080.
• I chose correctness over speed by disabling the M5 tensor API affected by the bug. FastConformer still trails NeMo-Speech.cpp in speed, which is something to work on next.
• Transcribing long recordings by Silero VAD regions greatly reduces dropped sentences, and live transcription works through an OpenAI-compatible Realtime interface.

Update: faster FastConformer in 0.8.3 (2026-10-10)

The FastConformer work I mentioned above is now in speech.cpp 0.8.3. I reduced repeated memory allocation inside the FFT, cached position computations that stay the same across inputs, and reused decoder computation graphs.

Running 0.8.2 and 0.8.3 alternately on the same audio gave these median times to a returned transcript. All models use F16 weights; loading and the first warmup request are excluded.

The Japanese timing sample uses the first 100 Common Voice inputs, 99 retained by VAD, repeated three times. English uses 300 FLEURS inputs, 299 retained by VAD, once each. These are different sample counts from the 4,483-input Japanese tables above, so they do not replace those results. ReazonSpeech's default beam search also improved from 104 to 85 ms on M5.

I checked accuracy separately on the complete sets on M5. Compared with the original article's run, ReazonSpeech greedy's CER on the 4,483 Japanese inputs changed from 12.50% to 12.49%, while CER allowing spelling variants stayed at 7.69%. Five of the 4,479 VAD-retained transcripts changed; empty results stayed at four. Parakeet v3's WER on 300 English inputs stayed at 8.76%.

Alternating requests with NeMo-Speech.cpp on the same audio now gives roughly equal speed on Windows. On M5, NeMo-Speech.cpp remains about 3 ms faster for ReazonSpeech and 7 ms faster for Parakeet v3, but disabling its tensor API makes speech.cpp as fast or faster. speech.cpp keeps the tensor API workaround described above. The PR's measurement report has the full conditions and p90 values.

The model files have not changed. Updating speech.cpp is enough; existing GGUF files still work.

Appendix

Measurement method

For comparisons between inference implementations, I used speech-bench, which I also develop. speech.cpp was a 0.8.0 candidate, commit f5ab84c, built locally for M5 and by CI for RTX 2080. All implementations were measured on October 8, 2026.

Synthesis was measured on M5 with 32 GB of memory and macOS 26.2, and on Windows 11 with an RTX 2080, 8 GB of VRAM and driver 591.86. The 20 texts in speech-bench's prompts/speak-ja-JP.json include backchannels, replies, longer explanations and Japanese mixed with English words. Irodori-TTS used the approximately ten-second voice-bright-young-woman reference generated for speech-bench, with seed 1. Qwen3-TTS used the preset ono_anna voice, with a new seed each time. The first text was synthesized once before measurement to exclude first-use GPU overhead. CER was calculated by transcribing the generated audio with Qwen3-ASR 1.7B.

ASIST playback was measured on October 9, 2026, using the released version 0.8.0, which bundles speech.cpp 0.8.2, on the same M5. After one warmup text per model, I played each of the same 20 texts once, with backchannels and bridge phrases disabled. Qwen3-TTS used ono_anna; Irodori-TTS used ASIST's bundled calm-young-woman voice. The conversation API returned the requested text exactly in all 60 cases. Synthesis start was estimated by subtracting the app's reported synthesis time from the time that measurement arrived in the renderer. Voice onset was the first 20 ms window of the scheduled audio with RMS at or above 0.004. Inter-process communication adds measurement error; output-device latency is excluded.

For underrun checks, the speech.cpp worker read the same 20 texts while I recorded chunk arrival times. Assuming playback starts with the first chunk, there is no underrun if every later chunk arrives before all preceding audio finishes playing.

Recognition used the Common Voice 8.0 Japanese test set, 4,483 examples with 93,471 reference characters, in the same order for every implementation on M5 and RTX 2080. silero-vad v4 found the speech boundaries; trimming retained 0.2 seconds on each side. Four examples with no detected speech were excluded. Qwen3-ASR used explicit ja, and latency excluded model loading.

Here are the M5 recognition results:

Here is parakeet-tdt-0.6b-v3 on 300 English FLEURS utterances:

NeMo-Speech.cpp does not publish F16 weights, so speech-bench used its conversion script to produce F16 files.

The long-recording experiment used speech.cpp's measure/region_cap_compare.py on M5 with Metal. It took 321 Japanese FLEURS test sentences, one recording per sentence, and the first 600 Common Voice 8.0 Japanese test recordings, trimmed them with Silero VAD, normalized them to -23 dBFS and joined them with 0.3–1.0-second gaps. Every fourth gap was two to eight seconds long, with -60 dBFS noise in the gaps. The resulting 105.6 minutes were transcribed with Japanese specified. CER used NFKC normalization with punctuation and whitespace removed. Results for each maximum region length follow, as FLEURS / Common Voice:

Live-transcription latency was measured by joining reference dump audio with silence, converting it to 24 kHz, and streaming it to /v1/realtime in real-time 20-millisecond pieces. Speech onset and offset are the edges of the unpadded speech regions.

Stage-by-stage comparison results

These Irodori-TTS results start each stage from inputs dumped by the official implementation, on Apple M5:

Metal's SNR is lower because ggml's Metal matrix multiplication rounds inputs to half precision. MF takes only four large steps, so those differences remain in the latents. On Metal, the waveform therefore differs while speaking the same content.

Here is FastConformer, parakeet-tdt_ctc-0.6b-ja, on three Japanese FLEURS utterances lasting 6.36, 10.50 and 25.50 seconds:

Inside the GGUF file

Each speech.cpp model occupies one GGUF file, including its codec. Names and languages use the standard GGUF metadata keys, so tools that read GGUF can display that information.

Before loading weights, speech.cpp checks that metadata and tensor names, shapes and types are complete. It rejects missing or unexpected entries by name. speech info displays this information without loading the weights.

Reproducing the tensor API bug

Add matrix-multiplication cases with 64 and 192 output columns to ggml's test-backend-ops and run them on M5. They fail with incorrect results through the tensor API and pass when GGML_METAL_TENSOR_DISABLE=1 disables it. Detailed instructions are in speech.cpp#13.

References

• speech.cpp
  • nyosegawa/speech.cpp
  • nyosegawa/speech-bench
  • speech.cpp#13: Metal on Apple M5 corrupts matrix products whose column count is 64 modulo 128
  • sakasegawa/common-voice-ja-accepted-spellings
  • ggml-org/ggml
• Models
  • Aratako/Irodori-TTS
  • Aratako/Irodori-TTS-v4.1-Small-MF
  • MeanFlow Distillation (Irodori-TTS docs)
  • Qwen/Qwen3-TTS-12Hz-0.6B-CustomVoice
  • Qwen/Qwen3-ASR-1.7B
  • nvidia/parakeet-tdt_ctc-0.6b-ja
  • nvidia/parakeet-tdt-0.6b-v3
  • reazon-research/reazonspeech-nemo-v2
  • snakers4/silero-vad
• OpenAI
  • Realtime transcription
• Paper
  • Flow Straight and Fast: Learning to Generate and Transfer Data with Rectified Flow
  • Mean Flows for One-step Generative Modeling
  • FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness
  • Fast Conformer with Linearly Scalable Attention for Efficient Speech Recognition
  • Universals and cultural variation in turn-taking in conversation
  • Lenient Evaluation of Japanese Speech Recognition: Modeling Naturally Occurring Spelling Inconsistency
  • Towards Orthographically-Informed Evaluation of Speech Recognition Systems for Indian Languages
  • HiKE: Hierarchical Evaluation Framework for Korean-English Code-Switching Speech Recognition
  • The Hidden Cost of Digits: Number Normalization and WER in ASR Systems
  • Echo-TTS
  • Qwen3-TTS Technical Report
• Other implementations
  • ggml-org/llama.cpp
  • FunAudioLLM/CosyVoice
  • Blaizzy/mlx-audio
  • 0xShug0/audio.cpp
  • mackron/miniaudio
  • MaAI-Kyoto/MaAI
• Articles on accelerating Irodori-TTS
  • irodori-TTS を速くする方法を理解したい (株式会社Rosso)
  • AITuber向けに Mac MPS で Irodori-TTS をチューニングして2.72倍高速化 / bf16 では遅くなった (osushi_cr)
• ONNX Runtime
  • CoreML Execution Provider
  • DirectML Execution Provider

今日は音声対話のために作った音声合成と音声認識のエンジン、speech.cppについてまとめていきたいと思います。

作ったもの

speech.cppは、音声合成と音声認識のモデルをggmlの上で動かすC++のエンジンです。MacではMetal、WindowsとLinuxではVulkanでGPUを使い、GPUがなければCPUで動きます。

いま動かせるのは次のモデルです。どれも、元のモデルの重みをspeech.cpp用のGGUFのファイルに変換して、Hugging Faceに置いています。

音声合成モデル

Qwen3-TTSは用意された9人の声から選べます。Irodori-TTSは録音や言葉で声を指定でき、速さを重視するならMFが向いています。

音声認識モデル

Qwen3-ASRは、固有名詞などをプロンプトで教えられます。日本語ではparakeet-jaが速く、ReazonSpeechはビームサーチで書き起こします。精度と速さは後半で比較します。

音声区間検出モデル

音声のどこで人が話しているかを見つけます。長尺の録音を区間ごとに書き起こしたり、話し終わりを見つけたりするのに使います。

使ってみる

インストールする

インストールは1行です。Apple siliconのMacと、x86-64のLinuxではこちら、

curl -fsSL https://raw.githubusercontent.com/nyosegawa/speech.cpp/main/install.sh | sh

Windows x64ではPowerShellで実行します（Vulkan対応のGPUドライバーが必要です）。

irm https://raw.githubusercontent.com/nyosegawa/speech.cpp/main/install.ps1 | iex

Linuxの配布版には、AVX2・FMA・F16Cに対応するCPUとglibc 2.34以降が必要です。Vulkanローダーが入っていなければ、インストーラーがCPU版を選びます。Intel Macではソースからビルドしてください。詳しい条件はインストールの説明にあります。

モデルは名前で指定します。初めて使うときに、Hugging Faceから取ってきてOSのキャッシュのフォルダに置きます。

ブラウザで試す

いちばん手軽なのは、試すためのページを開くことです。

speech serve --open

Speak、Transcribe、Liveのタブで、モデルを選んで文を読ませたり、録音や音声ファイルを書き起こしたり、マイクに話しているそばから書き起こしたりできます。

文を読み上げる

コマンドからも使えます。Qwen3-TTSで読む場合です。

speech tts qwen3-tts-0.6b --voice ono_anna --language ja -o out.wav "明日の東京は晴れです。"

好きな声で読み上げる

Irodori-TTSは、参照音声のWAVファイルを直接渡して、その声で読み上げられます。この例では、合成した音声をout.wavに保存します。

speech tts irodori-tts-mf \
    --add-voice me=my-voice.wav --voice me \
    -o out.wav "こんにちは。"

同じ声を繰り返し使うなら、speech voiceで声のファイルを一度作っておくこともできます。WAVを渡すたびに参照音声をエンコードする時間を省けます。

speech voice irodori-tts-mf my-voice.wav my-voice.voice.gguf
speech tts irodori-tts-mf \
    --add-voice me=my-voice.voice.gguf --voice me \
    -o out.wav "こんにちは。"

参照音声がなくても、声の特徴を言葉で書けば、それに合った声で読んでくれます。

speech tts irodori-tts-mf --voice none \
    --instructions "低く落ち着いた男性の声で、ゆっくりと読み上げてください。" \
    -o out.wav "明日の東京は晴れです。"

書き起こす

Qwen3-ASRは、固有名詞をプロンプトで教えられます。

speech asr parakeet-tdt_ctc-0.6b-ja utterance.wav
speech asr qwen3-asr-1.7b --language ja --prompt "逆瀬川, Codex, Claude" utterance.wav

長尺の録音やマイクから書き起こす

長尺の録音は、Silero VADで話している区間を見つけて、区間ごとに書き起こします。--liveにすると、マイクに向かって話しているそばから書き起こします。

speech asr reazonspeech-v2 --vad silero-vad meeting.wav
speech asr reazonspeech-v2 --vad silero-vad --live

HTTPサーバーとして使う

HTTPサーバーを立てると、OpenAIのAPIと同じ形で呼べます。

speech serve irodori-tts-mf --add-voice me=my-voice.voice.gguf
curl http://127.0.0.1:8080/v1/audio/speech -H 'Content-Type: application/json' \
    -d '{"input": "明日の東京は晴れです。", "voice": "me"}' -o out.wav

Pythonからは、届いたところからPCMを受け取れます。

import requests
import wave

with requests.post("http://127.0.0.1:8080/v1/audio/speech",
                   json={"input": "明日の東京は晴れです。", "voice": "me", "response_format": "pcm"},
                   stream=True) as r:
    r.raise_for_status()
    with wave.open("out.wav", "wb") as w:
        w.setnchannels(1)
        w.setsampwidth(2)
        w.setframerate(int(r.headers["X-Sample-Rate"]))
        for chunk in r.iter_content(chunk_size=None):
            w.writeframes(chunk)

アプリに組み込む

ふつうはHTTPサーバーかワーカーで足ります。アプリに直接組み込みたいときは、C APIを使います (C APIより)。

speech_model * model = NULL;
speech_request * request = NULL;
if (check(speech_model_load("Irodori-TTS-866M-MF-v4.1-F16.gguf", NULL, &model)) &&
    check(speech_voice_add(model, "bright", "bright-young-woman-10s.voice.gguf")) &&
    check(speech_request_new(model, &request)) &&
    check(speech_request_set_text(request, "明日の東京は晴れです。")) &&
    check(speech_request_set_string(request, SPEECH_OPT_VOICE, "bright")) &&
    check(speech_synthesize(request, on_audio, NULL))) {
    /* on_audio が、できた音声を少しずつ受け取る */
}
speech_request_free(request);
speech_model_free(model);

なぜ作ったか

わたしはASISTというデスクトップ向けの音声対話アシスタントを作っています。音声対話でいちばんしんどいのは待ち時間です。人どうしの会話では、相手が話し終えてから次の人が話し始めるまでは200ミリ秒くらいだそうです (Stivers et al., 2009)。アシスタントが1秒黙っていると聞こえているか心配になります。

日本語の声はAratakoさんのIrodori-TTSがとても良くて、読みが自然ですし、参照音声を渡せばその声で話してくれます。ただ、そのまま動かすと若干遅く、リアルタイムの会話には少し向きません。

Windowsではめちゃくちゃつらく、検証に使っているマシンはRTX 2080 (8 GB) なのですが、PythonとCUDAで音声のモデルを動かそうとすると、ことごとくうまくいきませんでした。

• Qwen3-TTSは、PyTorchの公式のパッケージでWindowsで動かせませんでした
• 音声認識に使っていたllama.cppは、CUDA 13向けのビルドがRTX 20向けの機械語を含んでおらず起動しませんでした。CUDA 12向けのビルドは動きましたが、最初の起動でGPUのコードのコンパイルに28秒かかりました

CUDAとPythonで行くなら、NVIDIAのGPUでドライバー580以上、RTX 20以降が前提になり、数GBのPythonの環境も配ることになります。

しかも、モデルごとに動かし方がばらばらでした。ASISTでは、音声認識をllama.cppのllama-serverで、読み上げを自分で作ったワーカーで動かしていました。llama-serverのほうは、モデルとmmprojの2つのファイル、ループバックのポートとその鍵、アプリが落ちたときに止める見張りが要り、文脈が4096トークンなので約270秒より長い発話は失敗していました。

なので、音声合成も音声認識もひとつのエンジンで動かせて、MacでもWindowsでもLinuxでも同じものがGPUで動いて、会話に間に合う速さで、公式の実装と同じ結果を出すものが欲しい気持ちがありました。まずは、声が出るまでを短くする話からです。

音声合成: 声が出るまでを短くして途切れないようにする

最初の声が出るまでを見る

ASISTは会話のモデルの返事を文ごとに分けて、届いたものから読み上げています。Irodori-TTSには1文ずつ渡し、Qwen3-TTSには待っている文を合計300文字以内でまとめて渡します。続きは先の音声を再生しているあいだに作れるので、利用者が最初に待つのは最初の文の声が出るまでです。なので全体の速さ (RTF、1秒の音声を作るのに何秒かかるか) よりも、最初の声が出るまでの時間を見ていきます。

計測するときは、相槌、短い返事、長めの説明、英単語まじりのテキストなど20文を、どの実装にも同じ声で読ませて中央値を取りました。Irodori-TTSのseedは固定し、Qwen3-TTSのseedは毎回変えています (くわしくはAppendixに書いています)。

Irodori-TTSのしくみ

Irodori-TTSは、LLMのように1トークンずつ出していくモデルではありません。Echo-TTSにならったDiffusion Transformer (DiT) が、音声コーデックの潜在表現 (latent、48 kHz、25 Hz、32次元) をテキスト全体ぶん一気に作り、コーデックがそれを波形に戻します。音声の長さは、生成の前に別のモデルが予測します。

DiTはテキスト全体をいっぺんに見て解くので、途中から声を出すことはできません。公式の実装では、声が出るまでに、テキストの準備、長さの予測、サンプラーの全ステップ、コーデックのデコードが全部終わっている必要があります。

DiTがノイズから音声を作るやり方の違いで、モデルが2つあります。

もとのv4.1-SmallはRectified Flowで学習しています。ノイズと音声のあいだを直線で結んで、その途中の各点で「どちらにどれだけ進めばいいか」(速度) を覚えさせます。生成するときは、いまの速度を予測して少し進む、を40回繰り返します。テキストや話者に強く従わせるCFGのために、前半はDiTを3回ずつ計算するので、けっこう重いです。

v4.1-Small-MFは、v4.1-Smallを教師モデルとしてMeanFlowで蒸留したモデルです。MeanFlowは、その時点の速度ではなく、ある区間の平均の速度を覚えます。その時点の速度のまま大股で進むと曲がった道からはみ出してしまいますが、区間の平均の速度がわかっていれば大股でも目的地に着けます。教師モデルのCFG付きの道筋をそのまま学ぶので、生徒モデルは1ステップにDiTを1回計算するだけで済み、4ステップで音声ができます (Irodori-TTSのMeanFlowの説明)。

MFのモデルカードによると、v4.1-Smallをそのまま4ステップにすると参照音声との声の近さが0.75から0.38まで落ちますが、MFなら4ステップで0.74を保てます。会話では速さが大事なので、ASISTではMFを使っています。

公式の実装はどこに時間を使っているか

では公式の実装は何に時間を使っているのでしょうか。M5のMPSで、MFに33文字のテキストを読ませて処理ごとに計測しました。

参照音声をWAVEファイルで渡すと、読ませるたびに毎回エンコードしています。一度エンコードした潜在表現を渡せばこの1秒はなくなり、音声もまったく同じものが出ます。残りでいちばん時間がかかっているのは、コーデックのデコードでした。MFでステップが4まで減ったので、DiTよりコーデックのほうが重くなっています。

速くする方法を考える

この内訳を見ながら、速くする方法を考えてみます。

ステップを減らすのは、MFを使えば済みます。参照音声のエンコードは、一度作った潜在表現を使い回せば済みます。

Irodori-TTSを速くする工夫は、ほかの方も試して記事にしています。Rossoさんの記事は、RTX 3080とv4で1文の時間を処理ごとに分けて測り、DiTの計算そのものより、GPUに命令を出す手間で時間がかかっていることを確かめています。そこでDiTをCUDA Graphに記録して命令を出す手間を省き、文ごとに違う音声の長さは、予測した長さを少し切り上げていくつかの長さにそろえることで対応しています。5.1秒の音声を作る時間が0.90秒から0.30秒になり、Sway Samplingでステップを8に減らすと0.23秒になっています。

Macではosushi_crさんの記事があります。M1 MaxのMPSとv2で、Sway Samplingでステップを40から8に減らし、モデルを常駐させて次の文を再生中に作っておくことで、5文の読み上げを28.77秒から10.58秒にしています。MPSではbf16にするとかえって遅くなり、コーデックをCPUに置くと2倍ほど遅くなったそうです。

どちらもPyTorchのまま、動かし方を工夫して速くしています。speech.cppでは、MacでもWindowsでも同じものをGPUで動かしたいので、別の方向も考えました。

重みを8ビットに量子化して軽くする手もあります。ただ、Irodori-TTSで試すと、20文を書き起こしたCERが2.99%から3.81%に増え、聞いてわかる崩れも出ました。

PyTorchから別の実行環境に移す方法もあります。ONNX Runtimeは、MacではCoreMLを経由し、これはプレビュー扱いで入力の形が変わると遅くなります。WindowsのDirectMLは保守だけの扱いになりました。MLXはMacでしか動きません。MacとWindowsの両方でGPUを使いたいので、ggmlを選びました。

ggmlは、llama.cppやwhisper.cppのもとになっているC/C++のテンソルのライブラリです。Metal、Vulkan、CUDA、CPU向けの計算をそれぞれ持っていて、計算グラフは呼ぶたびに組み立てるので、テキストの長さが毎回違っても困りません。実行ファイルにそのまま組み込めるので、使う側は何もインストールしなくて済みます。

最後に、作り終える前に声を出してしまう方法です。DiTはテキスト全体ぶんを一度に作るので途中では出せませんが、DiTが終わったあとのコーデックのデコードは、少しずつ進めて流せます。MFではコーデックのほうがDiTより重いので、ここを少しずつ流せば待ち時間はかなり減るはずです。

speech.cppでやったこと

speech.cppでは、MFをggmlに移植し、参照音声は潜在表現にしてファイル (声のファイル) に保存し、コーデックをウィンドウに分けてデコードしました。

コーデックは、全体を一度にデコードするのをやめました。最初の12フレーム (0.48秒ぶん) をデコードしたらすぐ返して再生を始め、残りは再生しているあいだに24〜48フレームずつデコードします。ウィンドウの大きさは、それまでのウィンドウで計測したデコードの速さから、聞いている人の手元に0.1秒ぶんの音声が残っているうちに終わる、いちばん大きいものを選びます。遅いPCでは小さく、速いPCでは大きくなります。

ウィンドウに分けるときは、つなぎ目で音が変わらないようにしています。各ウィンドウの前後に10フレームずつ余分にデコードして、その部分を捨てると、一度にデコードしたときと同じ波形になります。どの大きさで分けてもビット単位で同じなので、PCの速さでウィンドウの大きさが変わっても、同じseedなら同じ音声が出ます。これでデコードの時間のほとんどが再生と重なり、待ち時間にはほぼ入らなくなりました。

もうひとつ、会話ならではの工夫があります。会話では、アシスタントが話している途中でこちらが話し始めることがよくあります。そのとき読み上げ中の文を取り消しても、サンプラーが最後まで回ってしまうと次の返事が待たされます。そこでサンプラーのステップの合間に取り消されていないかを確かめるようにしました。120文字のテキストを取り消した直後の返事は、声が出るまで881ミリ秒かかっていたのが351ミリ秒になりました。

Qwen3-TTSは1フレームずつ流す

Qwen3-TTSは、Irodori-TTSとは逆に、LLMのように音声トークンを1フレームずつ出していくモデルです。1フレームは0.08秒ぶんの音声で、16個のコードブックのトークンでできています。talker (Qwen3のデコーダー) が各フレームの1つ目のトークンを出し、code predictorが残りの15個を埋めます。コーデックも過去の入力しか見ないので、1フレームできるたびにデコードして流せます。speech.cppではコーデックの途中の状態を次の呼び出しに持ち越しているので、1フレームずつデコードしても、全体を一度にデコードしたときとほぼ同じ波形になります (後で比較するqwentts.cppとの違いは、ここです)。

ほかの実装と比較する

M5で、同じ20文を、同じ参照音声、同じseedで読ませて比較しました。参照音声のエンコードは、どの実装も一度だけにしています。speech.cppの行は名前を太字にし、同じモデルの中でいちばん速い値も太字にしました (このあとの表も同じです)。

RTX 2080 (Vulkan) のWindowsでも計測しました。mlx-audioはMacでしか動かず、公式の実装はWindowsでは試していないので、この表には入っていません。

表の時間は、合成を要求してから最初の音声が届くまでです。声が実際に始まるまでとは違います。Qwen3-TTS 0.6Bは、文の頭に無音を作ることが多いモデルです。最初の音声は0.04秒で届いても、声が聞こえ始めるのは中央値で0.5秒ほどあとでした (4人の声で0.24〜0.48秒、長いときは1.9秒)。公式の実装でも同じで、ono_annaに同じ文を20回読ませると、頭の無音は中央値で0.89秒ありました。1.7Bは0.10秒、Irodori-TTSのMFは0.03秒なので、会話で使うなら1.7BかIrodori-TTSのほうが早く声が聞こえます。

公式の実装もmlx-audioもaudio.cppも、音声を全部作り終えてから返すので、声が出るまでの時間は1文を作り終える時間と同じです。speech.cppは最初のウィンドウをデコードしたら返すので、ここで差がつきます。MFのRTFはmlx-audioとほぼ同じ (0.174と0.171) なので、全体の速さはあまり変わらず、声が出るまでの差はほとんどがウィンドウに分けてデコードしたおかげです。CERは、合成した音声をQwen3-ASR 1.7Bで書き起こして数えたもので、実装ごとにノイズの作り方が違うので、1回の計測だと数ポイントは上下します。audio.cppはMFに対応していないので、RFの16ステップで比較しています。

声が出たあとに途切れないようにする

声が早く出ても、途中で途切れては困ります。音声をチャンクに分けて少しずつ渡すときは、届いた音声を再生し終える前に、次のチャンクが届いている必要があります。最初のチャンクを小さくすれば声は早く出ますが、そのぶん次のチャンクが間に合いにくくなります。

ほかの実装は、これをそれぞれ別のやり方で避けています。Qwen3-TTSの公式は、最初から4フレーム (0.32秒分) ずつ送ります (Qwen3-TTS Technical Report)。途切れにくい代わりに、最初の声は4フレームを作り終えるまで出ません。CosyVoiceは、チャンクを毎回決まった倍率で大きくしていきます。倍率は、動かすPCの速さに合わせて人が決めます。再生する側で多めに貯めてから鳴らすやり方もありますが、そのぶん声が出るのが遅れます。

speech.cppのQwen3-TTSでは、最初は小さく、だんだん大きくしていくようにしました。チャンクの大きさは、1フレーム、1フレーム、2フレーム、そのあとは4フレームずつです。

1フレームを作るのにかかる時間は、M5でもRTX 2080でも、1フレームぶんの音声 (0.08秒) よりずっと短いので、小さいチャンクで始めれば、次のチャンクが届く前に手持ちの音声が尽きることはありません。そのあとは4フレームずつまとめて送るので、コーデックを呼ぶ回数もほとんど増えません。

チャンクの大きさを、その場の速さを計測しながら決めることも考えました。ただ、チャンクの分け方が変わると、聞き分けられないほどわずかですが音声の値も変わります。その場の速さで分け方を決めると、同じseedでも実行するたびに音声が変わってしまうので、決まった表にしています。ここまでの話は、生成した音声を頭の無音も含めて、そのまま再生する場合です。

本当に途切れないかも確かめました。同じ20文を読ませ、最初のチャンクが届いたらすぐ再生を始めたとして、手元の音声を鳴らし終える前に次のチャンクが届いているかを見ています。M5でもRTX 2080でも、Qwen3-TTSの0.6Bと1.7B、Irodori-TTSのMFと16ステップのどれも、20文すべてで一度も途切れませんでした。

ASISTでは、頭のほぼ無音な部分だけを削ります。息やため息などの音が始まったら、その後の間も残します。ただ、頭を削るとその間に次の音声を作る余裕もなくなるので、最初の音が届いてから、届いている音声の長さと合わせて0.2秒になるだけ待って鳴らします。すでに前の文の再生を待つ間に0.2秒以上届いていれば、追加では待ちません。

公開版のASIST 0.8.0でも、M5で同じ20文を読ませて確かめました。モデルを読み込んだあと、合成開始から声の部分を再生する予定時刻までの中央値は、Qwen3-TTS 0.6Bが0.40秒、1.7Bが0.25秒、Irodori-TTS MFが0.26秒でした。これはWeb Audioの再生予定から求めた値で、スピーカーや出力機器の遅延は含めていません。

これで音声合成は、会話に間に合う速さで、途切れずに話せるようになりました。

公式実装と同じ形状であることをしっかり確かめる

モデルを別の実行環境に移すと、計算の順番や精度が少しずつ変わります。音声合成なら声が少し変わり、音声認識なら書き起こしのテキストが変わります。困るのは、聞いただけでは気づけないことです。音声合成は毎回ノイズから作るので、もともと読むたびに声が少し違いますし、音声認識の違いは数十件に1件にしか出ないこともあります。

そこでspeech.cppでは、移植するモデルごとに、公式の実装と段階ごとに比較するようにしました。

たとえばIrodori-TTSでは、テキストの処理、DiT、デコードの段階ごとに、次のように比べています。

1. 公式の実装をCPUのfloat32で、ノイズを固定して動かし、各段階の入力と出力をファイルに書き出す
2. 移植したほうの各段階に、書き出した同じ入力を渡す
3. 出力を比較する。数値はSNR (誤差が信号よりどれだけ小さいか) で、トークンや文字列は完全に一致するかで見る

ほかのモデルも、段階の分け方が違うだけで同じように比べています。Qwen3-TTSはサンプリングせずにgreedyで動かして比べ、音声認識のモデルは、音声の特徴量、エンコーダー、デコーダーの段階ごとに比べます。

1段ずつ同じ入力から始めるので、どこでずれたかがすぐわかります。CPUのfloat32なら、Irodori-TTSはどの段階も公式と86 dB以上の精度で一致し、Qwen3-TTSはgreedyデコードで読ませると公式と同じ54フレームを出し、parakeetとReazonSpeechは音声から書き起こしたテキストがすべて公式と一致します (表はAppendixにあります)。

この比較をしていると、ほかの実装でずれてるとこにも気がつけるようになりました。

• llama.cppのQwen3-ASRは、公式と違うテキストを書くことがありました。10個の録音を書き起こさせると (言語を自動にした場合と指定した場合で、合わせて20回)、0.6Bで6回、1.7Bで4回が公式と違っていました。たとえば公式が「群島や湖では必ずしもヨット」と書いたところを、1.7Bは「軍港や湖ではカマザタ寿司もヨット」と書いています。原因は、モデルに渡す入力が公式と少しずつ違うことでした。最初に置く指示 (systemの発言) が抜けていて、音声の特徴量 (log-mel) が1フレーム多く、音声の最後の1秒に満たない部分をゼロで埋めて、その無音のぶんまで音声のトークンにしています
• qwentts.cppのQwen3-TTSは、少しずつ流しながら作ると、声に震えるような雑音が乗りました。同じテキストを一度に全部作ったときは乗りません。Qwen3-TTSのコーデックは、それまでの音声の続きとして次の音声を作る仕組みです。なので、チャンクをまたいでコーデックの途中の状態を引き継げば、少しずつ作っても一度に作ったときとほぼ同じ波形になります。speech.cppはそうしていて、1フレームずつ作った音声と一度に作った音声の差が、聞き分けられないほど小さい (133 dB) ことを確かめています
• CrispASRのReazonSpeechは、前後に無音の残る録音で、録音にない「あっ。」や「うん。」を書き足しました (Common Voiceの最初の10文のうち4文)。前後の無音を詰めると、4,479文のうち数文に減ります
• audio.cppのIrodori-TTSは、コーデックをMetalで動かすと、声の14 dB下に歪んだ同じ声が重なり、無音のはずの部分も持ち上がります

どれも、聞き比べただけでは気づきにくい違いです。逆に、段階ごとに公式と同じだと確かめられていれば、速くするために計算の形を変えても、結果が変わっていないことをすぐ確かめられます。次は、ユーザーの声を聞くほうです。

音声認識: きれいに移植できるようにがんばる

FastConformerを1回だけ移植する

音声認識のモデルで最初に移植したのは、NVIDIAのNeMoのモデルです。parakeet-tdt_ctc-0.6b-ja (日本語)、parakeet-tdt-0.6b-v3 (ヨーロッパの25言語)、ReazonSpeech NeMo v2 (日本語) の3つは、どれもFastConformerという同じ形をしています。log-melの特徴を作り、畳み込みで時間方向を8分の1にして、24層のConformerに通し、最後のデコーダーでトークンにします。

違いは細かいところだけです。

なので、FastConformerを1回だけ移植して、違うところはGGUFのファイルに書いた設定で切り替えるようにしました。

デコードのやり方は、NeMoのtranscribe()がデフォルトで使うものに合わせています。parakeet-jaにはCTCの頭もついているのですが、NeMoはデフォルトでTDTを使い、2つは一部の発話で違うテキストを書くので、TDTだけを移植しました。ReazonSpeechも、NeMoのgreedyデコードではなく、モデルの設定にあるビームサーチ (幅4) を使います。greedyデコードだと、句読点が抜けたり別の言葉になったりする発話があったからです。ただgreedyのほうがずっと軽いので、頼めばgreedyでもデコードできるようにしました。Common Voiceの4,483文では、M5でCERが12.03%から12.50%に上がるかわりに、待ち時間の中央値は0.110秒から0.077秒になります。

Qwen3-ASRも組み込むことに

Qwen3-ASRは、音声のエンコーダーの後ろにQwen3の言語モデルがつながった形をしています。言語モデルの部分は、キャッシュを持って1トークンずつ書き出していくので、llama.cppがもともと得意なところです。なので最初は、Qwen3-ASRはllama.cppで動かして、speech.cppではFastConformerだけを動かすつもりでした。同じことを2回作る必要はないと考えたからです。

ところが、段階ごとに比較してみると、前に書いたとおりllama.cppのプロンプトは公式と違い、20回中4〜6回でテキストが変わりました。約270秒より長い発話も失敗します。それに、llama-serverを動かし続ける限り、ASISTはspeech.cppとは別の実行環境をもう1つ抱えることになります。

そこで考え直して、Qwen3-ASRもspeech.cppに移植しました。実はQwen3のデコーダーは、Qwen3-TTSのtalkerですでに移植していました。同じものなので、そのまま使い回せます。新しく作ったのは、8秒ずつのウィンドウの中だけを見る音声のエンコーダーと、公式のqwen-asrが書くとおりのプロンプトです。言語を指定すると、答えの書き出しにlanguage Japanese<asr_text>を置いてモデルを導くところまで、公式と同じにしています。こうすると、書き起こしのテキストは公式と同じになりました。

公式と同じ書き起こしが出せるようになったので、次はどのくらい正しく聞き取れているかを計測したくなります。ところが日本語では、この「正しさ」を計測すること自体にも難しさがありました。

表記の揺れを許して日本語の書き起こしの精度を計測する

音声認識の正しさは、ふつう書き起こしと参照のテキストの文字の誤り率 (CER) で計測します。ただ日本語は、同じ言葉にいくつもの書き方があります。参照が「三十分」で書き起こしが「30分」なら、聞き取りは合っているのに、CERでは誤りとして数えられてしまいます。

モデルが良くなるほど、CERは「聞き取れたか」より「参照と同じ書き方を選んだか」を計測するようになっていきます。

これは日本語に限った話ではなく、いくつも研究があります。

• Karita, Sproat, Ishikawa (CAWL 2023)は、日本語の参照のテキストを、ありうる書き方の組み合わせ (ラティス) に広げてから採点しています。人が見て95.4%の書き方を妥当と判断し、CERはタスクによって2.4〜3.1ポイント下がりました
• OIWER (ICASSP 2026)は、インドの言語で、LLMを使って書き方の揺れを拾っています。誤り率は平均で6.3ポイント下がり、人の感覚に近くなりました
• HiKE (EACL Findings 2026)は、韓国語と英語が混ざる話し言葉の評価セットで、外来語にラベルを付けています
• Kacprzak and Fraś (2026)は、ポーランド語で、数字を正規化するかどうかだけでWERが2ポイント以上動き、システム同士の差を上回ることがあると報告しています
• 昔からある評価ツールのNIST sclite も、参照に{ a / b / @ }のように別の書き方を並べて書けるようになっています

そこで、計測に使っているspeech-benchでは、ふつうのCERのほかに、表記の揺れを許したCERも出すようにしました。参照のテキストの1文ごとに、次のような注釈を付けておきます。

• かなで書かれていない部分には、読みをかなで付ける: 明日《あした》、｜Zoom《ズーム》
• 読みだけでは表せない別の書き方を並べる: ［九《く》時《じ》／9時］
• 「えーと」のようなフィラーは、なくてもよいことにする: ［えーと／えっと／］

書き起こしは、この注釈から作れる書き方のうち、いちばん近いものと比較して誤りを数えます。分母は参照のテキストの文字数のままなので、表記の揺れを許したCERは、ふつうのCERより大きくなることはありません。同じ音でも意味の違う言葉 (機会 と 機械) や、意味は同じでも話した言葉と違うもの (3時半 と 3時30分) は許さないので、本当の聞き間違いは誤りとして残ります。

Common Voice 8.0の日本語のテスト (4,483文) に付けた注釈は、sakasegawa/common-voice-ja-accepted-spellingsとしてHugging Faceに公開しています (CC0)。採点するスクリプトも付けていて、speech-benchと同じ誤りを数えることを、17,932件の書き起こしで確かめています。Common Voiceの音声とテキストはそれぞれの配布元から取ってきて、このデータセットの注釈と合わせて使います。

表記の揺れを許すと、たとえばCommon VoiceでのQwen3-ASR 1.7BのCERは9.25%から4.56%になります。誤りとして数えられていたもののおよそ半分が、書き方の違いだったということです。このあとの表では、両方のCERを並べています。

精度を比較するためのベンチマークはこれで準備できました。ただ、移植した直後のspeech.cppは、llama.cppより遅かったのです。

llama.cppと同程度になるまで速くする

M5でQwen3-ASR 0.6Bを動かすと、speech.cpp 0.7.0は1秒に123〜132トークンを書き出し、llama.cppは158〜165トークンでした。音声認識の時間の9割はこのデコードなので、ここを詰めないとllama.cppより遅いままです。

やったことは2つです。

1つ目はflash attentionです。speech.cppのQwen3のデコーダーは、attentionを2回の行列積とsoftmaxで計算していました。ggmlのggml_flash_attn_extはスコアを溜めずにまとめて計算するので、GPUではこちらのほうが速くなります。M5のMetalでは、キャッシュが2,000位置なら2.62ミリ秒が2.20ミリ秒に、8,000位置なら9.59ミリ秒が8.10ミリ秒になりました。ただCPUでは逆に、8,000位置で22.1ミリ秒が51.2ミリ秒と遅くなります。なので、モデルを読み込むときに、そのGPUのバックエンドがflash attentionを計算できるか (ggml_backend_supports_op) を見て、できるときだけ使うようにしました。

flash attentionは、attentionを小さなブロックに分けて、softmaxを少しずつ更新しながら計算し、大きなスコアの行列をメモリに置かない計算のやり方の名前です (Dao et al., 2022)。CUDAのライブラリのFlashAttention-2はRTX 30シリーズ以降向けですが、ggmlは同じやり方をMetalやVulkanのシェーダーで自前で書いているので、RTX 2080のVulkanでも使えます。

2つ目は、デコードの1ステップごとの計算グラフを、トークンの間で使い回すことです。ggmlでは計算グラフを組み立てるのにも時間がかかるので、形が同じあいだは組み立て直さないようにしました。

これで、M5のデコードは0.6Bで1秒に146〜158トークン (llama.cppは147〜157)、1.7Bで58〜63トークン (同じく58〜62) と並びました。RTX 2080では、0.7.0より13〜25%速くなりました。

Common Voice 8.0の日本語のテスト (4,483文) を、RTX 2080のWindowsで書き起こしてみた結果がこちらです。前後の無音はVADで詰めています。CERは書き起こしの文字の誤り率で、その右の列が前の章の表記の揺れを許したCERです。待ち時間は、要求を送ってからテキストが返るまでです。NVIDIAが出しているNeMo-Speech.cppも、speech.cppと同じくggmlでFastConformerを動かす実装なので、一緒に比べました。

Qwen3-ASRは、精度がllama.cppとほぼ同じで、待ち時間は1.7Bで10%、0.6Bで17%短くなりました。parakeetは、精度がCrispASRと同じで、待ち時間は3分の1です。重みがspeech.cppではF16、CrispASRではQ8_0なので、差の一部は重みの違いかもしれません。

ReazonSpeechは、NeMo-Speech.cppがいちばん速く、精度も少し上でした。greedyどうしで比べても、speech.cppより1.6倍速いです。M5でも1.4倍の差があり、parakeet-v3でもNeMo-Speech.cppのほうが速かったので (表はAppendixにあります)、FastConformerのどこで差がついているかを調べて、次のリリースで詰めるつもりです。CrispASRのReazonSpeechは、前の章で書いたように前後の無音に「あっ。」を書き足しますが、無音を詰めたこの条件では、speech.cppのビームサーチより少し正確でした。Common Voiceは文を読み上げた録音なので、会話の話し言葉ではまた違う結果になりえます。

ちなみに、M5ではまだllama.cppのほうが少し速いところがあります。Common Voiceの4,483文では待ち時間の中央値が並び、p90はllama.cppのほうが8%短くなりました。長い発話ほど差が出ていて、25.5秒の日本語の発話では、0.6Bはspeech.cppが0.80秒、llama.cppが0.75秒でした。デコードは並んだので、差が出ているのは音声のエンコーダーとプロンプトの読み込みです。llama.cppはここの行列積をMetal 4のtensor APIで計算していて、speech.cppはそれを使っていません。使わなかったのはちょっとしたバグが理由でした。以下でそれについて軽く説明します。

M5で見つけた不具合

Irodori-TTSの移植が終わって完成と思ったころ、M5で読ませた64本のうち1本だけ、音声の後半が雑音になりました。「暗証番号は4桁で、8264です。」の「8264です」がザーッという音に埋もれています。同じテキストをCPUやRTX 2080で読ませると、きれいに出ます。

調べると、原因はggmlのMetalの行列積でした。M5以降のチップでは、ggmlはMetal 4のtensor APIで行列積を計算します。このkernelが、出力の列の数を128で割って64余るとき (64、192、320…) だけ、出力の外まで書き込んでいました。はみ出した書き込みが隣のテンソルを書き換えるので、毎回違う結果になります。

雑音になった音声は、ちょうどこの条件に当たっていました。そのころはコーデックを48フレームずつ、前後に10フレームずつ足してデコードしていたので、114フレームの音声の3つ目のウィンドウが50〜114フレーム、つまりぴったり64フレームだったのです。

ggml自身のテスト (test-backend-ops) は通っていました。この形のケースがなかったからです。64列と192列のケースを足すとtensor APIでは失敗し、GGML_METAL_TENSOR_DISABLE=1でtensor APIを止めると通りました (speech.cpp#13)。

本体が直る前にできることは限られています。speech.cppではM5で同じ20文を読ませて比較してみてこの差は受容できる（というか、するしかない）と考え、tensor APIを止めています。

声が出るまでは0.04秒遅くなりましたが、雑音の心配がなくなり、ついでに公式との差も小さくなりました。前の章のM5での音声認識の差もこれが大きいです。ggmlの新しいバージョンでこの形のケースが通るようになったら、tensor APIを使うように戻して計測し直すつもりです。

OpenAIのRealtime Transcriptionに対応する

さて、ここまでは1つの発話を書き起こす話でした。使っていると、会議のような長尺の録音を書き起こしたり、話しているそばから文字を出したりしたくなります。0.8.0では、この2つを入れました。

長尺の録音を丸ごと渡すと文が消える

試すページで書き起こしていると、話したはずの文がまるごと抜けることがありました。ページは音声を20秒ずつに切ってサーバーに送っていて、その20秒に3つか4つの文が入っていると、ReazonSpeechが前の2文を落としていたのです。公式のNeMoに同じ音声を渡しても同じ文を落としたので、移植の誤りではなく、モデルの性質です。

どれくらい落ちるのかを測りました。FLEURSとCommon Voiceの日本語のテストの文を、0.3〜1.0秒の間をあけてつないで数分の録音を作り、丸ごとと、話している区間ごとに書き起こしました (作り方はAppendixに書きました)。半分以上の文字が消えた文を「落ちた」と数えています。

FastConformerの2つは、数分を丸ごと渡すと文をまとめて落とします。いっぽうQwen3-ASRはほとんど落とさず、CERも丸ごとのほうが少しよいくらいでした (FLEURSで9.80%と11.44%)。LLMのデコーダーが、前後の文脈を長く使えるからだと思います。区間ごとでもCommon VoiceでReazonSpeechが46文落としているのは、話す人の違う短い文が1つの区間に入ってしまうためで、つないだ録音ならではの数字です。

そこで、音声のどこで人が話しているかを見つけるSilero VADを移植して、区間ごとに書き起こしてつなぐようにしました。Silero VADは1.2 MBの小さなモデルで、公式のget_speech_timestampsと同じ区間をサンプル単位で返します。区間の終わりの決まりはOpenAIのserver_vadの既定に合わせて、0.5秒の無音で区切ります。間の短い話し方だと1つの区間が20秒を超えるので、区間の長さの上限を8秒から30秒まで変えて測り、平均のCERがいちばん低かった10秒にしました。

HTTPサーバーでは、OpenAIの書き起こしのAPIのchunking_strategyで区間ごとになります。まず、音声認識とVADの両方のモデルを読み込んでサーバーを起動します。前の例のサーバーが動いていれば、Ctrl+Cで止めてから実行してください。

speech serve reazonspeech-v2 silero-vad

別のターミナルから、OpenAIのPythonのSDKで呼び出せます。

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:8080/v1", api_key="unused")
with open("meeting.wav", "rb") as f:
    print(client.audio.transcriptions.create(model="reazonspeech-nemo-v2", file=f, chunking_strategy="auto").text)

話しているそばから文字を出す

もう1つは、話しているそばから文字を出すことです。形はOpenAIのRealtime APIの書き起こしに合わせたので、OpenAIのクライアントは接続先を変えるだけで使えます。

Realtime APIでは、話している途中の文字はdeltaというイベントで送ります。deltaは後ろに足していくことしかできず、前に送った文字を書き換える手段がありません。OpenAIのgpt-live-transcribeも、deltaを足していき、話し終わりのcompletedで全体を置き換える形です。speech.cppは、話している途中の音声を読み直すたびに前回の結果と比べて、2回続けて同じだった先頭の部分だけをdeltaで送り、話し終わったらcompletedで確定した文を送ります。

M5でほかに何も動かさず、6つの発話をつないだ音声を実時間で3回ずつ流して計りました。

話し終わりから確定までのうち0.6秒は、0.5秒の無音が続くまで待つ時間です。silence_duration_msで短くできますが、そのぶん息つぎで発話が切れやすくなります。最初の文字が少し遅いのは、2回の読み直しが一致するのを待っているからです。

コマンドの--liveは、マイクから同じように書き起こします。マイクはminiaudioを実行ファイルに組み込んで読んでいるので、SDL2やPortAudioを入れなくても動きます。

ちなみにASISTはこの仕組みを使っていません。話し終わったかどうかを相槌の分類器やMaAIの話し終わりの予測も使って自分で決めているからです。ASISTでは自分で切った発話をspeech.cppのワーカーに渡しています。

ひとつにまとめてよかったこと

ここまで、音声合成と音声認識を別々に見てきましたが、ぜんぶが同じエンジンに入っていることにもいいことがあります。

まず、配るものが少なくて済みます。speech.cppは、実行ファイルspeechが1つと、モデルのファイルが1つあれば動きます。実行ファイルはMacの0.8.2で約6.7 MB、WindowsではVulkanのシェーダーを中に持つので48 MBです。モデルは、コーデックも含めて1つのGGUFのファイルにまとめました。Releasesには、macOS (Metal)、Windows (Vulkan)、Linux (VulkanとCPU) 向けのビルドを置いていて、インストーラーがPCに合うものを選んで入れます。CUDAもPythonも要りません。

起動してから話せるようになるまでも速いです。ASISTはマイクを入れたときだけ音声のモデルを読み込むので、ここが遅いとマイクを入れてもしばらく話せません。

M5で起動してから最初の要求を受け付けられるようになるまでを計測しました (モデルのファイルはOSのキャッシュに載っている状態です)。

どのモデルも、同じやり方で呼び出せます。

呼び出し方は4つあります。

• speechコマンド: テキストを読むspeech tts、音声を書き起こすspeech asr、参照音声から声のファイルを作るspeech voiceなど
• HTTPサーバー (speech serve): OpenAIの音声のAPI (/v1/audio/speechと/v1/audio/transcriptions) と、Realtime APIの書き起こし (/v1/realtime) と同じ形で答える
• ワーカー (speech worker): 標準入出力でJSON Linesをやりとりする。ASISTはこれで動かしている
• C API (speech.h): 上の3つも、すべてこのC APIの上に作っている

ASISTは、読み上げも音声認識もspeech.cppのワーカーで動かすようになり、llama-serverを同梱するのをやめました。

まとめ

• 音声合成と音声認識の9つのモデルと音声区間検出のSilero VADを、ggmlで動くひとつのエンジンにまとめ、MacとWindowsとLinuxで実行ファイル1つで動くようにしました
• 公式の実装と段階ごとに比較して同じ結果を出すことを確かめながら、M5でIrodori-TTSの声が出るまでを0.25秒にし、RTX 2080ではQwen3-ASRをllama.cppより速くしました
• M5のtensor APIの不具合は、速さより正しさを取って、tensor APIを止めて避けました。FastConformerの速さはNeMo-Speech.cppにまだ負けているので、次に詰めます
• 長尺の録音はSilero VADの区間ごとに書き起こすことで文が落ちることが大きく減り、話しているそばからの書き起こしはOpenAIのRealtime APIと同じ形で使えるようになりました

追記: 0.8.3でFastConformerを高速化しました (2026-10-10)

上で「次のリリースで詰めるつもりです」と書いたFastConformerを、speech.cpp 0.8.3で高速化しました。FFTの中で繰り返していたメモリの確保、入力が変わっても同じ位置情報の計算、デコーダーの計算グラフの作り直しを減らしています。

0.8.2と0.8.3を同じ音声で交互に動かすと、文字起こしが返るまでの時間の中央値は次のようになりました。どれもF16で、読み込みと初回のウォームアップを除いた計測です。

日本語の速度はCommon Voiceの先頭100件のうちVADで残った99件を3回、英語はFLEURSの300件のうち残った299件を1回ずつ測りました。本文の日本語4,483件の表とは件数が違うので、その表を置き換える数字ではありません。ReazonSpeechの標準のbeam searchも、M5では104 → 85 msになりました。

精度はM5で別に全件を確認しました。記事の前回計測と比べて、ReazonSpeechのgreedyは日本語4,483件でCERが12.50 → 12.49%、表記の揺れを許したCERは7.69%のままです。VADで除外された4件を除く4,479件中5件で文字起こしが変わり、空の結果は4件のままでした。parakeet-v3の英語300件もWERは8.76%のままです。

NeMo-Speech.cppとも同じ音声を交互に処理させると、Windowsではほぼ同じ速さになりました。M5ではNeMo-Speech.cppのほうがReazonSpeechで約3 ms、parakeet-v3で約7 ms速いですが、NeMo側もtensor APIを止めると同等以上でした。speech.cppでは、前述のtensor APIの回避策を保ったままです。詳しい条件とp90はPRの計測結果にあります。

モデルのファイルは変えていません。speech.cpp本体を更新すれば、手元のGGUFをそのまま使えます。

Appendix

計測方法

実装どうしの比較には、自分で作っているspeech-benchを使いました。speech.cppは0.8.0の候補 (コミットf5ab84c) で、M5では手元のビルド、RTX 2080ではCIのビルドを使い、すべての実装を2026-10-08の同じ日に計測しています。

音声合成は、M5 (32 GB、macOS 26.2) と、RTX 2080 (8 GB、ドライバー591.86) のWindows 11で計測しました。テキストはspeech-benchのprompts/speak-ja-JP.jsonの20文で、相槌、返事、長めの説明、英単語まじりのテキストが入っています。Irodori-TTSの声はspeech-benchで作った約10秒の参照音声 (voice-bright-young-woman) で、seedは1です。Qwen3-TTSは用意された声のono_annaで、seedは毎回変わります。GPUを初めて使うときの時間を除くため、最初の1文は一度読ませてから計測しています。CERは、合成した音声をQwen3-ASR 1.7Bで書き起こして数えました。

ASISTの再生時間は、2026-10-09に公開版0.8.0 (同梱のspeech.cppは0.8.2) を同じM5で測りました。各モデルで1文をウォームアップしたあと、上と同じ20文を1回ずつ再生し、相槌とつなぎの一言は切っています。Qwen3-TTSの声はono_anna、Irodori-TTSはASISTに同梱するcalm-young-womanです。会話APIが指定どおりの文を返したことも全60文で確認しました。合成開始の時刻は、アプリが報告する合成時間を画面側で受け取った時刻から引いて推定しています。声の始まりは、再生する音声の20 msごとのRMSが0.004以上になる最初の区間としました。プロセス間通信の遅れが誤差に入り、機器の出力遅延は含めません。

途切れないかの確認は、speech.cppのワーカーに同じ20文を読ませて、チャンクが届いた時刻を記録して数えています。最初のチャンクが届いた時刻に再生を始めたとして、それぞれのチャンクが、その前までの音声を鳴らし終える時刻より前に届いていれば途切れません。

音声認識は、Common Voice 8.0の日本語のテスト (4,483文、参照の文字は93,471文字) を、M5とRTX 2080で、どの実装にも同じ順に聞かせました。音声の前後の無音は、silero-vad v4で声のある範囲を見つけて、前後に0.2秒ずつ残して詰めています (声が見つからなかった4文は除いています)。Qwen3-ASRには言語にjaを指定し、待ち時間には読み込みを含めていません。

M5での音声認識の結果です。

parakeet-tdt-0.6b-v3を、FLEURSの英語の300文で比べた結果です。

NeMo-Speech.cppには公開されたF16のファイルがないので、speech-benchがNeMo-Speech.cppの変換スクリプトでF16に変換したファイルを使っています。

長尺の録音の計測は、speech.cppのmeasure/region_cap_compare.pyでM5 (Metal) を使って行いました。FLEURSの日本語のテストの321文 (各文の読み1つ) と、Common Voice 8.0の日本語のテストの最初の600文の録音を、それぞれSilero VADで声のある範囲に切り、音量を-23 dBFSにそろえて、0.3〜1.0秒の間をあけてつないでいます。4つに1つの間は2〜8秒の無音にして、間と無音には-60 dBFSの雑音を入れました。こうして作った105.6分の録音を、言語を日本語に決めて書き起こし、NFKCで正規化して句読点と空白を除いたCERを数えています。区間の長さの上限ごとの結果はこちらです (FLEURS / Common Voice)。

話しながらの書き起こしの時間は、ダンプを無音でつないだ音声を24 kHzにして、20ミリ秒ずつ実時間で/v1/realtimeに送って計りました。話し始めと話し終わりは、余白を除いた区間の端から数えています。

段階ごとの比較の結果

Irodori-TTSの各段階を、公式の実装の書き出した入力から動かしたときの結果です (Apple M5)。

MetalがCPUより低いのは、ggmlのMetalの行列積が入力を半精度に丸めるからです。MFは4回の大きなステップで進むので、その差が潜在表現に残ります。そのためMetalでは、波形は同じにならず、同じ内容を話す音声になります。

FastConformer (parakeet-tdt_ctc-0.6b-ja) を、FLEURSの日本語の3つの発話 (6.36秒、10.50秒、25.50秒) で比較した結果です。

GGUFの中身

speech.cppのモデルは、どれもコーデックまで含めた1つのGGUFのファイルです。モデルの名前や言語は、GGUFの仕様にある標準のキーにそのまま書いているので、GGUFを読めるツールならモデルの情報を表示できます。

読み込むときは、重みを読む前に、キーとテンソルの名前、形、型がすべてそろっているかを確かめ、足りないものや余計なものがあれば名前を出して断ります。speech infoを使うと、重みを読まずにこれらの情報だけを表示できます。

tensor APIの不具合の再現

ggmlのtest-backend-opsに、出力の列の数が64と192の行列積のケースを足して、M5で動かすと再現します。tensor APIでは結果がずれて失敗し、環境変数GGML_METAL_TENSOR_DISABLE=1でtensor APIを止めると通ります。くわしい手順はspeech.cpp#13に書いています。

References

• speech.cpp
  • nyosegawa/speech.cpp
  • nyosegawa/speech-bench
  • speech.cpp#13: Metal on Apple M5 corrupts matrix products whose column count is 64 modulo 128
  • sakasegawa/common-voice-ja-accepted-spellings
  • ggml-org/ggml
• モデル
  • Aratako/Irodori-TTS
  • Aratako/Irodori-TTS-v4.1-Small-MF
  • MeanFlow Distillation (Irodori-TTS docs)
  • Qwen/Qwen3-TTS-12Hz-0.6B-CustomVoice
  • Qwen/Qwen3-ASR-1.7B
  • nvidia/parakeet-tdt_ctc-0.6b-ja
  • nvidia/parakeet-tdt-0.6b-v3
  • reazon-research/reazonspeech-nemo-v2
  • snakers4/silero-vad
• OpenAI
  • Realtime transcription
• Paper
  • Flow Straight and Fast: Learning to Generate and Transfer Data with Rectified Flow
  • Mean Flows for One-step Generative Modeling
  • FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness
  • Fast Conformer with Linearly Scalable Attention for Efficient Speech Recognition
  • Universals and cultural variation in turn-taking in conversation
  • Lenient Evaluation of Japanese Speech Recognition: Modeling Naturally Occurring Spelling Inconsistency
  • Towards Orthographically-Informed Evaluation of Speech Recognition Systems for Indian Languages
  • HiKE: Hierarchical Evaluation Framework for Korean-English Code-Switching Speech Recognition
  • The Hidden Cost of Digits: Number Normalization and WER in ASR Systems
  • Echo-TTS
  • Qwen3-TTS Technical Report
• ほかの実装
  • ggml-org/llama.cpp
  • FunAudioLLM/CosyVoice
  • Blaizzy/mlx-audio
  • 0xShug0/audio.cpp
  • mackron/miniaudio
  • MaAI-Kyoto/MaAI
• Irodori-TTSを速くする記事
  • irodori-TTS を速くする方法を理解したい (株式会社Rosso)
  • AITuber向けに Mac MPS で Irodori-TTS をチューニングして2.72倍高速化 / bf16 では遅くなった (osushi_cr)
• ONNX Runtime
  • CoreML Execution Provider
  • DirectML Execution Provider

Today I'd like to introduce "ASIST", a voice assistant for the desktop (Windows / Mac) that I built, and go over the parts I worked hard on while making it.

I wanted a general-purpose assistant with a futuristic UI

Personal AI agents have been popping up lately. Well-known examples include dots, Grok Bot, Muse and Manus. They are very well made, but what I really want is something like you see in anime and movies, with several panels floating softly around. Yet even in the 21st century, mid-air displays and AR glasses haven't gone mainstream. So for now I decided to build it as a desktop application.

Before starting, I wrote down what I wanted to value in an AI assistant.

• It feels futuristic
• The conversation feels good
• Its memory is reliable
• It helps with everyday life
• It can do anything on the PC, as long as it's connected to it
• It can be used from anywhere
• It is richly extensible

In the first version of ASIST, I think I managed to do a fair job on all of these except the last two. For the remaining two, I plan to bring in a more general version of an earlier idea for extensibility, and to handle where it can be used as well.

So what is ASIST?

ASIST is a voice assistant for the desktop. When you talk to it, it answers by voice and puts the weather, your schedule or an email draft on cards next to the conversation. Long-running work can be handed off to the codex or claude CLI once you approve it.

The official site is asist-agent.com. You can download the app from GitHub Releases, and the Install page of the documentation walks through everything from installation to the first-run setup. To run it you need an Apple Silicon Mac (macOS 14 or later) or an x64 Windows 11 PC, plus an API key for the conversation model (one of Anthropic, OpenAI, Google or Cerebras). The source code is open source under the MIT License at nyosegawa/asist.

Here are the main features.

• It talks at a nice tempo
• It opens cards to show you the information you need (there are 16 kinds of cards, including weather, schedule, email, to-dos, exchange rates and maps)
• Tasks, notes, email, the calendar and more open as mini apps inside the application

What I worked hard on in the voice conversation

I plan to write a separate, detailed post on this, but the hardest part of a voice assistant is the wait. With a cascade setup (ASR→LLM→TTS), a naive implementation takes about three seconds to respond. So ASIST buys time until the first reaction by slipping in backchannels and similar short responses.

About development

These days I mainly develop with Claude (Opus 5.5), and use Codex (Sol-6.1) for things like evaluating models. Since coding agents became common, all sorts of development environments have come into fashion. I also built a kanban-style agent session manager, even made it work on mobile, and used it for a while, but in the meantime the Claude and Codex desktop apps got good. Just doing things the ordinary way works best.

I also keep Agent Skills to about ten, limited to the things I really do often. Documentation mostly goes stale, so I put decisions in docs/adr and things to do in issues. ADRs go stale too, so let's keep at it.

Making the promotional video

I made a 48-second introduction video for YouTube and X with Claude.

Watch on YouTube

The setup is simple: the scenes are built with HTML and GSAP, headless Chrome captures them every 1/30 of a second, and ffmpeg puts it all together. npm run promo:video rebuilds it at any time. I no longer need frameworks like Remotion or HyperFrames, so I didn't use them this time.

Scene changes and the moments when cards appear are aligned to the beats of the music's tempo (106 BPM). So that fast-moving things blur naturally, each frame is captured 16 times and averaged, which adds motion blur.

For the BGM, I made three candidates with Gemini's Lyria 3.5, played each against the video, and chose the music box one. The track is 58 seconds long, so I joined two points where the chords are very similar, skipped the part in between, and fit it into 48 seconds. The sound effects were written in numpy by a coding agent. What an age we live in.

References

• nyosegawa/asist
• Gemini API: Music generation (Lyria)
• OpenAI Images API

今日はデスクトップ (Windows / Mac) 向けの音声対話アシスタント「ASIST」を作ったので、その紹介と、作るときに頑張ったところをまとめていきたいと思います。

未来っぽいUIの汎用アシスタントが作りたかった

さいきんパーソナルAIエージェントが増えてきています。代表的なものとしては、dotsやGrok Bot、Muse、Manusあたりでしょうか。 とてもよく作られている反面で、どっちかというとわたしはアニメや映画に出てくるような、複数のパネルがふわ〜っと動くものを欲しい気持ちがあります。でも、21世紀だというのに空中ディスプレイやARグラスは普及はしてません。ひとまずデスクトップアプリケーションとして作ることにしました。

AIアシスタントをつくるうえで、だいじにしたいことを最初にまとめました。

• 未来感があること
• 会話体験が良いこと
• 記憶が確かなこと
• 日常の支援ができること
• PC上の作業であれば接続をすれば何でもできること
• どこからでも使えること
• 拡張性が豊かであること

ASISTの最初のバージョンでは、これらのうち、さいごの2つ以外についてはある程度頑張れたかなと思っています。のこる2つについても、拡張性にかんしては以前のアイデアをもう少し汎用的にしたものを、使う場所についてもうまく対応していく予定です。

あらためてASISTとは

ASISTはデスクトップ向けの音声対話アシスタントです。話しかけると声で答えて、天気や予定やメールの下書きを会話の横にカードで出します。時間のかかる作業は、承認したあとにcodexかclaudeのCLIへ任せられます。

公式サイトはasist-agent.comです。アプリはGitHubのReleasesからダウンロードでき、インストールから初回セットアップまでの手順はドキュメントのインストールのページにまとめています。動かすにはApple SiliconのMac (macOS 14以降) かx64のWindows 11と、会話に使うモデルのAPIキー (Anthropic、OpenAI、Google、Cerebrasのどれか1つ) が必要です。ソースコードはnyosegawa/asistでMIT Licenseのオープンソースとして公開しています。

主な機能は以下のとおりです。

• いい感じのテンポで話してくれる
• 必要な情報はカードを開いて見せてくれる (天気、予定、メール、To-Do、為替、地図など16種類のカードがあります)
• タスク、メモ、メール、カレンダーなどはミニアプリとしてアプリケーション上で開くことができます

音声対話で頑張ったところ

これは別途詳細記事を書く予定なのですが、音声アシスタントでいちばんしんどいのは待ち時間です。cascadeな構成(ASR→LLM→TTS)だと素朴につくると3秒くらいかかってしまいます。そこで、相槌などを挟んで最初のリアクションまでの時間稼ぎをしています。

開発について

さいきんはおもにClaude (Opus5.5) で開発していて、Modelの評価などではCodex (Sol-6.1) を使っています。 Coding Agentが一般化してからいろいろな開発環境が流行り、自分もカンバン形式のAgentセッションマネージャーを作り、モバイル対応もして使っていたのですが、そのあいだにClaude/Codexのデスクトップアプリがまともになってきました。普通にやるのがよいです。

また、Agent Skillsは10個程度にして、本当によくやることに絞ってます。 documentはだいたい腐るので、docs/adrに決定事項、issuesにやることを入れています。ADRも腐るので、頑張っていきましょう。

プロモーション動画を作る

ClaudeでYouTubeとX向けの48秒の紹介動画を作りました。

YouTubeで見る

構成はシンプルで、HTMLとGSAPで場面を作り、headless Chromeで1/30秒ずつ撮って、ffmpegでまとめます。npm run promo:video でいつでも作り直せます。RemotionやHyperFramesのような仕組みはもう使わなくてよくなったので今回は利用していません。

場面の切り替えやカードが出てくる時刻は、曲のテンポ (106 BPM) の拍にそろえています。速く動くものが自然ににじんで見えるように、1コマごとに16回撮って平均し、モーションブラーもかけています。

BGMはGeminiのLyria 3.5で3案作り、動画に当てて聞き比べてオルゴールにしました。曲は58秒あるので、和音がよく似ている2か所をつないで途中を飛ばし、48秒に収めています。効果音はCoding Agentがnumpyで書きました。すごい時代です。

References

• nyosegawa/asist
• Gemini API: Music generation (Lyria)
• OpenAI Images API

今日は生成AI以前と以後でエンジニアが書く文章がどう変わったのかを、Qiitaの記事を数えて確かめた結果をまとめていきたいと思います。

最近の技術記事を読んでいると、見覚えのある言い回しに出会うことが増えました。「地味に効きます」「静かに壊れる」「〜とは別物です」みたいなやつです。太字と箇条書きもやたらと多い気がします。ただ、こういうのは肌感だけで語るとだいたい外すので、2019年から2026年までの各年8月にQiitaへ投稿された記事をすべて集めて、実際に数えてみました。

先に結果をざっくり書いておきます。

• 記事の組み立て方はかなり変わっていました。2026年の記事は2019〜2022年と比べて、地の文がおよそ2倍に長くなり、太字はおよそ3倍、箇条書きの割合はおよそ1.8倍になっています
• 1文の長さは35字から39字に伸びていましたが、これはAI以前から続いていた変化の延長でほぼ説明できる範囲でした
• 読点は増えていました。1文あたりの読点は0.63個から0.95個になっています
• 「実測」「既定」「入口」「事故」「別物」のように、AI以前はほとんど使われなかった語が、2026年には5〜7%の記事に出てくるようになっていました
• 一方で、AIっぽい言い回しの代表のように言われる「しましょう」は、むしろ減っていました

以下では、どうやって数えたのか、何がわかって何がわからないのかを順番に見ていきます。

「文章が変わった」を何で測るか

「AIっぽい文章」という言葉はよく使われますが、中身はわりとふわっとしています。英語圏では、これを実際に数えた研究がいくつもあります。PubMedの論文の要旨1,500万件以上で「delve」のような語が過去の傾向より増えた分を数えて、2024年の要旨の少なくとも13.5%がLLMで処理されたと推定した研究（Kobak et al., 2025）や、学会の査読コメントのうちLLMが大きく書き換えた割合を推定した研究（Liang et al., 2024）がよく知られています。論文だけでなく、消費者の苦情、企業のプレスリリース、求人でも、ChatGPTの公開直後から同じような変化が起きていて、2024年末には1〜2割程度の文書にLLMの助けがあったと推定されています（Liang et al., 2025）。技術文書では、GitHubのプルリクエストの説明文を集めて語の使い方でまとめたところ、あるまとまりが2025年初めの0.7%から2026年半ばには39%に増え、その特徴語が「load-bearing」だったという分析があります（Abraham, 2026）。

書き手の側でも、AIっぽさはかなり気にされるようになっています。英語では、AIが書いた文章の特徴を取り除くClaude Code向けのスキル（blader/humanizer）が作られ、たくさんのフォークが生まれています。日本語でも、「重要なのは」「このように」のような定型句や単調な文体を見つけて自然な日本語に直すAgent Skill（natural-japanese）が人気を集めています。どちらも、AIっぽいとされる書き方を具体的なパターンとして挙げて、それを見つけて書き直させるものです。

ただ、日本語の技術記事を生成AIの前後で比べて数えた分析は、探した範囲では見つかりませんでした。近いものとしては、自分の記事と同じタグのほかの人の記事を比べて、英語で見つかった特徴語が日本語の記事にはほとんど出てこず、うまく測れなかったと報告している記事があります（suwa_nobu, 2026）。英語の特徴語をそのまま持ってきても日本語の記事では測れないので、日本語の記事の中で何が増えたのかを、一から探す必要があります。

そこで今回は、次のような指標を決めて数えることにしました。

文と記事の6つを主要な指標にして、データを見る前に「箇条書きと太字は増える」「文長のばらつきは小さくなる」と予想を書いておきました。LLMの出力は文の長さがそろいやすく、箇条書きと太字を多く使うと言われているからです。指標をたくさん比べると、偶然の差がどこかで出てきやすくなります。なので、何を主に見るかと、差があるとみなす基準は先に決めて、設計書に残してから数えています。語彙の分析の一部（AI以前はまれだった語を探す分析など）は、結果を見た後に加えたものです。

さて、何を測るかが決まったら、次はどのデータで比べるかです。

Qiitaの各年8月の記事をすべて集める

比べるのは、2019年から2026年までの各年8月に投稿された記事です。同じ8月どうしで比べれば、夏休みの学生の投稿のような季節の影響をそろえられます。ChatGPTの公開は2022年11月30日なので、2019〜2022年をAI以前とし、この4年分で年ごとの揺れの大きさとそれまでの傾向を見ます。2023〜2025年は移行期として、変化の途中を見るのに使います。

Qiita APIで7万記事を取る

Qiita API v2 の記事一覧は、created:>=2026-08-01 created:<2026-08-02 のように作成日で検索できます。ただし1回の検索で取れるのは100件×100ページの1万件までで、2026年8月は11,562件あったので、1日ずつ検索しています。一覧APIの結果に本文のMarkdownが含まれているので、記事ごとに追加でリクエストする必要はありません。認証トークンを使えば1時間に1,000回まで送れるので、すべて取っても30分かからないくらいでした。

合計70,524件です。ここから、スライドモードの記事、AI以前の記事のうち2022年11月30日以降に更新されたもの（あとからAIで手を入れた可能性があるため）、地の文が300字未満の短い記事、日本語以外の記事を除いて、50,731件を分析しました。

2026年8月は8年間でいちばん投稿が多い月でした。短い記事の割合もかなり違っていて、地の文が300字未満の記事は2019〜2022年には各年の3割前後あったのに、2026年は7%しかありません。このあたりからすでに、2026年の記事が長くなっている気配があります。

データの扱い

記事は公式のAPIで、利用制限の範囲内で2026年9月11日に取得しました。記事の著作権は各投稿者にあるので、取得した本文は手元での集計にだけ使っています。この記事に載せているのは集計した値と、多くの記事に共通して出てくる短い言い回しだけです。言い回しの例は、2026年に20人以上の著者が使っていたものに限りました。記事の本文、著者名、記事のURL、取得したデータは公開していません。また、この記事は個人の分析で、Qiita株式会社とは関係ありません。

コードを除いて「地の文」を取り出す

技術記事にはコードブロックや表、コマンドの出力がたくさん入っています。これを混ぜたまま文の長さを数えると意味のない値になるので、Markdownを1行ずつ見て、コード、表、引用、見出し、箇条書きを分けました。残った普通の段落の文章を「地の文」と呼んでいます。文の長さと読点は地の文だけで数え、箇条書きは「箇条書きの割合」として別に数えています。

ひとつ悩ましかったのは文の区切り方です。Qiitaでは段落の中の改行がそのまま改行として表示されるので、句点を打たずに1行ずつ書く人がそこそこいます。そこで行の終わりも文の終わりとみなし、行が読点で終わっているときだけ次の行につなげることにしました。細かい規則はAppendix Aにまとめています。

「AIがなかったら」の予測値と比べる

比べ方はこうです。2019〜2022年の年ごとの平均に直線を当てはめて、そのまま2026年まで延ばします。これを「AIがなかった場合の予測値」とみなして、2026年の値との差を見ます。差はAI以前の記事の標準偏差で割って、指標どうしで比べられるようにしました。0.2で小さい差、0.5で中くらい、0.8で大きい差というのが、よく使われるCohenの目安です。

もうひとつ気にしたのは、同じ著者の記事どうしは似ることです。1人で何十本も書く人がいると、記事単位で数えた信頼区間は狭くなりすぎます。そこで、著者を単位にしたブートストラップ（著者を復元抽出して計算し直すことを1,000回繰り返す）で信頼区間を出しています。1年に数千件あると、わずかな差でもp値が小さくなるので、p値は使っていません。計算の詳細はAppendix Bにあります。

準備が整ったので、結果を見ていきましょう。

記事の組み立て方が大きく変わった

青い点が比べる年（2019〜2022年と2026年）で、灰色の点が移行期（2023〜2025年）です。破線はAI以前の直線を延ばした予測値です。

括弧の中は95%信頼区間です。地の文の文字数は分布が右に長く伸びるので、幾何平均で見ています。

企業アカウントの記事やAI関連のタグが付いた記事を除いたり、著者ごとに平均してから集計したりしても、結果はほとんど変わりませんでした（Appendix C）。2026年の記事の34%にはAI関連のタグが付いていますが、変化はAIについて書いた記事だけで起きているわけではなさそうです。

長くて太字と箇条書きの多い記事になった

いちばんはっきり変わったのは記事の組み立て方です。地の文の文字数は976字から1,914字とおよそ2倍になり、太字は1,000字あたり1.26個から3.83個とおよそ3倍、箇条書きの割合は8.9%から16.4%になりました。どれも予測値との差が+0.57〜+0.89で、中くらいから大きい変化にあたります。予想していた「箇条書きと太字は増える」は、そのとおりになりました。

太字と箇条書きがなぜ増えたのかを考えるうえでは、人の評価者も報酬モデルもリストや太字の多い回答を好むことを示した研究（Zhang et al., 2025）や、Chatbot Arenaで回答の長さや太字、リストの数をそろえて比べると順位が大きく入れ替わったという分析（Li et al., 2024）が参考になります。人に好まれやすい書式を身につけたモデルの文章が、そのまま記事に入ってきているのかもしれません。

面白いのは時期の違いです。箇条書きと太字は2025年がいちばん多く（箇条書き19.7%、太字4.45個）、2026年は少し減っています。それに対して地の文の長さは、2023〜2025年は1,100字前後で、2026年に一気に伸びています。同じ「AI以後」でも、2025年と2026年では変わり方が違うようです。

文の長さはもともと伸びていた

1文の長さは2019年の34.7字から2026年の39.2字に伸びています。これだけ見ると「AIで文が長くなった」と言いたくなるのですが、2019〜2022年のあいだにもすでに伸びていました。直線を延ばした予測値は38.9字で、2026年の値とほぼ同じです。米国土木学会の論文の要旨を25年分調べた研究でも、LLM以前から要旨と文が長くなる傾向が続いていたと報告されています（Sanger and Maurer, 2026）。AIの影響を見るときは、こうした長い傾向を差し引かないといけません。ただ、2022年の平均は1文が極端に長い記事1件で押し上げられていて、極端な値を抑えて計算し直すと、文の長さもわずかに伸びた可能性が出てきます（Appendix C）。

文長のばらつき（変動係数）も同じで、0.62前後から0.535に小さくなっていますが、AI以前からの傾向で説明できる範囲でした。「ばらつきは小さくなる」という予想は、傾向を超える変化としては確かめられませんでした。

読点は増えた

読点と読点の間の文字数は、21.2字から19.2字に縮みました。1文あたりの読点の数でいうと、0.63個から0.95個に増えています。文が少し長くなって、読点はそれ以上に増えた、という感じです。予測値との差は−0.17で、小さい差の目安にはぎりぎり届かないのですが、AI以前の隣り合う年の差の最大値は超えています。

さきほどの土木学会の研究でも、LLMの助けを受けたと判定された要旨ではカンマの使用が増えていました（Sanger and Maurer, 2026）。日本語でも、GPTが書いた求人の文章は人の文章より句読点が多いという報告があります（LAPRAS, 2023）。ただしこちらは企業のブログで、比べた文章の数は書かれていません。

組み立て方が変わったのはわかりました。では、使われている語はどう変わったのでしょうか。

語彙は何が増えて何が減ったか

手順を書く文章から仕組みを説明する文章へ

語はMeCab（fugashi）とUniDicで形態素解析して、原形で数えています。AI以前と2026年の語の出現回数を対数オッズ比で比べました。偶然の差を拾わないように、2026年の記事を著者単位で2つの組に分けて、片方で選んだ語がもう片方でも同じ方向に出るかを確かめています。この表は、AI関連のタグが付いた記事も含めて数えています。

AIの話題の語（claude、エージェント、プロンプトなど）や、rails、dockerのような技術名は表から外しています。

AI以前の記事は、手を動かした手順を、画面やコマンドを指しながら、書き手の感想を交えて書くものが多かったようです。「以下のコマンドを実行します」「こちらを参考にしました」「とりあえず動いた感じです」のような文章です（この3つは説明のために私が作った例です）。2026年の記事では、設計や検証のような抽象的な語で、仕組みと運用を説明する文章が増えています。

記事が長くなるとありふれた語が「増えて」見える

Kobakらにならった excess vocabulary の方法も試しました。AI以前の4年の傾向から2026年の文書頻度（その語を含む記事の割合）を予測して、実際にどれだけ上回ったかを見る方法です。

ところが、これをそのまま使うと、上位に「へ」「だけ」「まま」「まで」「同じ」のようなありふれた語が並びます。2026年の記事は地の文が約2倍に長いので、記事全体で数えると、ありふれた語ほど「その語を含む記事」の割合が上がってしまうからです。論文の要旨のように長さのそろった文章なら問題にならないのですが、ブログ記事では長さの変化を差し引かないといけません。

そこで、各記事の先頭200語だけで数え直してみました。AI関連のタグが付いた記事を除いて、語を選ぶのに使わなかった検証用の組で見ると、「設計」はおよそ4倍、「整理」は6倍、「壊れる」は7倍、「瞬間」と「止まる」は8倍、「単なる」は13倍、「実測」は18倍になっていました。記事が長くなった分を差し引いても、これらの語は増えています。

「効く」「瞬間」「静かに」

語の変化の中でも、個人的にいちばん肌感と合っていたのは次のような語です。

地の文と箇条書きにその語を含む記事の割合です。この表は、AI関連のタグが付いた記事も含めて数えています。次の節の表はAI関連のタグが付いた記事を除いて数えているので、同じ語でも値が違います（「実測」は9.4%と7.2%）。

「効く」を含む記事は2%から22%と、10倍以上になりました。「〜た瞬間に」の形は2026年に428人の著者が使っていて、ごくありふれた言い回しになっています。「静かに壊れる」「黙って無視される」は英語の silently break や silently ignored に、「〜した瞬間」は the moment に、「正本」は source of truth にそのまま対応していそうです。英語で考えたことを日本語に置き換えたような言い回しが、日本語の技術記事に入ってきているように見えます。ただし、これは用例を見たうえでの解釈で、翻訳された文章だと確かめたわけではありません。

また、これはAIが書いた文章が増えただけとは限りません。英語では、台本のない会話（ポッドキャスト）でも、ChatGPTの公開後に「delve」のような語が急に増えたことが報告されています（Yakura et al., 2024）。人がAIの文章を読むうちに、その言い回しを自分でも使うようになっている可能性があります。

ここまでで気になる語はいくつも見つかったのですが、上位の語だけを見ていると、ほかの語に気づけません。そこで、AI以前はまれだった語をまとめて探してみました。

AI以前はまれで2026年に広がった語彙

探し方

AI関連のタグが付いた記事を除いて、次の条件をすべて満たす語を探しました。

• AI以前にその語を含む記事が0.5%以下
• 2026年の2つの組のどちらでも0.8%以上、かつAI以前の5倍以上
• 英字の語、固有名詞、数ではない

これで402語が見つかりました。ただ、候補の語の使われ方を眺めていると、まったく同じ言い回しがちょうど同じ件数ずつ並んでいる語がいくつもありました。1人の著者が似た記事をまとめて投稿していると、文書頻度だけでは語が広まったように見えてしまいます。そこで「2026年にその語を使った著者が30人以上」「1人の著者の記事が、その語を含む記事の2割以下」という条件を足して、17語を除きました。残った385語は、その語を使った著者の割合で比べても、2026年はAI以前の8.8倍（中央値）です。

分け方は私の判断ですが、目立つ語を並べると、次の5つのまとまりがありました。表の言い回しは、2026年に20人以上の著者が使っていたものから選んでいます。20人以上に共通する言い回しがなかった語は「なし」としています。

確かめることや疑うことを表す語

位置や役割を場所や物にたとえる語

「〜するための土台」「〜するための道具」の形は、それぞれ59人と97人の著者が使っていました。物事の役割を、場所や物にたとえて説明する書き方です。

障害や失敗を表す語

作業を比喩的に表す動詞

判断や評価を述べる語

「〜のが定石」（61人）、「〜が要点です」（40人）、「〜が定番です」（35人）のように、評価の名詞を「〜です」で置いて文を締める形も見られます。

増えた時期の違い

増えた時期で分けてみると、385語のうち197語は、増えた分の8割以上が2025年から2026年のあいだに起きていました。反対に、増えた分の6割以上が2025年までに起きていた語は36語で、残りの152語はその中間です。2025年までに増えた語には「強み」「両立」「堅牢」「早期」のようなビジネス文書に多い語が多く、どれも2023年から増え始めています。

主要な指標でも、箇条書きと太字は2025年がピークで、地の文の長さは2026年に大きく伸びていました。Qiitaの記事を見るかぎり、2026年はClaude CodeやCodexのようなCoding Agentが一気に広まった年でもあります。ClaudeCode、Codex、Cursorなどのタグが付いた記事は、2025年8月の3.1%から2026年8月には9.5%に増えました。コードだけでなく記事もCoding Agentと一緒に書く人が増えたことが、2026年の変化に関係していそうです。ただ、今回のデータだけで理由を言い切ることはできません。

言い換えなのか足されたのか

「既定」が増えたなら「デフォルト」は減ったのかと思って確かめてみました。その語を含む記事の割合で見ると、「デフォルト」は15.6%から13.9%とほとんど減っていません。ただ、2026年の記事は長くなっているので、記事の割合だけでは使われ方の変化がわかりません。そこで、地の文と箇条書きの1万字あたりの回数でも比べてみました（AI関連のタグが付いた記事を除いて、文字列で数えています）。

1万字あたりで見ると、「デフォルト」は1.88回から1.01回とほぼ半分になり、「既定」は0.05回から0.55回に増えています。一部は「既定」に置き換わったのかもしれません。それに対して「要点」と「ポイント」、「実測」と「計測」は、どちらも増えています。こちらは言い換えではなく、語が足されたように見えます。「ハマる」（「ハマった」「ハマり」などを含む）は2025年に半分まで減ったあと、2026年にはAI以前と同じ水準に戻っていました。

さて、語彙のほかにも、数えてみると変わっていたところがいくつかありました。

そのほかに変わったこと

主要な指標のほかに、判断には使わない探索的な指標もいろいろ数えています。目立ったものを挙げます（すべての値はAppendix Dにあります）。

「まとめ」の見出しは、半分以上の記事に入るようになりました。ダッシュはおよそ10倍です。英語ではChatGPTがem dashを使いすぎることが「ChatGPT hyphen」と呼ばれて話題になり（Rolling Stone）、OpenAIが「指示すれば使わないように直した」と発表するほどでした（TechCrunch）。医学系のプレプリントでも、em dashを含む要旨の割合がChatGPT以前の4.2%から以後の11.6%に増え、2025年には20.3%になったと報告されています（Czuma, 2026）。LLMがMarkdownで書く習慣を学んだ結果、Markdownの記号を使わないように指示してもem dashだけは残る、という仮説を立てた研究もあります（Freeburg, 2026）。日本語の技術記事でも、同じ記号が増えています。

意外だったのは、AIっぽいと言われがちな「しましょう」「することが可能です」「また、」が減っていたことです。「しましょう」を含む記事の割合は10.3%から6.0%に下がりました。「〜しましょう」で読者に呼びかける書き方はもともと少数派でしたが、さらに減っています。英語でも、「delve」はAIらしい語として話題になったあとで減った一方、ほかのAIに多い語は増え続けたという報告があります（Geng and Trotta, 2025）。AIらしいと知られた言い回しは、書き手が避けたり、モデルの側で使わなくなったりするのかもしれません。冒頭で書いたような、AIっぽさを消すAgent Skillが広まっていることも、これと同じ流れにあるように見えます。

感嘆符も3割ほどに減っていて、です・ます調で統一された、感嘆符の少ない文章が増えています。漢字の割合が上がってカタカナの割合が下がったのは、漢語が増えたこと（語数に対する漢語の割合は18.1%から21.4%）と関係していそうです。論文の要旨でも、ChatGPTの後に接続語が減り、読みにくくなったと報告されています（Bao et al., 2025）。今回もjReadabilityは2.59から2.02に下がり、難しい側に動きました。ただしjReadabilityは平均文長を式に含むので、文が長くなった分だけ難しい側に出る点には注意が必要です。

何がわかって何がわからないか

ここまでの結果から言えるのは、2026年のQiitaの記事が、AI以前の傾向から予測されるものとは違っているというところまでです。いくつか注意があります。

• AIが書いた文章が増えたことと、人間の書き方が変わったことは区別できていません。全体の平均を比べると、両方がまとめて出てきます
• AI関連のタグが付いていない記事にもAIの話題は含まれうるので、タグで除いても話題の影響を完全には取り除けていません
• AI以前の記事は、2026年9月まで削除されずに残った記事だけです。スパムや質の低い記事が消えていれば、条件はそろっていません
• 8月の記事だけを見ているので、ほかの月でも同じかはわかりません
• 画像の入れ方など、Qiitaの編集画面の変化が書き方の指標に影響している可能性があります
• 予測値は4年分の点に直線を当てはめたもので、AI以前の傾向がそのまま続いたという前提に頼っています
• ある語が増えた理由がAIの書いた文章にあるのかは確かめていません。語の分け方と、言い回しの解釈も私の判断によるものです

まとめ

• 2026年のQiitaの記事は、AI以前と比べて地の文がおよそ2倍に長く、太字はおよそ3倍、箇条書きはおよそ1.8倍になりました。文の長さの変化は、AI以前からの傾向の延長でほぼ説明できました
• 「実測」「既定」「入口」「事故」「別物」「効く」「静かに」のような語が一気に広がり、その多くは2025年から2026年のあいだに増えています
• 「しましょう」のような、よく言われるAIっぽさの目印は、むしろ減っていました

Appendix A: 前処理の規則

Markdownの本文を上から1行ずつ読み、次のように分けました。

行の中では、インラインコード、インラインの数式、HTMLのコメントとタグ、画像、URLを除き、リンクは文字だけを残しました。太字は数えてから記号を外しています。文字数は空白を除いて数えました。

文は「。」「！」「？」「!」「?」の直後で区切り、閉じかっこが続くときは閉じかっこまでを前の文に含めます。行の終わりも文の終わりとみなしますが、行が読点で終わるときは次の行とつなげます。行の終わりを文の終わりとみなさず、段落の中の行をすべてつなげて句読点だけで区切った場合も計算しましたが、平均文長の差は−0.05、変動係数の差は−0.08で、結論は変わりませんでした。

Appendix B: 予測値と差の計算

指標の年ごとの平均を m_y とします。2019〜2022年の4点に最小二乗法で直線を当てはめ、傾きを b として、2026年の予測値を次のように求めます。

\hat{m}_{2026} = \bar{m}_{\mathrm{pre}} + b \times (2026 - 2020.5)

ここで m_pre の平均は2019〜2022年の年ごとの平均の平均で、2020.5はこの4年の中央です。差は、AI以前の記事単位の標準偏差 s_pre で割って標準化します。

d = \frac{m_{2026} - \hat{m}_{2026}}{s_{\mathrm{pre}}}

信頼区間は、著者を単位にしたブートストラップで出しました。全期間の著者を復元抽出し、選ばれた著者の記事をすべて使って年ごとの平均を計算し直し、直線の当てはめから d までをやり直すことを1,000回繰り返して、2.5パーセンタイルと97.5パーセンタイルをとっています。地の文の文字数は対数をとってから同じ計算をしました。

Appendix C: 条件を変えた計算

除外や集計の条件を変えて、予測値との差を計算し直しました。

• 下限100字と下限1,000字は、地の文の文字数の下限を300字から変えた計算です
• 極端な値を置き換える計算は、AI以前の記事の1パーセンタイルより小さい値と99パーセンタイルより大きい値を、その境目の値に置き換えています。2022年には地の文の1文の平均が約2,900字の記事が1件あり、平均文長と読点間の平均文字数を押し上げていたので、この計算も載せています
• 句読点だけで区切る計算は、行の終わりを文の終わりとみなさない規則で、平均文長と変動係数だけに関係します

どの条件でも、地の文の長さ、箇条書き、太字の差は+0.4以上で、平均文長とばらつきの差は±0.2の範囲に収まっています。

Appendix D: 語彙の分析の方法と探索的な指標

対数オッズ比は、Monroeらの informative Dirichlet prior を使いました。語 w の出現回数を2026年で y_i、AI以前で y_j、全期間で a_w とし、それぞれの総語数を n_i、n_j、a_0 とします。

\begin{aligned}
\delta_w &= \log\frac{y_i + a_w}{n_i + a_0 - y_i - a_w} \\
&\quad - \log\frac{y_j + a_w}{n_j + a_0 - y_j - a_w}
\end{aligned}

z_w = \frac{\delta_w}{\sqrt{\frac{1}{y_i + a_w} + \frac{1}{y_j + a_w}}}

excess vocabulary は、語ごとにAI以前の4年の文書頻度に直線を当てはめ、傾きを b_w として、2026年の予測値 q_w との差と比を見ます。傾きが負のときに0とするのは、もともと減っていた語の増加を大きく見積もらないためです。Kobakらは2021年と2022年の2点から2年先の2024年を予測していますが、今回は4年分に直線を当てはめて4年先を予測しています。

\begin{aligned}
q_w &= p_{w,2022} + 4 \times \max(b_w, 0) \\
\Delta_w &= p_{w,2026} - q_w \\
r_w &= \frac{p_{w,2026}}{q_w}
\end{aligned}

探索的な指標の全結果です。差は予測値との差で、単位はAI以前の標準偏差です。

文頭と文末の言い回し、記号、一人称、感情を表す語、話し言葉の文末、「(笑)」、見出しの数、表の数、絵文字の数は、地の文と箇条書きの1,000字あたりの回数です。見出しの数は予測値との差が−0.55と大きく出ていますが、AI以前の平均との差はほぼ0です。2022年の値が高かったせいで予測値が高くなっただけで、ほとんど変わっていません。MATTRはCovington and McFall (2010) の方法で窓の幅を100語にしています。jReadabilityはjReadabilityの式で計算しました。

References

• データ
  • Qiita API v2 ドキュメント
  • Introducing ChatGPT (OpenAI)
• LLMが文章に与えた影響
  • Delving into LLM-assisted writing in biomedical publications through excess vocabulary (Kobak et al., Science Advances, 2025)
  • Monitoring AI-Modified Content at Scale: A Case Study on the Impact of ChatGPT on AI Conference Peer Reviews (Liang et al., ICML 2024)
  • The widespread adoption of large language model-assisted writing across society (Liang et al., Patterns, 2025)
  • Have Large Language Models Enhanced the Way Civil & Environmental Engineers Write? (Sanger and Maurer, 2026)
  • Examining linguistic shifts in academic writing before and after the launch of ChatGPT (Bao et al., 2025)
  • Empirical evidence of Large Language Model's influence on human spoken communication (Yakura et al., 2024)
  • Human-LLM Coevolution: Evidence from Academic Writing (Geng and Trotta, 2025)
• 技術文書と日本語の記事
  • The load-bearing vocabulary of Claude (Abraham, 2026)
  • AIの口癖を日本語記事で測ろうとして、3回とも失敗した (suwa_nobu, 2026)
  • GPT の出力文章と人の書いた文章の比較 (LAPRAS, 2023)
• AIっぽさを消すためのAgent Skill
  • blader/humanizer
  • coji/natural-japanese
• 書式と記号
  • From Lists to Emojis: How Format Bias Affects Model Alignment (Zhang et al., ACL 2025)
  • Does style matter? Disentangling style and substance in Chatbot Arena (Li et al., LMSYS, 2024)
  • Em-ergence of the em-dash: a population-level rise in em-dash frequency in medRxiv preprints (Czuma, 2026)
  • The Last Fingerprint: How Markdown Training Shapes LLM Prose (Freeburg, 2026)
  • 'ChatGPT Hyphen': Are Em Dashes a Giveaway of AI Writing? (Rolling Stone)
  • OpenAI says it's fixed ChatGPT's em dash problem (TechCrunch)
• 方法
  • Fightin' Words: Lexical Feature Selection and Evaluation for Identifying the Content of Political Conflict (Monroe et al., 2008)
  • Cutting the Gordian Knot: The Moving-Average Type-Token Ratio (MATTR) (Covington and McFall, 2010)
  • jReadability
  • fugashi
  • unidic-lite