端側推論
smolperfbenchmark、エッジLLMのエネルギー効率ベンチマークを公開。ただしライブ・リーダーボードの結果は現在0件
新たなオープンソースのベンチマークスイートは、小型モデルをJetson、Mac、Raspberry Pi、Androidデバイスで動かし、データセンターGPUのスループットだけでなく、デコード速度、tokens/J、レイテンシ、温度を測定する。作者は約1,000通りのJetson構成をテスト済みとしているが、現在、公開リーダーボードにはデータが1件も読み込まれておらず、ユーザーは当面、リポジトリ内のレポートとraw artifactsを参照して結果を検証する必要がある。
smolperfbenchmarkは9月12日の公開後、LocalLLaMAで大きな注目を集めた。主流のモデル・リーダーボードが見落としてきたエッジ側の評価軸、すなわちモデルが4GB、8GB、16GBのメモリに収まるか、限られた冷却能力と電力のもとで実際にどれだけのtokenを生成できるかを補完することを掲げている。作者によると、初回データには13のモデルファミリーと、Jetson Orin Nano Super 8GBにおける約1,000通りの構成が含まれ、スループット、TTFT、ITL、エンドツーエンド・レイテンシ、消費電力、温度を網羅している。
単一のtok/sだけを公表するベンチマークとは異なり、このテストパイプラインではpromptとgenerationの長さを固定する。aiperf 0.11.0を使用し、同時実行数1で各組み合わせを通常約20回実行したうえで、レイテンシとスループットのp50を算出する。Jetsonのテストでは7W、15W、25W、またはMAXNモードに固定し、`tegrastats`を使って電力と温度の記録を時間的に対応付ける。スクリプトでは、同じGGUFを使用してllama.cppとOllamaを個別に実行できる。Mac向けのテストではllama.cpp MetalとMLX-LMを比較し、`powermetrics`でCPU、GPU、ANEの消費電力をサンプリングする。
この設計で重要なのは、output tok/Jをトップページに掲げている点だ。常時稼働するローカルエージェント、オフラインRAG、バッテリー駆動デバイスでは、最速のモデルが必ずしもエネルギー消費や冷却コストの最も低いモデルとは限らない。ただし、プロジェクト側もハードウェアごとにtok/Jの計算方法がまだ統一されていないことを明記している。JetsonとMacではデコード段階のエネルギーを使用する一方、Raspberry Piではテスト期間全体の平均消費電力から計算するため、デバイスをまたいだ直接的な順位付けはできない。
現時点で最大の問題は、公開状況と掲げられた内容が一致していないことだ。作者の投稿と集約ページには現在も13ファミリー、約1,000構成と記載されているが、確認時点でlive leaderboardは`0 families / 0 configs / 0 live`と表示されていた。GitHub READMEに実際に掲載されている完全なレポートも、主としてJetson上の135M～1.2Bの小型モデル8種とBonsaiシリーズに限られている。Mac、Raspberry Pi、Android、マルチノードMoEの大半は、依然として構築中または結果待ちの状態だ。
したがって現段階では、成熟したハードウェア購入ガイドというより、再現可能なベンチマーク基盤として捉える方が適切だ。エンジニアは各デバイスのフォルダにあるスクリプト、固定されたバージョン、raw artifactsを直接確認すべきである。今後の焦点は、リーダーボードのデータ復旧、品質指標の追加、そして同一モデルを異なるバックエンド、コンテキスト、冷却状態で実行した結果を第三者が再現できるかどうかにある。