LlmspeedローカルLLMベンチマーク、ハードウェア速度を可視化するも推定値は最終判断ではない

Llmspeedは、根強く残る一つの指標を可視化するローカルLLMベンチマークシミュレーターを公開した。選択したモデルとマシンで、応答をどれほど待たされる可能性があるかという指標だ。別のスプレッドシートを提示する代わりに、予測した速度でサンプル回答をストリーミング表示する。最初のトークンが現れるまでの待機時間もシミュレートする。

このプロジェクトは、ローカルAI向けの購入者が極めて複雑な選択に直面する中で登場した。モデルがメモリに収まっても、長いプロンプトでは遅く感じられることがある。別のモデルはテキストを高速に生成できても、エージェントが数千トークンのコードを読み込むとその優位性を失う可能性がある。

これがLlmspeedローカルLLMベンチマークを巡る中心的な緊張関係を生む。散在するフォーラム投稿より明確な出発点を提供する一方、その親しみやすいシミュレーションは、基礎となる証拠が許容する以上に決定的に見える場合がある。Hacker Newsでの反応は、この違いを巡る公開ストレステストへと急速に発展した。

Llmspeedはベンチマーク数値を待機体験へ変える

Llmspeedの有用な発想は、新たな性能指標ではない。ハードウェアを入手する前に、馴染みのある指標をより直感的に体験する手段である。

ライブシミュレーターでは、ハードウェア、モデル、量子化レベルを選択する。量子化はモデル重みの数値精度を下げる処理で、通常は出力品質をある程度犠牲にしてメモリ使用量を抑える。

続いてLlmspeedは、推定した生成速度を用いたシミュレーション応答を表示する。また、ストリーミング出力が始まる前の遅延を測るtime to first token、すなわちTTFTも含まれる。プロンプトに大きな文書やコードベースが含まれる場合、この遅延は生の生成速度以上に重要になり得る。

レースモードでは、二つの構成を並べて表示する。これにより比較は抽象的な毎秒トークン数の数値から、製品デモに近いものへ変わる。一方の構成が応答を始める一方で、もう一方がまだプロンプトを処理中である様子を確認できる。

現在サイトでは、15モデルにわたり30種のGPU、Mac、CPU構成をサポートするとしている。リストはCUDA、Metal、ROCm、Vulkan、CPUバックエンドにまたがる。利用可能なハードウェアには、コンシューマー向けグラフィックスカード、Apple Siliconシステム、ワークステーション向けデバイス、クラウドアクセラレーターが含まれる。

モデル一覧には、高密度モデルとmixture-of-experts、すなわちMoEアーキテクチャが含まれる。MoEモデルは各トークンについて、総パラメータ集合の一部だけを有効化する。この設計は生成速度を高められる一方、モデル全体では依然として大容量のメモリを必要とする場合がある。

メモリに収まるかどうかも、インターフェースの重要な要素だ。Llmspeedは、モデルが選択したデバイスに完全に収まるか、一部をシステムメモリにオフロードする必要があるか、あるいはそのモデル化した前提では実行できないかを推定する。

この区別は重要である。「実行できる」と「ビデオメモリ内で完全に実行できる」は異なる主張だからだ。llama.cppのようなツールは、モデルレイヤーをグラフィックスプロセッサとシステムメモリに分割できる。その構成は動作する可能性があるが、速度は分割方法とコンポーネント間の帯域幅に左右される。

Llmspeedの公開済み方法論では、結果を三つの信頼度カテゴリに分けている。「Measured」は同一のハードウェア、モデル、量子化による結果を表す。「Derived」は類似する測定結果から補間し、「projected」は直接結果のない構成にハードウェア仕様を用いる。

このラベリングは責任ある設計上の選択だ。洗練されたアニメーションであっても、推定値に基づく可能性があることを利用者に伝える。重要なのは、利用者が出力を購入予測として扱う前にラベルに気付くかどうかである。

