MiniMax H3 2K vs 768P：同じプロンプトを2回実行して異なる2本の動画を得た

カフェのカウンターに置かれた同じコールドブリューボトルのショットの写真2枚。1枚はソフト、もう1枚はシャープで、その間にレシートが挟まれている

同じショットの2枚のプリント、1枚はソフト、もう1枚はシャープ。MiniMax H3では、その差は品質スライダーではない。openai/gpt-image-2/text-to-image で生成。

同じプロンプトを2回提出した。変更したのは1つのドロップダウンだけ：768P、次に2K。

最初の実行は$0.40かかり、130秒で完了した。2回目は$0.56で、181秒かかった。そして2つのフレームを並べてみて、何かがおかしいと感じた。ボトルはまだそこにあった。ラベルもまだあった。小さな印刷もすべて。しかしカウンターは温かみのある木から薄い石に変わり、背景のバリスタの後ろに棚が現れ、グラスの結露が突然あちこちに現れ、光の色が変わっていた。

私はドラフトでお金を節約したわけではなかった。2つの異なるフィルムを撮影していたのだ。

これはバグではない。これこそがH3における「2K」の本当の意味であり、それを理解すれば、誰もが言う「安いドラフトで作って、高価な仕上げをする」という標準的なアドバイスは静かに崩れ去る。以下はそのテストからのすべての数字と、安いドラフト作成を機能させる1つの変更点である。

主なポイント（すべての数値はAtlas Cloud、2026-08-05に測定）

• 768Pは 1344x768、2Kは 2560x1440 を16:9のリクエストで提供。これはピクセル数とビデオビットレートの3.6倍。
• 4秒のクリップの課金は $0.40 vs $0.56、つまり $0.10/秒 vs $0.14/秒。768Pは1秒あたり29%安いが、半額ではない。
• 768Pはテキスト-to-ビデオのペアで 28%高速（130秒 vs 181秒）、イメージ-to-ビデオのペアで17%高速（194秒 vs 234秒）。
• 同じプロンプトでの768Pと2Kのテキスト-to-ビデオは、1つのテイクの2つの品質ではなく、2つの異なるテイクを生成した。裸の768Pドラフトは、2Kの最終版をプレビューしない。
• イメージ-to-ビデオで最初のフレームを固定すれば、ドリフトは止まる。同じセット、同じフレーミング、同じラベル位置。そして2Kはその追加ピクセルをMiniMaxが言う通り、まさに小さな印刷に使う。
• 768Pはゲートされていない。 2026-08-05現在、両方のティアが解像度enumに存在し、ドロップダウンで選択可能。古いまとめがまだ言っていることとは関係ない。

MiniMax H3 2K vs 768P：768Pはまだクローズドベータか？

いいえ。そしてこれは早期に潰しておく価値がある。なぜなら、ローンチ直後に書かれたほとんどの価格まとめでまだ繰り返されているからだ。

今日、3つのH3エンドポイントすべてのライブ入力スキーマを取得した。resolution フィールドは enum: ["768P", "2K"]、default: "2K" で、テキスト-to-ビデオ、イメージ-to-ビデオ、リファレンス-to-ビデオすべてで同じ。duration は4から15まで1秒刻みで、3つすべてで同じ。フラグもゲートもセールスフォームもない。その後、2つの異なるエンドポイントで768Pジョブを送信したが、両方とも完了し、低いレートで課金された。768Pについてセールスに問い合わせるよう書かれているページがあれば、そのページはローンチの最初の週を説明しているのであって、今週のことではない。

MiniMax H3 2K vs 768P、同じプロンプト、サイドバイサイド

左が768P。右が2K。同一のプロンプト、同一の duration=4、同一の ratio=16:9、minimax/h3/text-to-video に連続で送信。

MiniMax H3 2K vs 768P スプリットスクリーン。同じテキスト-to-ビデオプロンプトから。解像度、価格、経過時間を表示。

同じプロンプト、2回の実行。左：768P、1344x768、$0.40、130秒。右：2K、2560x1440、$0.56、181秒。サイレントGIFとして表示。両方の配信ファイルは32kHzステレオオーディオを含む。Atlas Cloud、2026-08-05に測定。

