Ollama 0.40.11 実践編：Windows上でローカルLLMを実行する

Ollama 0.40.11では、Windowsユーザー向けにデスクトップチャットアプリケーションと、他のソフトウェア用のローカルモデルランタイムが提供されています。また、Ollamaは従来のコマンドラインインターフェースからさらに進化し、検索可能なモデルセレクタ、画像添付機能、コーディングツールへのリンクなどが追加されました。テストに必要な一部のコントロールは、PowerShellとモデル構成ファイルに引き続き存在します。

Ollamaは、Windows 11 Pro for Workstations、128GBのRAM、NVIDIA RTX 5000 Ada Generation GPUを搭載したHP Z4 Rack G5にインストールしました。既存のJan V3.5 4BおよびJan V2 VL High GGUFを使用して、生成速度、チャット、画像、オンライン検索、およびローカルAPIをテストしました。Ollamaはローカルモデルをうまく実行しましたが、GGUFのインポートとパフォーマンスデータの収集にはデスクトップチャットから離れる必要がありました。これは、JanとOpen WebUIに続く、ローカルLLMシリーズの3番目のアプリケーションであり、その結果は「ベストローカルLLMツール」ページに掲載されます。

テストシステム

成分
オペレーティングシステム	ワークステーション用のWindows11 Pro
CPU	Intel Xeon w5-2465X、16コア
メモリ	128GB
GPU	NVIDIA RTX 5000 Ada 世代
VRAM	32GB（報告容量：32,760MiB）
NVIDIAドライバ	597.06
CUDA互換性	13.2（nvidia-smiによる報告）
オラマ	0.40.11
推論ランタイム	Ollama llama.cpp ランナー (ビルド番号は記録されていません)

Ollamaのインストールと使用開始

WindowsワークステーションにOllamaをインストールするのは、このシリーズの他のアプリケーションで経験したセットアップの煩雑さから解放され、非常に快適でした。標準のWindowsインストーラーをダウンロードしてアプリケーションを起動するだけで、別途推論ランタイムをインストールしたり、CUDAパッケージを探し回ったりする必要はありませんでした。PowerShellで簡単に確認したところ、Ollama 0.40.11が実行されており、ローカルサービスがhttp://127.0.0.1:11434で既に応答していることが確認できました。

ウェルカム画面を通過すると、Ollamaは使い慣れたチャットインターフェースを開き、左側のサイドバーには最近の会話、アプリ、設定が表示されました。メッセージフィールドには、添付ファイルボタン、ウェブ検索、モデルセレクターがまとめて配置されています。アカウントを作成しなくてもインポートしたローカルモデルとチャットを開始できましたが、テスト中にウェブ検索を有効にしようとした際、Ollamaからサインインを求められました。

モデルの閲覧と追加

Ollamaでは、モデル選択が非常にシンプルに行われ、インストール済みのモデルとダウンロード可能なモデルの両方を表示するドロップダウンメニューが用意されています。インポート済みのJanモデルとQwen3-VLに加え、小さな雲のアイコンで識別されるクラウドベースのオプションもいくつか表示されています。他のモデルを検索するための検索フィールドもありますが、モデルのサイズ、量子化、ハードウェア要件など、より詳細な情報が表示されていれば良かったと思います。Janはモデルハブを通じてこれらの詳細情報を提供していますが、Ollamaではこれらの情報のほとんどがメインのチャットインターフェースには表示されません。

2 つのベンチマーク モデルを Ollama に取り込むには、以前のレビューで使用した GGUF ファイルをそのまま使用してパフォーマンス テストをできるだけ比較可能にしたかったため、より多くの作業が必要でした。Ollama ではデスクトップ インターフェイスからモデルを直接ダウンロードできますが、ワークステーションに既に保存されている GGUF ファイルをインポートするオプションが見つかりませんでした。代わりに PowerShell を使用して、各モデルの既存の GGUF を指し、以前のテストで使用したサンプリング パラメータを含む Modelfile を作成する必要がありました。次に、 ollama create それらをOllamaのモデルライブラリに追加するコマンド。

どちらのインポートも問題なく動作し、Jan V3.5 は次のように表示されます。 jan-v35-sr そして Jan V2 VL High として jan-v2-srまた、別の画像解析テストのために、Ollama経由でQwen3-VL 4Bを直接ダウンロードしました。

