ローカルLLM Linux

この記事のポイント

・Node.js 18以降の標準fetchでOllamaのREST APIを追加パッケージなしで呼び出せる
・TypeScriptの型定義でOllamaのリクエスト・レスポンスを型安全に扱う実装手順
・stream: trueとReadableStreamを組み合わせてLLMのリアルタイム出力を受け取る方法
・Express.jsのPOSTルートにOllamaを組み込み、WebアプリのAPIエンドポイントとして公開する

この記事のポイント

・curl --max-timeでAPIタイムアウトを検出し、プロセス死活だけでなく応答不能状態も復旧する
・systemctl restart / docker restartを自動判定付きで実行し、復旧確認まで自動で行う
・Slackウェブフックとlogrotateの二重設定で24時間無人運用に対応する
・再起動回数を記録してフラッピング検出と管理者エスカレーションを実装する

この記事のポイント

・GrafanaとLokiはDocker Composeで起動し、Promtailはapt経由でUbuntuホストに直接インストールする
・Promtailのjournalスクレイプ設定に`ollama.service`のrelabel_configsを追加することでOllamaログだけを選別して転送できる
・LogQLの`{job="ollama"} |= "error"`構文でエラーログをリアルタイムに絞り込める
・Promtail接続エラーの典型原因はLokiのURL設定ミスとjournaldへの読み取り権限不足

この記事のポイント

・OLLAMA_MODELSのパスを確認してモデルファイルの保存場所を特定する
・rsync --progress --partial でGBクラスの大容量モデルを中断再開しながら転送できる
・新サーバーでsystemd override.confを再設定してOllamaを自動起動する
・移行後は旧サーバーをすぐ削除せず最低1週間並走して動作を確認する

この記事のポイント

・OllamaのインストールスクリプトはARM64を自動検出し、Raspberry Pi 5でも通常のcurlコマンドで導入できる
・8GBモデルではGemma 3（2B・q4_K_M）やPhi-4（q4_K_M）など3GB以内に収まるモデルが実用的な速度で動作する
・モデルファイルはUSB SSDに保存しOLLAMA_MODELSで参照先を変更することでロード時間を大幅に改善できる
・vcgencmd measure_tempで温度を監視しアクティブクーラーを搭載するとサーマルスロットリングを防げる

この記事のポイント

・LangfuseはDocker Composeでセルフホストでき、プロンプト・レスポンス・トークン使用量を完全ローカルで記録できる
・langfuse.openaiのOpenAIラッパーをOllamaのbase_urlに向けるだけで既存コードをほぼ変更なしにトレース対応にできる
・@observeデコレータを付けるだけでRAGパイプライン全体をネストスパンとして可視化できる
・ClickHouseに全文保存するためディスク容量管理とデータ保持期間の設定が本番運用の鉄則

この記事のポイント

・ElasticsearchはBM25と `dense_vector` を同一インデックスに共存させてハイブリッド検索を一本化できる
・OllamaのEmbedding API（`/api/embeddings`）で生成したベクターをそのままElasticsearchに格納する
・Elasticsearch 8系の `knn` クエリと `sub_searches` + `rrf` でスコア統合の実装コードが最小限に収まる
・ノートPCレベルのCPU専用環境でも `nomic-embed-text` + `llama3.3:8b-instruct-q4_0` の組み合わせで実用速度が出る

この記事のポイント

・Traefikはtraefik.yml＋dynamic.ymlの2ファイルでBasicAuth・HTTPS・レート制限を一括管理できる
・dynamic.ymlはwatch:trueで変更を自動反映するためTraefik再起動なしで設定変更が効く
・docker-compose.ymlにextra_hostsを設定することでコンテナ内からホストのOllama(11434番)へ接続できる
・Let's Encrypt証明書はTraefik内蔵のACMEクライアントが自動取得・自動更新するためcertbotは不要

この記事のポイント

・Tailscaleをインストールして `tailscale up` するだけでOllamaサーバーとクライアントが同一プライベートネットワークにつながる
・`OLLAMA_HOST` をTailscale IPにバインドすることでインターネット公開ゼロのまま、チームからAPIにアクセスできる
・TailscaleのACLポリシーでタグを使い、接続元をチームメンバーに限定できる
・MagicDNSを有効化するとIPの代わりに `http://サーバー名:11434` という固定URLでOllamaにアクセスできる

この記事のポイント

・LangGraphのStateGraphでノードとエッジを定義し、グラフ構造のエージェントを構築できる
・add_conditional_edgesで条件分岐とループを実装し、LLMが自律的に処理を継続・終了を判断できる
・MemorySaverをCheckpointerに指定すると、スレッドIDごとに会話履歴を永続管理できる
・LangGraphはLangChainの単純チェーンでは扱いにくい「繰り返し処理が必要なタスク」に向いている

