OllamaコミュニティがClefの読み込み時メモリ問題を報告、デフォルトのコンテキスト長が計算バッファを拡大する可能性

Ollamaコミュニティは10月8日、Clef／Clef Flashの読み込みに関する問題を報告した。報告者のWindows 11、Radeon 890M環境では、モデルのコンテキスト長をデフォルトの16,384 tokenにすると、CPU、ROCm、Vulkanの各バックエンドでメモリ割り当てに失敗した。報告には起動パラメーター、バッファサイズ、エラーログが添付され、検証可能な診断の手がかりが示されている。コミュニティの報告

ログで重要なのは、Ollamaが下位のllama-serverを起動する際に-b 512 -ub 512を渡している一方、実際の初期化結果ではn_batchとn_ubatchがn_ctxと同じ16,384に設定されていた点だ。報告者は、コンテキスト長に応じて計算バッファが大きくなることを確認した。ROCmの容量見積もりでは、当初約18.7 GBの空きが示されたが、その後、約3.3 GBのバッファを割り当てようとして失敗した。これは容量見積もりと実際の割り当てとの間にずれがある可能性を示しているが、根本原因はメンテナーによってまだ確認されていない。診断ログ

一時的な回避策として、派生モデルを作成し、PARAMETER num_ctxを4096に変更する方法がある。公式のModelfileドキュメントでは、FROMで既存モデルを引き継ぎ、PARAMETER num_ctxでコンテキストサイズを指定できることが確認できる。この変更により処理できる入力範囲も狭まるため、導入前にタスクの要件を確認する必要がある。公式ドキュメントはまた、コンテキスト長を大きくすると、モデルの実行に必要なメモリも増えると説明している。Modelfileドキュメント、コンテキスト長のドキュメント

工学的な観点からは、この事例を受けて、マイクロバッチ設定、コンテキスト設定、メモリ見積もりの整合性を確認する価値がある。開発者は、重みのサイズだけで読み込み可否を判断せず、起動コマンド、初期化ログ、実際のバッファ割り当てを照合できる。現時点の証拠は、報告者のハードウェアとテスト構成1件に限られており、すべてのプラットフォームに影響が及ぶと結論づけることはできない。今後は、上流がバッチ設定の挙動を確認するか、また容量見積もりとコンテキスト長の自動縮小の両方を対象とする修正が行われるかに注目したい。確認時点で、このissueはオープンのままで、関連する修正は記載されていない。issueの状態