ローカル LLM デプロイ完全ガイド:トークンの自由を手に入れるエージェントワークフロー構築術(初心者向け)

@Lonely__MH
中国語2026年8月17日
153K
287
74
94
470

TL;DR

vLLM を使用して 124B の Ling-3.0-flash モデルをローカルにデプロイするための詳細なチュートリアルです。パフォーマンスのベンチマーク、TUI の開発、および自動化されたコンテンツタスクのためのマルチモデルワークフローの統合について解説します。

本記事は、可能な限りわかりやすく解説し、初心者のプレイヤーでもローカルモデルのデプロイと独自ワークフローの構築を簡単に習得できることを目指しています。

今年、国内のオープンソース大規模言語モデルは非常に活発です。DeepSeek、Qwen、Kimi、GLM、MiniMax…次々と新しいモデルが登場し、絶えずウェイトを公開し、米国のクローズドソースモデルと互角に渡り合い始めています。

しかし、モデルが増えれば増えるほど、私は特定の疑問を抱くようになりました。これらのモデルは、ウェブページや API の中だけでなく、実際に私たち自身のマシンにインストールして、ローカルファイル、ツール、ワークフローに接続できるのでしょうか?

API トークンの単価は全般的に低下傾向にありますが、高頻度の呼び出しや長文テキストを扱う場合、コストは依然として高くなります。プライバシー、ネットワーク、データ管理といった問題も加わり、ローカルデプロイは、ますます多くの開発者や企業にとって選択肢となりつつあります。

そこで今回は、シングルマシンデプロイの代表例として、挑戦的なサイズのモデルを選び、ローカルデプロイの完全なプロセスを実行してみたいと思います。

最終的に選ばれた主役は、Ant Bailing がオープンソース化した Ling-3.0-flash です。これは、総パラメータ数 124B の Mixture of Experts(MoE)モデルです。ちょうど手元に NVIDIA DGX Spark があるので、これを実行できます。

それでは、早速本題に入りましょう。

Lonely - inline image

01 用語の基礎知識

始める前に、モデルに関するいくつかの用語を紹介し、皆さんの理解を深めましょう ✌🏻

モデル精度

同じモデルでも、異なる精度や量子化バージョンが提供されていることが多く、これらはモデルサイズと実行要件に直接影響します。

Lonely - inline image

今回は、公式の Ling INT4 バージョンを使用します。サイズは約 71.75GB です。

Dense モデルと MoE モデル

Lonely - inline image

5.1B は推論ごとに活性化されるパラメータ数に過ぎないことに注意してください。完全な 124B のウェイトはメモリにロードする必要があります。

推論エンジン

推論エンジンは、ウェイトのロード、コンテキストと同時実行数の管理、インターフェースの提供を担当します。これはモデルを実行するためのツールであり、モデル自体ではありません。

Lonely - inline image

今回は vLLM を選択しました。現在の公式アダプテーションが Ling-3.0-flash の INT4 ウェイトと MTP 投機的デコードをサポートしているためです。

02 モデルのインストールとデプロイ

まず、インストール環境を紹介します。使用しているのは NVIDIA DGX Spark で、GB10 チップと 121.6GB のユニファイドメモリを搭載し、ARM64 アーキテクチャ上で Ubuntu 24.04 を実行しています。デプロイするのは Ling-3.0-flash-INT4 で、以降のスループットテストでは、ローカルの Qwen 3.8-27B をリファレンスとして使用します。

公式からは、ベーシックバージョンに加え、FP8、FP4、INT4 などの異なる精度バージョンが提供されています。お使いのハードウェアに応じて選択できます。

また、8B の Ling-3.0-tiny とその FP8、INT4 バージョンもあります。通常の Mac やシングル 4090 をお使いのユーザーは、まず Tiny の低精度バージョンを試すことをお勧めします。

Lonely - inline image

ステップ 1: モデルをダウンロードする。 今回は公式の INT4 バージョンを使用しました。ダウンロードはこちらから 👇🏻

Hugging Face へのアクセスが難しい場合は、ModelScope から手動でダウンロードできます。ダウンロード後、24 個の safetensors シャードがあり、合計約 71.75GB です。また、実行時の推論エンジンと KV Cache 用のスペースも確保する必要があります。

ステップ 2: 環境を準備する。 Ling-3.0-flash の BailingMoeV3 アーキテクチャはかなり新しいものです。GGUF を llama.cpp で使おうと試みましたが、unknown model architecture: 'bailingmoe3' というエラーが発生しました。そこで今回は、公式にアダプトされた vLLM ブランチ を直接使用しました。