このプロジェクトは2026年10月18日、Show HNへの投稿を通じて注目を集めた。10月20日までに議論はニュースフィードに記録された初期の数を大きく上回った。この伸びは、ローカルAI利用者が繰り返し直面する問題への本物の関心を反映していた。

この結果は、対話型の計画支援ツールとして理解するのが最適だ。購入検討者と開発者に、可能な構成を比較する共通言語を与える。実際に実行する予定のワークロードをテストする代わりにはならない。

ローカルLLMハードウェア比較がこれほど難しくなった理由

ハードウェアは一つの変数にすぎず、同じマシンが遅く、許容範囲内、あるいは驚くほど高速に感じられるかどうかは、ソフトウェアスタックがますます左右している。

ローカルモデルの目に見える応答には、少なくとも二つの性能フェーズがある。しばしばprefillと呼ばれるプロンプト処理は、入力を読み込み、モデルの内部状態を準備する。decodeはその後、出力トークンを一つずつ生成する。

これらのフェーズでは、ハードウェアへの負荷が異なる。Llmspeedは、アクティブな重みを繰り返し参照する必要があるため、生成は主にメモリ帯域幅に制約されるとモデル化する。プロンプト処理は、より計算スループットに依存すると見なしている。

この単純化した区分は、有用な出発点となる。しかし実際の推論エンジンには、キャッシュ、バッチ処理、投機的デコーディング、カーネル最適化、アーキテクチャ固有のパスが加わる。どの最適化も、ハードウェアのラベルを変えずに観測結果を変え得る。

このプロジェクトは、収集したベンチマークとバックエンド効率係数を使って推定値を調整する。コンテキストが長くなるにつれて減速も適用する。部分オフロードについては、GPU常駐の重みとシステムメモリ内の重みを、それぞれ異なる実効帯域幅でモデル化している。

メモリ推定には、モデル重み、key-valueキャッシュ、ランタイムオーバーヘッドが含まれる。key-valueキャッシュは過去のトークンからの注意データを保存し、モデルが生成中にすべてを再計算しないようにする。

Llmspeedによれば、計算ではMacのユニファイドメモリのおよそ75％、ディスクリートGPUメモリの93％を、モデル化したワークロード用に確保している。これらは実用的な仮定であり、普遍的な動作上限ではない。

ほかのアプリケーション、ディスプレイ、ドライバー、推論設定は、利用可能なメモリを変え得る。長いコンテキストはkey-valueキャッシュを拡大する。並列リクエストはメモリ負荷を増幅させるか、推論サーバーにリソースの分割を強いる場合がある。

このプロジェクトは、llama.cppに含まれる確立済みのベンチマークハーネスを使った測定結果の提供を求めている。推奨コマンドでは、512トークンのプロンプトを使い、128トークンを生成する。

これにより結果は比較しやすくなるが、同時に狭いワークロードを定義することにもなる。短いベンチマークでは、大規模なリポジトリを読み込み、ツールを呼び出し、長い会話を維持するエージェントを十分に表現できない。

llama-benchのドキュメントは、別の重要な条件も付け加えている。その測定値にはトークン化とサンプリングの時間が含まれない。これらを除外することはモデルスループットを分離するうえで合理的だが、利用者はアプリケーション全体の経路を体験する。

コーディングアシスタントには、プロンプト構築、リポジトリ検索、ツール出力、ネットワークサービス、インターフェースの遅延も含まれる。ベンチマークは推論を正しく測定しつつも、完全な操作体験の予測には失敗する可能性がある。

これが、LlmspeedローカルLLMベンチマークが従来型のハードウェアレビューに圧力をかける理由だ。単一のピークスループットスコアでは、購入者が実際に抱く疑問に答えられなくなっている。利用者が知りたいのは、特定のタスクでモデルがどのように感じられるかである。

