【ITニュース解説】Ollama v0.34.2 vs v0.34.1: a targeted MLX fix, not the same regression

Ollamaは、大規模言語モデル（LLM）を手元のコンピューターで簡単に動かせるようにするツールだ。通常、高性能なサーバーが必要なLLMを、個人のPC、特にApple Siliconを搭載したMacなどで手軽に試せるようにすることで、開発者や研究者がLLMをより身近に活用できるようになる。

今回、Ollamaは非常に短い期間に2つのバージョン、v0.34.1とv0.34.2を立て続けにリリースした。v0.34.1は9月14日に、v0.34.2はその翌日の9月15日に公開された。どちらの更新内容も、Apple製品に搭載されているMLXと呼ばれる機械学習フレームワークと「メモリ」という言葉に触れていたため、多くの人が「同じ緊急の問題に対する修正ではないか」と推測したかもしれない。しかし、詳しく見ていくと、これらは異なる種類の修正であることがわかる。

まず、9月14日にリリースされたv0.34.1の変更点から見ていこう。このバージョンでは、いくつかの重要な改善と変更が加えられた。一つ目は、「MLX safetensors」の機能が実験的な段階を終え、正式に利用可能になったことだ。Safetensorsは、AIモデルの保存形式の一つで、従来の形式よりもセキュリティが高く、高速にロードできるという特徴を持つ。Ollamaでモデルを作成する際に、このMLX safetensorsがより安定して使えるようになったのは大きな進歩だ。ただし、GGUFという別のモデル形式を作成する場合には、引き続きllama.cppという別のツールの変換機能と量子化機能が必要となる。量子化とは、モデルのサイズを小さくし、より効率的に動かすための技術のことだ。

二つ目は、Apple Siliconを搭載したMacでの「MLXメモリハンドリングの改善」だ。これは、MLXフレームワークがメモリを扱う方法が全体的に見直され、より効率的になったことを意味する。Macユーザーにとって、モデルの動作がより安定したり、パフォーマンスが向上したりする可能性がある、一般的な改善と捉えられる。三つ目は、モデルが生成するテキストにおける「トークン繰り返し検出」の閾値が変更されたことだ。これまでは、少量のトークン（単語や文字の断片）の繰り返しでも検出され、不自然な生成を防いでいた。しかし、OCR（光学文字認識）のように、元々繰り返しの多いテキストを扱う際に、誤って「繰り返し」と判断されてしまうケースがあったため、この閾値が100回の繰り返しに設定し直された。これにより、より自然なテキスト生成が期待できる。

四つ目は、/api/tagsというAPIのパフォーマンスが大幅に向上したことだ。このAPIは、Ollamaに登録されているモデルの一覧を取得するために使われる。大規模なモデルライブラリを持つ環境でのテストでは、コールドスタート時（一度も呼び出されていない状態からの起動）の応答時間が3.1秒からわずか294ミリ秒へと劇的に短縮されたという。これは、モデル管理の快適さに直結する改善点だ。最後は、「typical_p」という設定項目の非推奨化だ。これはモデルのテキスト生成の多様性を調整するパラメータの一つだが、新しいモデルでは設定できなくなり、既存のGGUFモデルでのみ引き続き利用できるようになった。これは、Ollamaのモデル設定が整理され、よりシンプルになる方向性を示している。

次に、その翌日の9月15日にリリースされたv0.34.2の変更点を見ていこう。このバージョンでは、Ollamaを初めて実行する際に、サインインするか、ローカル環境で使い続けるかを選択できる初期設定機能が追加された。この設定状態は、macOSやWindows向けのOllamaデスクトップアプリとも共有されるため、ユーザー体験の一貫性が向上した。また、ollama://appsというリンク形式が導入され、macOSやWindowsのデスクトップアプリで直接「Apps」ページを開けるようになった。