この記事のポイント

・Celery+Redisでollamaリクエストを非同期タスクとしてキュー処理できる
・`worker_concurrency`でGPU/RAM容量に合わせた同時処理数を制御する
・systemdの`After=ollama.service`で起動順序を保証して本番運用に対応する
・バッチ処理とリアルタイム処理をキュー名で分離して優先度制御できる

この記事のポイント

・nomic-embed-textでMinIO上のドキュメントをEmbeddingに変換しChromaに格納する
・MinIOのPython SDKでオブジェクトを動的に取得してRAGパイプラインを構築する
・MinIOのイベント通知でドキュメント追加を自動検知してインデックスを更新する
・すべてのデータとモデルがオンプレに留まる完全ローカルRAGを実現する

この記事のポイント

・OLLAMA_MODELS環境変数でモデルパスを変更すれば、NFS上のモデルをそのまま使える
・NFSサーバー側の設定は /etc/exports へのエントリ追加とnfs-kernel-serverの起動だけ
・systemdのAfter=とRequires=でNFSマウントをOllama起動前に保証し、起動順のトラブルを防ぐ
・モデル追加作業を「書き込み許可サーバー1台」に集中させるポリシーで整合性を保つ

この記事のポイント

・pypdfで抽出したテキストをOllamaの/api/generateに渡すと完全ローカルでPDF要約が実現できる
・pip install pypdf requests の2パッケージだけで動作し、クラウド依存ゼロで導入できる
・長いPDFは1,500字程度のチャンクに分割してOllama APIに渡すとコンテキスト超過を防げる
・日本語PDFのテキストが空になる場合はpdfplumberへの切り替えで解消できるケースが多い

この記事のポイント

・セルフホストランナーとOllamaを同一Linuxサーバーに同居させ、PRレビューをローカルLLMで実行する
・ワークフローYAMLでgit diff取得→ollama run呼び出し→gh pr comment投稿の流れを実装する
・Gemma3:9b-instruct-q4_0がコードレビュー用途で速度・品質のバランスが取りやすい
・GITHUB_TOKEN権限のスコープとセルフホストランナーのセキュリティ設定が実運用の要

この記事のポイント

・systemdのDrop-in設定でOllamaにCPUQuota・MemoryMaxをサービス単位で適用できる
・/etc/systemd/system/ollama.service.d/override.confに記述してdaemon-reloadで即時反映する
・/sys/fs/cgroup/system.slice/ollama.service/配下のファイルで設定値とリアルタイム使用量を確認できる
・MemorySwapMax=0でSwap書き出しを禁止し、メモリ不足時はOOMで素早く回復させる運用が実務に向く

この記事のポイント

・OllamaはCUDAドライバが認識する全GPUを自動検出しVRAMを合算してレイヤー分散する
・ollama psとnvidia-smiの組み合わせで複数GPU使用を確認できる
・CUDA_VISIBLE_DEVICESで使用するGPUを明示的に制限・指定できる
・OLLAMA_GPU_OVERHEADで予約VRAMを設定しOOM（メモリ不足）クラッシュを防げる

この記事のポイント

・OllamaバイナリはGitHub Releasesのtar.gzを接続環境で取得してエアギャップサーバーへ転送する
・モデルは接続環境でollama pullしたあと~/.ollama/modelsをtar czfでパッキングして持ち込む
・GGUFファイル＋Modelfileのインポートを使えばモデル更新時の転送量を最小化できる
・OLLAMA_MODELS環境変数でモデル置き場を外付けストレージに変更すると容量管理が楽になる

この記事のポイント

・OLLAMA_NUM_PARALLELを設定し、httpx + asyncioで複数プロンプトを同時処理するPythonコードを解説
・asyncio.gatherで複数タスクを一斉実行し、完了順にレスポンスを回収する実装パターンを紹介
・asyncio.Semaphoreで同時接続数を制限し、Ollamaのリソースを超えない安全な呼び出しを実現
・社内ドキュメントの一括要約スクリプトを実装例として提示し、すぐに実務へ応用できる構成にする

この記事のポイント

・pip install ollama でフレームワーク不要のPythonクライアントを導入できる
・ollama.chat(stream=True) でストリーミング応答をジェネレータとして逐次処理できる
・AsyncClient と asyncio.gather() を組み合わせて複数リクエストを並列処理できる
・tools パラメータで Function Calling を OpenAI 互換フォーマットで実装できる

この記事のポイント

