モデル別実行レシピ
Qwen3-Omniのローカル実行条件：音声・動画経路を確認する
マルチモーダル対応でも、ローカルruntimeがすべての経路をサポートするとは限りません。
Qwen3-Omni Instructはthinkerとtalkerを含み、テキスト・音声・動画入力とテキストまたは音声出力に対応します。model cardの機能とローカルbackendの対応は同じではありません。このガイドではLinux CUDA1上の公式Transformers経路でローカルWAVファイルを1つ処理し、音声・テキスト・動画経路を別々に試して、モデルと入力に応じたメモリを確認します。
必要な対話の入出力の組み合わせを先に選ぶ
Qwen3-Omniをローカル音声assistantや動画要約に使う場合は、まず必要な入出力の組み合わせを決めます。マイク音声を受けてtextで答えるのか、生成音声で返答するのか、短い動画と質問を送ってsceneを要約するのかで必要なmodel経路が異なります。multimodal modelだからといって、すべてのruntime2がすべての組み合わせに対応するとは限りません。
公式Instruct構成にはthinkerとtalkerが含まれます。thinkerはtext・audio・video信号を理解して応答を構成し、talker経路は音声生成を担います。まずtextの入出力を確認し、その後audioやvideo token3の経路を追加してください。どの段階で失敗するかを切り分けやすくなります。
model cardへアクセスするnetwork、選択したbackendの実行環境、保存領域と十分なmemory、テスト用の音声または動画fileが必要です。実際の業務fileや個人情報を含む録音ではなく、短く非機密のsampleから始めてください。weightsと入力fileをdownloadした後、networkを切断してもtestを実行できるか別途確認すると、dataが外部送信されないことを確認する助けになります。
| 作業 | 最初に確認する経路 | 検証する質問 |
|---|---|---|
| テキスト対話 | thinkerの入出力 | modelとtemplateが読み込まれるか |
| 音声理解 | audio入力の前処理・認識 | 発話内容を正しく文字起こし・解釈できるか |
| 音声応答 | talkerのaudio出力 | 生成音声を保存・再生できるか |
| 動画質問 | video frame sampling・thinker | 時間情報と主要sceneが反映されるか |
testを計画するときはmodel機能、実行経路、task種別を分けて考えます。
テキスト対話
- 最初に確認する経路
- thinkerの入出力
- 検証する質問
- modelとtemplateが読み込まれるか
音声理解
- 最初に確認する経路
- audio入力の前処理・認識
- 検証する質問
- 発話内容を正しく文字起こし・解釈できるか
音声応答
- 最初に確認する経路
- talkerのaudio出力
- 検証する質問
- 生成音声を保存・再生できるか
動画質問
- 最初に確認する経路
- video frame sampling・thinker
- 検証する質問
- 時間情報と主要sceneが反映されるか
backendの対応範囲を先に確認する
検証可能な参照経路は、Linux NVIDIA GPU4上でHugging Face Transformersを使い、公式の`Qwen3OmniMoeForConditionalGeneration`とprocessorを読み込み、音声fileを1つ入力する方法です。Qwen teamはTransformers 5.2.0以降、`accelerate`、`qwen-omni-utils`、ffmpegを指定しています。FlashAttention5 2は対応CUDA GPUでFP16/BF16を使う場合のoptional機能です。大規模なserving workloadにはvLLM-Omniも選択肢として挙げられています。
以下の例はApple Silicon対応経路ではありません。macOS/MLXでのQwen3-Omni公式対応や、すべての音声・動画機能との互換性は確認できていないため、この組み合わせが動作すると仮定しないでください。Apple端末を対象にする場合は、公式変換checkpoint6、processor、audio/video backendの対応が確認されるまで実行を保留してください。
このcheckpointは30B-A3Bクラスで、相当量のGPU memoryとlocal storageが必要です。公式memory表はTransformersとFlashAttention 2を使うBF167条件です。install前にGPU、CUDA/PyTorchの組み合わせ、checkpointの保存容量を確認してください。precisionやbackendを変えると必要量と対応機能も変わる場合があります。
python -m venv .venv
source .venv/bin/activate
python -m pip install -U 'transformers>=5.2.0' accelerate qwen-omni-utils soundfile
# Install a PyTorch build matched to your CUDA and GPU from the official PyTorch selector.
python -m pip install -U flash-attn --no-build-isolation
ffmpeg -versionまず短い音声を一つ最後まで処理する
短く非機密のWAV fileを`sample.wav`として保存し、以下のcodeを実行します。conversationにはlocal file pathを指定し、`process_mm_info`でaudio入力を準備してthinkerからtext回答を得ます。初回は大きなcheckpointのdownloadとloadがあるため時間がかかり、GPU memoryも多く使う場合があります。fileを開けない場合は、まずcodec8とsample rate9、ffmpeg、`qwen-omni-utils`を確認してください。
次にtalkerを含む経路で音声出力を試します。同じ回答をtextとaudioの両方で返せるか、生成fileを再生できるか確認します。textしか返らない場合は、request形式、backend制約、model設定を公式例と比較してください。音声の入出力を一度にすべて有効にすると、認識と音声生成のどちらが失敗したか分かりにくくなります。
model load、入力処理、最初のtext応答までの時間、全応答時間を分けて記録します。coldとwarmの実行を区別し、同じfileで繰り返してください。以下のcodeはtext出力のみを要求し、talkerによる音声出力は含みません。
from transformers import Qwen3OmniMoeForConditionalGeneration, Qwen3OmniMoeProcessor
from qwen_omni_utils import process_mm_info
model_id = 'Qwen/Qwen3-Omni-30B-A3B-Instruct'
model = Qwen3OmniMoeForConditionalGeneration.from_pretrained(
model_id, dtype='auto', device_map='auto', attn_implementation='flash_attention_2'
)
processor = Qwen3OmniMoeProcessor.from_pretrained(model_id)
messages = [{'role': 'user', 'content': [
{'type': 'audio', 'audio': './sample.wav'},
{'type': 'text', 'text': 'Summarize the spoken message in one sentence.'},
]}]
text = processor.apply_chat_template(messages, add_generation_prompt=True, tokenize=False)
audios, images, videos = process_mm_info(messages, use_audio_in_video=False)
inputs = processor(text=text, audio=audios, images=images, videos=videos,
return_tensors='pt', padding=True, use_audio_in_video=False)
inputs = inputs.to(model.device).to(model.dtype)
text_ids, _ = model.generate(**inputs, return_audio=False, thinker_return_dict_in_generate=True)
answer = processor.batch_decode(
text_ids.sequences[:, inputs['input_ids'].shape[1]:],
skip_special_tokens=True, clean_up_tokenization_spaces=False
)
print(answer)
frame数を記録しながら動画を長くする
音声testに成功したら、5秒程度の短い動画について質問します。frame10をdecode11してmodelへ渡す経路だけでなく、時間情報も重要です。同じfile sizeの動画でも、frame sampling rateやresolutionが異なれば入力量は変わります。公式例の前処理とframe sampling設定を使って、短いclipから確認してください。
公式model cardのmemory値は、BF16のTransformersとFlashAttention 2を前提とする理論値です。cardでは15秒の動画に約78.85GB、120秒に約144.81GBという例が示されています。すべてのbackendにおける実際の最低要件でも、小型quantized modelの結果でもありません。長い動画ではmemory要求が大幅に増える可能性を示す注意として受け止めてください。
clip長だけを増やすのではなく、frame rateとresolutionを一つずつ変え、入力frame数とpeak memoryを記録します。時間順序が重要なら、「最後のframeには何が写っていますか」だけでなく、出来事の順番も尋ねてください。frame samplingを変えるとmodelが見る内容も変わるため、異なる設定での速度と正確性は直接比較できません。
| 作業 | 最初に確認する経路 | 検証する質問 |
|---|---|---|
| テキスト対話 | thinkerの入出力 | modelとtemplateが読み込まれるか |
| 音声理解 | audio入力の前処理・認識 | 発話内容を正しく文字起こし・解釈できるか |
| フレームのサンプリング | talkerのaudio出力 | 生成音声を保存・再生できるか |
| 質問 | video frame sampling・thinker | 時間情報と主要sceneが反映されるか |
testを計画するときはmodel機能、実行経路、task種別を分けて考えます。
テキスト対話
- 最初に確認する経路
- thinkerの入出力
- 検証する質問
- modelとtemplateが読み込まれるか
音声理解
- 最初に確認する経路
- audio入力の前処理・認識
- 検証する質問
- 発話内容を正しく文字起こし・解釈できるか
フレームのサンプリング
- 最初に確認する経路
- talkerのaudio出力
- 検証する質問
- 生成音声を保存・再生できるか
質問
- 最初に確認する経路
- video frame sampling・thinker
- 検証する質問
- 時間情報と主要sceneが反映されるか
遅延とメモリからボトルネックを見つける
multimodal対話では、file前処理、vision/audio encoder、thinker prefill12、生成decode、talker出力が続く場合があります。全体時間だけを記録すると、どの段階が原因か分からず「modelが遅い」という結論だけになります。logで確認できる詳細時間を記録し、未対応の監視値を推測して記入しないでください。
memory不足の場合は、model weights、入力長、video frame数、同時会話数、他アプリの使用量を分けて確認します。まず動画を短くすると安定するか試してください。音声と動画を同時処理する必要がなければ、それぞれ別の経路とも比較します。model cardの理論上のmemory条件とruntimeの実使用量を同じ値として扱わないでください。
リアルタイム対話が目的なら、最初の応答までの時間と音声出力の開始時点を重視します。長い録音の要約などbatch作業では、全処理時間とmemoryの安定性を重視してください。特定のhardware/backend構成で失敗する場合はunsupportedとし、小さなmodelまたは公式対応のserving環境を検討します。
公式model・実行資料とlicense
modalityとbackendの対応はmodelやruntimeのreleaseにより変わる可能性があります。deploy前に公式repositoryとmodel cardで必要version、利用条件、制限を再確認してください。このガイドはローカル端末の性能を測定していません。
用語の注釈
CUDA — NVIDIA GPUで汎用計算を行うソフトウェア基盤です。CUDA向けのプログラムが他のGPUでそのまま動くとは限りません。
本文に戻るランタイム — プログラムの実行時に必要な機能を提供するソフトウェア環境です。ローカルAIではモデル実行エンジンを指すこともあり、GPUランタイムライブラリと完成したサービングアプリは別の構成要素です。
本文に戻るトークン — モデルが入力や出力を分けて処理する単位です。1トークンが1文字や一定の時間に相当するわけではありません。
本文に戻るGPU — 多くの計算を並列に処理するプロセッサーです。AIモデルの実行ではモデル計算を担います。
本文に戻るFlashAttention — Attention計算のメモリアクセスを効率化する実装です。利用可否や効果はハードウェア、モデル、実行環境によって異なります。
本文に戻るチェックポイント — 学習済みモデルの重みなどを保存したファイルです。同じモデル系列でも、版や用途によって異なるチェックポイントを使うことがあります。
本文に戻るBF16 — モデルの数値を保存・計算する16ビット浮動小数点形式です。利用可否はハードウェアと実行環境によります。
本文に戻るオーディオコーデック — デジタル音声を符号化・圧縮し、復号する方式またはソフトウェアです。サイズ、互換性、非可逆かどうかはコーデックによって異なります。
本文に戻るサンプリングレート — 音声信号をデジタル化する際、1秒間に何回測定するかを示す値です。ビット深度とは別の属性です。
本文に戻るフレーム — 動画を構成する1枚の画像です。フレームレートとフレーム解像度は別の属性です。
本文に戻るデコード — LLMでは入力処理後に出力トークンを生成する段階です。VAEやオーディオコーデックでは、圧縮表現や符号化データから元の形式を復元する処理を指すことがあります。
本文に戻るプリフィル — LLMが入力プロンプトを読み、各トークンの内部表現を計算する段階です。プロンプトが長いほど処理するトークンが増えます。
本文に戻る