同じAIモデルを使っているのに、アプリを替えると答えの雰囲気が変わる。長い資料を渡すと、最初の一文字が出るまでじっと待たされる。ローカルLLMの使い心地には、モデルを動かすソフトも深く関わっています。
11月3日に公開されたOllama v0.40.14は、外部アプリから呼び出した際に回答設定が上書きされる問題を修正しました。翌4日のllama.cpp v0.9.0にも、長い入力や複数の会話を処理する仕組みの改善が入っています。
手元のAIを毎日使う人には、こういう更新こそ気になるところ。モデル名の横に、実行ソフトのバージョンも書き留めたくなるニュースです。
2026年11月5日に公式情報を確認。公開日は各プロジェクトの表示に基づきます。
Ollamaは「任せたつもりの設定」が変わっていた
Ollamaの修正で身近なのは、OpenAI互換のチャットAPIを使う場面です。自作のチャット画面などからOllamaへ接続するとき、アプリはモデル名や質問と一緒に、文章生成の設定を送れます。
その設定にあるtemperatureは言葉の選び方のばらつき、top_pは候補に残す言葉の範囲に関わる値。数字が違えば、同じ質問でも文章の出方が変わる要因になります。Ollamaの公式説明でも、これらの値と文章の多様さの関係が示されています。
問題は、アプリが値を送らなかったとき。OpenAI互換のチャットAPIである/v1/chat/completionsでは、指定されていないtemperatureとtop_pに1.0を補い、モデルに保存された値を上書きしていたのです。v0.40.14で直ったのは、この動作。モデル側の設定に任せたつもりなら、その意図どおりに動くようになりました。修正内容は公式PRで確認できます。
先日の記事で紹介したLFM3も無関係ではありません。修正PRでは、Ollamaのlfm3に含まれるtemperatureの0.1が、この接続では1.0になっていた例が挙げられています。モデル名をそろえただけでは、試している条件までそろっていなかったわけです。
アプリが値を明示して送る場合は、その指定が優先されます。更新後に返答の雰囲気が変わったら、まずは送信設定を見直したいところ。同じモデルを比べるなら、実際に渡した設定値までそろえたいところです。
自分のモデルに保存された値を見てみる
Ollamaでは、次のコマンドでモデル側に保存されたパラメータを確認できます。YOUR_MODELを、普段使っているモデル名に置き換えてください。構文はv0.40.14の公式ソースで確認しています。
ollama show --parameters YOUR_MODELここに出るのはモデル側の設定です。チャットアプリが別の値を送れば、そちらが使われます。見比べたいのは、チャット画面の「生成設定」。どこで条件が変わっているのかを追う手掛かりになります。表示が空の場合も、Ollama自体の既定値は別にあるため、設定が一切ないという意味にはなりません。
llama.cppは、答えを書く前の計算を減らした
llama.cpp v0.9.0で目を引くのは、Gemma 4 E2BとE4Bの入力処理です。AIは長い文章を渡されると、回答を書き始める前にその文章を処理します。この段階が「プリフィル」。チャット画面で返事を待つ時間の一部に当たります。
開発者の説明によると、計算途中の情報を保存するKVキャッシュをほかの層から使い回す部分にも、不要な入力トークンの計算が残っていました。今回の変更は、その計算を省くものです。この層の省略処理は、v0.9.0では処理する系列数を1に設定した構成が対象です。実装上も単一系列に制限されており、複数系列のサーバー構成には、表の改善をそのまま当てはめられません。
開発者が公開したM4 Proでの測定には、変化がはっきり表れています。Gemma 4 E2Bの公式QAT Q4_0モデルをMetalで動かし、10スレッドで測った例です。
| 測った処理 | 修正前 | 修正後 |
|---|---|---|
| 2,048トークンの入力処理 | 1,535.38 | 4,451.68 |
| 128トークンの文章生成 | 109.65 | 110.98 |
入力処理には大きな差がある一方、文章を生成する速度は近い値です。「AIが速くなった」という一言だけでは、この違いが見えません。資料を読み込んで待つ時間と、回答が流れてくる速さは、分けて見たいところです。
同じPRでは、全層がKVキャッシュを作るGemma 4 26Bには、この計算省略による改善がないとも説明されています。E2BやE4Bの数字を、そのまま26Bへ当てはめることはできません。
一台に複数の会話を任せる人にも関わる
もう一つは、複数の会話のKVキャッシュをまとめて扱う処理です。従来は、ある会話を計算するとき、ほかの会話に属する情報を計算対象から除く処理が負担になっていました。
新しい方式では、会話ごとに参照するKVキャッシュの行を指定できます。必要な途中結果を取り出すための処理を見直した形です。公式PRは、統合KVキャッシュの利点を保ちながら、複数の系列を扱う際の性能を改善する変更と説明しています。
ここから考えられるのは、一台のローカルLLMを複数人で共有したり、複数のAIエージェントから呼び出したりする使い方です。一人なら快適でも、同時に質問が来ると待ち時間が伸びる。そんな環境では、単独の会話だけを測っていても見えない差があります。
この方式の効果には、統合KVキャッシュの使用と、GPU向けの処理系が新方式に対応しているかが関わります。MacならMac、DGX SparkならDGX Sparkで、普段の同時接続数を使って比べたいところです。
更新後は、いつもの文章をもう一度渡してみる
ベア三郎なら、更新前にいつもの質問と資料を残しておきます。短い質問と、少し長い資料。更新後に同じものを渡せば、待ち時間のどこが変わったかを見比べられます。
| 気になっていること | 更新前後で見比べるもの |
|---|---|
| アプリを替えると返答の癖が違う | アプリが送るtemperatureとtop_p、モデル側に保存された値 |
| 長い資料を渡すと返事が始まらない | 送信から最初の応答までの時間と、入力処理の時間 |
| 回答は始まるが、文字が出るのが遅い | 文章を生成している間の速度 |
| 一人なら快適なのに、同時利用で待たされる | 同じ接続数で使ったときの待ち時間 |
モデルをメモリへ読み込む時間や、過去の入力を再利用するキャッシュも結果に関わるので、初回と二回目以降は分けて記録します。回答速度の見方は、以前のDGX SparkでStrataとllama.cppを比較した記事にもつながります。そちらは別のバージョンとモデルでの測定です。
llama.cppの更新が、OllamaやLM Studioなどの配布アプリに取り込まれる時期は、それぞれのリリースで確認してください。llama.cpp v0.9.0が出たことだけで、手元のアプリに同じ変更が入ったとは判断できません。
新しいモデルを試すときの楽しさは格別です。そこに、いつも使っているモデルを「どう動かしているか」という視点も足してみたい。回答設定のずれが直り、読むための余計な計算が減る。11月の更新には、手元のAIとの付き合いを少し変える材料が詰まっています。
コメント