・OllamaはデフォルトでTCP 11434を開放しており、OLLAMA_HOST=0.0.0.0にした瞬間に無認証APIが露出する
・nginxリバースプロキシ＋htpasswdでBasic認証を追加し、チームIDのみアクセス可能にする
・Let's EncryptでHTTPS化してBasic認証の平文漏洩リスクを排除する
・limit_req_zoneでレートリミットを設定し、GPU過負荷とブルートフォースを防ぐ

この記事のポイント

・nomic-embed-textのEmbeddingとQdrantを組み合わせてローカルRAGを構築できる
・docker runコマンド1つでQdrantサービスを起動し、Python qdrant-clientでコレクションを作成する
・pgvectorと異なり専用ベクターDBのためドキュメント数が増えてもミリ秒レベルの検索速度を維持できる
・本番運用時はQdrant Web UIとREST APIでコレクション状態を監視・管理する

この記事のポイント

・PodmanはDockerなしでOllamaをRocky Linux/RHELに動かせるRed Hat標準のコンテナエンジン
・dnf install podman 1コマンドでインストール可能・追加リポジトリ不要
・Podmanネットワーク機能でOllamaとOpen WebUIをコンテナ間で安全に接続できる
・podman generate systemd とloginctl lingerでサーバー再起動後の自動起動を実現する

この記事のポイント

・curlの-wオプションでTTFT・総レスポンスタイムを1コマンドで計測できる
・wrkの-cオプションで並列接続数を上げながらスループット上限を特定できる
・Pythonのasyncioで同時接続を段階的に増やし、エラーが出始めるラインをつかめる
・GPU VRAM使用率と応答速度の相関を見るとスペック判断の根拠が明確になる

この記事のポイント

・OLLAMA_HOST=127.0.0.1:11434をsystemd override.confに設定するだけで外部バインドを即座に防止できる
・ufw allow from 192.168.1.0/24 to any port 11434でLAN内IPのみに絞り込める
・Docker Composeのexpose＋internal networkでホストの11434公開を不要にできる
・Fail2banのOllama用filterとjailを組み合わせて過剰リクエストIPを自動ブロックできる

この記事のポイント

・nomic-embed-text をOllamaで動かすカスタムEmbedding関数でChromaDBと連携できる
・pip install chromadb 後、PersistentClientを使えばファイル永続化まで数十行で実装可能
・インジェスト→意味検索の一連の流れをPythonスクリプトのコピペで試せる
・コレクション管理・バックアップ・よくあるエラー対処法も網羅

この記事のポイント

・`ollama ps` コマンドで現在のモデルがGPUを使っているか即座に確認できる
・NVIDIAはCUDA 12.x系ドライバ、AMDはROCm 6.x系が現時点でのOllama動作確認済み推奨バージョン
・GPU未認識の第一原因はドライバ未インストール・バージョン不一致・グループ権限の未設定
・マルチGPUは `CUDA_VISIBLE_DEVICES` 環境変数で使用するGPUを選択できる

この記事のポイント

・HAProxyのhaproxy.cfgにfrontend/backendを定義して複数OllamaインスタンスをRound Robinで束ねる
・systemdのサービスユニットを複製してOLLAMA_HOSTを変えることで同一サーバーに複数インスタンスを立てられる
・`option httpchk GET /api/tags` とfall/rise設定でノード障害を自動検出・切り離し・自動復帰できる
・`hey -n 200 -c 20` で負荷前後のRequests/secを実測し、スループット改善を定量確認する

この記事のポイント

・`git diff --cached | curl http://localhost:11434/api/generate` の組み合わせだけでローカルLLMレビューが動く
・exitコードで制御するため、問題検出時に `git commit` を自動ブロックできる
・`commit-msg` フックでConventional Commits形式の書式チェックも同時に自動化できる
・`core.hooksPath` または `.pre-commit-config.yaml` でチーム全員に同じフックを展開できる

この記事のポイント

・Caddyfileにドメイン名とreverse_proxyを書くだけでHTTPS証明書が自動取得される
・certbotやcronの手動設定が不要で、証明書の更新もCaddyが自動で行う
・caddy hash-passwordとbasicauthディレクティブでAPIをパスワード保護できる
・OLLAMA_HOSTを127.0.0.1に限定してCaddy経由のみアクセスさせる構成が基本

この記事のポイント

・LoRA＋Unslothで ollama run できるカスタムモデルをGPU1枚で作れる
・学習データはJSONL形式のinstruction-outputペアを100件以上用意するのが品質の目安
・llama.cppの convert_hf_to_gguf.py でHugging Face形式→GGUF変換後、Modelfileでインポートする
・量子化タグ q4_K_M でVRAMを抑えつつ本番運用に耐える品質を保てる

この記事のポイント

