ローカルLLM Linux

この記事のポイント

・ssh -L 11434:127.0.0.1:11434 でOllamaのAPIをローカルに転送できる
・~/.ssh/config に LocalForward を書けば短いコマンドで常用設定になる
・ServerAliveInterval でキープアライブを設定し長時間推論中の切断を防ぐ
・autossh を使うと接続断時の自動再接続まで自動化できる

この記事のポイント

・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はOpenAI SDK互換の /v1/chat/completions エンドポイントを標準で提供している
・base_url・api_key（ダミー値）・モデル名の3点を変えるだけで既存OpenAIコードが動く
・Function CallingはLlama3.3・mistralで動作確認済み（Gemma 3は制限あり）
・外部公開時はOLLAMA_HOST=0.0.0.0:11434 の設定とNginx認証を組み合わせること

この記事のポイント

・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 と ollama run でモデルを瞬時に切り替えられる
・軽量はPhi-4・Gemma 3、高精度はGemma 4・Llama3.3が目安
・-q4_0 などの量子化タグでVRAM消費を大きく下げられる
・OOMの確認は nvidia-smi とOllamaのログが基本

この記事のポイント

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