長いコンテキストは遅い？VPSでprefill実測

【PR】この記事にはA8.netのアフィリエイト広告を含みます。

先に結論：Macが長いコンテキストでRTXより遅いかは、今回のXServer VPS実験だけでは判定できません。MacもRTXも所有していないからです。ただし、同じCPU modelへ532・2,287・4,537 tokenを渡すと、prefill中央値は1.738秒→11.211秒→31.540秒へ増えました。入力は8.528倍、prefillは18.146倍です。XServer VPSは非同期処理の逃がし先にはなりますが、長文を送れば速くなるわけではありません。判定は一部解決です。

2026年9月1日、XServer VPS 4GBでQwen3 0.6Bへ3種類の合成長文を各3回送りました。Ollamaが返すprompt_eval_countとprompt_eval_durationを使い、生成16 tokenの時間とは分けて測っています。

長いコンテキストで問題になるprefillとは？
MacはRTXより長文処理が遅い？
ZennのMac実測では何が報告されている？
今回のXServer VPS実験環境は？
キャッシュ条件は揃えた？
532 tokenのprefillは何秒だった？
2,287 tokenでは何秒だった？
4,537 tokenでは何秒だった？
入力が長くなると何倍遅くなった？
総待ち時間はどれくらい増えた？
RAMはどれだけ増えた？
最初の実験はなぜ失敗した？
XServer VPSへ長文処理を逃がせば速くなる？
公開中のAPIは影響を受けた？
XServer VPSで便利だった点は？
AIスマホ調査システムではどう長文を扱う？
よくある質問
Macの長いコンテキスト問題はXServer VPSで解決した？
最新条件の確認先

長いコンテキストで問題になるprefillとは？

prefillは、回答を1 tokenずつ生成する前に、入力prompt全体を読み込む処理です。長いコード、チャット履歴、RAG文書、Android調査ログをまとめて送ると、最初の1文字が返るまでの待ち時間へ影響します。

Ollama Generate API公式文書は、応答にprompt_eval_countとprompt_eval_durationを含めます。今回のprefill速度は、前者を後者の秒数で割って算出しました。

指標	意味	今回の使い方
prompt_eval_count	処理した入力token数	文字数ではなく実tokenを採用
prompt_eval_duration	入力処理時間	prefill時間として比較
eval_count	生成token数	全条件16に固定
eval_duration	生成時間	prefillと混ぜず記録
total_duration	load等を含む総時間	利用者の待ち時間に近い値

MacはRTXより長文処理が遅い？

model、量子化、runtime、cache条件を揃えないと比較できません。メモリに載ること、promptを速く読むこと、回答tokenを速く生成することは別の性能です。

Redditの「Qwen3.5 MLX vs GGUF Performance on Mac Studio M3 Ultra 512GB」では、複数ファイルやMCPを含む実作業でprompt processingが長くなったという個別体験が報告されています。一方、cacheやruntime更新で挙動が変わる例もあります。投稿者の条件をMac全体へ一般化しません。

ZennのMac実測では何が報告されている？

Zennの「Hy3 T512をM3 Ultra 512GBで実測」では、59K token入力を処理できた一方、短文と長文でpeak memoryや生成速度が変わり、512GBでも余裕とは言えなかったと報告されています。対象modelは今回のQwen3 0.6Bと全く異なります。

この違いこそ重要です。「Mac」「RTX」「VPS」という機種名だけでなく、model size、context、KV cache、backendをセットで記録しなければ一次情報として比較できません。

今回のXServer VPS実験環境は？

項目	条件
VPS	4 vCPU / 4GB RAM / 150GB NVMe、GPUなし
OS	Ubuntu 26.04
container上限	3 CPU / 2,200MiB / 追加swapなし / PID 256
Ollama	0.33.2、Docker
model	qwen3:0.6b、既存volumeを再利用
context設定	num_ctx 8192
生成	num_predict 16、temperature 0、seed 42
反復	各3run、中央値

公開中のCaddy、FastAPI、PostgreSQLは止めず、実験Ollamaだけを一時containerへ分離しました。

キャッシュ条件は揃えた？

各runをkeep_alive=0で終え、modelとKV contextを解放してから次へ進みました。prefixもcaseとrunごとに変えています。これは「同じ会話の続き」ではなく、長文を初めて読むcold prefillを比較するためです。

実運用ではstable prefixとKV cacheを使えば、毎回すべてを読み直さずに済む可能性があります。今回の結果を、cache有効なagent sessionの待ち時間へそのまま当てはめないでください。

[PR]
VPSでいろいろ試すなら『XServer VPS』

532 tokenのprefillは何秒だった？

3runのprefillは1.902秒、1.738秒、1.628秒で、中央値は1.738秒でした。prompt throughput中央値は306.084 tok/s、total中央値3.709秒、wall中央値3.714秒です。

run	prompt token	prefill	prompt速度	total
1	532	1,901.922ms	279.717 tok/s	3,900.521ms
2	532	1,738.087ms	306.084 tok/s	3,709.355ms
3	532	1,627.599ms	326.862 tok/s	3,626.532ms

2,287 tokenでは何秒だった？

prefill中央値は11.211秒、prompt throughput中央値203.997 tok/s、total中央値13.514秒でした。532 token比で入力は4.299倍、prefillは6.450倍です。

run	prompt token	prefill	prompt速度	total
1	2,287	11,009.280ms	207.734 tok/s	13,301.904ms
2	2,287	11,615.216ms	196.897 tok/s	13,934.081ms
3	2,287	11,210.927ms	203.997 tok/s	13,513.789ms

