QEngine RTX 5090ベンチマーク、キャッシュに支えられた優位性で504 Tok/sを報告
QEngineのRTX 5090ベンチマークは、Qwen3.8-Flash-Nextで毎秒504トークンを報告している。ただし、このピーク値には競争状況の見え方を変える条件が伴う。LocalLLaMAのユーザーは、2枚のRTX 5090カードでQEngine 1.3.1をテストし、単一ストリームのデコード、つまり1つの会話における生成速度で大幅な優位性があったと報告した。同じ比較では、エージェントのプロンプトレイテンシーテストでQEngineはStrataとおおむね同等である一方、より長いベンチマークプロンプトの処理はStrataのほうが速いとされている。
Relative-Ant-9249として投稿したテスターは、開発者bpx03に謝意を示し、QEngineは自分以外の人物のプロジェクトであると明言している。そのローカル推論ベンチマークでは、同一ワークステーション上の複数エンジンを比較している。これはレポートの有用性を高めるが、独立した再現検証を経ていないユーザー実施の比較であることに変わりはない。
中心的なトレードオフはすでに明らかだ。最速の出力ストリームが、会話全体を通じて最短の待ち時間を自動的に意味するわけではない。繰り返しのプロンプトではQEngineの適応型キャッシュが有利に働き、長い入力では報告されたテストでStrataが有利となり、アイドル状態の会話を維持するかどうかでもレイテンシーは再び変化する。これらのエンジンから選ぶ開発者は、どの遅延が実際に作業を中断させているのかを見極める必要がある。
QEngine RTX 5090ベンチマークが実際に測定したもの
504 tok/sという結果は、特定のワークロード、メモリ構成、ソフトウェアバージョンに属する。 比較全体の平均でもなければ、すべての応答での性能保証でもない。
ワークステーションには、各32 GBのビデオメモリを搭載したRTX 5090カード2枚に加え、Threadripper PRO 3975WXプロセッサが搭載されている。テスターは251 GBのシステムRAMと、約262,000トークンに設定されたコンテキストを報告している。トークンは、単純な単語数ではなく、モデルが処理・生成するテキストの単位である。
QEngineでは、4ビット整数重みを使用する圧縮モデル表現であるFlash-NextのINT4 AutoRoundビルドを使用した。テスターによると、CUDAのコンパイルターゲットをアーキテクチャ86から120へ変更し、nvcc 13.3とg++-13を使用したという。ほかのソース変更は行わず、起動からリクエスト提供までの間隔は53秒だったと報告している。
これは前向きな移植性の報告ではあるが、コンパイルの成功だけで広範なハードウェア対応が証明されるわけではない。このユーザーが、このマシン上でこのビルドを動作させたことを示しているにすぎない。異なるマザーボード、ドライバー、メモリ構成、または動作環境で同等の挙動を示すものではない。
テストでは叙述的な出力とコード出力を分けており、その違いは結果全体で重要となる。デフォルト構成では、QEngineは叙述テキストを370 tok/s、コードを439 tok/sで生成したとされる。会話キャッシュをシステムRAMへ移すと、それぞれ406 tok/sと504 tok/sまで上昇した。
StrataのISTA IQ3_S構成は、叙述出力で214 tok/s、コードで293 tok/sに達したと報告されている。UD-IQ4_XS構成では180 tok/sと239 tok/sだった。これらは異なる圧縮モデルビルドであり、この比較をエンジン実装のみの純粋な測定として扱うことはできない。
調整済みのbucko vLLM構成は、叙述出力で135 tok/s、コードで141 tok/sを記録した。出荷時構成の測定値は120 tok/sと118 tok/sだった。テスターはInfernix構成についても14–18 tok/sを挙げているが、対応するプロンプト処理の測定値はない。
これらの数値は、このワークステーション上で大きな差が報告されたことを示している。同時に、見出しが持つ限界も示している。504 tok/sは、一覧にあるコード生成結果の最高値である。同じエンジンの叙述出力はより低く、デフォルトのメモリ構成はRAM構成より遅い。
レポートによると、すべてのエンジンで同じベンチマークスクリプトとプロンプトを使用したという。リンクされたコミュニティのサービングレシピはテスト環境の文脈を提供するが、ベンチマークプロジェクトへのリンク自体が、投稿結果を独立して検証するものではない。
したがって、最も妥当な説明は具体的なものになる。QEngine 1.3.1は、このユーザーがテストした構成の中で単一ストリーム生成をリードし、最高報告値はコード生成時に記録された。利用可能な最速エンジンに関するより広範な主張には、さらに完全な比較対象と再現可能な独立テストが必要となる。
繰り返しプロンプトは生成性能の優位性を一般化しにくくする
QEngineの報告された優位性は意味のあるものだが、このベンチマークは通常のトラフィックでは再現されない可能性がある挙動にも報いている。 テスター自身がこの制約を直接指摘しており、結果を解釈するうえで中心的な要素となる。
投稿によると、QEngineのエキスパートキャッシュは直近の利用状況に適応する。エキスパートキャッシュは、頻繁に必要となるモデルの一部を保持し、エンジンが別の場所から何度も取得せずにアクセスできるようにする。まったく同じプロンプトを繰り返すことで、この仕組みに有利なワークロードが与えられる。
これは、ベンチマークが実行ごとにプロンプトを繰り返すため重要だ。最近の利用が将来の利用の有用な予測因子となり、モデルデータの移動を減らせる可能性がある。その結果得られる生成速度は、あらゆる会話を表すものではなく、好条件下での動作状態を示している。
テスターはこれを、ルーティングされたエキスパート量の約99.5%をすでに保持しているというStrataのキャッシュと対比している。その説明によれば、プロンプトの繰り返しはStrataにはそれほど大きな追加利益をもたらさない。この説明はテスターによるものであり、ここでは独立して確立されていない。
投稿では、多様なトラフィックにおける以前の観察結果として、単一ストリームで約300–400 tok/sも示している。テスターのエージェントワークロードを通じたリクエストは、330–470 tok/sの範囲だったとされる。これらの数値も高速ではあるが、504 tok/sという見出しは典型的な期待値というより好条件のケースに見える。
タイトルでは、テスト対象の次点エンジンに対して約1.5–1.9倍の優位性と表現している。本文では、ワークロードの違いを考慮したうえで、Strataに対し約1.4–1.9倍というやや広い推定を用いている。どちらの範囲も、無関係なハードウェアやプロンプトへ適用する普遍的な倍率にすべきではない。
ここでQEngine対Strataはワークロードの問題となる。同様のコードを繰り返し生成する開発者は、無関係な文書を行き来する人とは異なるキャッシュパターンから恩恵を受ける可能性がある。どちらのパターンも、測定された優位性が変化するまでにどれほど持続する必要があるかは、情報源では示されていない。
有用な独立比較では、両方の条件を維持すべきだ。繰り返しプロンプトは、直近の活動が将来の需要を予測する場合にエンジンが何をできるかを明らかにする。多様なプロンプトは、より協力的でないリクエストの連続をどれだけ適切に処理できるかを示す。
どちらの条件も、すべての評価で自動的に優先されるべきではない。反復は、共有された指示や繰り返されるタスクを持つ実際のアプリケーションを表すことがある。多様性は、コーディング、リサーチ、文書レビュー、不慣れなプロジェクトの間を移動するパーソナルアシスタントを表すことがある。
好条件が見出しから消えるときに、実務上の問題が生じる。504 tok/sだけを見る読者は、タスクを切り替えた直後にもその速度を期待するかもしれない。利用可能な証拠はその期待を支持していない。
したがって、このQEngine RTX 5090ベンチマークは、競合エンジンに対して、比較可能なキャッシュ条件下での挙動を説明するよう求めるものでもある。また、ベンチマークの作成者にも、それらの条件を明確に開示するよう促す。そうした開示がなければ、性能ランキングはランキングが成立する理由を覆い隠しかねない。
購入者や開発者にとって重要なのは、実際の作業が繰り返しベンチマークにどの程度似ているかという点だ。その答えによって、ピーク値をどれだけ重視すべきかが決まる。より低い速度でも挙動が一貫しているほうが、大きな変動を伴う高い速度より、一部のワークフローには適しているかもしれない。
Strataは回答生成前の段階で競争力を維持する
QEngineの生成性能の優位性は、リクエスト全体における明確な優位性にはつながらない。 報告されたプロンプト処理結果は、入力が長くなるにつれてStrataにより強い立場を与えている。
プリフィルとは、モデルが応答の生成を開始する前に入力を処理することを指す。約10,000入力トークンでは、QEngineのデフォルト構成は約5,700 tok/sを処理したとされる。RAMキャッシュ構成では、その入力長で約6,200 tok/sに達した。
StrataのISTA IQ3_S構成は、より短い入力長で約5,100 tok/sを処理したと報告されている。しかし約90,000トークンでは、約10,000 tok/sに達した。QEngineのデフォルト構成は、そのより長い入力長で約7,300 tok/sを記録した。
投稿には、QEngineのRAM構成について、対応する90,000トークン時のプリフィル値は示されていない。この欠けている結果は、より短い入力時の性能から推測するのではなく、そのまま欠けたものとして扱うべきだ。利用可能な測定値は、短いプロンプトではQEngineが先行し、長いプロンプトではStrataが先行するという分かれた結果を支持している。
この違いはコーディングアシスタントに直接当てはまる。最近の小規模なやり取りを基に作業するアシスタントと、大規模なリポジトリコンテキストをレビューするアシスタントでは、読み取りに費やす時間の割合が異なる。高速な生成は両方に役立つが、入力処理にかかる時間をなくすものではない。
エージェントテストは、もう1つの重要な境界を加える。これは、コンテキストが約35,000トークンまで増加する12ターンのツール使用シーケンスを対象とする。プレフィックスキャッシュが機能した状態では、QEngine 1.3.1は最終ターンのプロンプトを1.75秒で読み取ったとされる。
プレフィックスキャッシュとは、プロンプトの変わらない先頭部分に対する計算を再利用することだ。Strataの対応する結果は1.7–1.9秒であり、QEngineはこの報告範囲内に位置する。テスターはこの測定において、両エンジンを適切に同等と表現している。
同じ報告比較では、調整済みのbucko構成は4.36秒を要した。これはテストされた構成間の差を示すが、すべてのvLLMデプロイメントにおける結果を確立するものではない。構成、モデル表現、ワークロードはいずれも比較の一部であり続ける。
報告された数値がプロンプト読み取り段階を測定している点も重要だ。ツールの実行、結果の確認、後続指示の生成、タスク完了までに必要な総時間を測定しているわけではない。高速な段階はエージェントを改善しうるが、エージェント全体の完了時間を決定するものではない。
したがって、開示された測定全体におけるQEngine対Strataに単一の勝者はない。QEngineは生成で先行する一方、Strataはキャッシュされたエージェントプロンプトで競争力を保ち、報告された長入力プリフィルテストではより強い。すべてを出力トークン毎秒に集約するよりも、こちらのほうが有用な結論である。
ローカルアシスタントを運用するチームにとって、この問題は実務的だ。ユーザーが主に待っているのが入力処理、回答生成、外部ツールのいずれなのかを把握する必要がある。エンジンの変更が対処できるのは、エンジンが実際に制御する待ち時間の部分だけである。
この結果は、ローカル推論のデモの提示方法にも疑問を投げかける。高速に表示されるコードのストリームは見せやすく、理解もしやすい。そのストリームが始まる前の目立たない遅延も、繰り返されるツール操作の中では同じくらい重要になりうる。
アイドル状態の会話をRAMに保持すると別の待ち時間が変わる
最も実用的な結果は、最高の生成速度ではなく、古い会話を復帰させられることかもしれない。 QEngineのRAM構成は、途中に別のトラフィックが挟まっても有用な状態を維持したと報告されている。
KV キャッシュは、アテンション関連のキーと値を保存し、モデルが以前のトークンからの計算を再利用できるようにする。このテストでは、QEngine はそのキャッシュをピン留めされたシステム RAM に保持できた。これは予測可能な転送のために確保されたホストメモリを意味する。テスターは、合計でおよそ100万トークン分のキャッシュ容量に相当する13.5 GBのプールを報告している。
このプール容量は、個々の会話に設定されたコンテキスト上限とは別のものだ。合計容量は、プールがセッション全体でどれだけの会話状態を保持できるかを示す。ベンチマークが100万トークンを含む単一の会話をテストしたことを意味するわけではない。
アイドルセッションの実験は、それぞれ約58,000トークンの8つの会話から始まった。テスターはその後、元の会話に戻る前に、約400,000トークン分の別トラフィックを送信した。この手順では、マシンが別の処理を担った後でも、以前の作業がすぐ利用できる状態に保たれるかを検証する。
キャッシュを RAM に置いた場合、8つすべての会話がウォーム状態で復帰したと報告されている。つまり、保持された状態を再利用できたということだ。最初の応答までの時間は1.56〜2.01秒だった。これは出力ストリームが最終的にどれだけ速いかではなく、ユーザーが作業を再開する際に感じる遅延を測る指標である。
キャッシュをビデオメモリに置いた場合、ウォーム状態を維持した会話は2つだけだったとされる。残りの6つは入力を再処理する必要があり、8.7〜9.4秒を要した。テスターはコールドスタートの基準値を8.85秒と報告しており、実用上の影響は分かりやすい。
進行中のプロジェクトを行き来する開発者なら、このパターンに覚えがあるだろう。ある会話にはデバッグ調査があり、別の会話には実装レビューがあり、さらに別の会話では別機能を追跡している。重要な利点は、注意が別の作業に向いている間も、すでに処理済みの作業を保持できる点にある。
同じ区別は、検索可能なナレッジベースでも重要となる。適切な資料を見つけることと、モデルが以前に行った計算を再開することは別の問題だが、どちらも有用な作業に戻る速さに影響する。
情報源によれば、ビデオメモリ構成で古い入力を再処理する必要があった場合でも、回答の正確性は維持された。観測されたペナルティは遅延であり、回答の正確性が文書化された形で失われたわけではない。この区別により、あらゆるキャッシュミスを推論の失敗として扱うことを避けられる。
複数ストリームを同時に処理することを指す並行性についても、トレードオフがある。64,000トークンのコンテキストで8ストリームを同時実行した場合、RAM 構成はストリーム当たり124 tok/sを出したと報告されている。ビデオメモリ構成はストリーム当たり139 tok/sに達した。
テスターはこれを、単一ストリームでは約10%改善したにもかかわらず、この同時実行ワークロードでは約10%遅い結果だと要約している。また、各モードでの起動は1回、測定も1回だったことを開示している。検討に値するトレードオフを特定するには十分だが、その分布全体を確立するには不十分である。
より広い技術的課題は、このエンジンにとどまらない。ハイブリッドキャッシュのドキュメントでは、Flash-Next 固有の扱いが説明され、検証対象はテキスト生成に限定されている。モデル対応、状態保持、ワークロードの対象範囲には、製品名から推測するのではなく明示的な注意が必要だ。
個人用アシスタントでは、アイドル状態の作業を保持する価値が、同時出力速度の低下を上回る可能性がある。共有サービスでは、そのバランスが逆転するかもしれない。報告された結果は、どちらかを既定の選択肢として確定することなく、両方の可能性を評価する価値を示している。
品質チェックと競合エンジンが勝利の主張を制限する
この報告は QEngine の追加テストを支持するものであり、より優れた回答を生成する、あるいはすべての代替手段を上回るという宣言ではない。 報告自体の品質チェックと議論スレッドが、その限界を示している。
アシスタントテストでは、QEngine 1.3.1 で44件中44件のタスクが成功したと報告されている。以前の1.3系の実行では、低い effort 設定で44件中42件だった。テスターはこの小さな差を、確立された品質向上として提示せず、慎重に扱っている。
コーディング比較では、さらに慎重なバージョン帰属が必要となる。リリース候補ビルドでは、テスターのコーディングセットで30件中26件のタスクが成功した。Strata 構成では24件と25件であり、ある構成では繰り返し測定の結果が24〜26件の範囲だった。
テスターは、コーディングチェックを1.3.1で再実行していないと明言している。したがって、見出しの根拠となった正確なバージョンに対する直接的な品質認証としては使えない。これは以前のビルドに関する文脈と、比較で観測されたばらつきを示すものだ。
妥当な結論は、これらの限定的なチェックでは、QEngine の圧縮モデルに明白なコーディング上の不利は見つからなかったということだ。すべてのタスクで同等の品質を確立するものではない。また、生成速度の改善が、本番アプリケーションに必要なすべての挙動を維持することも示していない。
数値モデル重みを圧縮する量子化は、エンジン比較をさらに複雑にする。異なる圧縮ビルドは、性能と出力の両方を変えうる。完全なデプロイ構成を比較するベンチマークは実用的な問いに答えるが、寄与するすべての原因を切り分けるものではない。
競争領域も不完全だ。議論の中で、Basalt の開発者は NVIDIA Blackwell ハードウェア向けに特化設計されたエンジンのテストを提案している。その開発者は別マシンと別ベンチマークの性能を報告しているため、その数値を元のランキングに組み込むことはできない。
それでも、Blackwell 推論サポートの存在は、「最速エンジン」という表現を解釈するうえで重要である。QEngine は投稿者が測定した構成をリードした。未テストの代替手段は、開発者が他所で有望な数値を報告しているかどうかにかかわらず、未テストのままである。
情報源のスレッドには、熱心なユーザーの反応や構成支援の依頼も含まれている。こうした反応は関心を示すが、熱意も逸話も、単独でベンチマークを再現するものではない。別のワークステーションで同じ性能主張を裏付けるには、所有者の経験だけでなく、文書化されたテストが必要だ。
バージョンの変動も別の検証上の問題を生む。確認時点で、QEngine ソースコードリポジトリはバージョン1.3.2と追加の Flash-Next 機能を説明している。こうした現在の説明を、テスト対象だった1.3.1ビルドに遡って適用すべきではない。
リポジトリはこのプロジェクトを source-available と呼び、RTX 3090 ハードウェアに重点を置いていることを文書化している。ビルドノートでは依然としてアーキテクチャ86が特定され、他の GPU モデルは未テストとされている。そのため、投稿者による5090でのコンパイルは、一般的な互換性の保証ではなく、個別の結果に関する有用な証拠となる。
したがって、独立した再現では実際のソフトウェアリビジョン、モデルファイル、コンパイラ選択、起動構成を保持すべきである。すべてを最新バージョンに更新すれば興味深い結果が得られるかもしれないが、それは別の問いに答えることになる。再現性は、測定されたものを保持することにかかっている。
QEngine に今求められているのは、有望なユーザーレポートを信頼できる運用パターンへと変えることだ。競合他社に求められているのは、比較可能なワークロードと透明性の高い構成で応答することだ。どちらの課題も、無関係なハードウェアから大きな数値を投稿するだけでは満たされない。
次の比較をより有用にする3つの結果
次に有用な証拠は、別の孤立したピーク値ではなく、ワークロード横断でより再現可能な比較である。 この報告の解釈を強める、または弱める3つの具体的なシグナルがある。
第一に、別の2枚構成 RTX 5090 ワークステーションでの独立再現に注目したい。有用な結果では、正確な QEngine リビジョンとモデルビルドを特定し、繰り返しプロンプトと多様なプロンプトの両方を報告する。両条件で実質的な生成優位を再現できれば、その優位性が元のマシンを超えて成立する根拠が強まる。
多様なプロンプトで優位性が小さくなれば、元の測定を無意味にすることなく、その根拠は限定される。観測結果のより大きな部分を、直近のワークロード履歴が説明していることを示すためだ。この情報は、ユーザーが自らのトラフィックに基づいてエンジンを選ぶ助けになる。
独立テストでは、叙述的な出力とコード出力の区別も維持すべきだ。それらを単一の平均値にまとめると、元の報告ですでに明らかになっている差を隠してしまう。結果を分けて報告すれば、読者はベンチマークを自分のアプリケーションにより適切に対応付けられる。
第二に、Basalt のような Blackwell 重視の代替手段を含む、同一マシン上の比較に注目したい。元の投稿者の結果は、そのエンジンがランキングのどこに位置するかを確立していない。同一条件でテストすれば、議論で指摘された具体的な欠落を埋められる。
信頼できる比較では、圧縮モデルビルドと品質設定の違いを開示すべきだ。また、生成速度に加え、プロンプト処理の遅延と再開セッションの挙動も含める必要がある。そうでなければ、新たな勝者も古い見出しと同じ曖昧さを引き継ぐことになる。
QEngine がこの拡大した競合領域でも優位を保てば、競争上の主張は強まる。別のエンジンが生成性能で並びつつ、長い入力や再開セッションの遅延を改善するなら、選択はよりアプリケーションの挙動に依存するものになる。どちらの結果も、互換性のないスクリーンショットを比較するより有益である。
第三に、アイドルセッションの保持と同時生成について、混合ワークロードでの反復テストに注目したい。報告された RAM の結果が魅力的なのは、作業セッション間の中断を扱っているためだ。同時実行時の低速化は、この利点を継続的な利用下で評価すべき理由を示している。
反復実行により、会話が蓄積し活動が変化した場合でも、ウォームセッションの復帰が一貫しているかを明らかにできる。また、エンジンが古い入力を再処理する頻度、障害が発生する頻度、ストリーム当たりの速度が低下する度合いも分かる。こうした測定は、メモリ構成が持つ実用的価値を検証する。
許容可能な同時実行性能とともに一貫した復帰が得られれば、RAM バックドの会話状態を支持する論拠は強まる。頻繁なばらつきやより大きな低速化が見られれば、その魅力は軽いワークロードに限定される。どちらの結果であっても、すべてのローカルアシスタントが同じリクエストパターンを処理するふりをする必要はない。
変更を検討する開発者にとって、QEngine RTX 5090 ベンチマークは、異例なほど明示的な制約とともに、調査する十分な理由を提供している。その最大の貢献は、生成速度、プロンプト遅延、会話復帰がそれぞれ異なる方向に動きうることを示した点にある。
既存のエンジンを置き換える前に、ユーザーが実際に体験する待ち時間を比較してほしい。代表的な長い会話を保持し、無関係なトラフィックを発生させ、元の作業を再開したときに何が起きるかを測定する。繰り返しプロンプトとともに多様なタスクも含め、完了させる必要がある作業を反映した品質チェックを維持する。後の更新が比較の意味を消してしまわないよう、テストしたバージョンと構成を記録する。QEngine RTX 5090 ベンチマークは、その評価を行う説得力ある根拠を示している一方で、最終的な選択は自分のワークロードから得られる証拠に委ねられる。あなたのアシスタントは、回答の生成、増大するプロンプトの読み込み、あるいは記憶しているはずの会話の復帰のうち、どれに最も時間を費やしているだろうか。