そして、v0.34.2の最も重要な修正点は、「MLX投機的デコーディングを用いた長文生成時に発生する過剰なメモリ増加の修正」である。ここでいう「投機的デコーディング」とは、LLMがテキストを生成する際により高速に、より少ない計算で次のトークンを予測する技術の一つだ。特にMLXというフレームワーク上でこの技術を使い、非常に長い文章を生成するような特定の条件下で、システムメモリが予想以上に消費されてしまう問題があった。v0.34.2は、このピンポイントな問題を解決するためにリリースされた。また、このバージョンでは、llama.cppの基盤ライブラリもアップデートされたとされているが、具体的なバージョンや、そのアップデートによってどのような変更があったのかは、公式のリリースノートには明記されていない。

それでは、なぜこれら二つの修正が、一見似ているように見えても、同じ問題への対処ではないと判断できるのだろうか。その理由は、それぞれのリリースノートが記述している内容の「具体性」にある。v0.34.1のリリースノートは、「MLXメモリハンドリングの改善」と、非常に一般的な表現でメモリの問題に触れている。どのような状況で、あるいはどの部分でメモリの問題が発生していたのか、具体的なシナリオは明記されていない。これは、MLXフレームワーク全体の、広範囲にわたるメモリ利用の最適化を指している可能性が高い。

対照的に、v0.34.2のリリースノートは、「MLX投機的デコーディングを用いた長文生成時」という、非常に特定の条件下でのメモリ増加問題に焦点を当てている。投機的デコーディングは、LLMの推論（テキスト生成）の特定のメカニズムの一つであり、これは一般的なメモリハンドリングとは異なる、具体的な機能における課題を解決したものと言える。公式ドキュメントには、v0.34.1の変更がv0.34.2の問題を引き起こしたという記述もなければ、これら二つの修正が同じ根本原因を持つという記述もない。単に、それぞれのバージョンで異なる、しかし関連性のある課題に対処したと考えるのが自然だ。

したがって、v0.34.2のメモリ修正が特に重要となるのは、どのようなユーザーだろうか。それは、Apple Siliconを搭載したMacでOllamaを使用し、MLXバックエンド（MLXフレームワークを使った処理）でモデルを実行し、特に投機的デコーディングという高速化技術を利用して「長い文章を生成する」ユーザーだ。このような使い方をしている場合、v0.34.2へのアップデートは、システムメモリの過剰な消費を防ぎ、より安定した動作をもたらす可能性が高い。一方で、GGUF形式のモデルをllama.cppというバックエンドで実行しているユーザーの場合、v0.34.2で修正されたメモリ問題は、その利用シナリオには直接適用されない。なぜなら、GGUFモデルはMLX投機的デコーディングとは異なるメカニズムで動作するためだ。

今回の情報からは、いくつかの点が不明瞭なままだ。例えば、v0.34.2で修正されたメモリ増加が、v0.34.1の変更によって新たに引き起こされたものなのか、それともv0.34.1よりも前から存在していた問題なのかは確認できない。また、投機的デコーディング中にメモリが増加した具体的な技術的理由や、v0.34.2で更新されたllama.cppのバージョンやその内容の詳細も、リリースノートからは読み取れない。さらに、/api/tagsのパフォーマンス測定で示された数値（3.1秒から294ミリ秒への短縮）についても、そのテスト方法が具体的にどのように行われたのかは説明されていない。

以上の情報に基づくと、現時点でOllamaをアップデートすべきユーザーは、Apple Silicon環境でMLXモデルを使い、投機的デコーディングを有効にして長文生成を行っている人たちだ。このグループのユーザーは、v0.34.2で具体的なメモリ問題の修正の恩恵を受けられる。その他の変更点、例えばSafetensorsの安定化、トークン繰り返し検出の閾値変更、typical_pの非推奨化、/api/tagsのパフォーマンス向上などは、すでにv0.34.1に含まれている内容であるため、v0.34.2にアップデートすればそれらも自動的に利用できることになる。したがって、基本的には最新バージョンであるv0.34.2へのアップデートが推奨されると言えるだろう。