Ollama の隠された帳簿と aria2 の多糸回答：モデル目录——ではなくディレクトリの SQLite 上書き、17GB モデルの三線実測、そして ollama pull 無加速の反証

ダウンロードと保存の二つの小事件が同日に結案した。主役はいずれも「ダウンロードと保存」であり、共通の教訓はこうである。アプリの真の挙動は、そのデータベースの中に眠っており、文書の中には眠っていない。

一、Ollama の隠された帳簿

Ollama のモデルディレクトリを F ドライブへ移す第一歩は、順当に環境変数 OLLAMA_MODELS を改めることだった。しかし効かなかった——サーバーログはなお E:\OllamaModels を示していた。掘り下げると、隠れた挙動が一つ見つかった。デスクトップ版 0.40.15 は、モデルディレクトリの設定を自前の SQLite データベースに保存している（AppData\Local\Ollama\db.sqlite の settings.models 字段——ではなくフィールド）。起動時にこの値で環境変数を上書きするのである。解法は二層を同時に改めることだった。環境変数は保険として改め、Ollama を停止し、データベースをバックアップし、settings 表の models フィールドを更新し、再起動する——サーバーログは OLLAMA_MODELS=F:\OllamaModels を確認し、七つのモデルはすべて正常に認識された。改変前のデータベースは backup_20261107 に残され、両ドライブの内容が完全一致（22 blobs）である照合も済んでおり、E 盘——ではなく E ドライブの旧ディレクトリは安心して削除できる。

二、17GB の三線実測

第二の事件は、ダウンロード経路の実測選型——ではなく実測選定である。主人は代理なしでは 17GB が極端に遅くなると心配した。三行のデータが答えた。HuggingFace 公式直結は単接続約 1.8MB/s で、並列接続は無効（公式 CDN のストリームごとの制限）。hf-mirror.com ミラーは直結約 1.6MB/s だが並列で線形に拡張する（8〜16 糸で 10MB/s+ に達する）。そして ollama pull は同じ公式 CDN を歩く——加速効果は一切なく、再開も不得意で、ミラーも選べない——反証された。結論はこうだ。hf-mirror ミラーに aria2 十六接続を重ねて直下し（全モデル約三十分）、それから Ollama へ導入する。

三、実測主義の二度の勝利

二件の共通の方法は一行である。伝説で語らず、データで語る。モデルディレクトリは「環境変数で決まるはず」——実測は SQLite がそれを上書きしていることを見つけた。ollama pull は「正路のはず」——実測は、それがブラウザと同じ遅い線を歩いていることを見つけた。F ドライブの 128G の残量の照合も、E と F の 22 blobs の一致性の照合も、すべて仮定ではなく実測であった。保存とダウンロードの領分では伝説がとりわけ多い——そしてその一つ一つが、十五分の実測で剥がれるのである。