「ローカルLLMでコーディング」系の記事を読もうとして、tok/s とか prefill とか num_ctx とかが出てきて挫折した人向けの記事です。
筆者は GPU なし・CPU だけの環境（Ryzen 5 4500U・メモリ32GB）で、ローカルLLMに「ファイルを読む・編集する・テストを回す」というコーディングエージェントの仕事をさせる実験をしました。その結果「ファイルサイズが大きいモデルほど速くて正確だった」など、常識的な予想がことごとく裏切られる面白いデータが取れたのですが、それを語る前に必要な用語を全部ここに置きます。
「学校の授業レベル」を意識して、各用語は「一言でいうと → なぜ重要か → 実測での実例」の順で書きます。
土台: LLMは「文字を予測する機械」
LLM（大規模言語モデル）は、入ってきた文章の続きとして「次に来るべきトークン」を確率的に予測し続ける機械です。考えたり調べたりしているのではなく、予測の連鎖です。この一点を押さえると後の全部が理解しやすくなります。
用語1: トークン（token）
一言でいうと: LLMが扱う文字の最小単位。だいたい英単語1つか、日本語なら1〜数文字。
モデルの速さ・料金・記憶容量はすべてトークンで測ります。「ファイルを読ませた」= そのファイルの内容がトークン列になって入力された、という意味です。
用語2: prefill / decode（プロンプト処理と生成）
一言でいうと: LLMの仕事は2段階。入ってきた文章を全部読み込む「prefill（プロンプト評価）」と、続きを1トークンずつ書き出す「decode（生成評価）」。
これが別れているのが重要で、速度の内訳がまったく違うのです。
実例: 1800トークンのコードファイルを読んで要約させるタスクで、あるモデルは prefill に 84秒、decode に 30秒かかりました。つまり「返事が来るまで待つ時間」の大半は読み込みです。エージェントループでは毎ターン、全履歴を読み直すので、この prefill が律速になります — これが後の話の全てに効いてきます。
用語3: tok/s（評価速度）
一言でいうと: 1秒あたりに処理できるトークン数。eval rate（decode側の tok/s）が「文字が書き出される速さ」の指標。
筆者の環境では実用の目安を 5 tok/s と置きました。それを切ると、エージェントが1ターン考えるだけで数分かかります。
実例: 同じPCで、モデルによって 3.1 tok/s から 8.0 tok/s まで開きがありました。クラウドAPI（Web版ClaudeやGPT）の何十分の一の速度ですが、「待てば着実に進む」範囲内です。
用語4: コンテキストウィンドウ / num_ctx
一言でいうと: モデルが一度に「見える」範囲。num_ctx は Ollama での設定値（既定 4096 トークン）。
なぜ重要か: ウィンドウを超えた古い内容は、黙って捨てられます。警告も出ません。モデルが「さっき読んだはずのファイルの中身を忘れた」ように見える時、実はコンテキストから押し出されているだけ、ということが実際に起きます。
実例: エージェントループ（システムプロンプト＋ファイル内容＋往復履歴）では 4096 はすぐ溢れます。筆者は 8192 を推奨値として実測しています。ただし大きくしても賢くはならず「見える量」が増えるだけです。
用語5: KVキャッシュ
一言でいうと: 読み込んだコンテキストを保持する作業用メモリ。num_ctx を大きくすると実際に使った分だけ増えます（9B級モデルで +1〜2GB 程度）。32GB RAM なら誤差範囲です。
用語6: 温度（temperature）
一言でいうと: 出力の「揺らぎ度」。0 に近いほど毎回同じ答え（決定的）、1 付近で創造的・散らかりやすい。
よく言われる「温度を下げると安定する」は半分だけ本当で、筆者の実験では 温度 0.2 の決定性が、モデルの「同じ失敗を繰り返す癖」まで固定してしまう事態を観測しました（詳しくは別の記事で）。温度は「知性」ではなく「ばらつきの調整」です。
用語7: thinking / 推論モード
一言でいうと: 答えを出す前に「考えた過程」を長文で生成するモード。推論系モデル（qwen3.5・gpt-oss・gemma4 等）が持ちます。
注意点が2つ:
- この「思考トレース」もトークンを食います。低速環境では返事までの時間の大部分を占め、切ると劇的に速くなります
- モデルによって切れるものと切れないものがあります。実測では gpt-oss:20b と gemma4 系は思考を完全に切れず、「Off」を送ると返事本文が空になる不具合すらありました
用語8: ハーネス（harness）
一言でいうと: モデルを囲むツール側の仕組み全般 — プロンプトの組み立て方、コマンドの解釈、結果の返し方、履歴の持ち方。
「モデルの性能」として見える現象のかなりの部分が、実はハーネスの設計で決まります。筆者の実験で最大の発見は「モデルが弱いと見えたのは、自分のハーネスのバグだった」でした（第3弾の記事で詳述）。ローカルLLM記事で「このモデルは使えない」と読むとき、そこにはモデルとハーネスの合計が書かれている、と思ってください。
用語9: エージェントループ / ツール呼び出し
一言でいうと: 「考える→コマンドを出す→結果を見る→また考える」を繰り返す自律的な仕組み。
コーディングエージェントは「ファイルを読む（READ_FILE）」「編集する（EDIT_FILE）」「コマンドを実行する（RUN_COMMAND）」等をモデルがテキストで出力し、ハーネスがそれを解釈して実行し、結果をモデルに返す、という往復です。OpenAI系の「function calling」はこれを構造化データでやる方式で、Ollamaの素のAPIでは自分でテキスト形式を決めて運ぶこともできます（筆者のIDEはそちらの方式）。
用語10: 幻視（hallucination / ハルシネーション）
一言でいうと: モデルが、存在しない事実を確信的に述べること。
実例: 実際には export が1つしかないファイルを「2つあります」と答えたモデルがいました。存在しないテスト結果を「確認しました」と述べることもあります。小さいモデルほど起きやすいのですが、ハーネス設計（モデルの記憶を補助する）でかなり減らせます。
これだけで読める
以上の10個が分かれば、こういう記事が読めるようになります:
「qwen3.5:4b は decode 8 tok/s で速いが幻視が多い。gemma4:e4b は num_ctx 8192 のエージェントループを形式崩れなしで完走した」
この言葉が「だから ○○ は使える/使えない」に直結している構造が、次の記事以降の実データで見えてきます。
続きはこちら（全数字の実測データあり）
この記事は「CPUだけのローカルLLMコーディング」シリーズの第1弾です。実際の計測データ・全ログ・モデル別評価は公開サイトに置いています:
- 第2弾: 「ローカルLLMは実用にならない」と思っていた人へ — CPUだけで全数字検証
https://labo.mond.jp/articles/localllm-usable.html - 第3弾: 「モデルが弱い」と思ったら自分のアプリのバグだった — 計測がハーネス欠陥を暴いた話
https://labo.mond.jp/articles/localllm-harness-bug.html - シリーズ一覧・計測の生データ（GitHub）へのリンク集
https://labo.mond.jp/articles/localllm-terms.html