4,537 tokenでは何秒だった？

prefill中央値は31.540秒、prompt throughput中央値143.849 tok/s、total中央値34.339秒でした。532 token比で入力は8.528倍、prefillは18.146倍です。

run	prompt token	prefill	prompt速度	total
1	4,537	31,661.370ms	143.298 tok/s	34,572.885ms
2	4,537	31,540.018ms	143.849 tok/s	34,338.944ms
3	4,537	30,192.960ms	150.267 tok/s	33,217.874ms

入力が長くなると何倍遅くなった？

実token中央値	token倍率	prefill中央値	prefill倍率	prompt tok/s
532	1.000	1.738秒	1.000	306.084
2,287	4.299	11.211秒	6.450	203.997
4,537	8.528	31.540秒	18.146	143.849

532→4,537 tokenでprompt throughputは約53.0%低下しました。このmodel、CPU backend、batch、context深度では、一定tok/sで単純比例しませんでした。

llama.cpp server公式READMEもprompt token数、prompt処理秒数、prompt tok/sをgeneration指標と分けています。長文比較では生成tok/sだけを載せないことが重要です。

総待ち時間はどれくらい増えた？

token	load中央値	prefill中央値	total中央値	wall中央値
532	約1.655秒	1.738秒	3.709秒	3.714秒
2,287	約1.650秒	11.211秒	13.514秒	13.518秒
4,537	約1.654秒	31.540秒	34.339秒	34.344秒

長文になるほどload約1.65秒よりprefillが支配的になりました。4,537 tokenではtotalの約91.8%がprefillです。

RAMはどれだけ増えた？

Docker statsの条件別最大は1,521.7MiB、1,537.0MiB、1,543.2MiBでした。532→4,537 tokenの差は21.5MiBです。

prompt token	container RAM最大	532 token比
532	1,521.7MiB	基準
2,287	1,537.0MiB	+15.3MiB
4,537	1,543.2MiB	+21.5MiB

これは0.5秒samplingで得たcontainer全体の最大値です。modelが小さく、contextも4.5K程度なので差が小さい結果でした。70Bや100K contextのmemory増加を示すものではありません。

最初の実験はなぜ失敗した？

初回は文字列の反復数500・2,000・4,000を、そのままtoken相当と見込みました。しかしrecord-about-...という識別子がQwen tokenizerで約8 tokenへ分割され、実際は4,036・4,098・4,098 tokenとなりました。後ろ2条件はcontext境界へ丸められ、比較になりません。

初回もOOMなし、restart 0、ready 9/9、container RAM最大1,549.3MiBで終了しました。一時containerを削除し、実測比から反復数を62・250・500へ修正。本測定で532・2,287・4,537 tokenを得ました。

文字数や単語数をtoken数と思わず、APIが返す実tokenを確認することが、今回最も初心者が迷いやすい点でした。

XServer VPSへ長文処理を逃がせば速くなる？

速くなるとは限りません。今回4,537 tokenのcold prefillだけで31.540秒かかりました。GPUなしCPU VPSはMacやRTXの高速代替ではありません。

一方、夜間のログ整形、記事素材のchunk分割、検索index作成、非同期要約なら、自宅PCを塞がずに処理できます。「低遅延チャット」と「待てるバックグラウンド処理」を分けるのが現実的です。

公開中のAPIは影響を受けた？

確認	結果
ready check	9/9成功
database	全回ok
artifact storage	全回ok
OOM / restart	false / 0
container CPU最大	303.17%、3 CPU上限のsampling境界
experiment container	削除済み

VPS available RAMは実験前3,282.2MiB、削除後3,286.7MiB。swap freeは前後1,928.8MiBでした。

XServer VPSで便利だった点は？

同じDocker image、model、CPU/RAM上限で条件を固定できた。
Ollama APIからprefillとgenerationを分離取得できた。
公開APIを止めず、各run後にreadyを確認できた。
失敗した校正結果もJSONで残し、条件を修正できた。
実験containerだけを削除し、model volumeを再利用できた。

AIスマホ調査システムではどう長文を扱う？

スクリーンショット、UI XML、操作履歴、料金、errorを毎回promptへ全部貼ると、調査が続くほどprefillが伸びます。VPS側で次のように分けます。

生の画像とUI XMLはartifact storageへ保存する。
操作eventは時刻・画面・action・結果の構造化JSONにする。
直近の必要部分だけをretrievalする。
完了区間は短い要約へ圧縮する。
stable system promptを固定し、cacheを壊す可変IDを本文へ混ぜない。

「大きなcontext windowがあるから全部入れる」のではなく、一次証跡を保存したまま、推論へ渡す量を制御します。

よくある質問

この結果でMacよりRTXが速いと言える？

言えません。今回測ったのはGPUなしXServer VPSだけです。Mac/RTXは未所有・未測定です。

なぜ指定512・2048・4096と完全一致しない？

入力文字列をQwen tokenizerが分割した実数を採用したためです。比較値は532・2,287・4,537 tokenです。

長文ならRAMが急増するのでは？

今回は532→4,537 tokenでcontainer最大が21.5MiB増でした。小型model・4.5K contextに限るため、大型modelへ外挿できません。

keep_alive=0は実運用より不利？

cache再利用を消すので、同じ会話の継続より不利です。cold prefillを条件間で揃えるために使いました。

VPSで長文処理する価値はある？

即時応答には遅い場合がありますが、自宅PCを塞がない非同期要約、chunk化、index作成には利用できます。