実際に異なる点を見てみよう。シャープネスではない。フィルムそのものだ。カウンターの素材、背景の装飾、結露の量、カメラの高さ、色温度、そしてラベルの位置がすべて異なる。プロンプトはそのどれも変更するよう求めていない。

そして、誰もが逆だと思っている部分。以下は、両方のテイクからラベル領域を、ネイティブファイルからクロップし、同じ幅に拡大したもの。そのため、768Pのクロップは2Kのクロップよりも拡大率が高い。

MiniMax H3 768Pと2Kのテイク間のラベルクロップ比較。両方とも小さな成分表示が読める。

「single origin ethiopia guji / 250ml / roasted 04.08.2026」という小さな行は768Pでも残っている。ソフトになり、文字間隔が揺れるが、判読不能ではない。ここでの768Pの本当のコストは、ぼやけたテキストではなく、異なる構図だった。

つまり、MiniMax H3 2K vs 768Pの正直なフレーミングは「シャープ vs ぼやけ」ではない。「このテイク vs 別のテイク、さらにディテールパスが上乗せされたもの」である。

MiniMax H3 2K vs 768P スペックシート、実測値

この表のすべての数字は、ドキュメントページではなく、配信ファイルに対する ffmpeg -i と、完了した予測の price フィールドから得られたもの。

学ぶのに費用がかかった2つの脚注。まず、両方のティアが duration=4 のリクエストに対して4.46秒を配信し、両方とも4秒で課金された。つまり、余分な0.46秒は無料だが、カットを計画するためにそれを使うことはできない。次に、オーディオはティア間で同一である。クリップが会話や音楽の同期で成り立っている場合、2Kは重要なことには何も買わない。

MiniMax H3 2K vs 768Pがなぜみんなを躓かせるのか

なぜなら、H3の2Kはアップスケールステップではないからだ。それは第二世代である。

MiniMaxはメカニズムを直接説明している：「H3の2K出力では、従来の専用スーパーレゾリューションモジュールを使用する代わりに、H3ベースモデルが自身の低解像度出力をコンテキスト内で再生成する。」彼らはなぜそのように構築したのかも説明している：コンテキスト内アプローチは「元のマルチモーダルコンテキストを再度利用して高解像度出力を生成し、従来のスーパーレゾリューションが「推測」するだけで、小さなテキストや細かいディテールなど、回復できないことが多い詳細を回復できる」(MiniMax、2026年7月)。

これをプロダクションの視点で読み直してほしい。2Kパスは元のコンテキストに戻り、再度生成する。コンテキストがテキストプロンプトだけの場合、「もう一度生成する」は「もう一度サイコロを振る」ことを意味する。それがまさに私の2つのテイクが示していることだ。モデルは768Pバージョンを再現するように指示されたことは一度もない。なぜなら、モデルは768Pバージョンを一度も見ていないからだ。

実際に問題となる3つのケース：

1. テキスト-to-ビデオで768Pの安いドラフトを作成し、勝者を選び、それを2Kで再実行する。 見知らぬ人が返ってくる。プロンプトは尊重されるが、フィルムは新しい。これがこのページの上部にあるテストである。
2. 1秒あたり29%安いということは、全体で29%安いと予算を組む。 そうではない。なぜなら、本番用は実際のバッチの高価な部分であり、無駄になった2Kの再ロール1つで、いくつかのドラフトの節約が消えるからだ。
3. 安価なアップグレードパスがどこかにあると想定する。 今日、Atlas Cloudの全カタログを確認した：452モデル、3つのH3エンドポイント、その中にH3再生成エンドポイントはない。3つの生成エンドポイントだけが公開されている場合、「このクリップを2Kにアップグレードする」は、再ロールするか、別のアップスケーラーを実行することを意味する。どちらも費用がかかり、同じものを買うわけではない。