モデルをインポートした後、Ollama がそれらをどのように識別したか、また設定が正しく引き継がれたかどうかを確認しました。Jan V2 VL High は、Q4_K_M 量子化を使用した 8.2 億パラメータの Qwen3-VL モデルとして認識され、これは元のファイルと一致しました。Jan V3.5 は例外で、インポートした GGUF の名前が Jan-v3.5-4B-Q4_K_XL.ggufしかし、Ollamaは量子化をQ4_K_Mと報告しました。元のファイルは変更せずに残しました。その理由は、Q4_K_XLがUnslothの動的量子化であり、主にQ4_K_Mレイヤーから構築されているため、ファイルのメタデータにその基本タイプが記録されていると考えられます。

モデル設定とGPUの使用状況

Ollamaの設定ページには、クラウドアクセス、自動更新、ネットワークアクセス、モデル保存パス、コンテキスト長スライダーが含まれており、最初に確認したときは32Kと表示されていました。パフォーマンス テストでは、API を介して明示的に 8,192 トークンを要求したため、以下のベンチマーク結果はデスクトップのデフォルトではなく、そのコンテキストを使用しています。

OllamaはJanほどデスクトップインターフェースを通して詳細なモデル設定ができないことから、ほとんどの調整はモデルファイルとAPIリクエストを通して行いました。ベンチマークの比較可能性を保つため、以前のテストと同じ設定（温度0.8、Top K 40、Top P 0.95、Min P 0.05、繰り返しペナルティ1.0）を使用しました。また、バッチサイズを2,048に設定しましたが、Ollamaが生成時にこの設定を適用したかどうかは独自に確認できませんでした。

GPU 構成も異なっており、1 月に使用した 100 の GPU レイヤーに相当するデスクトップ設定はありませんでした。Ollama は GPU オフロードを自動的に処理し、 ollama ps 輸入された両モデルとも、完全にRTX 5000 Ada上で動作していることが確認された。

NVIDIAの公式データと照らし合わせて、そのレポートを検証しました。Jan V3.5では、ロード後にVRAMの割り当てが数ギガバイト増加し、生成中のGPU使用率はリアルタイムで93%に達しました。Jan V2でもGPUが完全に常駐していることが報告され、診断実行では96%の使用率を示しました。少なくともこのワークステーションでは、高速な生成を実現するために、別のCUDAバージョンやGPUレイヤーの設定を行う必要はありませんでした。

地域発電性能

生成テストでは、 1月に公開したハンズオン記事と同じプロンプトを使用しました。「初めてNASを構築する人にRAID 5とRAID 6について説明してください。それぞれの主な利点と欠点を約400語で記述してください。」Web検索を無効にし、コンテキストを8,192トークンに設定し、各APIリクエストにはその単一のユーザーメッセージのみを含めました。モデルごとに1つのウォームアップ応答を破棄し、3回の測定実行を収集しました。

両モデルとも、測定対象とした3回の実行すべてにおいて、生成エラーを起こすことなく完了し、テスト全体を通してGPU使用率は高いままでした。Ollamaでは、両モデルをフルGPUアクセラレーションで実行するために、追加のCUDA設定やGPUレイヤーの手動調整は一切必要ありませんでした。これは、CUDAランタイムDLLを手動で追加する必要があったOpen WebUIとは対照的です。

モデル	量子化	出力トークン	デコード速度	GPUメモリ
Jan V3.5 4B	Q4_K_XLファイル*	529	145.48 トーク/秒	5,082 MB
1月 V2 VL 高	翻訳元	1,696	92.87 トーク/秒	7,124 MB

注：出力トークン数、デコード速度、およびGPUメモリの値は、ウォームアップ実行を1回除外した後の3回の測定実行の中央値です。GPUメモリは、各測定実行中に記録されたGPU全体の最大メモリ使用量の中央値です。

*Jan V3.5 GGUFファイル名ではQ4_K_XLが識別されますが、Ollamaのモデル情報ではQ4_K_Mと報告されています。上記のインポートに関する注記を参照してください。

Jan V3.5 は、測定された実行全体で 145.48、145.73、145.44 トークン/秒を記録し、Jan V2 は 92.87、92.22、92.97 トークン/秒を記録しました。どちらのセットも実行ごとにほぼ同じ値を示し、各セット内で測定された GPU メモリのピーク値は変化しませんでした。Jan V2 は、推論アクティビティを含めて、報告された出力トークンがかなり多く生成されたため、これらの合計値は目に見える回答の長さの直接比較ではありません。

同じワークステーションとモデルファイルを使用した場合、これらはこのシリーズでこれまでで最速の結果です。Jan V3.5 はJan自体 (123 トークン/秒) より 18% 速く、 Open WebUI Desktop (115.32)より 26% 速くデコードされ、Jan V2 は Jan (82) より 13% 速く、Open WebUI (75.06) より 24% 速くなりました。各アプリケーションは独自の llama.cpp ビルドを実行し、独自の方法で GPU オフロードを管理するため、比較はモデル単体ではなく、各アプリケーションが同梱する完全なパッケージを反映しています。

