MiniMax H3 Max は本当に実時間か？ レイテンシー計測ガイド

MiniMax H3 Max は特定の定義では実時間より高速です： fal は、最適化された自社スタックで 5 秒のクリップを 3 秒以下で生成していると報告しています。ただし、これは 5 秒のリクエスト全てがユーザーの画面に 3 秒で到達することを意味しませんし、モデルが継続的にフレームをストリーミングしていることを意味しません。 キューイング、プロンプト展開、出力処理、ポーリング、ダウンロードはすべて狭いインference計測の外にあります。^[1]

この違いは実際の数値から見えます。MiniMax Design は、5秒の H3 Max ビデオはそのプラットフォームで約 15 秒かかり、15秒のビデオは約 40 秒かかると述べています。実際の時間は設定とサービス状況によって変動します。^[2] 両方の説明が真実です。 異なるシステムと計測境界を説明しているだけです。

クイック回答

• 「実時間より高速」とは、生成がクリップの再生終了前に完了することを意味しますが、ライブフレームストリーミングを意味しません。
• fal の 3 秒以下の結果は、自社の最適化された H3 Max スタックを計測しており、普遍的な API の約束ではありません。^[1]
• MiniMax Design は自社プラットフォームでより長い待ち時間を推定しており、そのためアプリはキュー、生成、転送、ダウンロードを個別に計測する必要があります。^[2]
• 承認された クリップあたりの時間を報告してください。高速に拒否されたクリップは有用なスループットを提供しません。

生成ビデオにおける「実時間」の意味

ラベルを使う前に比率を使用してください。標準的な実用的な計算は以下の通りです：

real-time factor (RTF) = generation time / output playback duration

5 秒の出力では：

公式は単純ですが、分子はそうではありません。「生成時間」は GPU inference、プロバイダーの壁時間、POST から完成したタスクまでの時間、またはプレイヤーが完全な MP4 を得るまでの時間を意味する場合があります。RTF を発表するたびに分子にラベルを付けてください。

これは 4 つの異なる計測です：

1. Inference RTF： モデル実行を出力期間で割ったもの。
2. Provider RTF： プロバイダーの入場から最終出力まで（プロバイダーがこの境界を公表している場合）。
3. 観測された API RTF： クライアント POST から最初のターミナルレスポンスまで。
4. 再生対応 RTF： クライアント POST からファイルの正常なダウンロードまたはバッファリングまで。

最後の 2 つだけがアプリケーション内の待ち時間を説明します。Inference RTF は serving 作業を比較するのに依然有用ですが、クライアントが見ることのできないキューを説明することはできません。

実時間より高速な生成はストリーミングと同じではない

一般的な H3 Max API パターンは非同期です：ジョブを送信し、ID を受け取ってから完成した MP4 を待つ。クリップは独自の期間より高速に完了できますが、フレーム 1 を早期に配信することはできません。これは高速バッチ生成であり、インクリメンタルビデオストリーミングの証拠ではありません。

連続再生システムは、承認されたクリップが再生されている間に後続のクリップを生成し、前のバッファーを維持することができます。これはバッファーされたパイプラインです。完全なファイルとして到着するすべての生成でも連続に感じることができます。

fal と MiniMax Design が異なる H3 Max 時間を公表する理由

fal は訓練後の H3 Max バリアントを開発し、インference システムをそれと並行して最適化しました。ローンチアナウンスは、5 秒のクリップを壁時間 3 秒以下で、そして fal の評価では公式の MiniMax H3 エンドポイントのスループット約 35 倍を報告しています。^[1] 結果は fal のモデルとサービングの組み合わせに属しています。

MiniMax Design は異なるプラットフォームのユーザー向け推定値を示します：5 秒の出力で約 15 秒、15 秒の出力で 40 秒。ページは実際の時間が設定とサービス状況によって異なることを明示的に警告しています。^[2]

ギャップはいくつかのステージを含む可能性があります：

POST 送信
  -> 認証と検証
  -> キュー入場
  -> オプションのプロンプト処理
  -> モデル推論
  -> エンコーディングとセーフティチェック
  -> ストレージと結果公開
  -> 次のクライアントポーリング
  -> MP4 ダウンロードまたはプレイヤーバッファリング

異なるプロバイダーは異なるハードウェア、バッチングルール、並行制限、プロンプト展開、エンドポイント実装を実行することもできます。1 つのプロバイダー内でさえ、480P と 768P は同じレイテンシー分布を持つ必要はありません。1 つのローンチ番号を別のルートの約束に変換する確実な方法はありません。

MiniMax H3 Max を配信する実装パスで エンドツーエンド計測する

有用なレイテンシーテストは POST 前に始まり、出力が実際に使用可能になるときに終わります。計測ベースラインを確立する際には、プロンプト、期間、解像度、ソースアセット、アカウント、リージョンを固定してください。その後、1 回に 1 つの変数を変更してください。

これらのタイムスタンプを記録してください：