text
1pip install uv
2uv venv ~/my_ling_env
3source ~/my_ling_env/bin/activate
4
5git clone -b ling_3_0 https://github.com/inclusionAI/vllm-ling-v3.git
6cd vllm-ling-v3
7VLLM_USE_PRECOMPILED=1 uv pip install --editable . --torch-backend=auto

ステップ 3: 推論サービスを起動する。 モデルパスを、ローカルにダウンロードした INT4 ウェイトのパスに置き換えてください。

text
1vllm serve /path/to/Ling-3.0-flash-int4 \
2 --served-model-name ling-int4 \
3 --host 127.0.0.1 \
4 --port 30000 \
5 --trust-remote-code \
6 --max-model-len 16384 \
7 --gpu-memory-utilization 0.8 \
8 --max-num-seqs 8 \
9 --reasoning-parser ling3 \
10 --speculative-config '{"method":"bailing_hybrid_v3_mtp","num_speculative_tokens":1}'

⚠️

コマンド内のパスは、実際のマシンのパスに置き換えてください。

ここでは、コンテキスト制限を 16K、同時実行数を 8 に設定し、MTP 投機的デコードを有効にしています。

注: MTP(Multi-Token Prediction)により、モデルは複数のトークンを一度に予測しようと試みます。正しく予測された部分はそのまま採用できるため、トークンを一つずつ生成する際の計算回数を減らし、出力速度を向上させます。

ステップ 4: サービスを確認する。 起動したら、簡単なリクエストを送信します。

bash
1curl -s http://127.0.0.1:30000/v1/chat/completions \
2 -H "Content-Type: application/json" \
3 -d '{"model":"ling-int4",
4 "messages":[{"role":"user","content":"こんにちは、一言で自己紹介してください。"}],
5 "stream":true}'

ターミナルがストリームでコンテンツを返し始めれば、この 124B モデルがローカルで実行されていることを示しています。

Lonely - inline image

03 モデルのパフォーマンスと能力のテスト

  1. トークンスループット モデル起動後、vLLM に組み込まれているベンチマークを使用してテストを実行しました。20 件のリクエストすべてが完了し、出力スループットは 84.34 tok/s、総トークンスループットは 133.10 tok/s、MTP 受入率は 67.35% でした。
Lonely - inline image

元のログ出力はこちら 👇🏻

text
1============ Serving Benchmark Result ============
2Successful requests: 20
3Failed requests: 0
4Request rate configured (RPS): 2.00
5Benchmark duration (s): 60.71
6Total input tokens: 2960
7Total generated tokens: 5120
8Request throughput (req/s): 0.33
9Output token throughput (tok/s): 84.34
10Peak output token throughput (tok/s): 61.00
11Peak concurrent requests: 20.00
12Total token throughput (tok/s): 133.10
13---------------Time to First Token----------------
14Mean TTFT (ms): 19692.98
15Median TTFT (ms): 18877.99
16P99 TTFT (ms): 40039.02
17-----Time per Output Token (excl. 1st token)------
18Mean TPOT (ms): 44.61
19Median TPOT (ms): 44.09
20P99 TPOT (ms): 49.68
21---------------Inter-token Latency----------------
22Mean ITL (ms): 74.09
23Median ITL (ms): 72.39
24P99 ITL (ms): 280.71
25---------------Speculative Decoding---------------
26Acceptance rate (%): 67.35
27Acceptance length: 1.67
28Drafts: 3051
29Draft tokens: 3051
30Accepted tokens: 2055
31Per-position acceptance (%):
32 Position 0: 67.35
33==================================================

その後、Ling とローカルの Qwen 3.8-27B に対して同時実行テストを実施しました。同時実行数 8 において、Ling の総スループットは 141.38 tok/s であったのに対し、Qwen 3.8 は 32.61 tok/s で、このラウンドでは約 4.34 倍の差がありました。

🔥🔥🔥Ling-3.0-Flash Vs Qwen3.8-27B 負荷テスト比較

Lonely - inline image

Ling-3.0-flash

Lonely - inline image

Qwen 3.8 -27B

Lonely - inline image
Lonely - inline image

疑問に思う方もいるかもしれません。なぜ Ling のシングル同時実行数は 34.77 tok/s なのに、同時実行数 8 では 141.38 tok/s になるのか?技術に詳しい方なら、このシングル同時実行数のスコアは公式データと比較して遅いのではないかと疑問に思うかもしれません。