このモデルを回避するためにエンジニアリングする価値がある理由を述べておく。ローンチ時の見出しは「最大2K解像度、最大15秒のクリップ、ネイティブステレオオーディオのビデオ」(DataNorth AI、2026年8月)であり、スコアもそれを裏付けている：H3は現在、Artificial Analysisのビデオ編集Eloボードで1,130ポイントでトップ、Gemini Omni Flashの1,122ポイントを上回り、Dreamina Seedance 2.0 720pの1,037ポイントを93ポイント引き離している(Artificial Analysis、2026年8月)。品質はワークフローに値する。ワークフローはただ、2Kがどのように生成されるかを尊重しなければならない。

このMiniMax H3 2K vs 768Pテストの背後にある4つのモデル、1つのタブで

テスト全体は4つのモデル、1つのAPIキー、1つの請求書である。私はAtlas Cloudで実行した。なぜなら、画像モデル、2つのH3エンドポイント、アップスケーラーの間を切り替えるには、通常3つのアカウントと月末に調整する3つの請求書が必要だからだ。

数字をコピーする前に2つの注意点。H3エンドポイントはすべて、単一のヘッドラインレート$0.14/秒を公開しており、これが2K層である。768Pのレートはリストではなく請求書に表示されるので、自分で一度測定すること。そして、これらの4つのモデルは現在割引されていない。フレーム固定ステップを削減したい場合、openai/gpt-image-2-developer/text-to-image は2026年8月現在50%オフ（$0.009から$0.004）で稼働しており、同じファミリーで同じ仕事をする。

自分でMiniMax H3 2K vs 768Pテストを実行する方法

5ステップ、$2.21のクレジット、約15分の総経過時間。以下のすべてのプロンプトは、私が送信した正確な文字列である。

最初に3つのパラメータノート。それぞれが静かに実行を損なう可能性があるため：

• テキスト-to-ビデオでは、フィールドは ratio であり、aspect_ratio ではない。デフォルトは 1:1 で、enumには adaptive オプションがない。自分で 16:9 を渡さなければ、正方形のクリップになる。イメージ-to-ビデオでは、enumは adaptive のみ。なぜなら、最初のフレームが形状を決定するからだ。
• 文書化されたデフォルトの8を信頼するのではなく、常に duration を明示的に送信すること。請求されるのは、あなたが想定したものではなく、配信されたものに従う。
• すべてのH3ジョブは通常のインラインタイムアウトを超えて存続するため、非同期で送信し、ポーリングすること。price フィールドも遅れて入力される：status が completed に変わった時点では空であることが多く、実際の数値を得るために予測IDをもう一度ポーリングする必要がある。その2回目のポーリングなしでは、正直なコスト表を作成できない。

ステップ1：GPT Image 2でフレームを固定する

このステップが、ドラフトを宝くじではなくプレビューに変える。完成した構図を静止画として生成し、それを両方のビデオ実行の不動の部分にする。

textCopy
1Macro product photograph of a matte black cold-brew coffee bottle standing on a wet slate slab, morning window light raking across it from the right. A cream paper label wraps the bottle, sharply legible: bold uppercase title "NORTHBOUND COLD BREW" on one line, and directly beneath it in small type "single origin ethiopia guji / 250ml / roasted 04.08.2026". Condensation beads on the glass, an espresso machine and a barista in a denim shirt softly out of focus in the background. Cinematic, shallow depth of field, warm neutral grade, photoreal, 16:9.
2

設定：品質 high、サイズ 2048x1152。ここで節約してはいけない。2Kパスが保護したいすべてのディテールが、このフレームに最初に存在しなければならない。

GPT Image 2で生成された固定された最初のフレーム（2048x1152）。コールドブリューボトルと判読可能な小さな印刷が表示されている。

openai/gpt-image-2/text-to-image で生成、品質高、2048x1152。$0.1745請求、146秒で完了。

Atlas Cloud上のGPT Image 2プレイグラウンド。フレームプロンプトが入力され、出力パネルに生成されたボトルが表示されている。

Atlas Cloud上のGPT Image 2：品質を高、16:9に設定。固定フレームが右側にレンダリングされている。

ステップ2：768Pでドラフトを作成する

最終版で使用するのと同じエンドポイント。このステップとステップ4の違いは解像度のみ。

textCopy
1Slow macro dolly-in on the bottle. Condensation beads slide down the glass. The label stays perfectly still and legible. In the soft background the barista wipes the counter once. Natural cafe room tone, a faint espresso machine hiss. No camera shake.
2