従来のベンチマークスイートは別の問題を解決する。MLPerf Inferenceは、定義されたシステムとシナリオにおける標準化可能かつ再現可能な比較を重視する。Llmspeedは、コンシューマーの選択肢全体でのアクセシビリティと体感応答性を重視する。

どちらのアプローチも、もう一方を不要にはしない。標準化されたスイートはより強い統制を提供し、対話型シミュレーターは利用者のレイテンシー解釈を助ける。手軽な推定値が実験室レベルの検証と誤認されるときに、隔たりが生じる。

この隔たりは、ソフトウェアの変化が大半のハードウェアレビューサイクルより速いため拡大している。新しいバックエンドのリリースは、カーネル、キャッシュ、モデルオフロードを改善し得る。以前は魅力が乏しかったデバイスも、物理的なアップグレードなしに実用的になる可能性がある。

モデルアーキテクチャも比較を複雑にする。総パラメータ数が似ている二つのモデルでも、トークンごとに有効化するパラメータ数は大きく異なり得る。メモリ要件、速度、出力品質は大幅に乖離する場合がある。

量子化は別のトレードオフをもたらす。低ビット重みはメモリ使用量を減らし、速度を高める場合があるが、品質への影響はモデルとタスクによって異なる。最も高いトークンレートの構成が、より多くの修正を必要とする結果を生む可能性もある。

したがってローカルLLMハードウェアの比較には、GPU名とモデル名だけでは不十分だ。エンジンのバージョン、バックエンド、量子化、コンテキスト長、キャッシュ形式、オフロード計画、ワークロードの説明が必要になる。

Llmspeedは、これらの次元のいくつかを表面化させている。その人気は、利用者がそれらを比較できる一つの場所をどれほど強く求めているかを示す。その批判者たちは、それらを一つの体験に圧縮することが依然として難しい理由を示している。

LlmspeedローカルLLMベンチマークは実際のワークロードに直面する

最も鋭い批判は、Llmspeedが推定値を用いることではない。短時間かつ単一デバイスの推定では、本格的な利用者が実際に展開する構成を見落としかねないことだ。

ローンチ時の議論では、二つの反応が同時に生じた。一部の利用者は、複数のモデルバリアントをダウンロードせずにシステムを比較できる手段を歓迎した。一方で、シミュレーターと自分たちの実運用構成の間に大きな差があると報告する利用者もいた。

複数のコメント投稿者は、従来の適合チェックでは対象外とされそうな古い、あるいは小規模なグラフィックスカードでモデルを動かしていると説明した。これらの構成では、積極的な量子化、CPUオフロード、特化型フォーク、または新しい推論技術が用いられていた。

これらの報告は逸話的であり、統制された反証ベンチマークを確立するものではない。それでも、静的な推定器に共通する基本的な弱点を明らかにしている。ローカル推論には、シミュレーターが表現していない組み合わせを含め、多くの有効な構成がある。

Llmspeedは、単一デバイス対応を制約として明示している。複数のグラフィックスプロセッサ間でのテンソル分割やレイヤー分割は、まだシミュレートしていない。制作者は、マルチGPU対応には十分な信頼できる測定値の取得が必要だと述べた。

この制約が重要なのは、より大規模なモデルを動かす愛好家の間でマルチGPUシステムが一般的だからだ。インターコネクト、PCIe世代、分割戦略、メモリレイアウトはいずれも性能を変え得る。

ハイブリッド推論も同様の課題を生む。GPUメモリを超えるモデルでは、レイヤーの一部をシステムメモリに配置できる。モデルがGPUに収まらないと言うのは正確だが、実行できないと言うのは誤解を招く。

Hacker Newsのある利用者は、まさにこの違いを指摘した。選択したモデルはデバイスのビデオメモリを超えていたが、llama.cppはレイヤーをオフロードして実行できた。体験は遅くなるものの、不可能ではなかった。

