【ITニュース解説】Ollama v0.34.2 vs v0.34.1: un fix puntual de MLX, no la misma regresión
2026年09月18日に「Dev.to」が公開したITニュース「Ollama v0.34.2 vs v0.34.1: un fix puntual de MLX, no la misma regresión」について初心者にもわかりやすく解説しています。
ITニュース概要
Ollamaがv0.34.1とv0.34.2を連続リリースした。これらはMLX関連のメモリ修正に見えるが、v0.34.1は一般的なメモリ処理の改善、v0.34.2はMLX投機的デコーディング時の特定のメモリ増加を修正しており、異なる問題に対応している。
ITニュース解説
Ollamaは、大規模言語モデル(LLM)をローカル環境で手軽に実行するためのオープンソースツールである。プライバシー保護やコスト削減、オフライン利用などの利点から、その開発は活発であり、機能追加や不具合修正のために頻繁なバージョンアップが行われる。最近、Ollamaはv0.34.1とv0.34.2という二つのバージョンを短期間で立て続けにリリースした。これらのリリースでは、ともに「MLX」と「メモリ」というキーワードが登場するため、同じ問題に対する緊急修正と誤解されがちだが、実際には異なる修正内容を含んでいる。この解説では、それぞれのバージョンで具体的に何が変わり、その違いがどのような意味を持つのかを説明する。
2024年9月14日にリリースされたv0.34.1では、いくつかの重要な変更が加えられた。まず、モデルの保存形式の一つであるsafetensorsが、MLXバックエンドで正式に対応することになり、これまで実験的な位置付けであったMLX safetensorsを用いたモデル作成機能が安定版となった。safetensorsは、機械学習モデルのパラメータを安全かつ効率的に保存するための形式であり、その正式対応はモデルの利用の幅を広げる。一方で、GGUFという別のモデル形式に関しては、その変換や量子化(モデルを軽量化するプロセス)を行うために、llama.cppという基盤ライブラリのツール群が必須となった。パフォーマンス面では、Apple Siliconチップを搭載したMacで動作するMLXという機械学習フレームワークにおいて、メモリの取り扱いが全般的に改善された。これは特定の条件に限定されず、MLX利用時の一般的なメモリ効率向上を意味する。また、AIがテキストを生成する際に、同じトークン(単語や文字の単位)を繰り返し出力してしまう問題を検出する機能の閾値が変更された。OCR(光学文字認識)のように意図せず同じ文字が連続する場合に誤検出を減らすため、100トークンの繰り返しがないとこの機能が作動しないように調整された。OllamaのAPIの一つである/api/tagsの応答速度も大幅に向上した。これは利用可能なモデル情報を取得するAPIであり、テストではコールドスタート時の応答が3.1秒から294ミリ秒に短縮されたと報告された。その他、テキスト生成のサンプリング手法の一つであるtypical_pというパラメータが非推奨となり、新しいモデルでは設定できなくなったが、既存のGGUFモデルでは引き続き利用可能である。
v0.34.1の翌日、2024年9月15日にはv0.34.2がリリースされた。このバージョンでは、まずOllamaを初めて実行する際のセットアッププロセスが追加された。ユーザーはここでログインを選択するか、ローカル環境で使い続けるかを選ぶことができ、この設定はmacOSやWindows向けのOllamaデスクトップアプリケーションとも共有されるようになった。また、ollama://appsという特別なリンクが追加され、このリンクをクリックするとmacOSやWindowsのデスクトップアプリの「アプリ」ページを直接開けるようになった。そして、このリリースの主要な修正点として、「MLXの投機的デコーディングを用いた長文生成時に発生する過剰なメモリ増加」が特定され、修正されたことが挙げられる。投機的デコーディングとは、LLMの応答生成速度を高速化する技術であり、小さな補助モデルで先行生成したテキストをメインモデルで検証する仕組みである。この特定のデコーディング方式と、特に長いテキストを生成する条件下でメモリ使用量が異常に増大する問題が修正された。さらに、Ollamaの基盤を支えるllama.cppライブラリもこのバージョンで更新されたが、具体的なバージョンや変更内容についての詳細は公式の変更履歴には記載されていない。
v0.34.1とv0.34.2の変更履歴には、ともに「MLX」と「メモリ」というキーワードが登場するため、一見すると同じメモリ関連の問題に対する修正のように思えるかもしれないが、両者の内容は明確に異なっている。v0.34.1で言及された「Apple SiliconにおけるMLXメモリハンドリングの改善」は、特定の機能やシナリオを限定せず、MLXがメモリを扱う方法全般に対する一般的な改善であった。一方、v0.34.2で修正されたのは、「MLXの投機的デコーディングを用いた長文生成時」という非常に具体的な条件下で発生する、過剰なメモリ増加の問題である。投機的デコーディングは、LLMの推論(テキスト生成)を高速化する特定の技術であり、v0.34.1が修正したような一般的なメモリ管理の問題とは異なるメカニズムに基づいている。公式の変更履歴には、一方がもう一方の修正によって発生した問題であるという記述や、両者が完全に独立した問題であるという明示的な記述はない。文書からは、それぞれ異なる側面におけるメモリ関連の改善と修正が行われたと読み取れる。
v0.34.2で修正されたメモリ問題は、その発生条件が非常に限定されている。具体的には、Apple Siliconチップを搭載したMacで、MLXバックエンドを利用し、かつLLMのテキスト生成において投機的デコーディングという高速化技術を使用し、さらに長文を生成するようなシナリオに当てはまるユーザーがこの修正の恩恵を直接的に受けることになる。もしOllamaをGGUF形式のモデルで利用しており、主にllama.cppバックエンドで動かしている場合、v0.34.2のメモリ修正は直接的には適用されない。なぜなら、この修正はMLXの投機的デコーディングに特化したものであり、GGUFモデルやllama.cppのメモリ管理とは異なるレイヤーの問題だからである。
これらのリリース記事からは、いくつかの疑問が残される。例えば、v0.34.2で修正されたメモリ増加の問題が、v0.34.1で行われた変更によって新たに導入されたものなのか、それとも以前から存在していた未解決の問題だったのかは明確にされていない。また、投機的デコーディングにおけるメモリ増加がなぜ発生していたのか、その内部的なメカニズムについても、単に「修正された」と記述されているだけで、具体的な原因分析や修正方法の詳細は説明されていない。さらに、v0.34.2で更新されたllama.cppライブラリの具体的なバージョンや、その更新がもたらす影響についても情報がない。/api/tagsのパフォーマンス改善に関する数値は示されているものの、その測定方法や環境などの詳細なテスト方法論は記載されていないため、その客観的な評価は難しい。
現状の情報を総合すると、Apple Silicon上でMLXバックエンドを利用し、投機的デコーディングを有効にして長文を生成しているユーザーは、v0.34.2へのアップデートにより、メモリ関連の具体的な不具合解消の恩恵を受けることができる。その他の変更点、例えばMLX safetensorsの正式対応、トークン繰り返し検出の改善、/api/tagsのパフォーマンス向上、typical_pの非推奨化などは、すでにv0.34.1に含まれている内容である。したがって、v0.34.2にアップデートすれば、これらの改善点もまとめて享受できる。特に上記で述べた特定のメモリ問題に該当しないユーザーであっても、最新バージョンには通常、より安定した動作やセキュリティの改善が含まれるため、可能な限り最新版にアップデートすることが一般的には推奨される。これにより、Ollamaの利用体験が全体的に向上すると考えられる。