minimax/h3/image-to-video の設定：最初のフレーム = ステップ1の出力、resolution=768P、duration=4、ratio=adaptive。

MiniMax H3 768Pドラフトクリップ。コールドブリューボトルへのスローマクロドリーイン。

768Pドラフト：1344x768、$0.40請求、194秒で完了。サイレントGIFとして表示。ファイル自体は32kHzステレオを含む。ラベルに4本の濃いドリップスジが付いていることに注目。

Atlas Cloud上のMiniMax H3イメージ-to-ビデオプレイグラウンド。固定フレームがアップロードされ、プロンプトが入力され、出力パネルに完成したクリップが表示されている。

イメージ-to-ビデオフォームに固定フレームがロードされている。解像度とDurationが、このステップとステップ4を分ける唯一のフィールドであり、両方のティアが同じリストにあり、どちらもゲートされていない。このキャプチャは2Kと8秒のデフォルトのままなので、Runボタンは$1.12を表示。Resolutionを768P、Durationを4に切り替えると、その見積もりは$0.40に下がる。

ステップ3：正しい点でMiniMax H3 2K vs 768Pドラフトを評価する

ドラフトはリハーサルであり、証明ではない。私の2つのペアから、以下が信頼できる情報とそうでない情報である。

以下を信頼する：プロンプトの文言、動きが全く読めるかどうか、カメラの動きの量、4秒間のペース、オーディオベッド。これらはすべてクリーンに転送された。

以下を信頼しない：細かい表面テクスチャ、製品上の最も小さな活字、またはそれが作り出すアーティファクト。私の768Pドラフトでは、ラベルに4本の濃い茶色のドリップが現れたが、2Kランでは生成されなかった。また、小さな成分表示行は判読不能になった。もしそのドラフトを汚れて見えるという理由で拒否していたら、機能しているプロンプトを拒否することになっていただろう。

これが本当の役割分担である。768Pは「これが正しいショットか」に答え、2Kは「これが納品可能か」に答える。

ステップ4：1つのフィールドを切り替えて2Kで仕上げる

同じエンドポイント、同じ最初のフレーム、同じプロンプト文字列。resolution を 2K に変更するだけで、他は何も変えない。

同じ固定された最初のフレームからのMiniMax H3 2K最終クリップ。クリーンなラベルと判読可能な小さな印刷。

2K最終版：2560x1440、$0.56請求、234秒で完了。ドラフトと同じスラブ、同じエスプレッソマシン、同じ植物、同じバリスタ、同じラベル位置。

これが、この記事全体がテストするために作られた質問への答えであり、良い方向に進んだ。最初のフレームを固定することで、ドリフトは止まった。セット、フレーミング、カメラの高さ、タイポグラフィの位置はすべて、768Pドラフトと2K最終版の間で維持された。違いはディテールに限定された：2Kパスは、スミアされたドリップを1本の細い流れにきれいにし、紙の質感を解像し、小さな成分表示行をノイズから言葉に戻した。これはまさにMiniMaxがコンテキスト内再生成について主張する動作であり、このテストで初めて2Kが品質層のように見え、再ロールではないように見えた。

対照的に、コントロールグループ。これが、このページの上部で見知らぬ人を生成した、裸のテキスト-to-ビデオラン（2K）である。同じプロンプト内容、最初のフレームなし。そのため、構図を固定するものは何もない。

MiniMax H3テキスト-to-ビデオプレイグラウンド（2K）。出力パネルに完成したコントロールクリップが表示されている。

Atlas Cloud上のMiniMax H3テキスト-to-ビデオ：最初のフレームなし、解像度2K、アスペクト比16:9、出力パネルに完成したクリップ。この生成自体に問題はなかった。ただ、768Pランが生成したフィルムと同じではないだけだ。

ステップ5：または、MiniMax H3 2K vs 768Pの再ロールをスキップして、代わりにアップスケールする

時には、768Pテイクがすでに正解であることもある。パフォーマンスは決まり、タイミングは正しく、別の結果になる可能性のある再生成は望まない。その場合は、再ロールしない。正確なファイルをアップスケーラーに通す。