意見の食い違いを生む別の要因は、投機的デコーディングだった。この技術では、より小さなドラフトプロセスまたは別の予測手法がトークンを提案する。メインモデルはその後、複数の候補をまとめて検証し、目に見える生成速度を高める可能性がある。

投機的デコーディングによる結果は、通常のdecode測定値と直接比較できない。受理率、モデルの互換性、ドラフト設定、生成するテキストの種類に依存するためだ。

一部のコメント投稿者は、コンテキスト長も強調した。短いプロンプトでは印象的なdecode数値が出る可能性がある一方、大規模なコーディングコンテキストではスループットが低下し、長いprefill遅延が生じることがある。

ある実務家は、数万トークンに達するプロンプトを用いる本番ワークロードを説明した。報告された体験では、実際のdecodeスループットは短いコンテキストのベンチマーク結果を大きく下回る可能性があった。

その観察は、正確な遅延幅こそ異なるものの、より広い技術的メカニズムと一致する。長いコンテキストはより多くのキャッシュメモリを消費し、アテンション処理を増加させる。また、異なるオフロード判断を強いる場合もある。

並列作業はさらに別の複雑さを加える。キャッシュ済みコンテキストを持つ単一のチャットと、複数のエージェントが同時に動作する状況は同じではない。全体のスループットは増加しても、各ユーザーが受け取るトークンは遅くなる可能性がある。

個人向けチャットインターフェース用のハードウェアを選ぶ開発者なら、このトレードオフを受け入れるかもしれない。多くのエンジニアにサービスを提供するチームには、並行性の計測、テールレイテンシ、キャッシュ挙動、リソース分離が必要となる。

品質はLlmspeedの主な約束の対象外である。このシミュレーターは、準備された応答がどの程度の速さで表示されるかを示す。より高速な量子化モデルが、コーディング、推論、検索のタスクを正しく解決すると主張しているわけではない。

この違いは購入判断に反映すべきだ。高速に生成する小規模モデルでも、ユーザーがプロンプトを再試行したり、誤った出力を修正したりする必要があれば、全体ではより時間がかかる可能性がある。

同じことはエージェントのワークフローにも当てはまる。エージェントはツール結果の処理やコンテキストの再構築に大半の時間を費やすかもしれない。デコード速度だけでは、タスク全体がより早く完了するかどうかを明らかにできない。

Llmspeedは、ドライバー、エンジンのバージョン、flash attention、電力制限、熱の影響により、実際の結果が10〜30%変動し得ると認めている。コミュニティの報告によれば、最適化された特殊なケースでは、さらに大きく乖離する可能性がある。

だからといって、このシミュレーターが役に立たないわけではない。むしろ、それが価値を発揮する境界を定義している。Llmspeedは、明らかに不適合な構成を除外したり、大まかな性能クラスを比較したりする際に最も力を発揮する。

調整済みの本番ワークロードに対する調達レベルの予測が必要な場合には、最も力を発揮しない。その段階では、シミュレーターはテストへの入口であるべきであり、テストの代替ではない。

より良い購入判断の問いは、どのワークロードが高速に感じられる必要があるか

有用なハードウェア判断は、比較ページで最高のトークン数を見ることではなく、応答性を保たなければならない操作から始まる。

通常のチャットでは、生成速度は即座に感情的な重みを持つ。出力が遅いと会話のリズムが崩れる。快適な読書速度で安定して流れる出力のほうが、極端なピークスループットより重要な場合がある。

文書分析では、注目点がプリフィルに移る。有用な応答を生成する前に、システムはプロンプトを取り込まなければならない。長いレポートや技術仕様書では、TTFTが支配的な遅延になることがある。

コーディングエージェントは、より厳しいプロファイルを生み出す。リポジトリマップ、ソースファイル、ツール指示、テスト出力、過去の判断を読み込むことがある。そのコンテキストは最終回答を大きく上回る可能性がある。