・OllamaのPOST /api/generateに「CREATE TABLEスキーマ＋質問」を渡すとSQL文が得られる
・information_schemaでスキーマを動的取得すれば、テーブル追加後もプロンプト更新不要になる
・生成SQLは読み取り専用ユーザー＋SELECTのみ許可フィルタで安全に実行できる
・few-shot例をプロンプトに追加するとJOINや集計クエリの生成精度が大幅に向上する

この記事のポイント

・HAProxyのbackendブロックにOllamaサーバーを列挙するだけで複数台へ分散できる
・OLLAMA_HOST=0.0.0.0:11434 をoverride.confで設定してLAN公開が前提
・option httpchk GET /api/version でOllamaのヘルスチェックを行い障害サーバーを自動切り離す
・LiteLLMプロキシと組み合わせるとAPIキー管理と負荷分散を分離して管理できる

この記事のポイント

・GitLab RunnerをシェルモードでOllamaと同じサーバーに配置すれば、MR差分を直接ローカルLLMに送れる
・.gitlab-ci.ymlに`only: - merge_requests`を指定するとMR作成時だけジョブが起動する
・Python 20行でOllama APIに差分を投げてレビューを取得し、GitLab APIでMRコメントに自動投稿できる
・差分は`head -c 3000`で切り詰めてトークン上限を超えないようにするのが最初の実務的対処

この記事のポイント

・RedisStackのHNSWベクターインデックスと nomic-embed-text でセマンティックキャッシュを実現できる
・類似度閾値0.92（コサイン距離0.08）を起点に調整すれば、意味が同じ質問を自動でキャッシュヒットに振り分けられる
・Pythonの redis-py 17行のクラスで既存Ollamaコードへの差し込みが可能
・TTL・DIM不一致・メモリ上限が本番でよく引っかかるポイントで、それぞれ具体的な対処がある

この記事のポイント

・OllamaはGPU不在でもCPU-onlyモードで自動起動し、追加設定なしで推論できる
・CPU環境ではRAMの60%以内のモデルサイズとq4_K_Mタグを組み合わせるのが基本方針
・OLLAMA_NUM_THREADSとOLLAMA_MAX_LOADED_MODELS=1で他サービスとの同居稼働を安定させる
・swapとvm.swappiness=10でOOM Killを防ぎ、長時間の安定稼働を実現する

この記事のポイント

・docker compose up -d だけでAnythingLLMのWeb UIとRAGが即起動する
・LinuxではDockerからOllamaへの接続にextra_hostsの明示設定が必要
・ワークスペース単位でドキュメントを隔離しユーザーごとに参照権限を割り当てられる
・チャンクサイズとTop K Resultsの調整がRAG精度向上の主要ポイント

この記事のポイント

・Ollama APIの `/api/generate` レスポンスに含まれる `eval_count` と `eval_duration` を使えば外部ツール不要でtokens/secを算出できる
・`nvidia-smi dmon` をバックグラウンドで走らせながらAPIを叩くことでモデル別のVRAM消費量を記録できる
・シェルスクリプトでモデルを順番に切り替えてCSVに保存し比較判断に使う一連の手順を示す
・初回実行はVRAMロード時間が混入するため、ウォームアップ後の値を使うのがベンチマークの鉄則

この記事のポイント

・n8nのHTTP RequestノードでOllamaのREST APIを呼び出し、ワークフローにローカルLLMを組み込める
・メール分類・Slack要約翻訳・CSVバッチ解析の3フローを設定例付きで解説
・タイムアウトが発生する場合はnum_ctxを削減するか軽量モデルへの切り替えで対処できる
・全データは社内LAN内のコンテナで完結し、クラウドAPIへのデータ送信は一切不要

この記事のポイント

・Ollamaのhealthcheckとcondition: service_healthyでOpen WebUIの起動順を確実に制御できる
・networks.backend.internal: trueでOllamaを外部ネットワークから構成レベルで隔離できる
・GPUパススルーにはnvidia-container-toolkitとdaemon.jsonのランタイム設定が前提条件になる
・docker-compose.ymlをGitで管理すれば別サーバーでも完全再現できる環境になる

この記事のポイント

・OllamaのREST APIとTelegram Bot APIをPythonスクリプトで橋渡しし、スマートフォンからローカルLLMへ話しかけられるボットを構築する
・ユーザーID許可リストを実装してBot乗っ取りを防ぎ、外出先からでも安全に利用できる環境にする
・systemdユニットファイルで常時起動化すれば、サーバー再起動後もボットが自動復旧する
・会話履歴をメモリ内に保持してマルチターン対応にし、前後の文脈を考慮した応答が得られる

この記事のポイント