ここで、具体的なテスト方法と、評価方法の違いによる速度の差について説明する必要があります。

  1. テスト方法と実際のエンドツーエンドリンク: このテストでは、ローカルの OpenAI 互換インターフェースを使用し、HTTP ストリーミングリクエストを介して負荷テストを実施しています。これは、サービスフレームワークから切り離されたオフライン推論テストではありません。各 Ling リクエストは約 150 トークンの長いテキストプロンプトを使用し、最大 512 トークンを生成します。計測はクライアントの HTTP リクエストからストリーミングレスポンスが完了するまで行われ、ローカル HTTP 呼び出し、サービススケジューリング、トークナイザー処理、Prefill、トークン単位のデコード、ストリーミング返却が含まれます。
  2. シングルストリーム出力レート vs. マシンの総スループット: シングルストリーム速度(実際のユーザー体験): $c=1$ の場合、エンドツーエンドの出力レートは約 35.34 tok/s(実際のシングル会話テストでは 38+ tok/s)で、これは毎秒 35 文字以上の中国語文字に相当し、視覚的に非常に高速です。総スループット(同時実行時の総出力): 同時実行数が増加するにつれて、vLLM は Continuous Batching を使用して複数のリクエストを GPU 計算に結合し、Blackwell のユニファイドメモリ帯域幅を完全に活用します。同時実行数 8 では、マシンの総スループットは 141.38 tok/s に急上昇しました。

一部の公式ベンチマークと異なる理由は、テスト基準が鍵です。モデル精度、推論エンジン、コンテキスト長、入出力トークン数、同時実行規模、オフライン推論か HTTP サービスかなど、すべての条件が最終結果に影響します。これらの条件が基本的に一致している場合にのみ、数値は直接比較に適しています。

簡単に言えば、速度は評価方法によって異なります。非常に高い同時実行数(例:32/64)や、ネットワークプロトコルを使用しない純粋な計算環境でテストすると、総スループットの数値は高く見えます。日常的なシングル会話やコーディングのプロダクション呼び出しでは、Ling のシングルストリーム 35+ tok/s と 220ms 未満のファーストトークン待ち時間は、非常にスムーズでラグを感じさせません。

シングル同時実行数では、Ling の平均シングルストリーム速度は約 35.34 tok/s です。同時実行数 8 では、総スループットは 141.38 tok/s に達します。Qwen3.8 の同時実行数 8 における総スループットは 32.61 tok/s です。このラウンドでは、Ling の優位性は主に出力速度と同時実行スループットに現れており、実際の使用では応答が著しく高速です。

2. 実際の能力

ベンチマークはパフォーマンスの一部を反映するに過ぎません。実際の有用性は、特定の問題に対するモデルのパフォーマンスにかかっています。私は 3 つの方向性を選んで簡単なテストを行いました。

(1) 論理的推論

鶏とウサギの問題のバリエーション、古典的な洗車問題、洗車機問題を用意しました。主な目的は、よく知られた答えを当てはめるのではなく、条件を正確に理解できるかどうかを確認することです。その中で、鶏とウサギの問題には、従来のパターンを打ち破るために、脚が 3 本ある 4 台の機械式鳥が含まれています。

Lonely - inline image

(2) 安全性の境界: 次に、高リスク操作に対する反応をテストしました。直接実行するのか、リスクを特定してユーザーに確認し、より安全な代替案を提供するのかを確認します。

Lonely - inline image

(3) 長文テキスト

最後に、長文テキストのテストを実施しました。長いコンテキスト内に重要な情報を隠し、それを正確に見つけて回答できるかどうか、また長文テキストでの出力速度と安定性を観察しました。

Lonely - inline image

04 API から TUI、そしてツール呼び出しへ

モデルのデプロイと能力テストは完了しましたが、一般ユーザーにとって、curl はインターフェースの確認には適していても、日常的な使用には向きません。ローカルモデルと長時間対話するには、より便利なインタラクションインターフェースが必要です。

そこで、まずシンプルな TUI、つまりターミナル内で動作するチャットインターフェースを作成しました。複雑なソフトウェアではなく、AI に Python スクリプトを書かせて、ローカルインターフェースの呼び出し、ストリーミング出力、会話履歴をカプセル化し、ワンコマンドで起動できるようにしました。

text
1python3 ling-3.0-chat.py

これで、毎回 curl を書く必要がなくなりました。ターミナルを開いて直接チャットでき、回答がストリーミング表示され、TPS、TTFT、トークン数も確認できます。前述の能力テストはすべてこのインターフェースで行いました。