こうしたワークフローは、推論とツール実行を交互に行う。ローカルモデルは高速に生成しても、その後にビルド、検索、テストスイートを待つ可能性がある。エンドツーエンドのタスク時間は、デコード速度より有益な指標となる。

ナレッジワークにはもう一層の要素が加わる。最適なローカル構成は、アプリケーションがモデルへのプロンプト前に関連資料をどれほど効率的に取得できるかに左右されることがある。検索性能が向上すれば、コンテキストサイズを減らし、レイテンシと回答の焦点の両方を改善できる。

開発者は検索可能なナレッジベースを利用して、モデルに渡す資料を絞り込める。これにより不要なプロンプト処理を減らせるが、効果は検索システムとタスクに依存する。

ハードウェアが遅くても、プライバシーはローカル推論を正当化する理由になり得る。機密文書は、アプリケーションの設計とセキュリティ設定に従って管理されたマシン内にとどまる。

可用性も別の理由となる。ローカルアシスタントは、リモートサービスに依存せずに作業を継続できる。ただしその場合、ユーザーは更新、ストレージ、モデル選択、システム保守の責任を負う。

したがって、適切な評価では代表的なプロンプトを定義すべきである。開発者なら、複数のファイル、ビルドログ、リファクタリング要求を選ぶかもしれない。研究者なら、固定の質問セットを伴うレポートを使用するかもしれない。

テストでは、最初のトークンまでの時間、生成速度、総タスク時間、ピークメモリ、出力の有用性を記録すべきだ。コールドスタート後に繰り返せば、モデル読み込みとキャッシュの影響を明らかにできる。

比較中はエンジンの詳細を固定しなければならない。あるランタイムから別のランタイムへ変更すると、カーネル、対応する量子化、デバイス利用率が変わり得る。そうでなければ、このテストは2つのプロセッサではなく、2つのソフトウェアスタックを比較することになる。

コンテキスト長も想定するワークロードに合わせる必要がある。512プロンプトトークンでテストされたシステムから、定期的に64,000トークンを処理するエージェントについて結論を導くことはできない。

ユーザーは、余裕を持って収まる量子化を少なくとも1つ、利用可能なメモリを限界まで使う量子化を1つテストすべきだ。これにより、高精度化による結果の改善が、速度低下やコンテキスト容量の縮小を正当化するほどかどうかが分かる。

ノートPCやコンパクトなシステムでは、熱挙動にも注意が必要だ。短時間の実行では、持続的な発熱が性能を変える前に完了してしまう可能性がある。より長いテストは、短いベンチマークでは見落とされるスロットリングを明らかにできる。

並行性は、予想されるユーザーまたはエージェントの数に合わせるべきだ。個人用ワークステーションに必要な証拠は、開発チームを支える社内サービスに必要なものとは異なる。

Llmspeedは候補リストを絞り込むことで、このプロセスを導ける。その視覚的なシミュレーションは、重要となるほど大きな差をユーザーが見極める助けとなる。また、購入者がデコードだけに注目する前に、TTFTとメモリ適合性を提示する。

シミュレーターだけで最終選択を決めるべきではない。判断に運用上の影響がある場合、同等のハードウェアを借用またはレンタルして管理されたテストを行うほうが依然として信頼できる。

より大きな教訓は、このプロジェクトを超えて当てはまる。コンシューマー向けAIハードウェアには、ワークロード中心の評価が必要である。ピーク時の毎秒トークン数は比較しやすいが、実際のタスクが応答性よく感じられるかを表してはいない。

Llmspeedは、ユーザーをコンポーネント仕様から体感レイテンシへと移行させるときに成功する。その推定値に、より豊かなワークロードと明確な不確実性が取り込まれるほど、役立つものになるだろう。

Llmspeedが信頼される参照先になるかを示す3つのシグナル

Llmspeedの次の段階は、より優れた証拠の網羅性、複雑なシステムへの対応、実際のユーザーワークロードに対する可視的な検証にかかっている。