・deploy.resources.reservations.devicesブロックでNVIDIA GPUをコンテナへ割り当てる
・named volumeでモデルデータを永続化し、コンテナ削除後もモデルが消えない設計にする
・Open WebUI・Nginxをdepends_onとnetworkで連携させ、profilesで開発・本番のサービスを切り替えられる
・healthcheckとrestart: alwaysで障害時の自動復旧を仕組みとして組み込める

この記事のポイント

・systemctl status ollamaとjournalctl -u ollama -n 50で起動エラーの原因を素早く特定できる
・GPU非認識の主因はNVIDIAドライバ・CUDAバージョン不一致。nvidia-smiとOllamaログで確認する
・接続拒否（connection refused）はポートバインドかsystemd起動順序ミスが多い
・環境別（systemd/WSL2/Docker）で症状が同じでも原因が異なる。切り分け手順を必ず踏むこと

この記事のポイント

・docker-compose.yml の ollama サービス定義と GPU パススルー設定で環境を統一できる
・アプリコンテナからは http://ollama:11434 のサービス名でAPIに接続する
・named volume と OLLAMA_MODELS 環境変数でモデルをコンテナ再起動後も保持する
・healthcheck と depends_on の組み合わせで起動順序を確実に制御できる

この記事のポイント

・UFWで11434番ポートを特定IPからのみ許可し、全公開状態を即座に解消できる
・systemdのProtectSystem・PrivateTmpでOllamaプロセスをOSファイルシステムから分離できる
・auditdでOllamaの実行・モデル操作を監査ログとして記録・追跡できる
・AppArmorのcomplain→enforceの段階移行でプロセス権限を安全に最小化できる

この記事のポイント

・ssh -L 11434:127.0.0.1:11434 でOllamaのAPIをローカルに転送できる
・~/.ssh/config に LocalForward を書けば短いコマンドで常用設定になる
・ServerAliveInterval でキープアライブを設定し長時間推論中の切断を防ぐ
・autossh を使うと接続断時の自動再接続まで自動化できる
・Open WebUI（3000番）も同時にトンネリングしてブラウザUIをリモートで使える

この記事のポイント

・sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp でサブネット限定公開が即日実現できる
・systemdのEnvironment="OLLAMA_HOST=127.0.0.1:11434"でLoopbackバインドに絞るとプロセスレベルで外部遮断できる
・NginxをHTTPS終端にして11434番ポートを外部に見せないのがチーム運用の定石
・設定後はnmap -p 11434 でfilteredと表示されるか実測で確認する

この記事のポイント

・ollama ps でロード中モデル・使用VRAM・処理中リクエスト数をリアルタイム確認できる
・ollama show モデル名 でアーキテクチャ・コンテキスト長・量子化形式・デフォルトパラメータを一覧表示する
・ollama run はインタラクティブ・パイプ・1ショットの3パターンで使い分けると業務スクリプトに組み込みやすい
・ollama cp で既存モデルを複製してから ollama create でModelfileを適用するとリスクなしにカスタムモデルを試せる

この記事のポイント

・CREATE EXTENSION vector; の1行でPostgreSQLにpgvectorを組み込める
・nomic-embed-textの768次元EmbeddingをHNSWインデックスで高速類似検索できる
・psycopg3 + pgvectorライブラリでPythonからベクターをそのまま格納・取得できる
・Ollama推論もEmbeddingもPostgreSQLも社内サーバーで完結するRAGが完成する

この記事のポイント

・NVIDIA GPU OperatorでKubernetesにGPUリソースを認識させてからHelm install ollamaを実行する
・persistentVolume.enabled: trueでモデルデータを永続化し、Pod再起動後の再ダウンロードを防ぐ
・tolerations＋nodeSelectorでGPU NodeだけにOllamaがスケジュールされる設定が必須
・IngressのProxy-Read-Timeoutを3600秒以上に設定しないとLLM応答中にタイムアウトが発生する

この記事のポイント

・JupyterLabとOllamaはlocalhost:11434でそのまま連携できる
・ollama PythonパッケージのstreamオプションでCell内リアルタイム表示が実現できる
・会話履歴はPythonのリストで管理し、messagesに渡すだけで実装できる
・Embedding APIとnumpyのコサイン類似度でRAG前の挙動確認をノートブック上で完結できる

この記事のポイント

・OLLAMA_MODELS環境変数でモデル保存先を任意のパスに変更できる
・外付けHDDへの移転はrsyncとサービス停止で安全に実施できる
・ollama rmで削除してもblobsに孤立ファイルが残る場合がある
・バックアップはblobsとmanifests両方を対象にしないと復元できない

この記事のポイント

