Speech AI と GPU Runtime：Kaldi・Whisper のデプロイと運用ノート

Mon, 26 Oct 2026 00:00:00 +0800

2022 年から、私は Kaldi や Whisper といった speech recognition 技術と GPU runtime を実際のシステムに組み込む仕事をしています。範囲は model inference、system deployment、そしてその後の performance maintenance です。

この記事は特定プロジェクトの詳細な事例紹介ではなく、社内のアーキテクチャ、データ、性能数値は含みません。まとめたいのは、この種の仕事への向き合い方です。Kaldi と Whisper の違いをどう捉えているか、なぜ GPU runtime を先に安定させるのか、デプロイ後に何を確認しているのかを書きます。技術的な説明は公式ドキュメントに基づき、トラブル対応の経験は blog.clarence.tw（中国語）で公開してきた記事から引いています。

プロダクトにおける Speech AI の位置づけ

私の仕事の進め方でも書いたように、LLM や Speech AI の仕事は model API を呼ぶだけでは終わりません。batch processing、local model、GPU runtime、既存の backend workflow とつなげる必要があります。

音声認識は、多くの場合プロダクト全体の流れの一部です。一般的には、認識の前に音声の取得、形式変換、分割があり、認識の後にはテキストの後処理、保存、検索、他サービスへの受け渡しがあります。そのため Speech AI のコンポーネントを評価するときは、認識結果そのものだけでなく、次の点も一緒に見ます。

入力音声の形式と品質はそろっているか。前処理はどのレイヤーが担当するか。
ストリーミング認識か batch 処理か。失敗時にどう retry するか。
モデル出力をどう検証し、どの場合に人の確認が必要か。
この runtime を別のマシンで再構築できるか。

同じツールでも内容によって結果が大きく変わることは、早い段階で実感しました。2019 年に Amazon Transcribe が簡体字中国語に対応したとき、試してみた感想を記事にしました。歌では結果が良くなかった一方、会話中心の動画ではかなり良くなりました。managed service でも自前でデプロイするモデルでも、実際の利用シーンに近い音声で判断する必要があります。

Kaldi と Whisper の特性とトレードオフ

私の仕事では Kaldi と Whisper の両方を使います。どちらかがもう一方を置き換えるものではなく、設計思想が大きく異なる二つのツールだと考えています。

Kaldi on Clarence｜Backend・AI・DevOps・Infrastructure

Speech AI と GPU Runtime：Kaldi・Whisper のデプロイと運用ノート

プロダクトにおける Speech AI の位置づけ

Kaldi と Whisper の特性とトレードオフ