ポーリングは正確な完了モーメントが t2 と t3 の間に落ちることを意味します。サーバーが正確なフィニッシュタイムスタンプを公開しているかのように t3 - t0 をミリ秒精度で報告しないでください。3 秒ごとにポーリングする場合、観測は状態変更から約 3 秒後に到着する可能性があります。キャッシングはこの不確実性を広げることができます。

reAPI の Tasks API は 2 ～ 3 秒のポーリング頻度を推奨し、進行中のタスクレスポンスが 5 秒間キャッシュされることを注記しています。 より速いポーリングはリクエスト圧力を増やしますが、ビデオをより速く完了させません。^[4]

reAPI 用 Node.js タイミングハーネス

下のスクリプトは 1 つの有料 5 秒 480P ジョブを送信し、クライアント可視時間を計測し、返されたファイルをメモリにダウンロードします。fal の inference カーネルを計測することを 主張しません。実行前にライブモデルページとアカウントを確認してください。^[5]

const API_BASE = 'https://reapi.ai/api/v1';
const API_KEY = process.env.REAPI_API_KEY;

if (!API_KEY) throw new Error('Set REAPI_API_KEY');

const headers = {
  Authorization: `Bearer ${API_KEY}`,
  'Content-Type': 'application/json',
};

const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

async function readJson(response) {
  const body = await response.json().catch(() => ({}));
  if (!response.ok) {
    const message = body.error?.message ?? response.statusText;
    throw new Error(`HTTP ${response.status}: ${message}`);
  }
  return body;
}

const t0 = performance.now();

// Submit once. Do not automatically repeat this POST after an ambiguous
// network failure: the first request may already have created a paid task.
const submission = await readJson(
  await fetch(`${API_BASE}/videos/generations`, {
    method: 'POST',
    headers,
    body: JSON.stringify({
      model: 'minimax-h3-max',
      prompt:
        'One continuous shot of a red paper boat moving through a shallow rain gutter while the camera tracks beside it; natural rain and street ambience, no dialogue.',
      aspect_ratio: '16:9',
      duration: 5,
      resolution: '480P',
    }),
  }),
);

const t1 = performance.now();
let lastProcessingAt = t1;
let task;
const deadline = Date.now() + 30 * 60 * 1000;

while (Date.now() < deadline) {
  await sleep(3000);
  task = await readJson(
    await fetch(`${API_BASE}/tasks/${submission.id}`, {
      headers: { Authorization: `Bearer ${API_KEY}` },
    }),
  );

  const observedAt = performance.now();

  if (task.status === 'processing') {
    lastProcessingAt = observedAt;
    continue;
  }

  if (task.status === 'failed') {
    throw new Error(
      `${task.error?.code ?? 'FAILED'}: ${task.error?.message ?? 'Unknown error'}`,
    );
  }

  if (task.status === 'completed') {
    const t3 = observedAt;
    const videoUrl = task.output?.video_urls?.[0];
    if (!videoUrl) throw new Error('Completed task has no video URL');

    const download = await fetch(videoUrl);
    if (!download.ok) {
      throw new Error(`Download failed: HTTP ${download.status}`);
    }
    const bytes = (await download.arrayBuffer()).byteLength;
    const t4 = performance.now();

    console.table({
      task_id: submission.id,
      output_seconds: 5,
      submit_round_trip_ms: Math.round(t1 - t0),
      completion_after_ms_lower_bound: Math.round(lastProcessingAt - t0),
      completion_after_ms_upper_bound: Math.round(t3 - t0),
      playback_ready_ms: Math.round(t4 - t0),
      observed_api_rtf: Number(((t3 - t0) / 5000).toFixed(2)),
      playback_ready_rtf: Number(((t4 - t0) / 5000).toFixed(2)),
      downloaded_bytes: bytes,
    });
    break;
  }
}

if (!task || task.status === 'processing') {
  throw new Error(
    `Local polling deadline reached for ${submission.id}; resume GET requests instead of submitting again.`,
  );
}

異なる時間枠で同じハーネスを実行してください。観察しようとしているキューを変更する大きなバーストではなく。すべての結果を保存してください。失敗を含めて。小さなパイロットは中央値と範囲を報告できます。p95 などのテール百分位数は十分大きなサンプルのために予約してください。

ジョブを変更することなくレイテンシーを比較する

設定の一致は必要ですが十分ではありません。同じソース URL、プロンプトバイト、アスペクト比、期間、解像度を使用してください。1 つのプロバイダーがプロンプトを展開し、別のプロバイダーが展開しない場合、リクエストが内部的に同一であるふりをするのではなく、その違いを記録してください。

各実行について以下を保持してください：

• モデル ID、プロバイダー、エンドポイント、アカウントリージョン、観測日；
• T2V または I2V モード、各入力アセットのハッシュ；
• 期間と解像度；
• 送信ラウンドトリップ、完了境界、ダウンロード時間；
• ターミナルステータスとエラーコード；
• クリップが創造的承認チェックに合格したかどうか。

5 秒の 480P H3 Max ドラフトと 15 秒の 768P ベース H3 クリップを混ぜ、その違いをモデルベンチマークと呼ばないでください。同様に、fal 推論時間と MiniMax Design UI 時間は、表が計測境界にラベルを付けない限り、1 つの「勝者」列に属しません。