・ansible-playbookコマンド一発でOllamaを全サーバーに一括インストールできる
・ollama pullをAnsibleタスク化することで指定モデルを全台に自動展開できる
・--limitや--tagsオプションで特定ホストや特定タスクだけを安全に再実行できる
・Playbookをidempotent設計にすることで何度実行しても副作用が発生しない

この記事のポイント

・FastAPIとhttpxでOllamaの/api/chatをラップするカスタムAPIサーバーを構築し、Ollamaポートを外部から完全に隔離できる
・APIKeyHeaderとDependencyを使ってチームメンバーごとにAPIキーを発行し、不正利用を403でブロックできる
・slowapiで1分あたりのリクエスト上限を設定し、Ollamaが過負荷で応答不能になるリスクを防げる
・structlogで構造化JSON形式のログを出力し、チーム名・レスポンス時間・リクエストIDをjqで即座に絞り込める

この記事のポイント

・faster-whisperとOllamaを組み合わせると音声→文字起こし→要約が完全ローカルで完結する
・pip install faster-whisper＋ffmpegで日本語会議音声の文字起こし精度は実用レベルに達する
・Pythonスクリプト1本でバッチ処理に対応し、cronで定期自動実行にも組み込める
・GPUなしのCPU環境でも動作する（60分音声の文字起こしは5～8分程度が目安）

この記事のポイント

・OllamaのPOST /api/chat とrequestsでStreamlitから直接接続できる
・st.write_streamでストリーミング表示、st.session_stateで会話履歴を保持する
・GET /api/tags でモデル一覧を取得し、サイドバーで動的に切り替える
・本番公開はsystemdサービス化＋NginxのWebSocketプロキシ設定で安定運用する

この記事のポイント

・AutoGenはOllamaのOpenAI互換API（localhost:11434/v1）に接続するだけでローカル推論が使える
・config_listに`"price": [0, 0]`を必ず追加してコスト計算エラーを回避する
・GroupChatはmax_roundとmax_consecutive_auto_replyで無限ループを防ぐ
・コード実行は`use_docker: False`でDockerなし環境でも安全に動作させられる

この記事のポイント

・temperature=0.0～0.2でコード生成の精度が安定し、num_predict・num_ctxで速度と長文対応を制御できる
・curl の /api/generate に options オブジェクトを渡すだけでパラメータを即時切り替えられる
・PythonのPRESETS辞書に用途別設定をまとめると、チーム全体の設定標準化と属人化防止につながる
・num_ctx を拡張するほど KV-cache が VRAM を消費するため、nvidia-smi で空き容量を確認してから設定変更する

この記事のポイント

・journalctl -p err の出力をcurlでOllamaのAPIに渡してエラーを自動要約できる
・シェルスクリプト1本で取得・解析・メール通知まで一気に自動化できる
・cronで日次実行することでログ確認の工数をほぼゼロに近づけられる
・プロンプトに役割指定と出力フォーマットを明記すると解析精度が大きく上がる

この記事のポイント

・pip install llama-index-llms-ollama llama-index-embeddings-ollama の2パッケージでOllamaと接続できる
・SimpleDirectoryReaderでPDF・テキスト・Markdownを一括取り込み、VectorStoreIndexで検索可能にする
・SentenceSplitterのchunk_size（256～1024）とchunk_overlapを調整するとRAGの回答品質が大きく改善する
・StorageContextでインデックスをディスクに永続化し、再起動後も再Embedding不要にできる

この記事のポイント

・DifyをDockerでインストールし、OllamaのエンドポイントURLを登録するだけで連携できる
・チャットボット・RAGナレッジベース・AIエージェントをノーコードUIで構築できる
・DifyのAPIエンドポイントを使えば既存の業務システムにローカルLLMを組み込める
・連携時のモデル未認識・Docker疎通エラーは対処パターンが決まっており解消しやすい

この記事のポイント

・slack-boltとOllama REST APIを組み合わせれば社内SlackにローカルAIを追加できる
・Socket Modeを使えばポート開放もNginxも不要でボットサーバーを動かせる
・すべての推論が社内Linuxサーバーで完結するため機密データは外部AIに渡らない
・systemdのEnvironmentFileディレクティブでSlackトークンを安全に管理する

この記事のポイント

・OllamaのREST APIで stream: false を指定すれば、1回のcurl呼び出しで要約テキストを取得できる
・シェルスクリプトのforループとjqで複数テキストファイルをまとめて安全にバッチ処理できる
・PythonのThreadPoolExecutorで並列実行し、大量ドキュメントを高速に処理できる
・タイムアウト・リトライ設計と失敗ファイルのログ記録で本番バッチを安定稼働させる方法も解説する

この記事のポイント

