Qwen3.8 Basaltベンチマーク、16GB VRAMで毎秒153トークンを報告
10月25日に投稿されたQwen3.8 Basaltのベンチマーク結果は、16GBというグラフィックスメモリ制限のあるRTX 5080で毎秒153トークンを報告している。このワークステーションは、システムメモリも54.1GB使用した。投稿の見出しは毎秒250トークン超の生成を強調しているが、この数値は持続的な出力ではなく短時間のピークを示すものだ。
この違いは、ローカルのコーディングアシスタントを検討する開発者にとって重要である。投稿者によれば、このセッションでは103件のリクエストを処理し、別のテストでは異なるコンテキスト長で新規プロンプトを処理した。こうしたワークロードは応答性に関する有用な証拠となるが、いずれもコーディング精度や独立して検証された性能を確立するものではない。
中心的な論点は、有用な速度と許容可能な出力を維持しながら、大規模モデルをワークステーションに収めることにある。特化型推論エンジンのBasaltは、Strataやllama.cppのようなより広範な代替手段と、このワークロードをめぐって競合する。この報告は、グラフィックスメモリ容量がもはや重要ではないという一般論ではなく、そのアプローチを詳しく検討する根拠となる。
Qwen3.8 Basaltベンチマークはピークと持続速度を区別する
最も有用な生成速度は、コーディング中に毎秒153.0トークン、コンテキストスイープ中に154.9トークンと報告された平均値である。
トークンは、言語モデルが処理または生成するテキストの単位である。毎秒トークン数はスループットを測る指標だが、生成されたコードが動作するかどうかを直接測るものではない。平均出力とピーク出力を区別する投稿者の説明は、これらの結果を要約する際にも維持されるべきである。
RTX 5080 benchmarkでは、モデル構成をQwen3.8-Flash-Next IQ3_Sとしている。IQ3_Sは量子化形式であり、モデルの重みを低い数値精度で表現する。これは交換可能な細部ではなく、結果そのものを規定する構成要素である。
報告されたワークステーションは、RTX 5080にCore Ultra 9 285Kプロセッサと62GBのDDR5-6800メモリを組み合わせた。グラフィックスメモリ消費量は15.7GBに達した。エンジンはシステムメモリを54.1GB使用し、コーディング中には5.2GB、スイープ中には5.1GBが空いていたとされる。
コーディングセッションでは、コーディングエージェントのインターフェースであるopencodeを使い、103件のリクエストで約130,000トークンのコンテキストに到達した。コンテキストとは、モデルが応答を生成する際に利用できる情報である。ソースは構成上の容量を約262,000トークンと報告しており、これはコーディングセッションで観測された深さを上回る。
投稿者によれば、生成トークン全体とデコード時間でみた平均生成速度は毎秒153.0トークンだった。デコード時間は、出力トークンを生成する期間を指す。報告された毎秒262トークンのピークは、リクエスト全体やセッション全体ではなく、最も速かった1秒間を捉えたものだ。
別途行われたスイープでは、約15,000〜207,000トークンの新規プロンプトを使用した。生成速度の平均は毎秒154.9トークンに達し、ピークは186.6だった。投稿者は、384トークンの応答、サンプリング温度0.7、各深さで2回の実行という条件で、これらをリクエスト平均として説明している。
こうした定義により、誤解を招く解釈を避けられる。1秒間の最大値とリクエスト単位の平均値は、異なる観測結果を表す。どちらも毎秒トークン数を用いるからといって、一方が他方に置き換わるべきではない。
持続的な数値は、見出しだけが示す以上にこの報告を興味深いものにしている。コーディングのワークフローには、繰り返される対話でも一貫した応答が必要となる。短いバーストはシステムの特性把握には役立つが、開発者が最終的に体験するのは、完全なリクエスト、中断、ツール実行、修正である。
これらは依然として自己申告による測定値だ。利用可能な証拠は、投稿者が何を報告したかと測定カテゴリーを説明するにとどまる。別のワークステーションでも同じ結果が再現されることや、すべてのリクエストが集計平均を維持したことを確立するものではない。
キャッシュ再利用が応答時間の意味を変える
報告された中央値0.2秒の応答開始時間は、プロンプトトークンの99.5%をキャッシュから再利用したセッションにおける数値である。
プロンプトキャッシュは、以前の入力ですでに計算された情報を再利用し、同じ内容を再処理しない仕組みである。連続するリクエストが会話履歴、リポジトリ資料、指示を共有することが多いコーディングセッションでは、この挙動が重要になる。この作業を再利用できれば、継続中のセッションは大幅に応答性が高く感じられる可能性がある。
投稿者は、プロンプトトークンの99.5%がプロンプトキャッシュ由来だったと報告している。最初のトークンまでの時間の中央値は0.2秒だった。最初のトークンまでの時間は、回答を完了するまでの時間ではなく、出力が始まるまでの遅延を測る指標である。
これらを合わせて読むと、繰り返しの対話に適したワークロードを示している。しかし、エンジンがまったく未知の長大なリポジトリプロンプトを読み込み、同じ遅延で回答を始められることを示すものではない。新規リクエストは別途評価する必要がある。
ソースは、キャッシュされていない処理の測定値を通じて、この違いに一部対応している。コーディングセッションでは、プロンプト処理の平均は毎秒5,011トークン、ピークは5,118だった。投稿者によると、これらの数値は約10,700トークンと8,000トークンの新規トークンを含む、2回の大規模なキャッシュなし読み込みを表している。
プロンプト処理とは、回答を生成する前に入力を取り込むために必要な計算である。この段階ではモデルが異なる作業を行うため、そのスループットは生成スループットと異なる。両者を単一の速度主張にまとめると、読者が必要とする情報が隠れてしまう。
新規プロンプトのスイープでは、プロンプト処理スループットの平均は毎秒5,475トークン、ピークは5,662と報告された。これは入力処理について別の観測を提供する。エンジンの応答性を説明する際には、キャッシュ比率の高いコーディング結果と併せるべきだ。
開発者にとっての意味は、作業でコンテキストがどのように蓄積されるかに左右される。同じプロジェクトを繰り返し参照するアシスタントは、保持された計算から恩恵を受けられる。文書を頻繁に入れ替えたりリポジトリを変更したりするワークフローでは、異なる負荷が生じる。
たとえば、エージェントがプロジェクトを読み、編集案を提示し、コンパイラエラーを受け取り、パッチを修正する場合を考えてみよう。周辺情報の多くは、そのターンをまたいでも関連性を保つ。そのため、モデルの基礎的な生成速度が変わらなくても、キャッシュの挙動は体験に影響し得る。
一方で、一日を通して無関係な文書コレクションを開く分析担当者を考えてみる。繰り返される資料はそれほど多くないかもしれない。コーディングセッションの中央値の応答遅延をこのワークフローに当てはめるには、投稿にはない証拠が必要となる。
したがって、キャッシュは報告結果の実質的な一部である。ベンチマークを予測値として扱う前に、利用者が自身のリクエストパターンを確認すべき理由を説明している。決定的な問いは、アプリケーションが実際にどれだけの計算を再利用できるかだ。
システムメモリがワークステーションのトレードオフを支える
この構成は16GBのグラフィックスカードを基盤とするが、報告されたワークロードは54.1GBのシステムメモリにも依存している。
VRAMはグラフィックスプロセッサに接続されたメモリであり、システムRAMはコンピュータ全体で使用される。この報告では両方が使われている。結果をグラフィックスカードだけで説明すると、関与するマシンリソースを過小評価し、見込みユーザーにとっての実用上の制約を見えにくくする。
expert memory designでは、BasaltをNVIDIA Blackwellハードウェア向けのStrataフォークとして説明している。これは、計算において特化したモデル構成要素を選択するmixture-of-expertsモデルを実行する。グラフィックスメモリ容量を超えるエキスパートは、システムRAMに配置できる。
この設計は、この特定のベンチマークを独立して検証することなく、広範なアプローチを説明している。プロジェクトのドキュメントは、システムメモリの使用が意図的であることを確立している。Reddit上の測定値は、指定されたワークステーションにおける報告速度とメモリ消費量を示している。
実用上の圧力は、既存のマシンでローカルアシスタントを動かせるか判断する開発者にかかる。グラフィックスメモリ容量だけでは不完全な答えになる。利用可能なシステムメモリ、他のアプリケーション、ワークロードのコンテキスト要件も、同じ評価に含める必要がある。
報告された空きメモリの数値には特に注意すべきだ。コーディング中に5.2GBが空いていたことは不安定性を示すものではないが、そのテストマシンに余剰容量がほとんどないことを示している。エディタ、ブラウザ、ビルドプロセス、その他のローカルサービスは、さらなる需要を生む。
これは、同等のワークステーションがすべて通常の開発で失敗するという意味ではない。ベンチマークは快適なマルチタスクを保証できない、という意味である。推論エンジンを単独で動かした状態ではなく、実際の開発環境を稼働させた状態で測定する必要がある。
同じ考え方はグラフィックスメモリの測定値にも当てはまる。報告された15.7GBの使用量は、対象カードの16GB容量に近い。この観測からは、無関係なグラフィックス負荷や異なるエンジン設定のために十分な余裕があると想定すべきではない。
ここで、見出しの魅力と運用上のトレードオフが交わる。この報告は、利用可能なリソース全体にワークロードを収める割り当て戦略を説明している。控えめなグラフィックスメモリ予算の範囲内だけでモデルが動作していることを説明しているわけではない。
したがって、調達の判断はワークステーション全体から始めるべきである。対応するグラフィックスカードを、ほかの部分に制約のあるマシンへ追加しても、報告された環境は再現されない。メモリ容量を一致させても、プロセッサの挙動、ソフトウェア設定、持続的なスループットが再現されるとは限らない。
知識集約型アプリケーションでは、もう一つ考慮点がある。ソース資料を整理することとモデルを実行することは別の問題である。searchable knowledge baseは文書へのアクセスを扱う一方、このベンチマークは入力がエンジンに到達した後の計算を扱っている。
有用な結論は具体的だ。この構成を評価する開発者は、推論と周辺ツールの両方に必要なメモリを予算化すべきである。報告された速度はこの評価を行う価値を示しているが、システムメモリ要件は依然として結果の中心にある。
Strataとllama.cppには条件を揃えた比較が必要
このワークステーションの報告は、Basalt、Strata、llama.cpp間の統制された性能ランキングを確立するものではない。
タイトルではStrataとBasaltが併記されているが、提示されたワークロードの説明では、使用されたエンジンはBasaltとされている。読者はこの違いを維持すべきだ。フォークの結果が、親プロジェクトの性能主張に自動的に転化されるべきではない。
StrataはBasaltの系譜を示し、llama.cppはローカル推論におけるもう一つの関連する参照点を提供する。それらの存在は競争環境を示す。しかし、モデルファイル、設定、ハードウェア、リクエストシーケンスを揃えずに勝者を宣言する根拠にはならない。
inference benchmark documentationは、プロンプト処理とテキスト生成を分け、指定されたコンテキスト深度でのテストをサポートしている。また、繰り返し測定も記録する。これらのカテゴリーは、見出しのスループット数値を並べるだけでは比較に不十分である理由を示している。
対応の取れた比較であれば、エンジン間でもワークロードの同一性を保てるはずです。同じプロンプト、応答長、モデル表現、コンテキスト条件を比較の基盤とすべきです。そうでなければ、見かけ上のソフトウェア上の優位性には、セットアップ上の別の差異が含まれている可能性があります。
キャッシュ条件も同等に扱う必要があります。ウォーム状態のコーディングセッションと未知のプロンプトを比較すれば、後者は生成が始まる前から不利になります。どちらのシナリオも有用ですが、答える運用上の問いは異なるため、結果は分けて示すべきです。
エンジンに差異を帰属させる際は、ハードウェア構成も固定する必要があります。別のユーザーの高速なカードや大きなメモリ予算は、追加の変数を生みます。その情報は調査の手がかりにはなりますが、ソフトウェア単体の寄与を証明するものではありません。
出力の振る舞いにも別の複雑さがあります。投機的デコーディングでは、モデルが出力を受け入れる前に検証するドラフトトークンを使用します。この種の高速化を含む比較では、その設定を開示し、測定対象の構成でどの挙動が維持されているかを検証すべきです。
求められる基準は、正確な実行内容に関する透明性です。読者がモデルアーティファクト、ソフトウェアのリビジョン、構成、測定方法を特定できなければなりません。よく知られたモデル名であっても、数値表現や出力が同一である保証にはなりません。
ホスト型コーディングサービスを置き換えられるという主張にも、同じ注意が必要です。本レポートが測定しているのは、コーディングセッション中のローカル推論の挙動です。完了タスク、開発者の介入、サービスの信頼性、統合に要する労力について、ホスト型の代替手段と対応付けた評価は提示していません。
エンジン保守者にとって、競争圧力はより狭い意味で依然として現実的です。有望なワークステーションの報告は、ユーザーに特化実装を調べる理由を与えます。重要なのは、各エンジンがどこで優れた性能を示すかを再現可能な証拠で示すことです。
開発者にとっては、順位付けよりも候補の絞り込みの方が妥当です。報告された持続レートはインタラクティブな作業に関係するため、Basalt は対応ハードウェア上で試験する価値があります。Strata と llama.cpp も、同じ条件下での測定が必要な比較候補として残ります。
高速な生成はコーディング品質を立証しない
欠けているつながりはタスク性能です。このレポートは出力速度を測定しているものの、生成されたコードが問題をどれほど確実に解決するかは示していません。
コーディングセッションは、孤立したテキスト生成よりも認識しやすいワークロードを提供します。エージェントインターフェースが繰り返しリクエストを発行したことを示せます。しかし、リクエスト数だけでは、編集の成功、テストの通過、不要な再試行、人間による修正は分かりません。
この区別は、量子化において特に重要になります。数値精度を下げると、実行されるモデル表現が変化します。より高速またはより小規模な構成であっても、ユーザーが割り当てようとするタスクで評価する必要があります。
公開された量子化モデル評価は、テキストチャンクと高精度の参照を用いて限定的な品質証拠を提示しています。この比較はモデルの挙動を特徴付ける助けになります。しかし、リポジトリ修復の正確性、信頼できるツール利用、長いコンテキストでのコーディング成功を立証するものではありません。
長いコンテキストは、関連する検証上の空白を生みます。システムは長大なプロンプトを受け入れられても、関連するすべての詳細を確実に適用できるとは限りません。処理能力と、その入力内での検索精度は、同じユーザー体験に影響していても異なる性質です。
したがって、コンテキストスイープは限定的に解釈すべきです。異なる長さの新規プロンプトにわたるスループットを報告しています。モデルが埋もれた要件を一貫して見つけ出したか、矛盾する指示を調整したか、コード編集中にプロジェクトの制約を維持したかは示していません。
集計された生成レートからも、体験の分布は明らかになりません。平均はセッションを要約できますが、遅いリクエストを隠し得ます。難しい編集を待つ開発者にとっては、最良の瞬間的な速度よりも、そうした遅延の方が重要かもしれません。
同じ制約は、応答開始までの中央値にも当てはまります。中央値は中央の観測値を表します。最長の待機時間、キャッシュミス後の挙動、完全で利用可能なパッチを受け取るまでの時間を示すものではありません。
同時リクエストを意味するコンカレンシーも、もう一つの境界条件です。この概要ではコンカレンシーは1とされています。そのため結果は個別ストリームに関係しますが、チーム共有時の容量や、エージェントリクエストが重なった場合の性能を推定する根拠にはなりません。
こうした空白は、報告された成果を否定することなく解釈を形作るべきです。情報源は明示的な測定定義を提示し、ワークロードの種類を分けています。これらの詳細により、最大速度だけを示す説明のないスクリーンショットよりも、主張を評価しやすくなっています。
独立した再現では、既存のスループット分類にタスク結果を加えるべきです。有用なコーディング評価では、テストが通るか、変更が依頼を満たすか、人がどの程度介入するかを記録します。成功した実行だけを報告するのではなく、失敗も保持すべきです。
Qwen3.8 Basalt benchmark における未解決の問いは、報告された応答性が信頼できる作業を伴うかどうかです。対応するタスク証拠が現れるまでは、速度は実行に関する証拠であって、その構成がより優れたコーディングアシスタントを提供する証拠ではありません。
結果がどこまで広がるかを決める3つのシグナル
次に必要な証拠は、順に再現性、コーディングの信頼性、より不利な運用条件下での性能を確立するものです。
第1のシグナルは、同等の RTX 5080 ワークステーションでの独立した再現です。有用な公開には、正確なモデルアーティファクト、エンジンのリビジョン、構成、リクエスト順序、生のタイミング記録を含めるべきです。繰り返し実行により、キャッシュを多用するセッションと新規入力を区別する必要があります。
近い再現結果が得られれば、この構成が個人開発者にとって再現可能な選択肢を提供するという主張は強まります。大きな差が出た場合は、それをハードウェア、ソフトウェア、ワークロードに帰属させる前に調査が必要です。どちらの結果も、ユーザーが利用できる証拠を改善します。
再現では、元の測定上の区別を維持すべきです。セッション平均の生成速度、リクエスト平均の生成速度、1秒間のピークは分けて扱う必要があります。観測された最高バーストだけを一致させても、最も重要な持続性能の主張は未解決のままです。
第2のシグナルは、同じ量子化構成を用いたコーディング評価です。その価値は、別の生成速度チャートではなく、完了したタスクと記録された修正から生まれます。評価には、エージェントが実際に必要とするプロジェクトコンテキストを含めるべきです。
強いタスク結果が得られれば、このスループット報告はソフトウェア開発にとってより重要なものになります。生成が高速なままでも、失敗が頻発すれば魅力は限定されます。使えないパッチをより速く生成しても、タスクを完了するための作業は減りません。
第3のシグナルは、より広い運用条件下での性能です。関連する証拠には、不慣れな長いプロンプト、より長い出力、推論と並行して通常の開発アプリケーションを実行する状況、重複するリクエストが含まれます。各条件は、報告された体験がワークロードの変化に耐えられるかを検証します。
安定した挙動は、慎重に観察された個人セッションを超えてこの構成を利用する根拠を強めます。メモリ圧迫、待機時間の増加、出力の劣化は、その実用上の境界を示します。そうした境界は、エンジンを全面的に退けるのではなく、ユーザーがワークロードを選択する助けになります。
これらのシグナルはいずれも、リリース日を作り出したり、必然的な勝者を予測したりする必要はありません。保守者と独立ユーザーが今後数か月で公開できる、具体的な証拠の形です。現在の投稿は、その作業に向けた有用な出発点を提供しています。
より広い含意も具体的です。16GB のグラフィックスメモリを搭載したワークステーションが、大量のシステムメモリも使用することでインタラクティブな生成を持続したと報告されています。このことは、ローカル推論をグラフィックスメモリ容量だけで判断するのではなく、システム全体で評価する重要性を高めます。
セットアップを変更する前に、Qwen3.8 Basalt benchmark を自分の作業から得たセッションと比較してください。プロンプトを保持し、キャッシュが何を再利用するかを記録し、得られた編集が自分のチェックを通過するか確認してください。報告されたマシンには空きシステムメモリがほとんどなかったため、普段開いているアプリケーションも含めてください。応答開始までの遅延と完了までの時間は分け、持続出力同士を比較してください。判断は、自分の条件下で完了した有用な作業に基づくべきです。再現可能な実行は、正しい変更、許容できる待機時間、そして開発環境の残りの部分に十分な空きメモリを提供できるでしょうか。