しかし、この時点では TUI は単なるテキストチャットツールであり、ツールを呼び出す機能はありません。大規模言語モデルは思考を担当する「頭脳」のようなものですが、ファイルを読んだり、コマンドを実行したり、システムの現在の状態を知るための「手足」がありません。

システム機能を呼び出せるようにするには、ツール呼び出し機能を追加する必要があります。簡単に言うと、コマンド実行、ファイル読み取り、書き込みなどの操作をツールとしてカプセル化します。モデルはまず必要な情報を判断し、ツール使用を開始します。Python スクリプトがそれを実行し、結果をモデルに返してさらに処理させます。

例えば、最初にシステムの GPU 情報を確認するように依頼したとき、モデルは実際の使用状況を知らず、確認方法を教えることしかできませんでした。ツール呼び出しを追加した後は、モデル自身がシステムコマンドを実行し、クエリ結果を TUI 内で直接整理できるようになりました。

同じ原理に基づいて、Web 検索、社内エンタープライズインターフェース、データベースなどを接続し続けることができます。具体的なツールはビジネスニーズに応じて拡張できます。

Lonely - inline image

05 ビジュアルインターフェースへの接続

個人使用であれば、ツール呼び出し機能を備えた TUI で十分です。さらに一歩進んで、モデルをより完全な Agent ワークベンチに組み込むには、Harness のようなエージェントフレームワークに接続できます。

今回は Liang Sheng の DeepSeek Harness を選びました。これはチャットページを追加するだけでなく、コンテキスト管理、ワークスペース、ツール呼び出し、権限制御、タスク計画を提供し、組み込みの Web UI を備えています。「すべてがプラグイン」というアーキテクチャを採用しており、将来の機能拡張が可能です。

DeepSeek Harness はまだ開発者プレビュー段階であり、更新が頻繁に行われるため、互換性のない変更が発生する可能性があることに注意してください。他にも多くのオープンソースの Agent フレームワークがありますので、ニーズに応じて選択してください。

接続プロセスは複雑ではありません。核心は、カスタムモデルサービスを追加し、アドレスを vLLM が提供するローカルインターフェースに指定することです。Web UI で設定する以外に、以下のように設定ファイルを変更することもできます。

text
1llm-pi-ai:
2 providers:
3 ling:
4 displayName: "Ling-3.0-flash (124B)"
5 api: openai-completions
6 baseURL: http://127.0.0.1:30000/v1
7 apiKeyEnv: OPENAI_API_KEY
8 models:
9 - id: ling-int4
10 name: Ling-3.0-flash (124B MoE)

Web UI を起動したら、ブラウザでデフォルトのアドレスを開きます。

text
1http://localhost:3080

これで、日常的なチャット、履歴、モデル切り替えをすべて DeepSeek Harness 内で行えます。Harness 自体がファイル操作、コマンド実行、タスク計画を提供しており、プラグインを介してさらに拡張できます。具体的な使用方法やサードパーティプラグインについては、興味のある方は検索してみてください。

Python TUI で作成したツールは自動的に移行されないことに注意してください。Harness で使用するには、そのプラグインメカニズムに従って再統合する必要があります。以下は、私が Ling 用に作成した実際の統合効果です。録画をご覧ください。

Lonely - inline image

06 AI ワークフローの構築

ここまでで、Ling-3.0-flash のデプロイからインターフェース、ツール呼び出しに至るシングルモデルのリンクが完全に確立されました。

しかし、実際のプロジェクトでは、通常、1 つのモデルだけを使用するわけではありません。異なるモデルにはそれぞれ得意分野があり、1 つのモデルにすべてを任せるよりも、それらを組み合わせる方が効果的であることがよくあります。

Ling-3.0-flash の強みはテキスト処理と生成速度ですが、ネイティブのマルチモーダル入力はサポートしていません。画像や動画を理解する必要があるタスクの場合は、Qwen3.8-27B のようなマルチモーダルモデルを接続できます。動画を生成する必要がある場合は、最近オープンソース化された MiniMax H3 を接続できます。各モデルが最も得意とする処理を担当し、結果を次のモデルに渡します。

例えば、動画生成ワークフローを構築する場合、Ling が最初に要件を理解し、スクリプトを作成し、ストーリーボードを分割します。次に、マルチモーダルモデルが参考資料とビジュアルの一貫性をチェックします。最後に、動画モデルが生成を行います。生成後、さらにビジュアルチェックを行い、結果に基づいてプロンプトを修正し、再生成することができます。

