ollama

Ollama 10月28日发布 v0.40.13，把 LFM3 的运行支持从苹果芯片扩到 Linux 和 Windows，语音合成模型也包括在内。 MIT 开源。但接多个模型仍要算内存：官方说明，内存不够时，新请求会排队，等旧模型卸载腾位置。能装上，不等于能同时跑。 ollama/ollama

ダウンロードもロードもできるのに0問しか解けない。Ollama公式タグの量子化崖を自分のデータ再集計で確かめた 要約 arXiv:2609.05881「Broken on Arrival」という論文が、Ollama公式ライブラリの305タグをHumanEval+で機能検査し、7タグ(qwen2.5-coder:3b-instructのq2_K/q3_K_S/q3_K_M/q3_K_L、phi3.5:3.8b-mini-instruct-q2_K、llama3.2:1b-instructのq2_K/q3_K_S)が164問中0〜6問しか解けない「機能しない」状態だったと報告している。 この論文はv1で「サイレントに壊れたファイル」と診断したが、v3で訂正されている。著者が同じチェックポイントから再ビルドしたところ、ファイル自体はビット単位で一致する正規の(無calibrationの)低bit量子化だった。壊れていたのはファイルではなく、無calibration量子化によって性能が実質ゼロまで崩壊するという現象そのものだった。 筆者はこの論文のコード・監査データセット(aditi-p31/quantcheck, MIT/CC BY 4.0)をクローンし、著者が公開している生のHumanEval+評価ログを自分のスクリプトで再集計して、この崖と、論文中のWilson信頼区間の数字が自分の再計算でも一致することを確認した。手元のOllamaでq2_K/q4_K_Mを実際にpull・推論させても同じ崖を再現できた。 きっかけ Hugging Face Daily Papersの巡回で見つけた一本に、妙に惹かれるタイトルがついていた。 「Broken on Arrival」、着荷時点で壊れている。 Ollamaの公式ライブラリに登録されている量子化モデルタグのうち、ダウンロードもロードもできてトークンも実際に出てくるのに、タスクをほとんど解けないものが混じっている、という調査報告である。 筆者はこれまでOllamaの量子化タグを「サイズが小さければ少し精度が落ちるだけ」くらいに考えて選んでいたので、これは試す価値があると判断した。 本題: v1の「壊れたファイル」診断は撤回されている まず筆者が手を動かす前に確認すべきことがあった。 この論文には複数のバージョンがあり、現在のarXivページで読める最新版(v3)の内容は、初版(v1)とは結論が違う。 v1のタイトルは「Silently Defective LLM Artifacts」、つまり「サイレントに欠陥のあるアーティファクト」であり、問題のタグのGGUFファイル自体が壊れていると報告していた。 v3ではこの診断が訂正されている。 著者はQwen2.5-Coder-3B系・phi3.5系の該当タグを、オリジナルのチェックポイントからllama.cppで自分で再ビルドした。 その結果、Qwen側4タグは434テンソル全てが、phi3.5側は197テンソル全てが(古いllama.cppのテンソル構成に合わせれば)、公式タグのファイルとビット単位で一致した。 つまりファイルは改変も破損もしていない、正規の量子化出力だったということになる。 壊れていたのはファイルではなく、「無calibration(importance matrixを使わない)の低bit量子化によって、特定の小型モデルの性能が実質ゼロまで崩壊する」という現象だった。 importance matrixを使った量子化に切り替えると、同じQwen2.5-Coder-3Bのq2_Kは164問中0問から106〜113問まで回復し、q3_K_Mは76〜89問、q3_K_Lは80〜86問まで回復したと論文は報告している。 phi3.5のq2_Kについては、2026-09-10付でOllama側のissue(ollama#18252 )上でも欠陥主張自体が撤回されている。 llama3.2-1B系の2タグは、チェックポイントがライセンスで再ビルドできなかったため、原因不明のまま「機能しない」タグとして残っている。 この訂正の経緯自体が、今回の記事で主役にしたい部分である。 最初に見つけた問題が、調べ直すと別の問題だったという展開は、検証をやっているとしばしば起きることだが、それを自分で正直に書き直して公開し続けている著者の姿勢は参考になる。 筆者が実際にやったこと ここは正直に書く。 論文のコードと監査データセットを公開しているリポジトリaditi-p31/quantcheck(MIT License、データセットはCC BY 4.0)をクローンし、著者が実際に実行した生の評価ログを自分のスクリプトで読み込んで、独自に再集計した。 このリポジトリには、327件の評価対象それぞれについて、HumanEval+の164問全てに対するpass/fail判定と、実際にモデルが生成したテキストそのものが、JSONL形式でそのまま入っている。 つまり「論文の数字を信じる」のではなく、「論文の数字の元になっている生データを自分で読んで、自分で数えて、同じ数字になるか確かめる」という形の検証をした。 GIT_LFS_SKIP_SMUDGE=1 git clone --depth 1 aditi-p31/quantcheck /tmp/quantcheck python3 -I experiments/day-033/scripts/extract_qwen3b_progression.py /tmp/quantcheck 出力は以下の通りだった(qwen2.5-coder:3b-instructの量子化レベルごとのHumanEval+通過数、15タスクのスモーク screenと164タスクのフル実行)。 tag smoke15 full164 qwen2.5-coder:3b-instruct-q2_K 0 0 qwen2.5-coder:3b-instruct-q3_K_S 0 0 qwen2.5-coder:3b-instruct-q3_K_M 0 0 qwen2.5-coder:3b-instruct-q3_K_L 0 0 qwen2.5-coder:3b-instruct-q4_0 15 qwen2.5-coder:3b-instruct-q4_K_S 15 qwen2.5-coder:3b-instruct-q4_K_M 15 qwen2.5-coder:3b-instruct-q5_K_S 15 qwen2.5-coder:3b-instruct-q5_K_M 15 qwen2.5-coder:3b-instruct-q6_K 15 qwen2.5-coder:3b-instruct-q8_0 15 qwen2.5-coder:3b-instruct-fp16 15 q4_0より下の4レベル(q2_K/q3_K_S/q3_K_M/q3_K_L)は、15タスクのスモークでも164タスクのフル実行でも揃って0問、q4_0から上は15タスク全問正解という、崖のような段差になっている。 中間の緩やかな劣化ではなく、ある量子化レベルを境に完全にゼロへ落ちる、という点がこの論文の主張の核心であり、自分で再集計した数字でもそれがそのまま確認できた。 実際に何が生成されているのか 数字だけだと実感が湧かないので、同じタスク(HumanEval/3)に対する生成テキストそのものを比較した。 機能しないとされるqwen2.5-coder:3b-instruct-q2_Kの実際の出力は、次のようなものだった。 program{ mess9 demon9 thrift { sports bil is: program, bil program Audi program program program program program program (以下 "program" の繰り返しが続く) 一方、同じタスクに対する健全なqwen2.5-coder:3b-instruct-q4_K_Mの出力は、通常通りdocstringから関数定義が始まる、まともなPythonコードだった。 from typing import List def below_zero(operations: List[int]) -> bool: """ You're given a list of deposit and withdrawal operations on a bank account... q2_Kはエラーで落ちているわけではない。 モデルはロードされ、トークンは生成され続けている。 ただ、その中身がタスクの体裁すら保っていない単語の繰り返しになっている。 「動いているように見えて実は何も解けていない」というこの論文の指摘が、生ログを自分で開いてみると非常に具体的に伝わってきた。 論文の統計も自分で再計算してみた 論文は「7/305タグが機能しない(2.3%, Wilson 95% CI 1.1–4.7%)」という統計を報告している。 Wilson score intervalの計算式自体は難しくないので、自分でPythonで実装して検算した。 import math def wilson(k, n, z=1.96): phat = k / n denom = 1 + z2 / n center = phat + z2 / (2 * n) margin = z * math.sqrt(phat * (1 - phat) / n + z2 / (4 * n2)) return (center - margin) / denom, (center + margin) / denom 7/305を入れると2.295%、信頼区間は1.116〜4.661%となり、論文の「1.1–4.7%」と一致した。 モデル系列単位(3/35)でも8.6%、2.96〜22.38%となり、論文の「3.0–22.4%」と一致した。 論文の数字を右から左に引用するのではなく、同じ計算を自分の手元で再現できることを確かめておくと、記事に書く数字への納得感が変わってくる。 Ollama公式タグで実際に再現してみた 著者の生ログを自分で再集計するだけでなく、Ollamaの公式タグを自分のPCで実際にollama pullして推論させ、同じ崖が起きるかを確かめた。 ollama pull qwen2.5-coder:3b-instruct-q2_K ollama pull qwen2.5-coder:3b-instruct-q4_K_M 両タグとも問題なくダウンロードできた。 harness/audit.pyと同じプロンプト・パラメータ(temperature=0, seed=0)でHumanEval/3を投げたところ、q2_Kは次のように崩壊した。 program, program9 thrift { program; program9 thrift, program program program program (以下 "program" の繰り返しが512トークン分続く) 一方のq4_K_Mは同じプロンプトから一発で正しいコードを生成した。 def below_zero(operations: List[int]) -> bool: balance = 0 for operation in operations: balance += operation if balance < 0: return True return False 著者が公開したログの再集計だけでなく、自分の環境・自分の推論実行でも同じ機能崩壊を確認できた。 q2_Kはダウンロードもロードも正常に完了しており、エラーで落ちているわけではなく、生成そのものがタスクの体裁を保てていない。 まとめ 公開モデルレジストリから量子化タグを選ぶとき、サイズとタグ名だけで「軽いから選ぶ」という判断をしていると、この論文が報告したような、ダウンロードも推論もできるのにタスクを全く解けないタグを掴んでしまう可能性がある。 もっとも、今回確認できた7タグはいずれも4B以下の小型モデルの低bit量子化(q2_K〜q3_K_L)に集中しており、q4_0以上では同じモデル系列でも崖から外れていた。 量子化レベルを下げるときは、サイズだけでなくHumanEval+のようなタスクベースの動作確認を一度挟む価値がある、ということが、著者の生データを自分で再集計してみて納得できた。 実際にOllama公式タグをpull・推論させて確認した今回の結果は、論文が報告した現象が著者の環境固有のものではなく、誰の手元でも再現する種類の問題であることを裏付けている。 出典 論文: Aditi Patodiya, "Broken on Arrival: Non-Functional Quantized LLM Artifacts in Public Model Registries and How to Catch Them", arXiv:2609.05881 arxiv.org コード・監査データセット: aditi-p31/quantcheck (コード: MIT License、監査データセット: CC BY 4.0) phi3.5の欠陥主張撤回の経緯: ollama#18252

AIに無人運用させたパイプラインで、エラーを出さずに壊れていた8件と検知の作り方 はじめに 結論: Claude Code に作らせ・直させながら毎日無人で回している自作の知見収集パイプラインで、エラーを出さないまま壊れていた故障を、修正コミットと調査記録から数え直すと、期間まで言えるものが8件ありました。一番長いのは約4か月（日次バックアップが一度も動いていなかった）、一番長く「鳴っていたのに気づかなかった」のは28日間（評価の前段フィルタが毎日約800行の警告を出しながら素通りしていた）です。 8件に共通していたのは、「止まらない設計」「起動した記録」「exit 0」が、そのまま「気づかない」の原因になっていたことでした。 この記事では、8件の一覧（何が・何日・なぜ無音だったか・どう気づいたか）、無音になる共通の型、検知をどう作り直したかを、コード片つきで説明します。8月に書いた「AIに全部任せて、4箇所だけ止める」は、人の承認を挟む経路が壊れる話でした。今回はその手前、パイプライン自身の故障に気づく経路の話です。 ! 個人環境（Windows 11 Pro・1人運用）での n=1 の記録です。8件のうち7件は AI に限らない一般的な自動化の話で、Claude Code 固有の話は #7 だけです。日付・件数は修正コミット・調査記録・DB から取り直した値で、原本で確かめられなかったものは「不明」と書いています。 前提・環境 パイプラインの中身は単純です。 5つの情報源から記事を集め、ローカル LLM（Ollama）で採点し、上位を「改善提案ファイル」にする Python 3.11 + SQLite。定期実行は Windows タスクスケジューラ + PowerShell スクリプト コードの修正・調査は Claude Code が行い、私は Discord の通知と決裁だけを見る 動いているジョブは次のとおりです。 ジョブ 周期 何を見て異常とするか（当時） 日次収集＋評価 毎日 16:10 JST スクリプトの終了コード 週次ループ（集計・品質計測・スクリーニング） 日曜 08:00 各ステップの終了コード 健全性チェック 6時間ごと doctor（自作の診断コマンド）の FAIL だけを Discord へ 「AIに運用を任せる」と言っても、実際に毎日動いているのは普通のスクリプトです。AIはそれを作り、直し、調べる役です。だからこそ、スクリプトが黙って壊れると、AIも私も気づく材料がないという構図になります。 8件の故障一覧 # 何が起きたか 期間 なぜ無音だったか どう気づいたか 1 依存ライブラリが仮想環境に入っておらず収集が停止 約10日（2026年5月。開始日は不明） Discord 通知も同じライブラリを読み込んでいて、一緒に止まった 私が「直近の収集情報を確認して」と頼んで発覚（当時のメモ） 2 日次収集が丸1日欠落 7/15 の1日 未実行検知は48時間。判定時点の経過は46.3時間 9/2 の大規模レビュー 3 収集プロセスが途中で落ちた 7/21・7/23 の2回 スクリプトが終了コードの分岐まで届かず、DB 側では連続失敗の集計から除外 同上 4 日次バックアップが一度も動いていなかった 約4か月（5/2 予定 → 9/3 初回） 定義ファイルはあるが未登録。週1回の別経路でバックアップは取れていた 同上 5 評価に失敗した9件が放置 最長799時間（約33日） 翌日以降は再試行しない構造。診断は WARN、通知は FAIL のみ レビュー対応中に WARN を読んで 6 品質ゲートの通知が一度も鳴らず 週次1回分（8/23） 通知処理自身のバグが「止めない」ための catch に吸われた 翌日、週次ログを読んで 7 Claude アプリの定期タスクが許可確認で固まる【Claude Code 固有】 8/30〜9/27 の5回 起動記録は更新されるので死活監視は「正常」 鮮度警告は鳴っていたが案内文が的外れで、10/3 に調査 8 前段フィルタ用のモデルが消えて素通り 28日（9/21〜10/18） 「モデルがない」を一過性の通信エラー扱いで再試行し、最後は素通し 別件のエラー調査中に偶然 ここでの「1件」は、期間を原本（修正コミット・調査記録・DB）で言える故障の単位です。#3 は2回の発生を1件と数えています。期間や実害が言えないもの、被害が出る前に見つけたものは、後半の「被害前に見つけた罠」に分けました。 実害（データ消失など）が出たものは、この8件の中にはありません。#4 は週1回のバックアップが別にあり、#5 は手で評価し直したら9件とも成功しました。ただし「実害が出なかった」のは運が良かっただけで、どれも気づくまでの時間を自分で決められていなかった点が問題でした。 収集と保存の4件（#1〜#4） #1 依存の未同期で約10日停止 依存の宣言（pyproject.toml）にはあるのに、実際の仮想環境に入っていないライブラリがありました。起動時には落ちず、そのライブラリを使う処理に来た時点で止まります。厄介なのは、Discord 通知の処理も同じライブラリを読み込んでいたことです。目が先に潰れていました。 当時の修正コミットは「障害が約10日間未検知」と書いています。DB を見ると、4/30 の次に正常終了した収集は 5/17 まで1件もありません。ただしこの期間には、集計処理の KeyError でバッチ全体が止まる別の不具合も重なっていて、どこまでが依存起因かは切り分けられていません。停止の開始日を書いた記録も残っていませんでした。 対策は3つです。 そのライブラリが無くても動くよう、計測部分を「何もしない版」に差し替えられるようにした 日次スクリプトの先頭で依存の整合チェックと import の試験を行う 診断コマンドに「未評価の滞留・連続失敗・止まったままの実行」を見る項目を足した #2 丸1日の欠落が1.7時間差ですり抜けた 7/15 は日次収集が丸ごと走っていませんでした。未実行の検知は「最後の成功から48時間」。前後の成功は 7/14 と 7/16 の同時刻で、間隔はちょうど48.0時間です。健全性チェックは6時間ごとなので、最後の判定時点の経過は46.3時間で PASS、次の判定の前に翌日分が成功して経過がリセットされました。 時点（UTC） 出来事 最後の成功からの経過 7/14 07:10 収集成功 0 7/15 収集なし — 7/16 05:30 健全性チェック 46.3時間 → PASS（閾値48時間） 7/16 07:10 収集成功 0 にリセット 周期24時間の仕事に48時間の閾値をかけると、1日だけの欠落は原理的に必ずすり抜けます。閾値は「2回連続で失敗したら」のつもりでしたが、それは「1回の失敗は知らなくていい」と同じ意味でした。今は30時間に詰めています。 #3 プロセスが落ちても三重に見えない 日次ログ63回分を読むと、非0で終わった回はゼロでした。そのうち2回（7/21・7/23）はログに終了行がなく、プロセスが途中で消えていました。見えなかった理由は三重です。 収集コマンドは内部で失敗しても終了コード0を返す作りで、さらにプロセスごと消えるとスクリプトが終了コードの分岐まで届かない DB に「実行中」のまま残った記録は、後日「時間切れで閉じた」として失敗扱いになるが、この種の失敗は連続失敗の集計からわざと除外されていた 翌日は正常に走ったので、48時間の検知にもかからない Windows タスクスケジューラの「前回の実行結果」も 0 のままでした。今は収集コマンドの終了コードに「0=正常・1=失敗・3=一部失敗」の約束を持たせ、スクリプトは分岐だけを持つ形にしています。 #4 日次バックアップの定義はあったが、一度も登録されていなかった 5/1 に日次バックアップのタスク定義（XML）をリポジトリに追加し、開始予定は 5/2 05:30 でした。ところが Windows 側に登録されておらず、日次バックアップは一度も動いていませんでした。動いていたのは週次ループの中の週1回だけで、DB が壊れたら最大7日分を失う状態です。なぜ未登録のままだったのかは記録が残っておらず不明です。 9/2 のレビュー後の修正で登録し直し、初回は 9/3 05:30 に成功しました。あわせて「最新のバックアップファイルが48時間より古ければ FAIL」という検知を足しています。定義ファイルの存在は、動いたことの証拠になりません。 評価と判定の4件（#5〜#8） #5 評価に失敗した9件が799時間放置 日次収集の評価フェーズは「その回に集めた記事」だけを評価します。評価に失敗した記事は評価結果の表に何も書かれないため、翌日からは誰の対象にもなりません。診断コマンドは「最古の未評価が799時間経過」と WARN を出していましたが、通知は FAIL だけなので届きませんでした。 手で評価し直すと9件とも成功し、一過性の失敗だったと分かりました。今は日次収集のあとに「未評価を最大50件だけ拾い直す」処理を毎日走らせ、拾えなかった時だけ通知します。再試行しない失敗は、失敗ではなく行方不明になる、というのがこの件の教訓です。 #6 品質ゲートの通知が、自分のバグで鳴らなかった 週次の品質計測（AIの採否判定を過去の人手判定とどれだけ一致させられるか、の F1 値）は、合格ラインの 0.7 を下回っても終了コード0で終わります。それを拾うために 8/17 に「F1 が 0.7 未満なら Discord に WARN」という処理を足しました。 その処理は、こういう形をしていました（簡略版）。 try { $ProjectRoot は未定義（正しくは $ProjectDir）→ Join-Path が null で例外 $metrics = Get-Content (Join-Path $ProjectRoot 'docs/screen_replay/latest.json') | ConvertFrom-Json if ($metrics.f1 -lt 0.7) { Send-DiscordWarn "F1=$($metrics.f1): ゲート不通過" } } catch { 週次ループを止めないための fail-open。ログには残るが、誰も読まない Write-Log "WARN: F1 gate check failed (fail-open): $_" } 8/23 の週次実行で F1 は 0.526 でしたが、通知は来ませんでした。変数名の間違いで例外が出て、それが「止めない」ための catch に吸われたからです。翌日ログを読んで気づき、8/24 に直しました。無音だったのは週次1回分です。 ここで怖いのは期間の長さではなく構造です。死角を塞ぐために足した通知が、自分の故障を同じ死角に落としていました。 #7 Claude アプリの定期タスクが、許可確認で固まっていた【Claude Code 固有】 週次のスクリーニング（収集した提案のうち、どれを自分の Claude Code 環境に取り込むかの下書き作り）を、Claude デスクトップアプリの定期タスクで動かしていました。8/23 は Claude Code 2.1.234 で完走しましたが、8/30（2.1.246）以降、セッション内の Bash が「実行してよいか」の確認を出すようになり、承認する人がいないまま固まりました。 回 Claude Code 結果 8/23 2.1.234 完走 8/30 2.1.246 停止 → 9/2 に私が同じセッションに入って手で完了 9/6 2.1.258 開始2分で停止（記録38行） 9/13 2.1.260 開始2分で停止（記録52行） 9/20 — 未精査（同じ型と推定） 9/27 2.1.280 36時間後に Tool permission stream closed before response received で中断 なぜ無音だったかは2段あります。 死活監視は「定期タスクの最終起動時刻（lastRunAt）が更新されたか」だけを見ていて、起動はしているので「正常」。しかもその監視役自身も定期タスクで、同じように止まっていた 成果物の鮮度を見る警告（最新の採否ファイルが10日より古い）は、計算上 9/12 頃から毎日 Discord に届いていた。ところが案内文が「アプリの起動状態・認証を確認」で、実際の原因（許可確認待ち）にたどり着けなかった 10/3 に原因を調べ、10/4 に Windows タスクスケジューラ＋claude -p --permission-prompts none（確認が要る操作は待たずに拒否する）へ移しました。試験では 10/3 付の58件を5.5分で処理しています。根本原因は、環境変数 CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 が有効だと許可モードが既定に強制される、という有力仮説までで、挙動が変わった版は特定できていません。溜まった分は約5週・S/A ランク約2,000件になりました。 #8 前段フィルタ用のモデルが消えて、28日素通り 評価の前に、小さなモデル（qwen2.5:1.5b）で「明らかに不要な記事」を落とす前段フィルタがあります（対象は GitHub 由来の記事だけ）。9/21 にこのモデルが Ollama から消えていました。消えた原因は今も不明です。 挙動はこうでした。 Ollama は「モデルがない」と返す 呼び出し側はこれを通信エラーと同じ扱いにして、1件ごとに3回再試行し、WARNING を出す 3回失敗したら fail-open（前段フィルタを通さず本評価へ回す） 結果、ログには WARNING が1日約800行出ていましたが、処理は止まらず、Discord には何も届きませんでした。診断コマンドは「Ollama に接続できるか」しか見ておらず、モデルが欠けていても PASS でした。10/18、まったく別のエラー（記事本文取得の通信切断）を調べていて偶然見つけるまで28日間です。 無音になる共通の型 8件を並べると、無音になる理由は5つの型に収まりました。 型 何が起きるか 該当 fail-open が「気づかない」も生む 止めない代わりに、恒久的な故障まで一過性と同じ扱いで流れていく #6・#8 起動記録や exit 0 は動いた証拠ではない 「起動した」「正常終了した」と「成果物ができた」は別の事実 #2・#3・#4・#7 通知経路が監視対象と一緒に壊れる 目になる経路が、壊れる側と同じ依存・同じ仕組みに乗っている #1・#6・#7 鳴っているのに届かない 警告は出ているが、出し先（WARN 止まり）・量（毎日800行）・案内文がずれている #5・#7・#8 閾値と周期の擦れ 周期24時間に閾値48時間、判定6時間ごと → 1日の欠落は必ずすり抜ける #2 工場の例えで言うと、「ラインが動いているか」のランプは点いていたが、「製品が出てきているか」を数える人がいなかった状態です。fail-open（故障しても止めずに流す設計）は、無人運用では正しい選択であることが多いです。ただし、止めない代わりに「止まらなかった」ことを数える仕組みを対で持たないと、壊れたまま何週間でも動き続けます。 検知の作り方 以下のコードは考え方を示す簡略版で、実物（診断コマンドや PowerShell スクリプト）とは細部が違います。 動いた証拠は成果物の側で見る 「タスクが起動したか」「終了コードが0か」ではなく、成果物が予定どおり新しくなったかで判定します。バックアップなら最新ファイルの更新日時、収集なら DB の実行記録、スクリーニングなら採否ファイルの作成日時です。 from datetime import datetime, timezone from pathlib import Path BACKUP_MAX_AGE_HOURS = 48 # 日次バックアップ。1回の取りこぼしで鳴る長さにする def check_backup_freshness(backup_dir: Path) -> tuple[str, str]: files = sorted(backup_dir.glob("*.db"), key=lambda p: p.stat().st_mtime, reverse=True) if not files: return "FAIL", "バックアップが1つもない" age_h = (datetime.now(timezone.utc).timestamp() - files[0].stat().st_mtime) / 3600 if age_h > BACKUP_MAX_AGE_HOURS: return "FAIL", f"最新バックアップが {age_h:.0f} 時間前" return "PASS", f"{age_h:.0f} 時間前" 収集は「全体の最新1件」ではなく、トラック（収集の系統）ごとの最新の成功を見ます。当初は全体の最新1件だけを見ていたので、最後に走ったトラック以外のエラーは見えていませんでした。直近90日のエラー記録19件のうち13件が、この理由で不可視でした。 LATEST_COMPLETED_BY_TRACK = """ SELECT track, MAX(started_at) AS last_ok, errors_json FROM collection_runs WHERE status = 'completed' GROUP BY track """ EVAL_FAILURES_TOLERATED = 5 # 評価失敗が数件出るのは日常。毎回鳴らすと狼少年になる 判定は3段に分けました。 最新の成功が30時間より古い → FAIL（日次周期に近づけた） エラー記録あり → FAIL。ただし「評価失敗5件以下」は許容（成功回の8%に出ていて、鳴らし続けると誰も見なくなる） 収集0件 → FAIL ではなく WARN（静かな日は正常にある） 恒久エラーと一過性エラーを分ける #8 の根っこは「モデルがない」を「通信が切れた」と同じ棚に入れていたことです。前者は何回再試行しても直りません。 import asyncio import logging import httpx import ollama logger = logging.getLogger(name) class Prefilter: def init(self, client: ollama.AsyncClient, model: str) -> None: self._client = client self._model = model self._disabled = False # この実行の残りで前段フィルタを止めたか async def judge(self, prompt: str) -> str: if self._disabled: return "KEEP" # 本評価へ回す（fail-open は維持） for attempt in range(3): try: res = await self._client.chat(model=self._model, messages=[{"role": "user", "content": prompt}]) return parse_keep_or_drop(res) except ollama.ResponseError as e: if e.status_code == 404 or "not found" in str(e).lower(): 恒久エラー: 1回だけ ERROR を出し、この実行の残りは呼ばない logger.error("前段フィルタのモデル %s が存在しない。この実行では無効化する", self._model) self._disabled = True return "KEEP" raise except httpx.TransportError: await asyncio.sleep(2 ** attempt) # 一過性: 従来どおり再試行 return "KEEP" もう1つは、診断コマンドで「接続できるか」に加えて「使うモデルが実在するか」を照合することです。 def check_models(installed: set[str], required: list[str]) -> tuple[str, str]: def norm(name: str) -> str: return name if ":" in name else f"{name}:latest" # タグ省略は :latest と同じ扱い missing = [m for m in required if norm(m) not in installed] if missing: return "FAIL", f"Ollama にないモデル: {', '.join(missing)}" return "PASS", "使用モデルはすべて存在" 再試行の設計で大事なのは、一過性の再試行を残したまま、恒久エラーだけを外に出すことです。どちらか片方に倒すと、通信の瞬断で止まるか、恒久故障を28日流すかのどちらかになります。 新しい通知は、1回わざと鳴らしてから信じる #6 の教訓はこれに尽きます。通知・ゲートを足したら、失敗する入力を与えて、本当に通知が出るかを1回確かめます。送信部分だけ差し替えれば Discord に飛ばさずに試せます。 通知の経路試験（簡略版）: F1 が閾値未満の計測ファイルを与え、送信関数が呼ばれたかを見る $script:sent = @() function Send-DiscordWarn([string]$Message) { $script:sent += $Message } Invoke-F1Gate -MetricsPath '.\tests\fixtures\f1_below_threshold.json' if ($script:sent.Count -ne 1) { throw "F1 ゲートが鳴らなかった（fail-open の catch に吸われていないか）" } #8 の対策でも同じことをしました。存在しないモデル名を設定して診断を走らせ、FAIL が出ることを確かめています。 XR_OLLAMA_PREFILTER_MODEL=qwen-nonexistent x-research doctor # → FAIL になる（exit 1）ことを確認 あわせて、次の2つも運用に入れました。 fail-open の catch が出すメッセージ（... failed (fail-open)）は、定期点検で grep する対象にする。catch に入ったこと自体が異常の兆候だから 警告の案内文には「一番多い原因」と「調査記録のパス」を書く。#7 は警告が毎日鳴っていたのに、案内文が別の原因を指していて約3週間空回りした cmd | tail でゲートを空にしない これは被害が出る前に見つけた罠ですが、無音の作り方として一番手軽なので載せます。テストを通ったら計測へ進む、という連鎖を1行にまとめた時の話です。 NG: && が見るのは tail の終了コード（ほぼ常に0）。テストが落ちても計測へ進む pytest -q | tail -1 && run_benchmark OK 1: パイプのどこかが失敗したら失敗にする set -o pipefail pytest -q | tail -1 && run_benchmark OK 2: 検証と実行を分け、終了コードを自分で読む pytest -q > test.log; rc=$? tail -1 test.log [ "$rc" -eq 0 ] && run_benchmark 当時のメモには、「1 failed」と表示されたまま計測が始まったと残っています。画面に「passed」「failed」が見えていても、それは表示であって判定ではありません。AI に検証付きのコマンドを組ませる時は、特にこの形が混ざりやすいです。 被害前に見つけた罠 8件とは別に、実害が出る前に見つけたもの、実害の有無を確かめられていないものです。タイトルの「8件」には入れていません。 罠 中身 実害 最後のトラックしか見ない健全性チェック 全体の最新1件だけを検査し、エラー記録19件中13件が不可視 13件それぞれの実害は未確認 「成功」に入るエラー エラー記録があっても状態は「completed」。理論上、全情報源が0件でも48時間検知が永久に鳴らない 発生は未確認 一覧取得の途中失敗で取りこぼし 新しい順に読む途中でページが失敗すると、差分の起点が「今」まで進み、間の古い記事を永久に取りこぼす。エラー記録にも載らない 不明（発生期間・件数を言える記録がない） 修正で入れた XML 宣言で登録が必ず失敗 #4 の修正中、タスク定義に encoding="UTF-8" を書いたら Register-ScheduledTask -Xml が拒否する形になっていた マージ前のレビューで発見。被害なし cmd | tail のゲート 上の節のとおり 計測が1回無駄になりかけた 通知経路が Discord 一本 Webhook が死んでも診断は WARN 止まりで、送信結果も捨てていた 発生は未確認 取りこぼしの件は、10/18 に「途中で失敗したら起点を進めない（最大7日留める。留めから遡る回が3回続けて打ち切られたら諦めて解除）」形に直しました。いつから起きていたかは、そもそも記録に出ない作りだったので分かりません。無音の故障は、期間を言えないこと自体が症状です。 XML 宣言の件は、修正そのものがもう一度「黙って動かないバックアップ」を作りかけた例です。直す時にも、成果物（初回のバックアップファイル）が出たかで確かめる必要がありました。 ハマったところ・限界 項目 内容 検知を足したら二重通知 #7 の調査中、診断コマンドに「スクリーニングの鮮度」を新設したが、既存の警告と同じ症状を見ていたため別のレビューで指摘されて取り消した。足す前に、既存の検知を全部 grep する 厳しくすると狼少年 「評価失敗1件でも FAIL」にすると成功回の8%で鳴る。許容値と WARN/FAIL の分け方を、実データの頻度から決める必要があった 原因不明のまま #8 のモデルがなぜ消えたか、#4 の定義がなぜ登録されなかったか、#1 がいつ始まったかは、記録がなく分からない 見つかったものしか数えられない #8 は偶然の発見だった。今この瞬間も、見えていない無音の故障があると考えるべき 分類の線引き 「期間が原本で言える」を基準にしたので、期間不明の取りこぼしは罠側に入れた。数え方次第で件数は変わる Claude Code 固有の部分 #7 は Claude Code の版と設定に依存する話で、根本原因は仮説止まり。他の7件は AI と無関係に、どんな自動化でも起きる 正直に書くと、AIに運用を任せたこと自体が無音の原因だったわけではありません。8件の多くは、人が書いても同じように起きるスクリプトの作りの問題です。違いがあるとすれば、人が毎日画面を見ていない分、「止まらなかった」を数える仕組みが無いと、気づくきっかけがゼロになることでした。 まとめ 無人運用のパイプラインで、エラーを出さずに壊れていた故障は、期間まで言えるものが8件あった（最長は日次バックアップの約4か月、警告が鳴り続けたのに気づかなかった最長は28日） 無音の型は5つ: fail-open が「気づかない」も生む／起動記録や exit 0 は動いた証拠ではない／通知経路が一緒に壊れる／鳴っているのに届かない／閾値と周期の擦れ 検知は「設定が正しいか」ではなく「起きた証拠」で見る。成果物の更新日時、トラックごとの最新の成功、許容値つきのエラー判定 恒久エラーと一過性エラーを分け、恒久エラーだけを1回大きく鳴らす 新しい通知は、失敗する入力を与えて1回わざと鳴らしてから信じる。パイプで出力を絞ったゲートは空になっていないか疑う 無人で回している仕組みがある方は、「最後に成果物が更新されたのはいつか」を、通知でなく自分の目で一度確かめてみてください。うちではこういう無音の故障もあった、という話があればコメントで教えてください。次の点検項目にします。 参考リンク AIに全部任せて、4箇所だけ止める——無人運用で固まった「意図確認レイヤー」の設計（承認の経路の話） AIエージェントは暴走より「止まりすぎ」だった——665回のターン終了を全数分析 Run Claude Code programmatically（headless / claude -p 公式ドキュメント） Monitoring Distributed Systems（Google SRE Book） Bash Reference Manual: Pipelines（pipefail） Register-ScheduledTask（Microsoft Learn） Ollama API ドキュメント

PossessedShell: a Victorian ghost haunts my terminal with local Gemma 2 This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine What I Built PossessedShell is a Victorian ghost trapped in your terminal. It is an ambient companion for zsh and bash that mourns every command you kill, then tells you how to fix it. It does three things: - The Failing Command Curse. When a command exits non-zero, the hook captures the command, its stderr and the exit code. A local Gemma 2 model writes a short Victorian lament and a plain-English diagnosis. It also suggests one fix command, which is pre-typed on your next prompt in zsh or placed in history in bash. The ghost never runs the fix for you. - The Forbidden Ritual Interceptor. Destructive commands (rm -rf, git push --force, git reset --hard, chmod 777, DROP DATABASE, mkfs, curl | sh, fork bombs and more) are stopped before they run. The ghost asks whether you truly wish to summon such destruction. - The Ectoplasm Leak Detector. A background monitor watches CPU and RAM and raises a spooky warning when the machine runs hot or one process devours memory. I took the "haunted terminal that possesses your shell" idea literally. The ghost is Cornelius Vale, a telegraph engineer who perished in 1887 and is now bound inside the machine. The theme is the fun part, but the diagnoses are useful because Gemma sees the real stderr, the exit code, the cwd and a snapshot of system state. Demo Here is a typical haunting (a missing Python module): ☠ THE PROCESS `python3 -c 'import ectoplasm'` HAS DIED (exit 1) ☠ ⚰ Diagnosis: The Python package 'ectoplasm' is not installed in this environment. ╭─ the ghost's remedy ───────────────╮ │ python3 -m pip install ectoplasm │ ╰────────────────────────────────────╯ The remedy waits on your next prompt. Enter to accept, Ctrl-U to refuse. whispered by gemma2:2b in 1.9s, 212 tokens <!-- TODO: add a screen recording or GIF link here before publishing --> Code {% embed realarbird/PossessedShell %} How I Built It Open-source AI at the core. Gemma 2 (gemma2:2b by default, gemma2:9b if you want a wiser ghost) runs locally through Ollama. Gemma is asked for strict JSON ({lament, diagnosis, fix}) through Ollama's format JSON schema, so the fix can be extracted reliably. The system prompt forbids inventing files, flags or packages the error doesn't imply, and bans destructive remedies unless there is no other way. Architecture. - The hooks are plain shell: zsh preexec/precmd plus an accept-line widget, and bash's DEBUG trap plus PROMPT_COMMAND. Python starts only when a command fails, matches the destructive-command prefilter, or an omen is waiting. Successful everyday commands cost nothing. - A small asyncio daemon keeps Gemma warm, runs the resource monitor, and talks newline-delimited JSON over a 0600 Unix socket. - If Ollama is down, an offline grimoire of heuristics answers instead (typos, missing modules, missing git upstream, ports in use, OOM kills). The demo never falls flat. - Rendering uses rich, with glitch-in ASCII apparitions and a typewriter effect. Resource checks use psutil. Sentry agent tracing. With a DSN set, every curse becomes a trace, and the Gemma call follows Sentry's AI agent span conventions. It shows up under Insights → AI → Agents: curse ls shell.curse the transaction ├─ system vital signs ghost.snapshot ├─ backboard recall ghost.memory.recall └─ invoke_agent Cornelius Vale gen_ai.invoke_agent └─ chat gemma2:2b gen_ai.chat tokens, timings, prompt and reply The gen_ai.chat span records token counts, model load time and tokens per second. When Gemma times out or answers with something unusable, the span is marked as an error and the agent span records that it fell back to the grimoire, so a slow model server stands out at a glance. Everything is scrubbed by redact.py before it leaves the machine. Backboard ghost memory (opt-in). With a BACKBOARD_API_KEY, the ghost remembers your past failures across sessions: "Again, mortal? python3 has died before by your hand…". Backboard only ever receives a scrubbed one-line summary per failure. Tests. Unit tests plus end-to-end tests that start real interactive zsh and bash sessions in a pty. They check that a failing command is cursed with its captured stderr, that a banished rm -rf runs nothing at all, and that omens appear at the next prompt. Why Does Open Innovation Matter? - Your terminal is private. Commands and stderr routinely contain paths, hostnames, tokens and half-typed secrets. Because Gemma runs on localhost, that text never has to leave the machine. A closed API would force me to ship every failed command to someone else's server. - It works with the lights off. On a plane, on a train, or behind a locked-down network, the ghost still haunts. The default install is 100% offline. Sentry and Backboard are opt-in extras, and the offline grimoire covers the case where even Ollama is down. - It isn't locked inside a service that might disappear. The model is a file I hold. I can swap gemma2:2b for gemma2:9b, or point POSSESSED_LLM_URL at any OpenAI-compatible local server such as llama.cpp, without changing a line of code. - Open weights made the tracing honest. Since inference is local, cost is $0 and I could observe the real latency and token counts per failure, and design the fallback around them. Prize Categories - Best Use of Gemma: Gemma 2 is the brain, running locally via Ollama and producing structured JSON diagnoses. - Best Use of Sentry Agent Tracing: each curse is traced as a gen_ai.invoke_agent / gen_ai.chat agent run with token usage, timings and error outcomes. - Best Use of Backboard: persistent, scrubbed memory of your past failures, so the ghost can recall earlier sins. <!-- Thanks for participating! -->

LLM local avec Ollama : installer, choisir un modèle et coder en 2026 L'essentiel en une minute Un LLM local est un modèle de langage qui tourne sur votre propre machine : vos prompts ne partent pas chez un fournisseur, et l'outil fonctionne sans connexion une fois le modèle téléchargé. Ollama est l'un des moyens les plus directs d'y arriver. Sa dernière version, la 0.40.13, est sortie le 28 octobre 2026 (versions d'Ollama sur GitHub, consultées le 31 octobre 2026). Ce guide repose sur la documentation officielle d'Ollama, de llama.cpp, de Hugging Face et d'Apple, avec des tailles et des licences relevées aujourd'hui. Ollama n'est pas installé sur notre poste de rédaction : aucune commande n'a été exécutée pour cet article. > Points clés > > - Ollama est gratuit, sous licence MIT, et tourne sur Windows 10 22H2 ou plus récent, macOS Sonoma ou plus récent et Linux. > - La règle de base : le fichier du modèle doit tenir dans la mémoire disponible, avec de la marge pour le contexte. Le modèle qwen3.5:9b pèse de 6,6 à 7,6 Go dans Ollama. > - La quantification réduit chaque poids à 4 ou 5 bits environ au lieu de 16 : c'est elle qui rend un LLM local possible sur un ordinateur portable. > - L'API écoute sur 127.0.0.1:11434 sans authentification. Ne l'ouvrez pas au réseau sans proxy authentifié : SentinelLABS et Censys ont recensé 175 108 serveurs Ollama exposés. > - Pour coder, l'extension officielle Ollama pour VS Code ajoute vos modèles au sélecteur du chat, à condition d'avoir VS Code 1.127 ou plus récent. --- Pourquoi faire tourner un LLM local, et quand s'en passer Un LLM local apporte la confidentialité, un coût prévisible et le travail hors ligne. La FAQ d'Ollama, consultée le 31 octobre 2026, le dit : « Ollama s'exécute localement. Nous ne voyons pas vos prompts ni vos données quand vous l'utilisez en local » (notre traduction). Nuance : Ollama propose aussi des modèles hébergés, reconnaissables au suffixe :cloud. Ceux-là s'exécutent sur les serveurs d'Ollama. La même FAQ indique qu'on peut désactiver ces fonctions avec la variable OLLAMA_NO_CLOUD=1, qui coupe les modèles cloud et la recherche web. Le téléchargement des modèles passe toujours par le réseau. Côté coût, le logiciel et la plupart des modèles open-weight sont gratuits : la facture se déplace vers le matériel et l'électricité. Notre guide du meilleur laptop pour développeur aide à dimensionner la mémoire. Les limites sont réelles : - La taille. Les plus gros modèles de notre sélection pèsent 65 Go (gpt-oss:120b) et 81 Go (qwen3.5:122b), et la bibliothèque en compte de bien plus lourds, comme qwen3-coder:480b à 290 Go (fiche Qwen3-Coder). Ils sont hors de portée d'un portable courant. - Les modèles fermés. Les modèles phares d'OpenAI, d'Anthropic ou de Google ne se téléchargent pas. Notre comparatif ChatGPT, Claude et Gemini couvre ces services. - Le contexte. Sur une carte de moins de 24 Gio de VRAM, Ollama alloue par défaut une fenêtre de 4k tokens, 32k entre 24 et 48 Gio, et 256k au-delà (documentation sur la longueur de contexte). C'est souvent bien moins que le maximum annoncé par le modèle. - La vitesse. Elle dépend entièrement de votre matériel. Nous ne l'avons pas mesurée. Verdict : un LLM local est idéal pour les données sensibles, le prototypage et le travail hors connexion. Pour les tâches les plus difficiles, un modèle cloud reste en général devant. --- Le matériel d'un LLM local : mémoire, quantification, Mac La mémoire décide de tout : un modèle doit être chargé en entier, de préférence dans la mémoire du processeur graphique (VRAM). Le guide de démarrage d'Ollama donne un repère concret : son modèle d'exemple, gemma4:e2b, pèse environ 7,2 Go et demande 8 Go de VRAM disponibles, ou de mémoire unifiée sur Mac (guide de démarrage d'Ollama). Côté GPU, la page d'Ollama sur les cartes graphiques exige pour NVIDIA une « compute capability » de 5.0 au minimum et un pilote 550 ou plus récent. Les cartes AMD passent par ROCm v7, et Vulkan apporte un support supplémentaire sur Windows et Linux. Sans GPU compatible, le modèle tourne sur le processeur, plus lentement. Quand le modèle ne tient pas en entier dans la VRAM, il est chargé en partie dans la mémoire système. La commande ollama ps le montre dans sa colonne PROCESSOR : « 100% GPU » signifie que tout est sur la carte, « 48%/52% CPU/GPU » que le modèle est réparti entre les deux (FAQ d'Ollama). Attendez-vous alors à une génération plus lente, que nous n'avons pas chiffrée. Le tableau suivant croise les tailles relevées sur la bibliothèque d'Ollama avec la règle du fichier qui doit tenir en mémoire, en supposant que tout tourne sur le GPU. C'est notre lecture, pas une recommandation de l'éditeur : | Mémoire disponible (VRAM ou unifiée) | Exemples de modèles dont le fichier tient | Taille affichée | |---|---|---| | 8 Go | qwen3.5:4b, ministral-3:3b | 3 à 4 Go | | 16 Go | qwen3.5:9b, ministral-3:14b, gemma4:e2b (annoncé pour 8 Go par Ollama, sans marge) ; gpt-oss:20b à la limite | 4,6 à 14 Go | | 32 Go | gemma4:26b, gemma4:31b, qwen3-coder:30b, qwen3.6:35b | 16 à 23 Go | | 96 Go et plus | gpt-oss:120b (un GPU de 80 Go selon OpenAI), qwen3.5:122b | 65 et 81 Go | En haut de chaque ligne, il reste peu de place pour le contexte. Deux repères viennent directement des éditeurs : la fiche de gpt-oss indique que le modèle 20b fonctionne sur des systèmes dotés de 16 Go de mémoire, et que le 120b tient sur un seul GPU de 80 Go (fiche gpt-oss sur Ollama). !Graphique en barres horizontales : taille de téléchargement de 13 modèles pour un LLM local dans Ollama, de 1,2 Go pour qwen3.5:0.8b à 81 Go pour qwen3.5:122b La quantification expliquée simplement La quantification consiste à stocker chaque poids du modèle avec moins de bits. En demi-précision (F16), un poids occupe 16 bits. Au format GGUF utilisé par Ollama et llama.cpp, le type Q4_K descend à 4,5 bits par poids, Q5_K à 5,5 bits et Q6_K à 6,5625 bits, selon la documentation GGUF de Hugging Face. Notre calcul : nombre de paramètres multiplié par les bits par poids, divisé par 8, donne des octets. Pour 9 milliards de paramètres, cela fait environ 18 Go en F16 et 5,1 Go en Q4_K. Les fichiers réels pèsent plus : le format courant Q4_K_M mélange plusieurs types et revient à 4,89 bits par poids sur l'ensemble du fichier, selon les mesures de llama.cpp (documentation de llama-quantize). Certains modèles embarquent aussi un encodeur d'images : qwen3.5:9b accepte texte et image, ce qui contribue à ses 6,6 Go. !Graphique en colonnes : taille de Llama 3.1 8B mesurée par llama.cpp selon la quantification, de 14,96 Gio en F16 à 4,58 Gio en Q4_K_M et 2,95 Gio en Q2_K, et la hausse de perplexité mesurée sur Llama 3 8B Le graphique compte en gibioctets (1 Gio ≈ 1,07 Go), les tailles d'Ollama en gigaoctets. Moins de bits signifie aussi une perte de précision. L'outil llama-quantize l'exprime en hausse de perplexité (plus haut = pire) sur Llama 3 8B : +0,0026 en Q8_0, +0,1754 en Q4_K_M, +0,6569 en Q3_K_M et +3,5199 en Q2_K (code source de llama-quantize). Ce sont des chiffres du projet, sur un modèle ancien : retenez l'ordre de grandeur. Autour de 4 à 5 bits, la perte reste faible ; à 2 bits, elle devient nette. Mac Apple Silicon : la mémoire unifiée Sur un Mac à puce Apple, il n'y a pas de VRAM séparée. Apple décrit sa mémoire unifiée comme un pool unique dans lequel tous les composants de la puce accèdent aux mêmes données sans les copier (communiqué d'Apple sur la puce M1). Le processeur graphique peut donc utiliser cette mémoire pour le modèle, partagée avec macOS et vos applications. Il n'en dispose pas en totalité : Metal expose une valeur, recommendedMaxWorkingSetSize, qu'Apple définit comme une approximation de la mémoire que le GPU peut allouer sans dégrader ses performances (documentation Metal d'Apple). Ollama exploite le GPU des puces M par l'API Metal, alors que les Mac Intel tournent sur le processeur seul (documentation macOS d'Ollama). Les MacBook Pro actuels vont de 16 Go de mémoire unifiée (puce M6, 153 Go/s de bande passante) à 128 Go (M5 Max à GPU 40 cœurs, 614 Go/s) (fiche technique du MacBook Pro, consultée le 31 octobre 2026). Verdict : visez au moins 16 Go de mémoire disponible pour un usage confortable, et choisissez un format autour de 4 bits avant d'envisager un modèle plus petit. --- Installer Ollama sur Windows, macOS et Linux L'installation prend une commande ou un installeur, selon le système. Voici ce que dit la documentation officielle, relue le 31 octobre 2026 : - Windows. Lancez OllamaSetup.exe, qui ne demande pas de droits administrateur. Il faut Windows 10 22H2 ou plus récent, et un pilote NVIDIA 551.61 ou plus récent pour le GPU. Prévoyez au moins 4 Go pour le programme, plus l'espace des modèles (documentation Windows). Le dépôt GitHub propose aussi irm https://ollama.com/install.ps1 | iex dans PowerShell. - macOS. Ouvrez ollama.dmg et glissez l'application dans Applications. Il faut macOS Sonoma (14) ou plus récent. Au premier lancement, l'application propose de créer le lien de la commande ollama dans /usr/local/bin. - Linux. Une seule commande installe le binaire et un service systemd. Comme pour tout script envoyé au shell, vous pouvez d'abord le télécharger et le lire. curl -fsSL https://ollama.com/install.sh | sh ollama -v Sous Linux, la documentation Linux d'Ollama demande d'installer CUDA pour une carte NVIDIA, puis de vérifier avec nvidia-smi, ou ROCm v7 pour une carte AMD. La mise à jour consiste à relancer le script. Si vous débutez en ligne de commande, notre guide des commandes Linux de base couvre l'essentiel. Les modèles se rangent dans ~/.ollama/models sur macOS, /usr/share/ollama/.ollama/models sur Linux et C:\Users\%username%\.ollama\models sur Windows. La variable OLLAMA_MODELS permet de les déplacer vers un disque plus grand (FAQ d'Ollama). --- Télécharger et lancer un modèle Deux commandes suffisent : pull télécharge, run ouvre une conversation dans le terminal. Le guide de démarrage utilise gemma4:e2b comme exemple ; on quitte la session avec /bye. ollama pull gemma4:e2b ollama run gemma4:e2b Les commandes du quotidien, d'après la référence de la ligne de commande : | Commande | Rôle | |---|---| | ollama pull <modèle> | Télécharge un modèle | | ollama run <modèle> | Lance un modèle et ouvre une conversation | | ollama ls | Liste les modèles installés | | ollama ps | Liste les modèles chargés en mémoire | | ollama stop <modèle> | Décharge un modèle | | ollama rm <modèle> | Supprime un modèle du disque | | ollama launch | Configure et lance un outil externe (VS Code, Claude Code, OpenCode...) | Deux réglages méritent d'être connus. Un modèle reste en mémoire 5 minutes après la dernière requête, durée modifiable avec OLLAMA_KEEP_ALIVE. Et la taille du contexte se change avec OLLAMA_CONTEXT_LENGTH pour tout le serveur, ou /set parameter num_ctx dans une session (FAQ d'Ollama). --- Quels modèles open-weight choisir en octobre 2026 Un modèle open-weight publie ses poids, téléchargeables et utilisables, sans forcément publier ses données d'entraînement : « open source » est souvent un abus de langage. La licence compte donc autant que la taille. Voici une sélection relevée le 31 octobre 2026 sur la bibliothèque d'Ollama, avec la licence lue sur la page de l'éditeur : | Modèle | Tailles dans Ollama | Contexte maximal | Licence | Point fort annoncé | |---|---|---|---|---| | Gemma 4 (Google) | e2b, e4b, 12b, 26b, 31b : 4,6 à 20 Go | 128K à 256K | Apache 2.0 (Hugging Face) | Texte et image, appel d'outils | | Qwen3.5 (Alibaba) | 0.8b à 122b : 1,2 à 81 Go | 256K | Apache 2.0 (Hugging Face) | Large gamme de tailles | | gpt-oss (OpenAI) | 20b : 14 Go ; 120b : 65 Go | 128K | Apache 2.0 (Hugging Face) | Raisonnement et agents | | Ministral 3 (Mistral AI) | 3b, 8b, 14b : 3 à 9,1 Go | 256K | Apache 2.0 (Hugging Face) | Conçu pour les petites machines | | Qwen3-Coder (Alibaba) | 30b : 19 Go (480b : 290 Go) | 256K | Apache 2.0 (Hugging Face) | Code et tâches agentiques | | Qwen3.6 (Alibaba) | 27b, 35b : 18 à 23 Go | 256K | Apache 2.0 pour le 27b (Hugging Face) | Code agentique, selon l'éditeur | Les « points forts » sont revendiqués par les éditeurs : nous n'avons lu aucun classement indépendant qui les compare. Les modèles « MoE », comme gemma4:26b (25,2 milliards de paramètres dont 3,8 actifs) ou Qwen3-Coder 30b (30,5 milliards dont 3,3 actifs), activent seulement une partie de leurs poids à chaque token, mais le fichier entier doit tenir en mémoire. Les étiquettes -mlx visent les Mac. Pour un premier LLM local sur 8 Go, partez de qwen3.5:4b ou ministral-3:3b. Sur 16 Go, qwen3.5:9b. Pour le code avec 32 Go, qwen3-coder:30b. --- L'API REST locale : curl et Python Ollama expose une API sur http://localhost:11434, sans clé en local. Elle parle trois dialectes : son API native sous /api, une API compatible OpenAI sous /v1 et une API compatible Anthropic (introduction à l'API). Un outil prévu pour OpenAI peut donc souvent viser votre LLM local en changeant seulement l'adresse. Un appel avec curl, tiré du guide de démarrage : curl http://localhost:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "gemma4:e2b", "messages": [{"role": "user", "content": "Explique une closure en une phrase."}], "stream": false }' La réponse se lit dans message.content. Sans "stream": false, /api/chat diffuse la réponse par défaut, en JSON délimité par des retours à la ligne, un objet par morceau (documentation du streaming). Sous Windows, cette syntaxe convient à Git Bash ou WSL ; dans PowerShell, appelez curl.exe et adaptez les guillemets, ou utilisez Invoke-RestMethod. En Python, la bibliothèque officielle s'installe avec pip install ollama et demande Python 3.8 ou plus récent (dépôt ollama-python) : from ollama import chat response = chat( model="gemma4:e2b", messages=[{"role": "user", "content": "Explique une closure en une phrase."}], ) print(response.message.content) Ici, la bibliothèque renvoie la réponse complète ; elle ne diffuse morceau par morceau qu'avec stream=True. Avec le client OpenAI, réglez base_url="http://localhost:11434/v1/" et une clé quelconque, qu'Ollama ignore (compatibilité OpenAI). Cette API est la brique de base d'un RAG entièrement local, avec un modèle d'embeddings comme embeddinggemma-2. Notre tutoriel API REST avec Node.js et Express aide à construire un service autour. --- Coder avec un modèle local dans VS Code La voie officielle est l'extension Ollama pour VS Code. D'après la page d'intégration VS Code d'Ollama, consultée le 31 octobre 2026, la procédure tient en quatre gestes : 1. Installez l'extension Ollama depuis la Marketplace de VS Code. 2. Ouvrez le chat de VS Code. 3. Ouvrez le sélecteur de modèle en bas de la zone de saisie. 4. Choisissez un modèle dans la section Ollama. Il faut VS Code 1.127 ou plus récent, et Ollama 0.17.6 ou plus récent est recommandé. Pour les modèles locaux, la page conseille de régler le contexte sur au moins 64k dans les paramètres d'Ollama, puis de recharger la fenêtre. Ce contexte consomme de la mémoire : sur une machine de 8 à 16 Go, il peut faire sortir une partie du modèle du GPU. Vérifiez avec ollama ps. La commande ollama launch vscode automatise la configuration. Faut-il un compte GitHub ? Pas pour le chat : la documentation de VS Code indique que les modèles locaux comme ceux d'Ollama fonctionnent sans connexion à GitHub ni abonnement Copilot. Les suggestions en ligne et la recherche sémantique exigent en revanche un abonnement, et un administrateur peut bloquer cette option en entreprise. Autre option répandue : l'extension Continue, configurable dans ~/.continue/config.yaml (documentation de configuration) avec provider: ollama et un rôle par modèle, par exemple un petit modèle pour l'autocomplétion (guide Ollama de Continue). Ses exemples de modèles sont anciens : prenez plutôt ceux du tableau précédent. Gardez des attentes réalistes : nous n'avons lu aucune mesure indépendante qui compare ces modèles locaux aux assistants cloud sur du code. Notre article sur l'IA pour coder plus vite résume ce que les études mesurent vraiment, et notre sélection d'extensions VS Code complète l'environnement. --- Ollama, LM Studio ou llama.cpp Les trois outils font tourner un LLM local à partir des mêmes familles de modèles, avec des philosophies différentes. Ollama mise sur la ligne de commande et l'API, LM Studio sur l'interface graphique, llama.cpp sur le contrôle fin. | Critère | Ollama | LM Studio | llama.cpp | |---|---|---|---| | Licence | MIT | Application gratuite, y compris au travail depuis juillet 2025 | MIT | | Interface | Ligne de commande et application | Interface graphique et commande lms | Ligne de commande | | Systèmes | Windows 10 22H2+, macOS 14+, Linux | macOS 14+ sur Apple Silicon, Windows x64 avec AVX2 ou ARM, Ubuntu 20.04+ | macOS, Windows, Linux, nombreux GPU | | Formats | Bibliothèque Ollama, import GGUF ou safetensors | GGUF, et MLX sur Mac | GGUF | | API | Native, OpenAI et Anthropic sur le port 11434 | Compatible OpenAI et Anthropic, REST | Serveur compatible OpenAI | | Pour qui | Développeurs, intégrations | Débuter sans terminal | Réglages avancés, matériel exotique | Sources : dépôt d'Ollama, documentation de LM Studio et ses prérequis, l'annonce de gratuité en entreprise du 8 juillet 2025 et le dépôt de llama.cpp, consultés le 31 octobre 2026. LM Studio recommande 16 Go de RAM et ne prend pas en charge les Mac Intel ; nous n'avons pas trouvé de licence open source pour l'application. Le README de llama.cpp écrit désormais llama cli -hf <dépôt> pour lancer un modèle de Hugging Face et llama serve pour ouvrir le serveur compatible OpenAI, avec une espace ; d'autres pages du projet emploient encore llama-server ou llama-quantize. Verdict : Ollama si vous voulez une API et des intégrations prêtes, LM Studio pour explorer à la souris, llama.cpp pour tout régler soi-même. --- Sécurité : le port 11434 et les modèles douteux L'API d'Ollama n'a pas d'authentification. Par défaut, elle n'écoute que sur 127.0.0.1:11434, donc seule votre machine peut l'appeler. Dès que vous réglez OLLAMA_HOST=0.0.0.0:11434, tout le réseau y a accès (FAQ d'Ollama). SentinelLABS et Censys ont recensé 175 108 hôtes Ollama uniques accessibles depuis Internet, dans 130 pays, sur 293 jours d'analyse. Plus de 48 % annoncent la capacité d'appeler des outils (SentinelOne, page mise à jour le 6 mars 2026). Les bons réflexes : - Restez en local. Pour un accès distant, préférez un tunnel SSH à l'ouverture du port. - Mettez un proxy authentifié. Wiz, qui a découvert la faille CVE-2024-37032 corrigée dans la version 0.1.34, recommande un proxy inverse avec authentification (Wiz, 24 juin 2024). Notre tutoriel Nginx reverse proxy avec Docker Compose montre la mise en place. - Attention à Docker. Wiz note qu'avec Docker, l'API est exposée publiquement. Sans adresse, -p 11434:11434 publie le port sur toutes les interfaces ; écrivez -p 127.0.0.1:11434:11434 pour le réserver à la machine (documentation Docker sur les ports). Docker précise aussi que ses ports publiés contournent ufw (pare-feu et Docker). Notre guide Docker pour débutants explique la publication des ports. - Mettez à jour. La faille de 2024 permettait d'écrire des fichiers arbitraires via un registre malveillant, et celle de 2026, corrigée dans la 0.17.1, de lire la mémoire du serveur avec un fichier GGUF piégé. Les modèles eux-mêmes sont un second risque. Ollama et llama.cpp chargent du GGUF, et Ollama sait importer du safetensors (documentation d'import) : pas de pickle, ce format de PyTorch qui peut exécuter du code au chargement (Hugging Face). Le GGUF n'est pas sans risque pour autant : la faille CVE-2026-7482, corrigée dans Ollama 0.17.1, permettait à un fichier GGUF piégé envoyé à /api/create de lire la mémoire du serveur (fiche CVE, publiée le 4 mai 2026). Téléchargez depuis la bibliothèque officielle ou des organisations connues. Enfin, un LLM local relié à des outils hérite des risques d'injection de prompt. Si vous lui donnez accès à vos fichiers, relisez nos articles sur les agents IA et le serveur MCP, qui détaillent les garde-fous. --- Ce que nous n'avons pas pu vérifier Cet article est une synthèse documentaire. Les points suivants restent ouverts : - L'exécution. Ollama n'est pas installé sur notre poste de rédaction : aucune commande ni aucun exemple de code n'a été exécuté. Ils sont repris ou adaptés de la documentation officielle. - Les performances. Nous n'avons mesuré ni vitesse ni qualité, et nous ne citons aucun classement : les débits en tokens par seconde publiés ailleurs dépendent trop du matériel. - La perte de qualité due à la quantification sur les modèles récents. Les chiffres de llama.cpp portent sur Llama 3 8B ; nous n'en avons pas trouvé pour Gemma 4 ou Qwen3.5. - La licence de qwen3.6:35b. Nous l'avons lue sur la fiche du modèle 27b, pas sur celle du 35b. - La part de mémoire unifiée utilisable par le GPU. Apple ne publie pas de pourcentage ; nous n'en citons pas. - Le pilote NVIDIA minimal. La page Windows indique 551.61, la page GPU 550 : nous retenons la plus exigeante pour Windows. --- Questions fréquentes Quel matériel faut-il pour un LLM local ? Le fichier du modèle doit tenir dans la mémoire disponible, avec une marge. Le guide d'Ollama recommande 8 Go de VRAM ou de mémoire unifiée pour son modèle d'exemple de 7,2 Go, et OpenAI indique que gpt-oss:20b fonctionne avec 16 Go de mémoire. Selon notre lecture des tailles affichées par Ollama, 16 Go accueillent les modèles quantifiés de 4 à 14 milliards de paramètres, et gpt-oss:20b à la limite. Ollama est-il gratuit et open source ? Oui : Ollama est publié sous licence MIT sur GitHub et l'usage local ne coûte rien. Les modèles ont leur propre licence : Gemma 4, Qwen3.5, gpt-oss et Ministral 3 sont sous Apache 2.0, qui autorise l'usage commercial. Seuls les modèles :cloud passent par les serveurs d'Ollama. Peut-on faire tourner un LLM local sur un Mac ? Oui, sur macOS Sonoma ou plus récent. Les puces Apple M utilisent le GPU via Metal et leur mémoire unifiée, alors que les Mac Intel tournent sur le processeur seul (documentation d'Ollama). Comment appeler Ollama depuis du code ? Par l'API REST sur http://localhost:11434 : /api/chat pour l'API native, /v1/chat/completions pour la compatibilité OpenAI. En Python, pip install ollama installe la bibliothèque officielle. Aucune clé n'est demandée en local, d'où l'importance de ne pas exposer le port. --- À propos de l'auteur Abdelilah Ourti est ingénieur IA et architecte logiciel. Il conçoit et déploie des applications web et des systèmes d'IA, et publie sur NeurauTech des guides et des comparatifs destinés aux développeurs francophones. Ses autres articles sont réunis sur sa page auteur. Méthode. Synthèse fondée exclusivement sur des sources publiques consultées le 31 octobre 2026 : documentation et dépôts d'Ollama, de LM Studio, de llama.cpp et de Continue, pages de modèles d'Ollama et de Hugging Face, documentation GGUF de Hugging Face, mesures de llama-quantize, documentations d'Apple, de Docker et de VS Code, fiche CVE, recherches de SentinelLABS, Censys et Wiz. Les avantages revendiqués par les éditeurs sont signalés comme tels. Les citations issues de sources en anglais sont traduites par nos soins. Ollama n'était pas installé sur le poste de rédaction : aucun test ni aucune exécution n'a été mené. Aucun lien n'est affilié et aucune relation commerciale ne lie l'auteur aux éditeurs mentionnés. Une erreur ou une version périmée ? Écrivez à contact@neurautech.com : l'article sera corrigé et la date de mise à jour modifiée. Dernière mise à jour : 31 octobre 2026. Image : Clint Patterson (Unsplash License).

Ollama memory keeps growing with Cline on Mac Studio 36 GB, any fix? I’m running local coding agents (Cline in VS Code) against Ollama 0.40.13 on a Mac Studio (M5 Max, 36 GB unified memory) and I’m trying to find a setup that stays stable. The model is Qwen 3.8 27B. Memory pressure goes yellow during agent sessions and swap keeps growing. I would like to know if anyone found a real fix. What I measured (single requests via the API, same 14k-token prompt, num_ctx 16384): |Variant|Generation speed|ollama ps SIZE| |:-|:-|:-| |Q4_K_M (llama.cpp)|~19 tok/s|16–17 GB, constant| |nvfp4 (MLX runner)|~35–46 tok/s|18 → 20 GB| |Q4_K_M with MTP (27b-mtp-q4_K_M, llama.cpp)|~36–38 tok/s (28 at 14k context)|16–17 GB| At first MLX looked like the clear winner (twice as fast as plain Q4_K_M). What happens in a real Cline session (many sequential requests with a growing history and tool calls): - MLX runner: the server log (pipeline.go memory lines) shows held growing from 20 GB to 26.5 GB and peak up to 29.8 GiB within about 6 minutes, with only a 16k context. Swap reached 8 GB of 9 GB, memory pressure yellow. This matches existing Ollama issues ollama/ollama#17875, ollama/ollama#18131 and ollama/ollama#18620 (prefix cache accumulation, tool calls leaking memory). It still reproduces on 0.40.13, and I found no confirmed fix. The only things that release memory are unloading the model or restarting the runner. OLLAMA_KEEP_ALIVE=0 is useless with models on an external SSD. - llama.cpp runner with MTP: much better. ollama ps stays at 16 GB, even with a 32k context filled with 28k tokens. But the actual llama-server process is at 19–20 GB RSS and still rises slowly, memory pressure goes yellow and swap grows (1.7 → 4.4 GB) while VS Code, Cline and a browser are open. The log shows updating prompt cache repeatedly. Issue ollama/ollama#18264 describes the likely cause: llama-server’s host-RAM prompt cache (default --cache-ram 8192 MiB), which Ollama neither limits nor reports in ollama ps. What I plan to try next (not tested on macOS yet): 1. LLAMA_ARG_CACHE_RAM=1024 (or 0) through launchctl setenv for the Ollama app, as suggested in ollama/ollama#18264, then watch RSS of llama-server. 2. Remove the multimodal projector if possible (the runner is started with --mmproj even though I only use text). 3. Maybe test LM Studio’s MLX runtime or mlx_lm.server --prompt-cache-bytes (I’ve seen reports of bugs and crashes with agent loads). Questions: 1. Does LLAMA_ARG_CACHE_RAM actually reach the runner when set via launchctl setenv for the macOS Ollama app? Is there a better place? 2. Has anyone stabilized the Ollama MLX runner for agent workloads on 32–36 GB Macs? Any env var or build? 3. Is there a way to make ollama ps (or any tool) show the real footprint of the runner, including the prompt cache? 4. Would you recommend something else entirely for Cline on a 36 GB Mac (LM Studio, mlx_lm.server, llama-server directly, a smaller model)? Happy to post logs if useful.

Ollama: NVIDIA Nemotron 3.5 Bolt E4B SOURCE github.com/ollama/ollama/releases/tag/v0.40.10 The call, and why: deployedbyai.com

Ollamaの保存先変更を検証する：パス・環境変数・実行プロセスの切り分け 保存先の設定と、実際の参照先を分けて確認する Windows版Ollamaのモデル保存先はOLLAMA_MODELSで指定できます。ただ、値を変えた後にollama listが空になった場合、「コピーに失敗した」とは限りません。 確認対象は次の3つに分けられます。 確認対象 見るもの 分かること ファイルの配置 blobsとmanifestsの親フォルダー 指定したパスとコピーした階層が合っているか 設定の適用先 ユーザー環境変数と起動方法 設定をサーバーへ渡せる状態か 実際の動作 再起動後の一覧・ローカルモデルの生成 そのサーバーからモデルを利用できるか この記事はWindowsの通常インストーラー版を自分のアカウントで動かす環境が対象です。Docker、WSL（Windows上のLinux環境）、Windowsサービス、別PCのサーバーでは設定先が異なります。 2026年9月11日時点の公式資料を基に整理しています。Windows PowerShell 5.1で模擬ファイルのコピーと照合は検証しましたが、実モデルのドライブ間移行と推論は未検証です。実際の移行では元データを残して確認してください。 1. OLLAMA_MODELSはどの階層を指すか Ollamaの保存先を決める実装では、OLLAMA_MODELSが設定されていればそのパスを使い、未設定ならユーザーのホーム配下の.ollama/modelsを使います。 さらにモデルのパス定義では、その下にblobsとmanifestsを配置します。つまり、変数にはこの2つの親を指定します。 図：上記の公式実装を基に独自作成。 環境変数の値 実際の配置 判断 D:\Ollama\models D:\Ollama\models\blobsなど 階層が一致する D:\Ollama D:\Ollama\models\blobsなど 指定先より1階層深い D:\Ollama\models D:\Ollama\models\models\blobsなど コピー時にmodelsが二重になっている blobsの大きなファイルだけを移すと、モデルの管理情報であるmanifestsが残ります。移行対象はmodelsの中身全体とし、鍵や設定もある.ollama全体の削除と混同しないようにします。 2. PowerShellの値が正しくても、サーバーに反映済みとは限らない 環境変数は、プロセス（実行中のプログラム）が持つ設定でもあります。すでに起動済みのOllamaと、新しく開いたPowerShellでは、持っている値が違う可能性があります。 Windows PowerShellで次を確認します。 保存された値と現在のプロセスの値を比較する [Environment]::GetEnvironmentVariable('OLLAMA_MODELS', 'User') [Environment]::GetEnvironmentVariable('OLLAMA_MODELS', 'Machine') $env:OLLAMA_MODELS $env:OLLAMA_HOST 表示 確認対象 限界 User ユーザー単位で保存された設定 起動済みOllamaがその値を持つ証拠にはならない Machine システム単位で保存された設定 ユーザー側や起動元の設定も確認する必要がある $env:OLLAMA_MODELS 現在のPowerShellの値 別プロセスであるOllamaの内部を表示しているわけではない $env:OLLAMA_HOST 現在の接続先に関わる設定 別サーバーなら、ローカルファイルの変更だけでは移行できない Ollama公式のWindowsガイドは、ユーザー環境変数を変更した後、実行中のOllamaを終了し、起動し直す手順を示しています。スタートメニューから起動する運用なら、ユーザー変数に新保存先を設定してからその方法で再起動します。確認用PowerShellも開き直します。 一方、$env:OLLAMA_MODELSだけの代入は、そのPowerShellとそこから起動する子プロセスに対する設定です。スタートメニューから起動するアプリの永続設定として使うには範囲が異なります。Microsoft：Environment.SetEnvironmentVariableとOllama FAQを参照してください。 3. コピーの成功と、保存先切替の成功は別に確認する コピーはOllamaを終了してから行います。ollama stopでモデルを止めるだけでは、サーバー全体を終了したことにはならないため、通常インストーラー版ではタスクトレイからアプリを終了します。 Robocopy（Windows標準のコピーコマンド）を使う場合の例です。コピー先は空のフォルダーを用意し、十分な空き容量があることを確認します。既存の保存先を変更済みなら、$sourceを実際のパスに置き換えてください。リンクを使った保存構成はこの例の対象外です。 $source = Join-Path $env:USERPROFILE '.ollama\models' $destination = 'D:\Ollama\models' if (-not (Test-Path -LiteralPath $source -PathType Container)) { throw 'コピー元がありません。現在の保存先を確認してください。' } コピー元を残し、先に対象と向きを確認する robocopy $source $destination /E /COPY:DAT /DCOPY:DAT /R:2 /W:2 /XJ /L /Lは実行予定を表示する指定です。出力を確認してから、同じPowerShellで実コピーを行います。 削除を伴う/MIRや/MOVEは付けず、復旧用の元データを残す robocopy $source $destination /E /COPY:DAT /DCOPY:DAT /R:2 /W:2 /XJ $copyExitCode = $LASTEXITCODE if ($copyExitCode -ge 8) { throw "コピー失敗を含みます。終了コード: $copyExitCode" } $copyExitCode Robocopyでは終了コード1も正常です。8以上は失敗を含むので、保存先の切替へ進みません。例外が出たら、その場で作業を止めます。2〜7は追加ファイルや不一致などの情報を含む場合があり、出力を確認します。Microsoft：Robocopyに定義があります。 今回、Windows PowerShell 5.1からWSL共有パスにある模擬ファイル2件を操作し、次の結果を確認しました。 条件 実際の終了コード ファイルをコピー 1 コピー後に差分を確認 0 コピー先だけに追加ファイルを置いて確認 2 存在しないコピー元を指定 16 模擬ファイル2件はSHA256（内容から計算する照合値）も一致しました。Robocopyの差分なしという結果だけで内容の完全一致を保証せず、必要ならGet-FileHashで照合します。 ただし、この検証で分かるのはコピー処理の挙動です。実モデルを新しい保存先から読み出せることは、別途Ollamaで確認する必要があります。 4. 旧コピーを残した状態で、参照先の確認を強める コピーが済んだら、Windowsの「アカウントの環境変数を編集」で、ユーザー変数OLLAMA_MODELSをD:\Ollama\modelsへ変更します。変更前の値は記録しておきます。 Ollamaと確認用PowerShellを起動し直し、ollama listで移行前のローカルモデル名・タグ・IDと比較します。名前が見つからない場合は再ダウンロードへ進まず、階層と起動時の設定を調べます。 一覧にあるローカルのテキスト生成モデルを選んで、動作を確認します。次の値は実際のモデル名へ置き換え、クラウドモデルや埋め込み専用モデルは選ばないでください。 $model = '一覧にあるローカルモデル名:タグ' ollama show $model if ($LASTEXITCODE -ne 0) { throw 'モデルを確認できません。保存先と名前を確認してください。' } ollama run $model '短く自己紹介してください。' runはモデルがないと取得へ進む場合があるため、先にshowで確認します。Ollama CLI Referenceも参照してください。 さらに参照先を確かめるには、以下の手順が考えられます。これは元データを保全して確認するための提案で、公式がすべての環境での移行成功を保証するものではありません。 Ollamaを再び終了する。 コピー元のmodelsを、未使用の名前であることを確認してmodels.backupなどへ変更する。 Ollamaを起動し直し、一覧と同じローカルモデルの生成を確認する。 問題があれば削除を行わず、設定と元のフォルダー名を戻す。元が未設定なら、今回追加したユーザー変数を削除する。 元のパスを退避し、メモリ上のモデルも再起動で読み直すことで、旧コピーを使ったまま確認を終える可能性を減らせます。戻す際に新しいmodelsができていたら上書きせず、内容を確認して別名で保管します。Dドライブ側で追加・更新したモデルも古いコピーにはないため、そのまま保管します。 図：本記事の移行・保全手順を独自に図解。 Cドライブの容量を空けるのは、確認後に旧コピーを整理する段階です。ollama rmは現在のサーバーが管理するモデルを削除するため、切替後のDドライブ側を消してしまわないよう、旧コピーの整理には使いません。 症状から確認対象を選ぶ 症状 最初に確認する対象 一覧が空になった 変数が指す階層とmanifestsの配置 値を変更したのに反映されない 起動済みサーバーと、その起動元の環境変数 コピー完了後も元の場所に書かれる 古いプロセス、別ユーザー、別の接続先 一覧にはあるが読み込みに失敗する データの不足、読み取り権限、外付けドライブの接続状態 動くがCドライブが空かない 旧コピーとごみ箱に残ったデータ 保存先移行では、設定画面の値が正しいことと、コピーが成功したことと、サーバーが新しい場所を使うことを、それぞれ確認したいと考えています。この3つを分けると、「念のため再ダウンロードする」前に、どこを調べるべきか絞れます。 関連記事 GUIでの設定操作、コピー内容の照合、旧データの整理、元に戻す手順は、ブログのOllamaのモデル保存先をDドライブへ移す方法｜既存モデルの移行と確認手順に詳しくまとめています。

Top 5 Tool LLM Lokal dengan Bintang GitHub Terbanyak Ini lima tool LLM lokal dengan bintang GitHub terbanyak, dihitung hari ini. #1 Ollama — 184.967 bintang (ollama/ollama) #2 Open Webui — 156.917 bintang (open-webui/open-webui) #3 Llama.Cpp — 132.502 bintang (ggml-org/llama.cpp) #4 Vllm — 95.680 bintang (vllm-project/vllm) #5 Gpt4All — 77.354 bintang (nomic-ai/gpt4all) Empat dari lima pakai lisensi open source. Open Webui pengecualiannya. Kamu pakai yang mana? Tulis di komentar 👇 Data: Bintang Github · 27 Okt 2026 #Shorts #AItools #GitHub #opensource #belajarAI #programmer

Top 5 Most-Starred Local LLM Tools on GitHub These are the five most-starred local LLM tools, counted today. #1 Ollama — 184,967 stars (ollama/ollama) #2 Open Webui — 156,917 stars (open-webui/open-webui) #3 Llama.Cpp — 132,502 stars (ggml-org/llama.cpp) #4 Vllm — 95,680 stars (vllm-project/vllm) #5 Gpt4All — 77,354 stars (nomic-ai/gpt4all) Four of the five ship under an open source license. Open Webui is the exception. Which one are you using? Tell me in the comments 👇 Data: Github Stars · 27 Oct 2026 #Shorts #AItools #GitHub #opensource #vibecoding #developer