atlascloud/video-upscaler の設定：video = 768P出力URL、target_resolution=2k。2Kへの入力制限は23秒と690フレーム、入力fpsは30以下。H3の24fpsクリップは問題なく通過する。

768PテイクをAtlas Cloudビデオアップスケーラーで2Kにアップスケール。同じ映像、より高い解像度。

アップスケールされたテイク：2540x1452、$0.12請求、40秒で完了。同じ4本のドリップ、同じすべて。これは同じフィルムであり、新しいものではない。

Atlas Cloudビデオアップスケーラープレイグラウンド。768Pクリップがロードされ、出力パネルに2K結果が表示されている。

Atlas Cloud上のビデオアップスケーラー。768P H3クリップがロードされ、アップスケール結果が右側で再生されている。このキャプチャは1080pデフォルトで実行されたため、Runボタンは5秒最小未満のものに対して$0.09と表示している。Target Resolutionを2kに切り替えると、$0.024/秒の層になり、自分の実行で請求された$0.12になる。

そして、誰もスキップすべきではない評決：同じ固定フレームからの3つのラベルクロップすべて、同じ倍率。

3方向ラベルクロップ比較：ネイティブ768P、そのクリップを2Kにアップスケール、ネイティブ2K。ネイティブ2Kのみが小さな印刷を回復する。

ネイティブ768P、同じクリップのアップスケール、ネイティブ2K。アップスケーラーは紙の質感と大きなタイトルを美しくシャープにし、正確なテイクを維持する。できないことは、小さな行を戻すこと。なぜなら、その情報は768Pファイルには決して含まれていなかったからだ。再生成パスはそれができる。なぜなら、ピクセルではなくコンテキストに戻るからだ。

つまり、2つのルートは競合しない。それらは異なる質問に答える。アップスケーリングはパフォーマンスを保存する。再生成はディテールを回復する。クリップが失うわけにはいかないものに基づいて選択する。

MiniMax H3 2K vs 768Pでテストする価値のあるバリエーション

• 縦型。 私の16:9テストでは1344x768が返ってきたので、短辺がティアによって固定される。9:16のリクエストは、同じ論理で768x1344になるはずだが、縦型バッチを仮定して構築する前に一度測定すること。イメージ-to-ビデオでは、adaptive enumと戦うのではなく、最初のフレームを通して形状を設定する。
• トーキングヘッド。 これは、ドラフトを完全にスキップして、直接2Kに進む場合である。顔、歯、アイラインは、まさに再生成パスが存在する小さなディテールクラスであり、768Pドラフトはこれらすべてについて誤った情報を与える。
• 長いクリップ。 15秒では、差は$1.50対$2.10に広がり、経過時間もそれに伴って伸びる。予算だけでなく、キューも計画する。
• 製品テキストと多言語作業。 H3の安定したフレーム内タイプとネイティブ多言語オーディオは、人々がそもそも商業用パッケージにそれを選ぶ理由である。両方とも768Pで生き残るため、768Pはリハーサルルームだけでなく、ソーシャルクロップのための真に使用可能な配信層になる。

MiniMax H3 2K vs 768Pが使用可能なクリップ1つあたり実際にかかるコスト

まず、2K配信物への3つのルート。8秒クリップあたり、実際に請求されたレートで。

次に、あなたの月を決定する数字。現実的な混合を取る：ショットを見つけるための10の4秒ドラフトロール、次に2つの完成した8秒クリップ。

真ん中の行を正直に読んでほしい。1秒あたりの節約は29%だが、バッチあたりの節約は18%である。なぜなら、最終版は依然として最終版だからだ。節約は、ドラフトが支配的になるにつれて29%に近づく：20の8秒ドラフトロール（10の短いものの代わり）では、ルート2はすべて2Kより約25%低くなる。そして、その1セントごとに固定フレームに依存する。なぜなら、それなしでは、それらの10の安いロールは、あなたが出荷しない10のフィルムだからだ。