・ollama pull hf.co/ユーザー名/リポジトリ:タグ でHugging Faceの任意GGUFを直接取得できる
・GGUFファイルをダウンロードして FROM ./model.gguf と書いたModelfileから ollama create で登録する
・インポート後は ollama ls・ollama show・ollama rm でモデルを一元管理できる
・hf.co直接ロードはGGUFがリポジトリルートにあるパブリックリポジトリのみ対応

この記事のポイント

・FlowiseはChatOllamaノードを設定するだけでOllamaと即接続でき、コードは不要
・npm install -g flowise またはDockerで5分以内に起動できる
・PDF読み込み＋nomic-embed-textでRAGフローをビジュアルエディタだけで構成できる
・本番環境ではsystemdサービス化とNginxリバースプロキシで安定運用する

この記事のポイント

・pip install 'litellm[proxy]' でOllamaの前段にAPIゲートウェイを追加できる
・/key/generate でメンバーにバーチャルAPIキーを発行しモデルと予算を個別設定できる
・rpm_limitとmax_budgetでキー単位のレート制限と月額上限を実装できる
・base_urlをlocalhost:4000に変えるだけで既存のOpenAIクライアントコードがそのまま動く

この記事のポイント

・ollama pullのタグにサフィックスを付けるだけで量子化レベルを選択できる
・fp16→q8_0→q4_0の順にVRAMは半減するが回答精度も段階的に低下する
・q4_K_Mはq4_0より精度が高くq8_0より軽量な、VRAM節約と品質のバランス型
・nvidia-smiとollama psでVRAM使用量を実測してから量子化レベルを決める

この記事のポイント

・pip install langchain-ollama でChatOllama/OllamaEmbeddingsが使えるようになる
・ChatOllama(model="llama3.3:70b-instruct-q4_0") でOpenAI互換の会話実装が数十行で可能
・RunnableWithMessageHistoryで複数セッションの会話履歴をLangChainが自動管理する
・OllamaEmbeddings+FAISSでクラウド不要のローカルベクトル検索が完成する

この記事のポイント

・/api/chat の tools パラメータにJSONスキーマでツールを定義し、tool_callsを検出して実行する
・Function Callingに対応したモデルはllama3.3:70b-instruct-q4_0やmistral:7b-instruct-v0.3-q8_0が代表例
・Pythonのollamaライブラリを使うと数十行でツール連携エージェントを実装できる
・ツール実行可能範囲はコード側のホワイトリストで制限し、LLMに任意実行させない設計が基本

この記事のポイント

・"format": "json" をAPIリクエストに追加するだけでJSON modeが有効になる
・スキーマの固定はシステムプロンプトで行う。モデル側では型・フィールド名を保証しない
・json.loads(response.json()["message"]["content"]) でPythonからパースできる
・本番運用ではjsonschemaバリデーション＋リトライロジックを必ずセットで実装する

この記事のポイント

・OllamaのEmbedding APIは/api/embedエンドポイントでテキストをベクトル化できる
・nomic-embed-text（768次元）またはmxbai-embed-large（1024次元）をモデルとして使う
・取得したベクトルとコサイン類似度でキーワード一致なしの意味検索が実現できる
・SQLiteに埋め込みを保存することで数千件規模の社内文書検索DBを低コストで構築できる

この記事のポイント

・Ollamaは標準で `/metrics` エンドポイントを持つためPrometheusと追加プラグインなしに連携できる
・Prometheus＋node_exporter＋nvidia_gpu_exporterの3点セットでシステム・GPU・LLMを一元監視できる
・Grafanaのデータソースにprometheusを登録するだけでリアルタイムダッシュボードが構成できる
・アラートルールを設定すればVRAM逼迫やレスポンス遅延を自動検知してSlack通知できる

この記事のポイント

・`ollama pull llava:7b-instruct-q4_0`でインストールし、REST APIの`images`フィールドにbase64画像を渡すだけで動作する
・LLaVA 7B（Q4量子化）はVRAM約6GB、Moondreamは約2GBでCPU環境でも実用的な速度が出る
・`base64 -w 0`の`-w 0`オプションを省略すると改行が入りAPIのJSONエラーになるため必ず付けること
・社内機密の帳票・監視画面など、クラウドAIに送れない画像の解析用途に特に適している

この記事のポイント

・Continue.devはconfig.jsonのprovider: "ollama"とapiBaseを設定するだけでローカルLLMに接続できる
・チャット用にLlama3.3、Tab補完用にPhi-4と役割でモデルを分けることで応答速度と品質を両立できる
・コードはすべてローカル推論で処理されるため、社内規定でSaaSのCopilotが使えない環境でも導入できる
・VS Code拡張の初回インストールだけはオンライン環境またはVSIXファイルで事前に済ませておく

