プリフィル・TTFT・デコードは何が違うのか

回答が出る前に、モデルは何をしているのか

初めてローカルモデルを動かすと、この待ち時間をエラーだと感じるかもしれません。質問を送ったのに、画面には何も出てこないからです。同じ質問をもう一度送る前に、回答が出るまでに何が起きているのかを見てみましょう。

PDFを渡して、要約を頼んだとします。モデルはいきなり要約を書き始めるわけではありません。まず、質問と文書を処理する必要があります。この入力を処理する段階を、プリフィルと呼びます。

文書が長くなるほど、この段階の負担も増えます。短い質問にはすぐ答えていた機器が、長い議事録を渡すと、しばらく止まったように見えることがあります。回答がまだ見えなくても、モデルが休んでいるとは限りません。

最初のトークンまで10秒なら、プリフィルも10秒？

必ずしもそうではありません。リクエストを送ってから、最初のトークンが画面に届くまでの時間をTTFTといいます。プリフィル以外にも、リクエストの待機、入力のトークン化、実行の準備などが含まれる場合があります。

使う側にとっては、その全体が最初の待ち時間です。一方、プログラムに表示されるプリフィル時間は、そのうち入力処理だけを測った値かもしれません。画面によって数字が違うときは、どこからどこまでを測ったのかを先に確認してください。

回答が始まりました

最初のトークンに続いて回答を作っていく段階が、デコードです。性能表のdecode tok/sは、その間に1秒あたり何トークンを生成するかを表します。トークンと文字は同じ単位ではありませんが、同じモデル同士なら、数値が高いほど文章が速く続いていくと考えられます。

長文を書かせたり、大量のコードを出力させたりすると、この差を長く感じることになります。MTPなどの高速化も、主にこの段階を短くするための方法です。使えるかどうか、実際に速くなるかどうかは、モデルとランタイムの組み合わせで確認する必要があります。

同じ文書について再び質問すると、なぜ速くなるのか

初回は長く待ったのに、同じ文書でもう一度質問すると、すぐに回答が始まることがあります。入力の前半が同じ場合に、以前の計算結果を再利用するプロンプトキャッシュが働いた可能性があります。

その結果を、キャッシュなしで初めて実行した別の機器と比べるのは公平ではありません。初めて文書を読ませる場面なのか、同じ文書について繰り返し質問する場面なのかを決めて、両方の条件をそろえましょう。

長い入力からトークンを選び、処理量を減らすSpecPrefillもありますが、キャッシュとは別の仕組みです。最初の回答が速くなったという結果だけで、同じ機能だと考えないようにしてください。

だから、どの数字を確認すればよいでしょうか？

長い文書から短い要約を得たいなら、まず最初のトークンまでの時間を見てください。短い指示で長い回答を作るなら、デコード速度も重要です。どちらの場合も、作業が終わるまでの総時間を併せて見ると判断しやすくなります。

比較画面でプリフィルを含む結果を見たら、次はトークン生成だけを比べてみてください。最初の待ち時間が長いのか、回答を書き進める速度が遅いのか。その違いによって、機器に求める性能も変わります。

速い機器を探す前に、もどかしく感じた瞬間を思い出してみてください。文書を入れても何も出てこなかったときでしょうか。それとも、回答が始まってからも、終わるまで長く待ったときでしょうか。その違いを言葉にできれば、漠然と「もっといいPC」を探す代わりに、自分に必要な性能を探せるようになります。