皆さん、こんにちは。
リアルタイムのボイスチャットパイプライン(STT -> LLM -> TTS)を構築しており、「Time to Sentence」の部分でボトルネックに直面しています。100トークンの応答を生成する総遅延を最小化するのが私の目標です。
私の要件:
* モデル: Qwen 3.5 9B(現在 FP16 と EXL3 クォンタイズをテスト中)
* ハードウェア: 1x NVIDIA RTX 3090 TI.
* 指標: 可能な限り低い TTFT(Time To First Token)と、単一ストリーム(バッチサイズ 1)に対する最高 TPS(Tokens Per Second)。
* 目標: 約100トークンの総時間を可能な限り 500–700ms に近づけるか、あるいはそれ以下にする。
現在のベンチマーク(単一ストリーム):
いくつかのアプローチを試して、だいたい以下のとおりです:
* TTFT: 約120ms〜170ms
* TPS: 約100〜120トークン/秒
(Nvidia RTX 3090 TI 1枚でのテスト)
この単一ユーザーのリアルタイム利用ケースでは、低遅延推論の現在の“金標準”とされるものを見つけようとしています。いくつかの異なるバックエンドを検討しましたが、TTFTを最小化しつつTPSを高く保つ適切なバランスを見つけるのは難しいです。開始後に持続生成が得意なエンジンもありますが、初期のオーバーヘッドのために総応答時間が対話型インタフェースとして望ましい水準より高くなることがあります。
特に、Flash Attention や最適化されたキャッシュ設定など、重要なミリ秒を削ることができる特定のフラグや低遅延モードに関心があります。さらに、小型ドラフトモデル(tiny Qwen や Gemma など)を用いた推測的デコードも検討していますが、9Bモデルの場合、オーバーヘッドが実際に純粋なゲインをもたらすのか、それとも性能を削ってしまうのか確信が持てません。
ご意見ありがとうございます!
[リンク] [コメント]
![[Boost]](/_next/image?url=https%3A%2F%2Fmedia2.dev.to%2Fdynamic%2Fimage%2Fwidth%3D800%252Cheight%3D%252Cfit%3Dscale-down%252Cgravity%3Dauto%252Cformat%3Dauto%2Fhttps%253A%252F%252Fdev-to-uploads.s3.amazonaws.com%252Fuploads%252Fuser%252Fprofile_image%252F3618325%252F470cf6d0-e54c-4ddf-8d83-e3db9f829f2b.jpg&w=3840&q=75)