text
1要件と素材
2→ Ling がスクリプトとストーリーボードを生成
3→ マルチモーダルモデルが素材とビジュアル要件をチェック
4→ MiniMax H3 が動画を生成
5→ マルチモーダルモデルがビジュアルと連続性をチェック
6→ Ling がフィードバックに基づいてプロンプトを調整
7→ 人間が最終レビューを完了

以下の動画は、Ling-3.0-flash によって生成されたプロンプトを MiniMax H3 に渡して生成した実際の効果を示しています。

Lonely - inline image

このプロセスが固定化されれば、要件と素材を変更するだけで繰り返し使用できます。ただし、複数の大規模言語モデルをローカルで同時に実行するには、非常に高い VRAM とメモリ容量が必要です。Ling INT4 は約 72GB、Qwen3.8-27B BF16 は約 51.77GB、さらに KV Cache と動画モデルを加えると、この Spark 上ですべてを常駐させることは困難です。

実際にデプロイする前に、各モデルが必要とする VRAM またはユニファイドメモリの量を必ず計算してください。リソースが不足している場合は、モデルを段階的に切り替えたり、量子化バージョンを選択したり、複数のデバイスにモデルを分散させたりできます。複数のモデルはもはや独立して実行されるのではなく、同じタスクを中心に連携します。これこそが、真に使用可能なマルチモデル AI ワークフローです。

07 最後に

モデルのデプロイ、TUI、ツール呼び出しからマルチモデルワークフローまで、すべてのリンクが完了しました。この記事の目的は、固定された設定ではなく、再現可能な方法を共有することにあります。

オープンソースモデルは今後も更新され続けます。将来的に、モデル、量子化バージョン、推論エンジンを変更しても、ウェイトのダウンロード、サービスの起動、ツールやワークフローの接続というパスは大きく変わることはないでしょう。

条件が許せば、皆さんにもぜひローカルモデルを実際にデプロイすることをお勧めします。

  1. データ管理: ファイル、会話、ビジネスデータは自身のマシンまたはイントラネット上に留まり、ディレクトリとコマンドの権限はユーザーが制限できます。
  2. 高頻度使用に最適: 使用のたびにトークンコストを計算する必要がなく、ネットワークやサードパーティサービスへの依存を減らせます。
  3. カスタマイズが容易: モデル、量子化精度、推論エンジン、ツールはすべて調整可能で、社内インターフェースやデータベースに接続できます。

オープンソースモデルが強力になるにつれて、ローカルデプロイはより多くの人々の選択肢となるでしょう。タスクのニーズ、機器の状態、予算に基づいて、ツールやワークフローを構築できます。皆さんがいつか自分自身のローカル Agent を持ち、毎回トークン消費を気にすることなく、真の「トークンフリーダム」を実現できることを願っています。

関連リソース

📚 過去記事まとめ

  1. Hermes Agent 実践ガイド: X の不安から自動積み立てへ
  2. プログラマーのための脱毛防止ガイド
  3. Hermes を iMessage に接続する
  4. Hermes を X Premium に接続する
  5. Hermes Agent 完全ガイド
  6. Hermes Agent 入門ガイド: 補助モデル
  7. Hermes Agent 入門ガイド
  8. Hermes Agent 上級ガイド
  9. Hermes Agent 不完全ガイド
  10. ナイジェリアでの Claude Pro サブスクリプション完全ガイド
  11. ナイジェリア Apple ID 登録チュートリアル
  12. トルコでの半額 ChatGPT Plus サブスクリプション
  13. 米国 Apple ID 登録
  14. Claude/ChatGPT/Gemini Alipay サブスクリプション
  15. Mac でのローカル LLM デプロイ完全チュートリアル
  16. IP 品質チェック
  17. Doubao があなたのブランドをおすすめしない理由
  18. おばあちゃんに Doubao の言っていることが真実ではないと説明する方法

参考になったら、フォロー + ブックマーク + リツイートをお願いします 👏🏻

@Lonely__MH をフォローして、初心者向けチュートリアルと AI ツールの最新情報を入手してください。

YouMindで再制作

Turn one viral article into a full content workflow

Collect the source, decode the pattern, create assets, draft the story, and distribute from one AI workspace.

Explore YouMind
クリエイターのために

あなたの Markdown をきれいな 𝕏 記事に

自分の長文を投稿するとき、画像・表・コードブロックを 𝕏 向けに整形するのは手間がかかります。YouMind は Markdown 全体を、そのまま投稿できるきれいな 𝕏 記事に変換します。

Markdown → 𝕏 を試す

解読すべきパターンをもっと

最近のバイラル記事

バイラル記事をもっと見る