第一のシグナルは、ベンチマークの出所である。各結果について、ソース、エンジンのバージョン、量子化、プロンプト長、信頼度カテゴリを容易に確認できるべきだ。

リポジトリはすでに、これらのフィールドを含む提出を受け付けている。計測済みデータセットを拡大すれば、補間やハードウェア予測への依存を減らせる。

これは特に、人気のあるハードウェアとモデルの組み合わせで重要となる。直接計測された結果は近い推定値の基準となり、複数の独立した実行は通常のばらつきを明らかにできる。

第二のシグナルは、長いコンテキストと最適化された推論への対応である。ユーザーは、コンテキスト長、キャッシュ精度、投機的デコード、関連するエンジン機能のためのコントロールを求めている。

考え得るすべてのスイッチを追加すれば、インターフェースは使いにくくなる。実用的な設計としては、チャット、文書分析、エージェント型コーディング向けの明確なプリセットを提供できる。

各プリセットは、その前提を開示すべきである。そうすればユーザーは、同じハードウェアでもワークロードごとに異なるTTFTと生成推定値が出る理由を理解できる。

マルチGPUおよびハイブリッドシステムも、この第二のシグナルに含まれる。トポロジーと分割戦略が重要になるため、技術的なモデル化はより難しい。限定的な対応でも、この議論で明らかになった大きなギャップに対処できる。

第三のシグナルは、外部検証である。Llmspeedには、管理された構成全体で予測性能と観測性能を繰り返し比較する必要がある。

検証ビューでは、予測値、提出された計測値、誤差範囲、関連するソフトウェアバージョンを表示できる。そうすれば、不一致は孤立したコメントではなくデータとなる。

このプロジェクトのオープンソース構造により、それは可能になる。ベンチマークデータと計算は検査、検証、改善の対象となり、公開の貢献を通じて改良できる。

しかし、オープンであることが自動的に正確さを保証するわけではない。プロジェクトには依然として、一貫した提出基準、重複処理、異例のチューニングを識別する方法が必要だ。

コミュニティベンチマークは、積極的に最適化する愛好家に有利になりがちである。デフォルトのインストールでは異なる性能になる可能性がある。インターフェースが両者を区別していれば、どちらの結果も有用である。

ユーザーは、エントリーがどれほど早く古くなるかにも注意すべきだ。ドライバー更新、新しいカーネル、モデル改訂、推論エンジンのリリースは性能を変え得る。タイムスタンプ付きの結果は、時代を超えた数字として提示される値より有益である。

Llmspeedが計測済みの網羅性を拡大すれば、その信頼度ラベルはより意味のあるものになる。長いコンテキスト向けプリセットが追加されれば、シミュレーターは現代のエージェントワークロードをよりよく反映するだろう。

予測が一貫して実測値に追随すれば、このツールはハードウェア調査における信頼できる最初の立ち寄り先になり得る。大きな説明不能の差が残るなら、頼れる予測ではなく、魅力的なデモンストレーションのままとなる。

現在のLlmspeedローカルLLMベンチマークは、すでに重要な考え方を1つ明確にしている。レイテンシは単なるグラフの行ではなく、体験である。そのアニメーションは、ユーザーがマシンを選ぶ前に待ち時間のコストを可視化する。

残る課題は、シミュレーションを直感的であるのと同じくらい透明にすることだ。購入者はこれを使って候補を絞り、信頼度ラベルを確認し、自身の代表的なワークロードをテストすべきである。

ローカルAIハードウェアを選ぶ前に、どの遅延が実際に作業を中断させるかを問うべきだ。次に、生成速度とともにTTFT、長いコンテキストでの挙動、メモリ適合性、出力品質を比較する。このプロセスは、どの単一のリーダーボードよりも長く価値を保ち、Llmspeedの推定値が完了すべき作業と合致するかを明らかにする。