この記事のポイント

・OLLAMA_NUM_PARALLEL・OLLAMA_MAX_LOADED_MODELS・OLLAMA_KEEP_ALIVEの3変数がチューニングの核心
・環境変数はsystemdのoverride.confに記述し、daemon-reload→restartで確実に永続化する
・ollama psでモデルのVRAM使用量とアンロードタイマーをリアルタイム確認できる
・量子化モデル（q4_0 vs q8_0）の選択でVRAM消費を抑えながら並列数と速度を両立できる

この記事のポイント

・OllamaはデフォルトでHTTP 11434番・認証なし。本番公開前に必ずNginxリバースプロキシを挟む
・systemdのoverride.confで OLLAMA_HOST=127.0.0.1 を設定し、Ollamaを外部バインドから切り離す
・Nginxの proxy_pass http://127.0.0.1:11434; でHTTPS転送とBasic認証を追加し安全に提供する
・UFWで11434番を閉じ443番のみを許可すると「Nginxが入口・認証が門番・UFWが外壁」の多層防御が完成する

この記事のポイント

・ollama pull nomic-embed-textでエンベディングモデルを取得してローカルベクター化を実現する
・LangChainのChromaVectorstoreとOllamaLLMを組み合わせてRAGパイプラインをPythonで実装できる
・ChromaDBはローカルファイルとして動作するため外部サーバー不要で機密文書を安全に扱える
・回答精度が低いときはchunk_sizeとchunk_overlapの調整が最初の改善ポイントになる

この記事のポイント

・ModelfileはFROM（ベースモデル）・SYSTEM（システムプロンプト）・PARAMETER（推論パラメータ）の3ディレクティブで構成される
・ollama create モデル名 -f ./Modelfileでビルドすればollama runやREST API・Open WebUIからすぐ使える
・temperatureを0.1 ～ 0.3に下げると技術サポート用途で安定した回答が得られる
・ModelfileをGitで管理することでチーム全員が同じ業務特化AIアシスタントを同一設定で再現できる

この記事のポイント

・docker run 1コマンドでOpen WebUIをOllama連携済みで起動できる
・管理者・一般ユーザーの権限分けで社内共有環境を安全に構築できる
・Nginxリバースプロキシ＋Let's EncryptでHTTPS化して本番運用可能
・コンテナが起動しない・モデルが表示されないなど頻出トラブルの対処法を網羅

この記事のポイント

・sudo systemctl edit ollama でoverride.confを作成しデフォルト設定を上書きできる
・Environment="OLLAMA_HOST=0.0.0.0:11434" でLAN全体にAPIを公開できる
・OLLAMA_MODELSでモデル保存先を専用ストレージに分離してディスク管理を独立させる
・起動失敗時は journalctl -u ollama -n 50 でログを確認するのが最初の一手

この記事のポイント

・Ollamaは curl -fsSL https://ollama.com/install.sh | sh の一行でUbuntu・WSL2に導入できる
・WSL2はUbuntuと同じコマンドで動くが、systemd有効化の確認とGPU連携の手順が追加になる
・Dockerでは docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 ollama/ollama で起動できる
・ollama: command not foundが出る場合はPATH再設定と source ~/.bashrc で解消できることが多い

この記事のポイント

・nvidia-smi未認識の主因はドライバ未インストール。ubuntu-drivers autoinstallで解消できる
・CUDAはNVIDIA公式リポジトリ経由でインストールし、nvccコマンドで正常動作を確認する
・OllamaはCUDAが正しく入っていれば自動でGPU推論に切り替わる（設定変更は不要）
・CUDA ToolkitのバージョンがnvidiaドライバのCUDA対応上限を超えると「Failed to initialize NVML」が発生する

この記事のポイント

・モデル選定の基準はVRAM容量と用途の2軸で決まる
・ollama pull 前に df -h でディスク容量を確認する（モデルは数GB～数十GB）
・軽量はPhi-4・Gemma 3、高精度はGemma 4・Llama3.3が目安
・-q4_0 などの量子化タグでVRAM消費を大きく下げられる
・OOMは nvidia-smi とログで確認、不要モデルは ollama rm で削除できる

この記事のポイント

・curl -fsSL https://ollama.com/install.sh | sh でOllamaを一発導入できる
・ローカルLLMなら機密データを外に出さず・月額ゼロ・オフラインで業務AIを動かせる
・本番運用はsystemdのoverride.confでOLLAMA_HOSTやモデル保存先を制御するのが基本
・「ollama: command not found」はPATHとsystemd起動の2点を切り分ければ解決できる
・巨大モデルが必要な場面はクラウドが優位。用途で使い分ける視点を持つ