Ollama設定の再現性をdigest・templateで分解する

先に結論

Ollamaの再現性は、temperatureを固定するだけでは評価できません。base modelの識別情報、Modelfile本文、templateとstop、生成parameter、Ollamaの版と実行機種を別々の変数として記録し、同じpromptを流す必要があります。公式仕様から言えるのは設定項目と表示方法までであり、同じ出力、速度、品質をこの制作環境で実測したわけではありません。

確認日時: 2026年8月18日（Asia/Tokyo）
対象仕様: Ollama公式Modelfile Reference、Create API、Show model detailsの現行記載。公式docs自体に固定されたOllama package versionやcommitは示されていないため、下記の比較では対象daemon版を実行前に記録する前提です。
検証区分: 机上調査と再現可能な検証計画です。実機の生成、速度、memory、token出力、adapter適用、rollbackは未実施です。
適用外: 特定modelの品質保証、タグの将来更新、全hardwareの互換性、licenseの適否を一般化しません。

比較対象と固定する条件

比較は、同じbaseと同じ短いpromptを使い、Modelfileの一つの層だけを変える形にします。Ollamaの公式リファレンスでは、FROMはbase model、PARAMETERは実行パラメータ、TEMPLATEはモデルへ送る全体形式、SYSTEMはsystem messageを定義します。Create APIにも、from、template、system、parameters、messages、quantizeなどの入力項目があります。

実験開始時には、次のmanifestを保存します。ここでいうdigestは、公式docsが常に返す固定フィールドだと断定するものではなく、取得したモデルを識別するために記録するartifact情報です。

• 実行対象: Ollama daemonの正確な版、OS、CPU/GPU、メモリ、推論設定。
• base: model名とtag、取得日時、ollama showで表示されるformat・family・quantization level、可能ならローカルartifactのSHA-256。
• 定義: Modelfile本文、作成コマンド、作成したモデル名、ollama show --modelfileの出力。
• 入力: system指示、固定prompt、出力上限、seed、実行回数、失敗時の再試行規則。

一変数ずつ切り替える比較設計

最初にbaselineを作り、次の順で差分を増やします。各ケースでは、変更した行以外を同一にし、出力本文だけでなくrequest条件と終了理由を保存します。

層	固定・変更する例	観測するもの
base	同じmodel名・tagから、識別情報を記録した別artifactへ変更	format、family、quantization、モデル取得差分
template	公式表示のtemplateをbaselineにし、変更は1箇所だけ	入力に付くrole token、stop、応答形式
parameter	temperature、seed、num_ctx、stopを一つずつ変更	出力差、終了位置、context不足、再現率
環境	Ollama版、backend、機種、同時実行数を固定	速度、memory、エラー分類、再試行の影響

この表から速度や品質の優劣はまだ出ません。たとえばtemperatureを下げて出力が似ても、同じ結果になる理由がmodel、template、seedのどれかは分離できないためです。比較結果を記事へ書く場合は、各ケースの条件、回数、中央値と分布、失敗例、出力判定基準を併記します。

template・stop・parameterの境界

公式リファレンスは、templateがGo template syntaxを使い、{{ .System }}、{{ .Prompt }}、{{ .Response }}を扱う例を示していますが、syntaxはmodel specificです。したがって、別modelのtemplateをコピーしても、同じrole tokenやstop sequenceになるとは限りません。まず各modelからollama show --modelfileでbaselineを取り、templateとstopを同じ比較単位として扱います。

num_ctxは生成時に参照するcontext windowのサイズ、temperatureは生成のランダムさ、seedは同じpromptで同じ出力を得るための補助条件です。stopは一致した文字列で生成終了を促すため、template内のassistant開始記号と整合しなければ途中で切れたり、不要な文字列が残ったりします。実測なしに「品質が上がる」「速度が何倍になる」と結論づけません。

adapter・quantize・API経路の適用範囲

公式docsでは、ADAPTERはbase modelへLoRA adapterを適用する指示で、学習時のbaseと異なる場合は挙動が不安定になり得ると説明されています。adapter比較では、base modelの識別情報とadapterの出所、形式、license、適用前後のModelfileを固定します。baseの一致を確認できないケースは、性能比較の対象から外します。

Create APIにはquantizeやparametersなどの入力項目がありますが、CLIで作ったModelfileとAPI requestが常に同一のartifactになると決めつけません。CLIの作成コマンド、APIのJSON、status response、作成後のshow出力を保存し、差分を確認します。API経路の比較をしないなら、記事や運用ではCLIかAPIのどちらか一方に統一します。

障害・更新・rollbackの判断

1. 出力が崩れたら、まず新しいpromptやmodel変更を止め、最後に成功したModelfile・model名・実行版を固定します。
2. template、stop、adapter、parameterを一度に全部戻さず、manifestの差分から直近の変更を一つずつ戻します。
3. 同じtagでも取得時点が違う可能性を考え、tagだけを再現性の証拠にしません。artifactを再取得する前に、旧blobと定義書を保全します。
4. 再現性を確認できない場合は、速度や品質の数値を公開・運用判断へ使わず、対象model・版・機種を限定した保留にします。

未検証なのは、特定のOllama版とmodelでの同一出力率、各backendの速度とmemory、adapterの実際の品質差、quantizeの作成時間、APIとCLI artifactの完全一致、tag更新からの復旧時間です。これらは固定条件を用意した別の実測で確認すべきで、公式リファレンスから補完できる数値ではありません。

入門記事

まずModelfileを作り、createとrun、showの関係を確認する場合は、同日の入門ガイドを参照してください。

参考資料

• Ollama Modelfile Reference（命令、template変数、parameter、adapterの適用条件を2026年8月18日に確認）
• Ollama Create API（CLI以外の作成入力とstatus responseを同日に確認）
• Ollama Show model details API（model情報、format、family、quantization levelの確認方法を同日に確認）