Jetson Orin Nanoでローカル AI を運用する—ダラブルストリーム設計が変える推論アーキテクチャ

ローカル AI 推論の現実的な課題—Request/Response では解決できない問題

ローカル AI を実運用する際、単純な Request/Response API では十分ではありません。テキスト音声変換（TTS）の Kokoro-82M モデルを例とすると、1 分間の音声生成に数秒のコンピュート時間がかかります。複数ユーザーからの同時リクエストがあれば、GPU は順番待ちの状態になります。

従来のアーキテクチャでは、この課題を解決するためにキュー、データベース、オブジェクトストレージ、リトライロジック、デデュープロセス、クリーンアップ処理など複数のレイヤーを積み重ねる必要があります。

推論ジョブの本質は、リクエスト単位で完結するのではなく、ネットワーク遮断やブラウザタブの閉鎖を超えて独立した生命サイクルを持つべきです。

こうした制約の根本的な原因は、TTS のような処理では出力が自然に段階的（インクリメンタル）だという性質を見落としていることです。最後の文字まで待たず、最初の文を生成したら即座にユーザーに届けるべき—これが従来の「全部完成を待つ」設計との決定的な違いです。

さらに、ユーザーが取得したリンクを後で開いたときに、同じバイト列を再生できる必要があります。結果に恒久的な ID を持たせ、任意のタイミングでアクセス可能にすることが求められています。

ダラブルストリーム—永続化された順序付きレコードで統一する

この問題を解決する鍵がダラブルストリーム（Durable Streams）です。これは：

• 順序付きレコードの列—各レコードはバイト列（ここでは音声チャンク＋メタデータ）を含む
• 永続化—すべてのレコードが保存され、何も失われない
• リーダーの自由度—先頭から読む、シーケンス番号を指定して seek、末尾で待機して新規到着を追う

これにより、以下が統一的に実現されます：

• Web サーバとGPU ワーカーの疎結合化
• ライブフィード（生成中の音声ストリーム）
• リプレイログ（後から同じ結果を取得可能）
• プログレス表示（シーケンス番号で進捗把握）

実装としては、各レコードがシーケンス番号、タイムスタンプ、ヘッダー、ボディを持つシンプルな構造を採用しています。このレコード概念が、ファイル、ライブフィード、ログ、進捗インジケーターのすべてを兼ねるわけです。

オンプレミス推論で検証してみた感覚としては、この設計は非常に理に適っていると感じます。GPU 処理の不確定性（冷起動、メモリ圧迫、キューイング）に対して、「ジョブの完成を待たない」という潔い割り切りが秀逸です。

Jetson Orin Nano Super の選定理由—現実的な価格と性能

この実装の土台となるハードウェアが NVIDIA の Jetson Orin Nano Super です。CUDA コア 1024 個、テンソルコア 32 個、67 TOPS（1 秒あたり兆単位の演算数）という仕様を持ちます。

このスペックでなぜ Kokoro-82M が実用的に動作するのかというと、現代の軽量 TTS モデルはエッジ推論を想定した設計になっているためです。リアルタイムよりも速く音声を生成できるというのは、ブラウザユーザーの体感として十分な応答性が得られる領域です。

設計の汎用性—TTS から先の拡張性

この記事で示唆されているのは、StreamTTS という具体的なアプリケーション以上に、ローカル推論の参照アーキテクチャとしての価値です。Web アプリ、CLI、他サービス向けに同じコア実装を再利用できる設計を目指しているとのことです。

推論キューの管理、ストレージの永続化、ライブ配信の実装は、画像生成（Stable Diffusion）や LLM のストリーミング出力にも応用できる構造です。GCP の BigQuery や Cloud Run を用いた大規模推論と異なり、エッジ～小規模オンプレミス環境での運用パターンを示した点に価値があります。

すべての出力が名前付きのタイムライン（ストリーム）として振る舞うことで、インフラの複雑性を劇的に削減できます。

このアプローチは、個人プロダクトやスタートアップが独自推論ワークロードを自前運用する際の指針として機能するでしょう。外部 API 依存を減らしつつ、ユーザー体験を損なわない設計の具体例として有用です。