2番目の配当は時間であり、それがより重要かもしれない。テキスト-to-ビデオペアでは、768Pは28%高速で返ってきて、両方のペアで一度も長くかかることはなかった。これらの経過時間での4秒クリップでは、1時間あたり約27のドラフトロールが可能で、20の代わりになる。適切なプロンプトを探しているとき、7つの追加のスイングは、節約した$1.60よりも重要である。

すべてを回避するためにセルフホスティングを計画していた場合の法的注意点。Hugging FaceのオープンウェイトはH3-Baseであり、768短辺で生成する。2KパスはAPI側にあるため、オープンウェイトはドラフト層を取得し、仕上げ層は取得しない。コミュニティライセンスには、EU、英国、韓国、米国をカバーする除外地域も含まれており、別の承認チャネルが開かれている。そのため、ローカルチェックアウトで商用パイプラインを構築する前に、ライセンスを読むこと。リリースされたウェイトに含まれるものと含まれないものの広範な概要については、MiniMax H3レビューを参照のこと。また、現在のビデオ分野の残りの部分に対してH3の価格を設定したい場合は、完全なモデルカタログを参照のこと。

よくある質問

MiniMax H3 2K vs 768Pにおいて、768Pは実際にクリップあたり安いのか？

はい。4秒の768Pクリップには$0.40、同じリクエストの2Kには$0.56が請求された。つまり、$0.10/秒対$0.14/秒で、1秒あたり29%の節約になる。ただし、節約が効果を発揮するのは、安い実行が高価な実行について何かを教えてくれる場合のみであり、そのためには最初のフレームを固定する必要がある。裸のテキスト-to-ビデオドラフト（768P）は別のフィルムであり、それに費やしたお金は節約されたお金ではない。

MiniMax H3 2K vs 768Pにおいて、2Kは単に768P出力のアップスケールなのか？

いいえ。MiniMaxは、専用のスーパーレゾリューションモジュールを実行するのではなく、ベースモデルが自身の低解像度出力をコンテキスト内で再生成する。そのため、2Kは小さなテキストや細かい表面のディテールを復元でき、アップスケーラーは近似するだけである。私の3方向ラベルクロップはそれを正確に示している：アップスケールされた768Pクリップは紙の質感をシャープにしたが、小さな成分表示行は判読不能なノイズのままだった。一方、ネイティブ2Kランはそれを言葉に戻した。

MiniMax H3 768Pドラフトは2K最終版のように見えるか？

最初のフレームを固定した場合のみ。裸のテキスト-to-ビデオでは、同じプロンプトから、2つのティアは異なるセット装飾、異なるカメラの高さ、異なる結露、異なるラベル位置を与えた。固定された最初のフレームを持つイメージ-to-ビデオでは、構図、フレーミング、タイポグラフィはすべてティア間で保持され、変更はディテールとテクスチャのみであった。

MiniMax H3 768Pのためにまだセールスに連絡する必要があるか？

いいえ、2026-08-05現在必要ない。3つのH3エンドポイントすべてのライブスキーマは、resolution を enum: ["768P", "2K"] としてリストしており、プレイグラウンドは両方を1つのドロップダウンに表示し、私の768Pジョブは2つの異なるエンドポイントで完了し、低いレートで請求された。クローズドベータという情報は、ローンチ直後の数日間に書かれた記事に由来する。

MiniMax H3 2K vs 768Pにおいて、2Kはどのくらい遅いか？

私の4秒のペアでは、1.2倍から1.4倍遅い：テキスト-to-ビデオで181秒対130秒、イメージ-to-ビデオで234秒対194秒（送信から完了まで測定）。アーキテクチャ的には、2Kは同じコンテキストに対する2回目の生成パスであるため、絶対的な差は長いクリップで拡大すると予想され、横ばいにはならない。

再ロールせずに768Pクリップを2Kにアップグレードできるか？

ビデオアップスケーラーを実行することで、テイクに触れずに解像度を上げることができる。私の場合、4.46秒のクリップを2K層でアップスケールするのに$0.12かかり（$0.024/秒、最低5秒）、40秒で返ってきた。これにより、パフォーマンスがフレームごとに保存される。しかし、キャプチャされなかったディテールを回復することはできない。そのため、2Kにする目的が判読可能な小さな活字である場合、アップスケーラーではなく再生成パスが必要である。