スループット、並行性、承認クリップは別の数値です

レイテンシーは 1 つのジョブの待ち時間です。スループットはシステムが時間内に完了する作業量です。プロバイダーは優れた単一ジョブの推論を持ちながら、同時リクエストを制限することができます。別のプロバイダーはジョブあたりより長くかかりながら、並行してより多くのジョブを完了できます。

1 つのクリップの後に別のクリップを再生する必要があるバッファーされたチャネルでは、大まかなワーカー推定は：

required concurrent workers ~= ceil(
  tail end-to-end seconds
  / (clip seconds × creative acceptance rate)
)

これは計画近似であり、容量保証ではありません。10 秒のクリップが選択したテール遅延で 20 秒かかり、出力の半分だけが合格した場合、1 つのワーカーは 20 秒ごとに 0.5 承認クリップを提供します。10 秒の再生スロットを満たし続けるには、安全マージン、モデレーション失敗、編集レビューを追加する前に約 4 つのワーカーが必要です。

バッファーも重要です。再生が始まる前に複数の承認されたクリップを生成してから、視聴者が現在のものを見ている間に次のスロットを生成し続けてください。バッファーがゼロに達すると、印象的な中央値に関係なくストリームが停止します。

ストップウォッチはサウンドやストーリーを評価できない

H3 Max は fal のローンチアナウンスによると H3 の共同オーディオビデオ生成を保持しています。^[1] これにより、承認レビューが実時間主張の一部になります。完成したクリップは、間違ったキャラクターが話す場合、会話が声の間を横切る場合、サウンドキューが間違ったアクションに着陸する場合、または次のショットが前の設定を忘れた場合には使用できません。

アプリケーションに重要な要件でクリップをグレーディングしてください：

次に生のスループットと承認スループットの両方を報告してください。後者はアプリケーションを活かし続けることができる数値です。

FAQ

MiniMax H3 Max は実時間より高速ですか？

fal は最適化されたスタックで 5 秒のビデオを 3 秒以下で報告していますが、これはその計測では実時間より高速です。使用するルートでテストしてください。数値は他の場所のエンドツーエンドレイテンシーを保証しません。

MiniMax Design はなぜ 5 秒のクリップに約 15 秒と言いますか？

別の配信プラットフォームとユーザー向け推定です。MiniMax は時間が設定とサービス状況によって異なると言います。モデル推論外のキューイングと処理も観測される待ち時間の一部である可能性があります。

実時間 H3 Max はライブストリームフレームバイフレームを生成しますか？

標準的な非同期エンドポイントに基づいていません。完成したビデオファイルを返します。連続体験は、後続のクリップを生成し前のクリップが再生されている間にバッファーを維持することで構築できます。

解像度は MiniMax H3 Max の速度に影響しますか？

実行される作業に影響する可能性がありますが、単一乗数は想定されるべきではありません。両方が重要な場合、選択したエンドポイント上の 480P と 768P の両方でベンチマークしてください。現在の MiniMax ダイレクトと reAPI H3 Max 契約は 2K を提供しません。^[3]

fal の timings.inference 値を自分の reAPI ストップウォッチと比較できますか？

テーブルが異なるメトリクスとしてラベル付けした場合のみ。1 つは fal 上のバックエンド推論フィールドです。もう 1 つはクライアント観測パスで、入場、キューイング、ポーリング、ストレージ、ネットワーク時間を含むことができます。

十分なテストはいくつですか？

通用的な数はありません。配信するプロンプト、モード、設定、時間枠に十分対応するまで実行してください。小さなパイロットでは不安定な p95 ではなく中央値と完全な範囲を発行し、創造的な拒否を記録に保ってください。

ユーザーが実際に感じる待ち時間を公表する

「MiniMax H3 Max 実時間」は名付けされたクロックでのみ防御可能です。fal の結果はその共同最適化スタックが何ができるかを示します。MiniMax Design の推定値は異なるプロダクトサーフェスがより長い待ち時間を公開できることを示します。アプリケーションは自社ルートで計測された独自の POST-to-再生番号が必要で、受け入れ率とペアになっています。

Inference RTF、観測された API RTF、再生対応 RTF、および承認クリップ/時間を別のフィールドとして保持してください。次に、スピード主張はローンチポストから借用されたフレーズではなく、再現可能な運用数になります。

References

1. fal. Introducing H3 Max by fal. Published August 26, 2026. fal.ai
2. MiniMax Design. MiniMax H3 Max—Fast AI Video Generator. Retrieved September 7, 2026. design.minimax.io
3. MiniMax API. Create Video Generation Task V2. Retrieved September 7, 2026. platform.minimax.io
4. reAPI. Tasks API: polling, status, and output. Retrieved September 7, 2026. reapi.ai
5. reAPI. MiniMax H3 Max model page and request controls. Retrieved September 7, 2026. reapi.ai

Further reading

• MiniMax H3 Max vs MiniMax H3
• MiniMax H3 API guide
• AI video generation API pricing