繰り返しリクエストが発生すると処理時間が非常に短くなり、キャッシュの影響を受けた可能性があるため、プロンプト処理の中央値は公開しませんでした。また、ランタイム設定はあらゆる点で同一である必要はありません。JanはGPUレイヤーを直接公開していましたが、Ollamaはオフロードを自動的に管理していました。

Ollamaを使ったローカルチャット

モデルをインストールした後、ドロップダウンメニューから「Jan V3.5」または「Jan V2」を選択し、RAIDプロンプトを入力しました。回答は見出しとリスト形式で表示され、最近の会話はサイドバーに残りました。Ollamaは応答の下に生成率やトークン数を表示しなかったため、API経由でこれらの数値を取得しました。

Ollamaでの会話管理は非常に簡単で、以前の会話を右クリックすると名前変更や削除のオプションが表示され、「その他のツール」から「共有」オプションも利用できました。送信済みのプロンプトを遡って編集することもできましたが、モデルの応答に関するオプションはそれほど多くありませんでした。唯一見つかったボタンは「コピー」で、カーソルを合わせていない時でも各回答の下に表示されたままでした。少なくともテストしたバージョンでは、チャットウィンドウから応答を再生成したり、生成統計を表示したりする方法を見つけることはできませんでした。

Ollamaには、Codex CLI、Claude Code、OpenCode、Clineなどのコーディングアシスタントを含むアプリセクションもあります。これらの連携がどのように機能するかを確認したかったので、Codex CLIをクリックしてセットアップ方法を見てみました。Ollamaは設定画面を開かず、起動コマンドをクリップボードにコピーしてターミナルに貼り付けるように指示しました。完全なインストールやCodexの実行は行いませんでしたが、Ollamaがローカルモデルを外部アプリケーションに接続する方法について、より深く理解することができました。

ウェブ検索

Ollamaはチャットの添付ファイルコントロールの横に地球儀ボタンを配置しますが、それを選択すると、Web検索にはOllamaアカウントが必要であるというメッセージが表示されました。無料アカウントに登録して機能を有効にした後、既存のテスト質問を使用して、2026年10月15日時点の最新の安定版Open WebUIリリースをソース引用とともに尋ねました。

OllamaのWeb検索機能をテストした際、別の問題が発生しました。アプリケーションは検索結果を取得しようとしましたが、「検索APIエラー（ステータス402）」というメッセージが返されました。HTTP 402は有料プランが必要であることを示すコードですが、Ollama側ではその旨は明示されていませんでした。モデルは、問題の原因がアカウントの料金設定や利用制限にある可能性を示唆しましたが、正確な原因を特定することはできませんでした。ローカル環境ではモデルが正常に動作していたため、検索サービスのトラブルシューティングにこれ以上時間を費やすのはやめました。とはいえ、このシリーズの他のアプリケーションで試みたのと同じWeb検索テストを完了できなかったのは残念でした。

マルチモーダル入力

最初の画像テストでは、1月に別のビジョンプロジェクターで動作したのと同じJan V2 VL High GGUFを使用しました。Ollamaは言語モデルファイルを受け入れましたが、インポート手順で付属のmmprojファイルが関連付けられませんでした。NVIDIAのスクリーンショットをJan V2の会話に添付しようとしたところ、プロンプトを送信する前にデスクトップアプリケーションに「このモデルは画像をサポートしていません」と表示されました。

次に、Ollama からダウンロードした Qwen3-VL 4B を試しました。GPU モデル、ドライバー バージョン、VRAM、使用率、温度、電力を尋ねる同じプロンプトを使用しました。このモデルはスクリーンショットを受け入れ、RTX 5000 Ada Generation、ドライバー 597.06、32,760 MiB、使用率 0 パーセント、39 ℃、40 W という 6 つの正しい値で終了しました。ただし、応答は全体を通して完璧ではなく、最終的な概要で値を修正する前に、一時的に使用率が 8 パーセントと誤って表示されました。

Ollamaでは、他のアプリケーションのようにWindowsのSnipping Toolからチャットウィンドウに画像を直接貼り付けることができませんでした。そのため、まずスクリーンショットを保存し、メッセージフィールドの横にある「+」ボタンを使ってアップロードする必要がありました。この方法は問題なく機能し、OllamaのQwen3-VLモデルは画像を正常に解析しました。しかし、インポートしたJan V2モデルは同じ添付ファイルを受け付けることができず、元のマルチモーダルテストを再現することができませんでした。

ローカルAPIサーバー

