背景: SDN の運用および保守ナレッジ プラットフォーム (RAG) を構築しています。質問と回答のために、Ollama を使用してイントラネット サーバー上でローカルの大規模モデルを実行する必要があります。選択されたモデル
qwen2.5:7b-instruct。この記事では、「ログの見方」、「パフォーマンスの測定方法」、「このモデルの大きさはどれくらいか」を一度にわかりやすく説明します。これらはすべて、文書で転送されたものではなく、実際に足を踏み入れて測定された実際のデータです。
1. 結論から先に話しましょう
qwen2.5:7b-instruct これは、Ali Tongyi Qianwen のオープンソース シリーズの「中カップ」です。70億パラメータ、命令の微調整バージョン、4ビット量子化後4.7GB「単体機」の中では最も甘い部類に属します。 RAG 構造では、「証拠を読み取り、回答を整理する」ことのみを担当します。知識を暗記する必要はないので、7Bで十分かつ妥当な組み合わせです。現時点での本当のボトルネックはモデルの選択ではありません。純粋な CPU 推論速度。
2. 私たちの派遣状況（まず家族背景を調べます）
モデルは上で実行されます 192.168.118.218オラマと システムサービスホスティング、ログはjournaldに送信されます。
# 服务形态
systemctl is-active ollama # active
systemctl is-enabled ollama # enabled
# 关键环境变量
OLLAMA_HOST=0.0.0.0:11434
OLLAMA_MAX_LOADED_MODELS=1 # 同时只能驻留 1 个模型
OLLAMA_KEEP_ALIVE=10m # 10 分钟不用就卸载
# 模型
ollama list
# qwen2.5:7b-instruct 4.7 GB 2 days ago
2 つの重要なポイント:
- GPU なし、純粋な CPU 推論(16コア/62GB RAM)。したがって、後続のパフォーマンス数値はすべて CPU レベルであり、GPU マシンからのデータと比較しないでください。
ollama ps現在は、ヌル～の～だからKEEP_ALIVE=10mモデルがロードされていないときは、モデルはメモリ内にありません。最初の各質問にはコールド ロード時間がかかります。
3. ログの見方
オラマの丸太は主に外側から内側に向かって 3 つの層で構成されています。
1. サービスログ (メインパス、systemd ホスティング)
journalctl -u ollama -f # 实时滚动
journalctl -u ollama -n 100 # 最近 100 条
journalctl -u ollama --since "30 min ago" # 最近半小时
journalctl -u ollama --since today --no-pager | grep -i error
ログ内の 3 種類の情報が最も価値があります。
-
リクエストごとに 1 行 GINアクセスレコードHTTP の導入にかかる合計時間。例:
POST "/api/generate" | 9.69s -
モデル読み込みプロセス：
loading model via llama-server→load_tensors …コールドロードにどれくらいの時間がかかるかがわかります。 -
リクエスト終了後のパフォーマンスの詳細行 (デフォルトでは出力されません。以下を参照)。
2. より詳細なデバッグログ
デフォルトのログではトークンごとのパフォーマンスの低下なし。したい llama_perf_context_print このタイプのきめの細かいラインの場合は、デバッグを有効にします。
systemctl edit ollama # 加 Environment=OLLAMA_DEBUG=1
systemctl restart ollama # 会中断服务几十秒，按需开启
3. システム独自の観点からのログ (誰が調整を行ったか、どれくらいの時間がかかったのか)
私たちのハブ自体もその呼び出しを覚えています: 216 data/ops.log + data/usage/*.jsonl内側は各モデル呼び出しの遅延、トークン、成功または失敗。モデル管理ページの「実行ステータス→通話統計」タブを直接確認してください。 p95、故障率、およびモデルごとの概要があります。これは、「発信者の観点」から見た最もクリーンなモニタリングです。
4. パフォーマンスの見方
パフォーマンス データには 3 つの観点があり、それぞれが相互に裏付けられます。
1. 居住国:ollama ps
現在ロードされているモデル、占有しているメモリの量、CPU/GPU 上で実行されているモデル、および存在できる期間 (UNTIL リスト）。空 = ロードされていません。
2. API にはタイミングが付属しています (最も正確な粒度の細かいデータ)
右 /api/generate または /api/chat 髪非ストリーミングリクエストとレスポンスには、4 つの期間と最後に 2 つのカウントが含まれます。
curl -s \
-d '{"model":"qwen2.5:7b-instruct","prompt":"用一句话介绍SDN","stream":false,"options":{"num_predict":60}}'
一度測定してみました（非ストリーミング、num_predict=60）。
| 索引 | 実際の値 | 説明する |
|---|---|---|
load_duration |
5.85秒 | メモリへのコールド ロード (CPU 負荷 4.7 GB の重み) |
| 入力処理のプレフィル | 37 トークン / 0.54 秒 ≈ 68件/秒 | 質問をエンコードする |
| デコードの生成 | 28 トークン / 3.29 秒 ≈ 8.5件/秒 | 純粋な CPU デコード速度、7B 標準レベル |
total_duration |
9.7秒 | エンドツーエンド |
換算式：decode 速度 = eval_count / eval_duration、prefill 速度 = prompt_eval_count / prompt_eval_duration(単位はナノ秒であることに注意してください)。
3. システムリソース層
top -p $(pgrep -f 'ollama serve') # CPU / 内存占用
free -h # 内存大盘
GPUがないのでダメ nvidia-smi 可視 – これは純粋な CPU マシンの標準です。
5. このモデルの大きさはどれくらいですか?
名前の内訳
| 一部 | 意味 |
|---|---|
| クウェン2.5 | アリババ 2024 オープンソース シリーズ、中国語能力はオープンソース モデルの最初の段階 |
| 7b | 70億 = 70億のパラメータモデルの「脳力」、トレーニング後に固まった知識や能力 |
| 指示する | 微調整されたバージョンの指示では、アシスタント モードを使用して会話します。同じ名前の基本バージョンは引き続きテキストの書き込みのみを行うため、展開の指示を選択する必要があります。 |
| 4.7GB | 4ビット量子化続く巻。元の半精度 (FP16) は約 1/3 に量子化された約 14GB を必要とし、効果の損失は通常 1% 未満です |
スケールラダー(Q4量子化ボリューム/ランニングメモリ)
パラメータの量が 1 桁増加するにつれて、機能と導入コストも増加します。 7B はたまたま「本格的に動作する最初のマシン」に行き詰まっています。
| モデル | 定量後の体積 | 走行メモリ（約） | 実行可能なハードウェア |
|---|---|---|---|
| qwen2.5-0.5b | 0.4GB | ～1GB | 携帯電話/Raspberry Pi |
| qwen2.5-1.5b | 1.0GB | ～2GB | ノート |
| qwen2.5-3b | 2.0GB | ～3GB | ノート |
| qwen2.5-7b (弊社のデプロイメント) | 4.7GB | ～6GB | 8GB グラフィックス カードまたは純粋な CPU |
| qwen2.5-14b | 9GB | ～12GB | 12 ～ 16GB グラフィックス カード |
| qwen2.5-32b | 20GB | ～26GB | 24GB プロフェッショナル カード (4090/A10) |
| qwen2.5-72b | 43GB | ～50GB以上 | マルチカード/サーバー |
実行メモリ ≈ モデル ボリューム × 1.3 (コンテキスト KV キャッシュを含む)。 14B からは専用のグラフィックス カードが必要となり、32B/72B がサーバー領域に入ります。
能力分布（定性スコア1～5、公的評価のおおよその範囲を参照）
パラメーターの数によってすべての機能が均一に向上するわけではありません。7B は「理解 + 表現」では大規模モデルに近いですが、「推論 + コード」ではギャップが明らかです。
| タスクの種類 | 7B | 32B（参考） | 説明する |
|---|---|---|---|
| 中国語読解・要約 | 4 | 4.5 | 7Bの強み |
| RAGアンサーグループ | 4 | 4.5 | このプロジェクトの主な用途 |
| 複数回の対話 | 3.5 | 4.5 | |
| 複雑な複数段階の推論 | 2 | 4 | 7Bは明らかに弱い |
| コード生成 | 2 | 4 | 7B を使用してコードを記述することは推奨されません |
6. この RAG アーキテクチャではなぜ 7B で十分なのでしょうか?
これは最も重要な点であり、「小さなモデル + 検索」と「メモリに依存する大きなモデル」の古典的な設計でもあります。
-
あなたの知識は基礎ですモデルにはない——ベクトル ライブラリ (Qdrant、ここには 815 個のコーパス チャンクがあります) 内にあります。
-
モデルのお仕事は「回収した証拠を読む → 一貫した回答に整理する」、つまり上の表（中国語理解・まとめ、RAG解答編成）の1行目と2行目、これが7Bの強みです。
-
システムもそうなったルールベースモード (ルール): モデルが利用できない場合でも、システムがクラッシュすることなく、章の位置を含む証拠リストを返すことができます。
したがって、7B の選択は「間に合わせ」ではなく、アーキテクチャ上のパラメータ要件の削減です。
7. ボトルネックとアップグレード パス
現在の実測値 CPU デコード 8.5 tok/s200 語の回答には 15 ～ 20 秒かかります。速度のボトルネックはハードウェアの選択ではなく、ハードウェアの選択にあります。推奨されるアップグレード順序:
- コストゼロ：バンドル
OLLAMA_KEEP_ALIVEサイズを大きくします（30m または-1永続的)、最初のクエリごとに 5.9 秒のコールド ロードが不要になります。 218 は 62GB のメモリを搭載しており、常駐の 5GB を圧迫せずに使用できます。 - トップGPU: 同じモデルの 12GB 以上のグラフィックス カード (3060 / 4070 など) の場合、速度は数倍高くなります (通常 30 ～ 80 tok/s)。
- より大きなモデルに変更する：
qwen2.5:14b-instruct(量子化後は約 9 GB)、推論とマルチラウンドは明らかに強力です。ただし、CPU では速度が遅くなります (約半分)。そのため、最初に GPU を使用してから、より大きなモデルに変更することをお勧めします。
systemd 構成を変更するには、以下が必要です
systemctl restart ollamaサービスは数十秒間中断されます。移行前に計画どおりに本番環境が確認されることになります。
8. まとめ（要点の概要）
-
展開する: 218 Ollama は systemd、GPU なし、純粋な CPU を提供します。
KEEP_ALIVE=10m、MAX_LOADED_MODELS=1;モデル 4.7GB は 4bit 量子化バージョンです。 -
ログを読む：
journalctl -u ollama -fリアルタイムで見る;トークンごとのパフォーマンスを確認したいOLLAMA_DEBUG=1;システム側センターdata/usage/*.jsonlまたは、モデル管理ページの「通話統計」タブ。 -
パフォーマンスを見てください：
ollama ps住人を見てください。 API の非ストリーミング リターンには、ロード、プレフィル、デコードという 3 つの時間のかかるステップが含まれます。システム層で使用されるtop/free。 -
測定されたベースライン: コールドローディング 5.85 秒、プレフィル ≈68 tok/s、デコード ≈8.5 tok/s、エンドツーエンド 9.7 秒 (純粋な CPU)。
-
モデルの大きさ: 7B = 70 億パラメータ、単一マシンのデザート ファイル。理解・要約・RAG構成に強く、推論・コードに弱い。
-
十分な理由: RAG アーキテクチャにより、ベクトル ライブラリとモデルで知識を「読み取り + 整理」することができ、すべてをカバーするルールがあれば、7B は完全に適格です。
-
アップグレードの優先順位：初め
KEEP_ALIVE恒久的な冷却から始めて、次に GPU を使用して高速化し、最終的に 14B を検討します。一言: 7B は「イントラネットの単一マシン展開」の入門レベルのスイート スポットであり、ナレッジ Q&A に RAG を使用するのが標準的です。ここでは、モデルの選択ではなく、CPU 速度にこだわっています。
