3万トークンで約10秒待ち。BaseRTは長文をどこまで速く読める？
短い質問なら、Qwen3.6はかなり早く返し始めます。
ただ、長い資料を渡したときも同じ感覚で使えるのでしょうか。
文章を出し始めてからの速さだけではなく、資料を読み終えて最初の一文字を返すまでを見たくなりました。
今回はBaseRTで動かしたQwen3.6-35B-A3B Q4へ、約129トークンから約32,813トークンまでの資料を渡しています。
最長の資料は約58,000文字でした。
結果から先に書くと、約8,200トークンまでは2秒弱で返答が始まりました。
約32,800トークンでは、最初の一文字まで約10秒です。
長文になるほど待ち時間は増えます。
一方で、1秒あたりに読み込める量は途中まで大きく伸びました。
ここが今回のおもしろいところです。
🔰 先にざっくり用語メモ
📝 トークン
AIが文章を処理するときの細かな単位です。
日本語では、文字数とトークン数がそのまま一致するわけではありません。
📝 TTFT
質問を送ってから、最初の一文字が返るまでの時間です。
長い資料を使うときの体感に近い数字として見ます。
📝 Prefill
AIが回答を作る前に、入力された資料を読み込む処理です。
今回は、長文を1秒あたり何トークン読めるかも確認しました。
📝 Decode
読み込みが終わったあと、回答文を順番に生成する処理です。
Prefillとは別の速さです。
1. 今回の長文
検証には、個人でローカルAIや画像生成を試した架空のメモを使いました。
同じ段落をそのまま繰り返すのではなく、BaseRT、Ollama、Q4とQ8、画像生成、記事メモなど、少しずつ内容の異なる記録を組み合わせています。
最後には、どの資料にも同じ質問を付けました。
資料全体で繰り返し確認された、個人でローカルAIを試すときの改善方針を3つ、番号付き3行だけで答えてください。
用意した入力は次の5段階です。
実測129トークン、資料本文12文字
実測518トークン、資料本文695文字
実測2,051トークン、資料本文3,426文字
実測8,201トークン、資料本文14,352文字
実測32,813トークン、資料本文58,056文字
129トークンの回は、比較の基準にするため、資料本文がほとんどない状態です。
残りの4段階では、資料を少しずつ長くしています。
Qwen3.6のThinkingは無効にし、各条件を3回ずつ試しました。
同じ入力を続けて読んだ影響を減らすため、各回はモデルを読み直した状態で測っています。
2. 最初の一文字
TTFTの中央値は次の結果になりました。
129トークン：0.111秒
518トークン：0.187秒
2,051トークン：0.494秒
8,201トークン：1.728秒
32,813トークン：10.161秒
約500トークンなら0.2秒未満です。
約2,000トークンでも0.5秒ほどなので、待っている感覚はほとんどありません。
約8,200トークンになると、返答開始まで1.7秒ほどかかりました。
少し間はありますが、長い資料を渡した結果としては十分に軽く感じます。
変化が大きかったのは約32,800トークンです。
最初の一文字まで約10.2秒、3行の回答が完成するまで約11.6秒かかりました。
ここまで来ると、さすがに「すぐ返ってきた」とは感じません。
ただ、約58,000文字を読ませたあと、十数秒で回答まで終わったと考えると、個人の検証用途では現実的な待ち時間です。
3. 長いほど速いのか
今回の仮タイトルには、「長い資料ほど速くなる？」という疑問を置いていました。
経過時間だけを見れば、答えは速くなりません。
資料が長くなるほど、最初の一文字までの待ち時間は増えました。
しかし、Prefillの処理速度を見ると別の動きが出ています。
128トークン：1,963 tokens/s
512トークン：4,054 tokens/s
2,048トークン：5,655 tokens/s
8,192トークン：5,473 tokens/s
32,768トークン：3,903 tokens/s
1秒あたりに読み込める量は、128トークンから2,048トークンへ増やす間に約2.9倍まで伸びました。
短すぎる入力より、ある程度まとまった入力の方が処理能力を使いやすいようです。
ただし、32,768トークンでは3,903 tokens/sまで下がっています。
長くすれば長くするほど効率が上がるわけではありません。
今回の条件では、2,000から8,000トークン付近が最も高いPrefill速度になりました。
一方、内蔵ベンチのDecode速度は、どの入力サイズでも約160 tokens/sでほぼ変わりませんでした。
つまり、長文で増えたのは主に回答を始める前の待ち時間です。
文章が流れ始めてからの速さは、入力の長さに大きく左右されませんでした。
4. 資料が短すぎる回答
速度だけでなく、返答内容も見てみます。
まず、資料本文が12文字しかなかった129トークンの回答です。
1. 高性能なMac（M1 Pro以降）を選択し、メモリ容量を最大限に拡張してモデルの読み込みと推論の速度を確保する。
2. 用途に合わせて適切なモデルサイズ（7B程度から70B以上）と量子化レベルを選択し、ローカル環境での実行負荷と精度のバランスを取る。
3. OllamaやLM Studioなどのローカル推論用ソフトウェアを活用し、API経由ではなくローカルネットワーク内で完結させてプライバシーと応答速度を最適化する。
3行という形式は守っています。
ただし、これは資料を要約した回答ではありません。
資料内に根拠がない「M1 Pro以降」「7Bから70B以上」「OllamaやLM Studio」といった一般的な知識を補っています。
材料が足りないため、Qwen3.6が質問からもっともらしい回答を作った形です。
速さは0.11秒でしたが、今回ほしかったのは速い一般論ではありません。
短い入力ほど使いやすいとは限らない例になりました。
5. 500トークンで揃った回答
518トークンまで資料を増やすと、回答は資料内の内容へ寄りました。
1. 入力トークン数を実測してから比較する
2. 回答形式の違反と生成失敗を分ける
3. 比較の前提を記事中で明記する
この回答は3回とも一字一句同じでした。
資料に繰り返し出てくる改善点を短く拾えており、質問にも直接答えています。
最初の一文字まで0.19秒、回答全体でも約1.06秒でした。
今回の課題では、500トークン程度でも必要な材料は足りていたようです。
6. 2,000トークン以降の回答
2,051トークンの代表回答です。
1. 派手な差がなくても実測結果をそのまま明記し、目標値と実測値を並べて比較の曖昧さを減らす。
2. 再現性を高めるため、同じ質問を複数回試して中央値を見るか、長文資料は文章の反復で水増ししない。
3. 速度の数字と文章評価を分け、キャッシュを含む結果は別枠で扱い、モデルの優劣より向いている使い方を考える。
資料が長くなったことで、単語を拾うだけでなく、改善方針と理由を一緒にまとめています。
3回の回答はほぼ同じでした。
8,201トークンでは、次の回答が返りました。
1. 派手な差がなくても実測結果をそのまま明記し、目標値と実測値を並べて比較の曖昧さを減らす。
2. 再現性を高めるため、同じ質問を複数回計測し、中央値を見ることで結果への安心感を増やす。
3. 長文評価や速度比較において、同じ文章の反復で水増しせず、入力だけを長くして確かめる。
こちらも資料の中心を外していません。
2回目と3回目は同じ回答で、1回目だけ3番目の内容が少し異なりました。
資料が増えても、指定した3行へ整理できています。
7. 3万トークンの回答
最長の32,813トークンでは、3回とも途中で止まらず、指定した3行を返しました。
代表回答です。
1. 再現性を高めるため、同じ質問を複数回（三回）計測し、中央値や実測値をそのまま明記する。
2. キャッシュの影響を排除するため、モデルを一度終了してから再実行するか、モデルを読み直す。
3. 比較の曖昧さを減らすため、入力だけを変えて出力条件を固定し、目標値と実測値を並べて記述する。
1回目と2回目は同じ回答でした。
3回目は次のように、少し短い内容へ変わっています。
1. 派手な差がなくても実測結果をそのまま明記する
2. 再現性を高めるため複数回の計測を行い中央値を見る
3. 比較の前提を記事中で明記しモデルの優劣より向いている使い方を考える
どちらも資料内にある内容です。
ただし、長い資料から選ばれる3項目は毎回完全には固定されませんでした。
資料が長くなるほど、候補になる論点も増えます。
その中から何を重要と判断するかには、少し揺れが残ります。
長文を最後まで読めることと、毎回同じ要点を選ぶことは別です。
ここは速度だけでは分からない部分でした。
8. 今回の判断
BaseRT上のQwen3.6-35B-A3B Q4は、約8,200トークンまでなら、最初の一文字を2秒以内に返しました。
約32,800トークンでも、最初の一文字まで約10秒、回答完了まで約12秒です。
長い個人メモをまとめて渡し、一度だけ整理してもらう用途なら十分に使えそうです。
一方で、普段の軽い相談へ毎回3万トークンを付ける使い方は、待ち時間も資料準備も重くなります。
今回の感覚では、2,000から8,000トークンあたりが、資料量と待ち時間のバランスを取りやすい範囲でした。
そして、資料が短すぎると、速くても一般論を補ってしまいます。
待ち時間を短くすることより、答えるために必要な材料を入れることの方が大切でした。
木曜日は速度から離れ、長文要約、条件整理、コード修正を試します。
35BのローカルAIが、実際の作業を一回で前へ進められるのかを見る予定です。
Tami
#BaseRT #Qwen3_6 #ローカルLLM #MacBookPro #M5Max #生成AI #長文要約