ProsGrowがAMD上のKimi K3のリクエスト全体スループットを50%向上させた方法

大量のコンテキストを読み込んでから回答するAIアプリケーションでは、入力処理の時間が生成速度と同じくらい重要になることがあります。そのため、リクエスト全体を最適化すると、より良い体験を提供するサービング構成の選択も変わり得ます。

Kimi K3の検証では、ProsGrowは同じAMDハードウェア上で、既存のATOM構成に対してリクエスト全体の出力スループットを50.1%向上させました。同じ元のモデルチェックポイントを使い、リクエストサイズを制御したうえで、サービングスタックの変更により得られた結果です。実験構成ではランタイムの一部で数値精度を変更しているため、より広範な品質検証が引き続き必要です。

結果：応答全体を受け取るまでの待ち時間を短縮

9月22日の測定では、AMD MI325X GPU8基でKimi K3を実行しました。各リクエストは正確に8,192入力トークンを含み、256出力トークンを生成し、同時に実行するリクエストは1件でした。

リクエスト全体のスループットは、出力トークン数を、入力処理と通信を含む応答全体の受信時間で割った値です。GPU単位ではなく、システム全体の測定値です。2つのパーセント値は同じ改善を別の観点から表しており、足し合わせるべきではありません。

プライベートAIを運用するチームにとって、サービング構成をハードウェア仕様と併せて評価する意義を示す結果です。大量の入力コンテキストと簡潔な生成出力を組み合わせる用途では、一定量の応答を受け取るまでの待ち時間短縮が重要になる場合があります。

4.41倍の結果が示す、ワークロードの重要性

実験構成と、MicrosoftのTutelランタイムを包むローカルアダプターも比較しました。ホスト、元のチェックポイント、固定リクエストデータ、クライアントは同じです。

入力8K・出力256トークンのワークロードでは、Tutelアダプターのリクエスト全体の出力レートは9.10 tokens/s、調整後のATOMは40.17で、リクエスト全体のレートは4.41倍でした。リクエスト時間の中央値は、アダプターが28.13秒、調整後のATOMが6.37秒でした。

デコードが始まってからのトークン生成は、Tutelの方が速いままでした。78.33対47.67 tokens/sです。また、短い512入力トークンのリクエストも、Tutelの方が速く完了しました。検証したアダプターで長いプロンプトの処理に時間がかかったことが、入力8Kでの結果を変えました。

ビジネス上の教訓は具体的です。アプリケーションが実際に使うリクエスト長と応答サイズに基づいて、サービング構成を選ぶべきです。これはローカルなランタイム比較であり、あるランタイムがあらゆるワークロードで速いという一般的な主張ではありません。

改善はどこから生まれたか

ProsGrowは、入力処理と生成を通じてサービングスタックがAMDハードウェアをどう使うかを調べ、複数の変更を組み合わせたランタイム構成を検証しました。この作業はATOMとAMD AITERのエコシステムに基づいています。

この手法は、最適化をリクエスト全体に結び付けます。また、数値精度と品質のトレードオフも明示します。同じ元のチェックポイントを使っていても、異なるサービング構成が同一の数値演算を行うとは限りません。この比較では、ランタイムとキャッシュの精度方針が異なります。

検証した内容

各構成では、入力長ごとにウォームアップを2リクエスト、測定を5リクエスト実施しました。投機的デコードは無効です。保存した応答ストリームを監査してトークン数とタイミングを確認し、3つの構成すべてが算術とマーカー想起の確認に合格しました。

これらの機能確認は、モデルの正解精度が同等であることを証明しません。実験構成は通常のサービスを置き換えず、選択可能な構成のままにしました。これらは開発段階の測定結果であり、信頼区間や本番サービスレベルの保証はありません。

プライベートKimiホスティングを検討するチームにとって、次のステップは、代表的なプロンプト、応答長、同時実行数、タスク品質基準での評価です。ProsGrowは、その要件を実測済みの導入構成に結び付けるお手伝いをします。

プライベート推論のパイロット導入に関するご相談は、contact@prosgrow.aiまでメールでお寄せください。