最初の出力までに、どれくらい時間がかかる？〜ローカルLLMの最初の待ち時間を測定してみた

2026年9月15日

ローカルLLMの「待ち時間」を測った記事を、以前記載しました。

その時は、プロンプトの長さを変えたら、最初の一文字が出るまでの時間はどう伸びるのか、という測定ができていなかったので、今回その宿題に取りかかってみました。結果、速度を決めている部分は、思っていたのと違う場所にありました。今回は、その測定内容を記載します。

2026年8月時点の実測です。

前回の記事はこちら

測定に使った環境

本体	GMKtec EVO-X2（Ryzen AI Max+ 395 / ユニファイドメモリ128GB）
モデル	gpt-oss:120b（65GB・常駐させたまま）
推論エンジン	Ollama 0.30.10
使い方	コーディング補助のエージェントを、このローカルLLMに繋いだ
OS	Ubuntu

最初の出力の時間が予想の100倍以上？

これまで私が測ってきた数字では、モデルを載せたまま短い質問を投げると、最初の一文字までは0.29秒で出ます。5回測った中央値で、ぶれも小さい値でした。

ところが、同じ機械の同じモデルに、エージェント経由で「このファイルを読んで」と頼んだときの数字がこれです。

投げ方	最初の一文字まで
短い質問（これまでの測り方）	0.29秒
エージェント経由で、ファイルを1つ読ませる	36.7秒

126倍です。ここで私は「エージェントは毎回これだけ待たされるのか」と結論を出しかけました。

待たされるのは毎回なのか

やり取りを続けて測り直すと、様子が変わります。

	最初の一文字まで
1回目（立ち上がり）	36.8秒
2回目以降	2〜3秒

4往復させたとき、全体で46.7秒。うち36.8秒が1往復目で、残り3往復は1回あたり3.3秒でした。

37秒は毎回かかる費用ではなく、立ち上がりに一度だけ払う費用でした。

その37秒は何に使われていたのか

文章を生成する前に、AIは送られてきた文章を読む工程を通ります。プレフィル（prefill）と呼ばれる部分です。人間でいえば、質問文に目を通してから答えを考え始めるようなものです。

驚いたのは、こちらが打ったのが一行の指示だったことです。それでも入力は33,000トークンありました。

内訳は、こういうものです。

• エージェント自身の指示書（どう振る舞うか、何を守るか）
• 使える道具の一覧（ファイルを読む、書く、検索する…といった定義）
• そのうえで、こちらが打った一行

ユーザーが打つ文の長さは、送られる量のごく一部でしかありません。大半は道具立ての説明です。

読む速さは手元の実測でこうなっていました。トークンというのは文章を細かく区切った単位で、日本語ならだいたい1文字が1〜2トークンです。

入力の長さ	読む速さ	読み終わるまで
約4,000トークン	1,219〜1,651 tok/s	2.4〜3.3秒
約33,000トークン	約900 tok/s	約37秒

入力が8倍になると、待ち時間は11倍以上に伸びています。読む速さ自体も、長くなるほど落ちていました。

ただ、この読み込みは一度済めば覚えていてくれます。2往復目からは、増えたぶんだけを読み足せばよいので2〜3秒で済みます。

実際に使っていて遅いのは何か

ここが今回いちばんの発見でした。

立ち上がりを過ぎれば、読む時間は2〜3秒です。生成の速さも、gpt-oss:120b は手元の実測で34.3 tok/s出ていて、ぶれも3.6%。数字だけ見れば快適なはずです。

それでも1往復に25秒前後かかっていました。

調べると、原因は喋る量でした。

「重複を残したまま1行で返して」という指示に対して、答えは5語で済みます。それに対してモデルが使ったトークン数が、700〜900でした。

gpt-oss は答える前に考えを組み立てる型のモデルです。その「考えている部分」も、生成した文章として時間を食います。短い答えを頼んでも、そこに至るまでを長く書きます。

体感の遅さは、入力を読む時間でも、生成の速さでもなく、生成した量で決まっていました。

読み違えていたこと

正直に書いておきます。私は途中まで、こう考えていました。

• エージェントは毎ターン33,000トークンを送り直している
• だから1手ごとに37秒かかる
• 10手続けば6分になる

どれも違いました。読み込みは立ち上がりの一度きりで、以降は2〜3秒。手数が増えても、そこは効きません。

思い込みの元は、最初の1回しか測っていなかったことです。1回だけ測って、それが毎回起きると決めつけました。続けて測れば分かることでした。

測り方に見つかった穴

この過程で、私の測り方にも穴が見つかりました。

Ollama には、いま何が載っているかを見る ollama ps という表示があります。モデルの読み込みにかかった時間も返ってきます。私はこれで「準備できているか」を判定していました。

ところが、載っているのに37秒かかる状態があります。そのとき ollama ps は「載っています」と答え、読み込み時間もほぼゼロと返します。どちらの指標も「準備できています」と言うのに、返事は来ません。

そこで測り方を2つ改めました。

ひとつ、ollama ps を「準備できている」の判定に使わない。②を見抜けません。

ふたつ、最初の一文字までの時間を必ず併記する。ここを見ないと②と③を取り違えます。

あわせて、これまで公開してきた読み込み速度の数字には、同じプロンプトを繰り返して測った値であるという条件が付きます。毎回ちがう文章を読ませる使い方では、同じ速さは出ません。該当記事にも追記しました。

この構成で成り立つことと、成り立たないこと

用途	この構成で成り立つか
短いやり取りのチャット	成り立つ。0.3秒で返る
エージェントに作業させる（立ち上がり）	最初の1回だけ37秒待つ
エージェントに作業させる（2手目以降）	読む時間は2〜3秒。詰まるのは喋る量

手を打つとすれば、待ち時間を削るより喋らせる量を減らすほうです。考えを組み立てる部分を短くする設定があるモデルなら、そこが効きます。私はまだ試していません。

まとめ〜待たされていたのは、どの段階か

• 同じ機械・同じモデルでも、最初の一文字までが 0.29秒のときと36.7秒のときがある
• 差を生むのは送った文章の長さ。約4,000トークンで2.4〜3.3秒、約33,000トークンで約37秒
• ただし ★その37秒は立ち上がりの一度きり。2往復目からは2〜3秒に落ちる
• ★体感の遅さの正体は、生成した量だった。5語で済む答えに700〜900トークン使い、1往復25秒前後になる
• 生成の速さ自体は 34.3 tok/s で足りている。遅いのは「速さ」ではなく「長さ」
• モデルが載っていても遅い状態がある。ollama ps でも読み込み時間でも見分けられない

前回の記事で「次回の宿題」と書いた問いには、ひとまず答えが出ました。同時に、1回しか測らずに結論を出しかけたという反省も残りました。

まだ測れていないこともあります。入力を4,000から33,000まで刻んだときに、待ち時間がどんな形で伸びるのか。今回は両端の2点しか取れていません。それと、考えを組み立てる部分を短くしたら1往復が何秒になるのか。この2つは次の宿題にします。

本記事の数値は2026年8月時点・当環境（GMKtec EVO-X2＋Ollama 0.30.10・gpt-oss:120b）のものです。使うモデルや構成が変われば結果も変わります。

検証に使用した機材

測定に使った本体です。

大きなモデルを載せる場合、置き場所が先に足りなくなります。