OllamaのローカルAPIは、デスクトップインターフェースから別のサーバーを起動することなく、Windowsサービスが起動するとすぐに利用可能になりました。 http://127.0.0.1:11434/v1/models インストール済みの Jan V3.5 および Qwen3-VL モデルを返却し、 /v1/chat/completions Jan V3.5を使用すると、RAID 6に関する1文の説明が生成されました。

応答では、RAID 6パリティに関する表現がやや不正確でしたが、これはモデル出力の問題であり、APIの障害ではありませんでした。正常に動作するエンドポイントを使用することで、デスクトップチャットを使用せずにPowerShellから直接ローカルモデルを照会できるようになりました。

何が悪かったのか

私たちが遭遇した最も厄介な問題は、インポートした Jan V2 VL High モデルで画像を扱うことでした。GGUF のインポートや、GPU アクセラレーションをフルに活用したテキストプロンプトの実行には問題ありませんでしたが、NVIDIA のスクリーンショットを添付しようとしたところ、状況が一変しました。Ollama は、インポートしたモデルに Jan V2 に必要な別のビジョンプロジェクターが含まれていないため、モデルが画像をサポートしていないと表示しました。それでも、Ollama の Qwen3-VL ダウンロードを使用すれば、問題なく画像解析テストを完了することができました。このことから、Ollama は画像を処理できることが分かりましたが、既存の Jan V2 モデルで同じことを行うには、GGUF ファイルをインポートするほど簡単ではありませんでした。

ウェブ検索機能を利用するには、まずOllamaアカウントを作成する必要がありました。ログインしてテスト質問を送信すると、HTTP 402エラーが返され、検索結果は表示されませんでした。エラーの原因は特定できず、解決するかどうかわからないままアカウント設定を変更したり、別のプランを試したりする意味もあまりありませんでした。

既存モデルのインポート、設定の調整、パフォーマンス測定の収集といった作業のために、PowerShellに戻る必要があったことも分かりました。デスクトップアプリケーションは日常的なチャットには使いやすかったものの、Janのインターフェースで得られたような高度な制御は提供していませんでした。これらの問題を除けば、Ollamaはテスト中にほとんどトラブルを起こしませんでした。両方のモデルが正常にインポートされ、6つのベンチマーク実行すべてが完了し、ローカルAPIも期待どおりに動作しました。

結論

Ollama 0.40.11 を使用したテストは概ね順調に進み、特に RTX 5000 Ada 上でローカルモデルを実行することに成功しました。インポートした 2 つの GGUF はどちらも、追加の CUDA 設定を必要とせずにフル GPU アクセラレーションで動作し、パフォーマンスはシリーズをリードしました。Jan V3.5 は平均 145.48 トークン/秒、Jan V2 VL High は 92.87 トークン/秒に達し、このシリーズで最速の結果となり、同じワークステーション上の Jan よりも 13 ～ 18 パーセント速い結果となりました。すべての設定が完了すると、デスクトップ チャット インターフェイスとローカル API 間の切り替えに問題はなく、すべてのベンチマーク実行も問題なく完了しました。

Ollamaは日常的なチャットにはシンプルで使いやすい点が気に入りましたが、デスクトップアプリケーションで個々のモデルをより細かく制御できる機能があれば良かったと思います。既存のGGUFをインポートするためにPowerShellを使用してモデルファイルを作成する必要があったため、特にJanと比較すると手順がいくつか増えました。Janでは、これらの設定のほとんどがインターフェースで直接利用できます。ローカルモデルの実行に慣れているユーザーにとっては問題ないかもしれませんが、グラフィカルインターフェースですべてを管理したい新規ユーザーにとっては、Ollamaは制限が多いと感じるかもしれません。また、Web検索とインポートしたビジョンモデルでいくつか問題が発生しましたが、どちらも通常のテキスト生成には影響しませんでした。

Ollamaで最も気に入った点は、別途サーバーを設定することなく、ローカルモデルを他のアプリケーションに簡単に提供できる点でした。デスクトップチャットはすぐに使い始めることができ、ローカルAPIと外部コーディングツールのサポートにより、ローカルモデルとのチャット以外にも多くのことが可能です。デスクトップインターフェースにおけるモデル管理機能の改善は依然として望まれますが、Ollamaはワークステーション上で優れたパフォーマンスを発揮し、GPUアクセラレーションを使用して2つのテストモデルを安定して実行できる方法を提供してくれました。

リーダーボード： Ollamaは、当サイトの「ベストローカルLLMツール」ページで「総合的に最も優れたローカルLLMランタイム」を獲得しました。この結果は、JanおよびOpen WebUIの数値と並んで掲載されています。