長い入力ではローカルLLMの速度順位が逆転する

何を早く終えたいですか？

たとえば、退社後、長い会議録を整理しようと機器を調べている状況を考えてみましょう。昼間は時間がないため、延期していた作業です。文書から決定された内容とまだ残っている作業だけを抽出してあげればよいです。長い回答は必要ありません。明日の朝に再読するだけの数段落があれば十分です。

そのとき必要なのは、画面に文字が最も速く流れ出るコンピュータでしょうか？それとも、ドキュメントをいれて数分も経たないうちに必要な整理を提示するコンピュータでしょうか？見た目は似ていますが、機器を比較する際には別の質問です。

パフォーマンスデータには、処理する会議録や、明日の朝までに整理しなければならない事情も記載されていません。与えられた条件に基づいて測定された数字だけが記されています。その数字を自分の状況に合わせて読み解く作業はまだ残っています。高価な選択をする前に、この差をまず確認してみましょう。

まず簡単な質問を送ります

この記事のAおよびBは、原理を説明するための仮想設備です。特定製品の実測値ではありません。同じモデルで同じ質問に対して約300トークンの回答を生成すると仮定します。

Aは最初のトークンまで4秒を待ってから、秒間60トークンを生成します。回答を継続して生成するのに約5秒かかり、全体で約9秒です。Bは最初のトークンまで6秒を要し、その後は秒間30トークンで生成されるため、全体で約16秒です。

この条件下ではAが最初に終了します。トークン生成速度が2倍であっても、全体の時間は正確に半分とは限りません。回答前の待ち時間があるためです。

ここでは60 tok/sと30 tok/sは、回答が開始された後の生成速度、すなわちデコード速度です。最初のトークまでにかかった時間は別に加算しています。計算は理解を助けるために丸められた近似値です。表でよく見られる大きな数字ではなく、ユーザーが待ち始めた時点で待ち時間の総計を測定したものです。

短い質問の代わりに、長い文書を入れたら？

今回は、2台のデバイスに同じ長いドキュメントを投入し、回答長は先ほどと同じように約300トークンに合わせてみます。ドキュメント処理後の結果として、Aの最初のトークンが40秒後に、Bの最初のトークンが10秒後に出現すると仮定します。回答開始後の速度はそのままです。

Aは約40秒待機してから5秒間回答するため、合計45秒かかります。Bは10秒待機してから10秒間回答するため、合計20秒です。トークンの処理速度は依然としてAが速いものの、処理はBが先に終了しました。

機器のパフォーマンスが急に変わったわけではないです。私たちが求めたことの内容が変わったのです。短い質問では明らかに見えなかった入力処理時間は、長いドキュメントでは大きな比重を占めます。

長い入力の処理を「プリフィル」といいます。最初のトークンまでの時間では、このステップ以外にもリクエストの待ちや実行準備が含まれる可能性があります。ここではその時間をすべて合計して比較しています。実際の設備においても、常にBが有利だという話ではなく、同じデコード順位だけでは他のタスクの結果まで把握することはできません。

それならば、最初のトークンが速いデバイスがより良いでしょうか？

今回は回答の長さを確認しなければなりません。ドキュメントから日付の一つだけを抽出する場合、回答が短くなるため、最初のトークンまでの待ち時間は重要です。逆に、長めの案を書くように要求されれば、回答を継続して書く時間も増加します。

つまり、最初のトークンかデコードのどちらかを選べば、同じ問題が繰り返されます。私は頻繁に使う入力の長さと望む回答の長さを一緒に調整しなければなりません。前記の仮想例を別の長さに変更すると、違いが現れます。

キャッシュも確認すべきです。既に読み込んだドキュメントの再使用結果と初めて読み込むドキュメントの結果を混ぜてしまうと、機器の差異とキャッシュ効果を区別することが難しくなります。

待てる時間は、作業によって違う

夜に数十件のドキュメントを担当して、朝に結果を受け取るなら、1つのリクエストが数秒遅れて開始されるのは大きな問題とは限りません。全体の作業がタイムリーに終了し、途中で失敗しないことの方が重要です。

一方で、コードをわずかに修正してほしいと尋ね、結果を見てから再度質問する作業は異なります。回答を待つ間、次の判断も停止します。一度の待機よりも、その待機を1日で何回も繰り返すかが、機器選定により大きな影響を与える可能性があります。

そのように、誰にでも共通の合格基準を数秒で定めるのは難しいです。読みながら追うには十分な速度であるものの、長い結果をコピーして使う人には遅く感じられる可能性があります。自分が「まあ、問題ない」と感じるポイントをまず把握して初めて、パフォーマンスデータの差にどの程度の余裕を加えるかを判断できます。

ちょっとした興味から触れてみるツールと、次の日にも再開できるツールは異なる可能性があります。購入前に確認したいのは、初日の感動だけではなく、繰り返し使用するときにも耐えられる待ち時間かどうかです。

自分の作業で、二通りの比較をしてみる

まず、短い質問でトークン生成速度だけを比較します。次に、通常入れるドキュメントに近い長さに変更し、プリフィルを含めて再び確認します。両結果で、同じデバイスが優位であるかを確認してください。

このサイトの比較画面では、入力長およびプリフィルの有無を変更できます。表示されているのは予想される体験時間であり、実際の実行記録とは区別すべきですが、回答までの待ち時間も含めた場合の選択の違いを確認できます。

デバイスを選定时必要な質問は「どちらの側がより高いtok/sを達成するか」にとどまらず、「自分が頻繁に要求するタスクをどちらがより速く処理できるか」まで考える必要があります。

2倍速いからといって、2倍の予算が必要とは限らない

いまは最初の速度データに戻ってみましょう。Aが1秒あたり60トークン、Bが30トークンであることは誤りではありませんでした。ただ、会議要綱を整理しようとしている人にとって、その事実だけでは購入判断に至るには不十分でした。

そのドキュメントを挿入するまでの待ち時間までを比較したところ、安い方で十分な処理が可能である可能性もあります。逆に、毎回長い回答を最後まで待つ必要がある場合、より速い方へのコストをかける理由は明らかになります。重要なのは、どの結論が導かれたとしても、自分が担当していることであるということです。

回答の内容も取り落とさないでください。迅速に生成される要約が重要な決定を漏らす場合、元の文章を再読しなければなりません。速度を比較する際には同じモデルを使用する理由であり、デバイスを決定する前にそのモデルが自分のドキュメントを適切に扱えるかを確認しなければなりません。

最初にやりたかったことは、最も大きな数を持つことではなく、未処理の会議録を整理することでした。その仕事を十分に終えることができれば、より高価な設備を購入する必要はなくなります。逆に、現在所有している設備でブレーキがかかる部分を特定できた場合には、そのときにはどのような改善のためにお金をかけるべきかを理解できます。

2台の設備を選択し、同じドキュメントを処理する状況で比較してみましょう。結果が予想以上に似ている場合も、それは役に立ちます。残った予算を性能データの次の欄に必ず書く必要はありません。