GCP上で Hermes エージェントを実装する — アーキテクチャ中心ガイド
対象： GCP上でオープンウェイトLLM（NousResearch Hermes 系）を自前ホストし、tool useで動くエージェントを構築したいエンジニア。
方針： コードの逐次手順より アーキテクチャ（構成・責務分担・トレードオフ・データフロー） を中心に解説。要所のみ最小コマンドを示す。
前提知識： GCPの基本サービス。
1. Hermes とは（最小限）
- NousResearch の Hermes 系＝ Llama 3.x / Mistral をベースにファインチューンしたオープンウェイトLLM。重みは HuggingFace で公開。
-
強み： 構造化された function calling / tool use。
<tool_call>形式のツール呼び出しに最適化されており、エージェント用途に向く。 - 含意（アーキテクチャ的に重要）： プロプライエタリAPI（Geminiなど）と違い、「モデルをどこかで自分でサーブする」レイヤが必須。ここが構成の主役になる。
2. 全体アーキテクチャ：2レイヤで考える
エージェントは大きく2層に分かれる。これを分離して設計するのが基本（全体像は次章の構成図を参照）。
| レイヤ | 責務 | 主な選択肢 |
|---|---|---|
| ① モデルサーブ | Hermesの重みをGPUで推論・OpenAI互換APIで公開 | GKE+vLLM ／ Cloud Run+GPU ／ Vertex AI Endpoint ／ GCE GPU |
| ② エージェント | ツール呼び出しループ・会話状態・ガードレール | Cloud Run ／ GKE |
設計原則： ①と②を別サービスに分離する。推論はGPUでスケール特性が特殊、エージェントはCPUで軽量・水平スケール。混ぜると非効率かつ運用が複雑化する。
3. モデルサーブ層の選定（アーキテクチャの肝）
| 方式 | スケール特性 | コスト | 自由度 | 向くケース |
|---|---|---|---|---|
| GKE + GPU（vLLM） | 高スループット・常時稼働・水平拡張 | GPUノード常時課金 | ◎ 最高（任意の重み・パラメータ） | 本番・常時トラフィック。本命 |
| Cloud Run + GPU | スケール0〜・従量 | アイドルゼロに近い | ○ | 散発・PoC・小型モデル(〜8B)。コスト最重視 |
| Vertex AI Endpoint（カスタムコンテナ） | マネージド・autoscale | エンドポイント常時課金 | ○（Google寄せ） | 運用をGoogleに寄せたい。MLOps統合 |
| GCE GPU VM | 手動 | VM課金 | ◎ | 検証・フルコントロール・特殊要件 |
GPUサイジングの目安（モデルサイズ別・要確認）
| Hermesベース | 概算VRAM（fp16） | GPU例 |
|---|---|---|
| 8B 級 | ~16GB+ | L4 (24GB) 1枚で収まる（量子化なら更に軽い） |
| 70B 級 | ~140GB+ | A100 80GB × 2 or H100 × 2（テンソル並列） |
| 405B 級 | 数百GB | H100 多数。自前は重い→量子化版や小型を推奨 |
💡 実務判断： 不正検知の調査補助など社内エージェント用途なら、8B〜70Bで十分なことが多い。まず 8B + L4 で握り、必要なら70Bへ。405Bは自前ホストの費用対効果が悪い。
サーブエンジン
-
vLLM を推奨。OpenAI互換API・高スループット（PagedAttention）・tool calling対応（
--enable-auto-tool-choiceと Hermes用 tool parser）。 - 代替：TGI（Text Generation Inference）。
4. リファレンスアーキテクチャ（推奨・本番想定）
各コンポーネントの責務
| コンポーネント | 役割 | なぜ必要か |
|---|---|---|
| Cloud Storage | Hermes重みのキャッシュ | HFから毎回DLは遅く不安定。一度GCSに置き起動高速化 |
| Artifact Registry | vLLM/エージェントのコンテナ管理 | デプロイ元イメージの一元管理 |
| Secret Manager | HFトークン・外部APIキー | コードに秘密を直書きしない |
| Load Balancing | 入口・認証・分散 | 公開面の制御。内部限定なら内部LB |
| IAM + SA | サービス間認証（キーレス） | 最小権限。エージェント→BigQuery等はSAで |
| VPC | ①②間・ツール接続を内部網に | 推論エンドポイントは外部非公開が基本 |
| Monitoring/Logging | GPU使用率・レイテンシ・トークン量・コスト | LLMサービスは観測必須 |
5. 実装ステップ（アーキテクチャ視点）
Step 0. 基盤の準備
- プロジェクト作成、必要APIを有効化（
container,run,artifactregistry,secretmanager,aiplatform等） - VPC・サブネット設計（①②を内部通信に）
- サービスアカウントを役割別に用意（サーブ用 / エージェント用 / CI用）
Step 1. モデル重みの準備（GCS）
- HuggingFaceからHermesの重みを取得（HFトークンは
Secret Manager に格納） - GCSバケットに重みを保存（リージョンはGPUと同一に＝レイテンシ・転送料最適化）
- サーブ層起動時にGCSからロード（毎回HF DLを避ける）
Step 2. モデルサーブ層（GKE + vLLM）
# GPUノードプール（例：L4）を持つクラスタ
gcloud container clusters create-auto hermes-cluster --region=asia-northeast1
# ※ Standardクラスタなら GPUノードプールを別途作成し、NVIDIAドライバを導入
-
vLLMコンテナをDeploymentとしてデプロイ。要点：
-
--model gs://.../hermes-weights（or ローカルパス） -
--enable-auto-tool-choice --tool-call-parser hermes（tool use有効化） - GPUリソース要求（
nvidia.com/gpu: 1等）
-
- 内部 Service / 内部LB で②にのみ公開（外部非公開）
- HPA や KEDA で負荷に応じスケール（GPUは増やすと高いので上限管理）
Step 3. エージェント層（ Cloud Run）
- LangChain / LlamaIndex or 自前で tool useループを実装
- LLM接続先＝Step2のvLLM内部エンドポイント（OpenAI互換クライアントの
base_urlを向ける） - ツール（ BigQueryクエリ等）はSA権限で実行
- Cloud Runの利点： CPU水平スケール・スケール0・従量。エージェント層は軽量なのでこれが最適
Step 4. ツール接続
- 各ツールを「関数」として定義し、Hermesのtool-callスキーマに登録
- 実行はエージェント層のSAで（ 最小権限：例 BigQueryは該当データセットの参照のみ）
Step 5. CI/CD・観測
- Cloud Build で①②のイメージをビルド→ Artifact Registry へ
- Monitoring：GPU使用率・推論レイテンシ・トークン消費・エラー率をダッシュボード化
6. スケーリングとコスト設計
| 観点 | 設計指針 |
|---|---|
| GPUは固定費の主因 | サーブ層を常時起動するか、散発ならCloud Run+GPUでスケール0 |
| ①と②で別スケール | 推論=GPU垂直/限定水平、エージェント=CPU水平。分離してこそ最適化できる |
| 重みキャッシュ | GCS or ノードのローカルSSDでコールドスタート短縮 |
| 量子化 | AWQ/GPTQ等で同GPUに大きいモデルを載せ、コスト削減 |
| オートスケール上限 | GPUノードは上限を必ず設定（暴走課金防止） |
🔁 判断軸（過去の議論と同じ）： 常時・高トラフィック → GKE常時（固定費がペイ）。散発・PoC → Cloud Run+GPU（従量）。
7. セキュリティ / ガバナンス
- 推論エンドポイントは外部非公開（内部LB / Private）。公開面はエージェント層のLBのみ
- SAは役割別＋最小権限。エージェントがツールで触れる範囲を絞る（プロンプトインジェクション対策の最後の砦）
- HFトークン・外部APIキーは Secret Manager
- 保存データは既定で暗号化。要件次第で CMEK
- モデルガバナンス： どのバージョンの重みを使っているか、ライセンス（Hermes/Llamaのライセンス条件）を管理
- ガードレール： ツール実行前のバリデーション、出力フィルタ、レート制限
8. バリエーション
| タイプ | 構成 | 向き |
|---|---|---|
| 本番・常時 | GKE+vLLM（①）＋ Cloud Run（②） | 推奨。高スループット |
| PoC・低コスト | Cloud Run+GPU（①）＋ Cloud Run（②）｜小型8B | スケール0で安い |
| マネージド寄せ | Vertex AI Endpoint（①）＋ Vertex Agent基盤（②） | 運用をGoogleに委譲・MLOps統合 |
| フルコントロール |
 GCE GPU VM |
特殊要件・検証 |
9. 判断チェックリスト
- モデルサイズは？（8B→L4 / 70B→A100×2）→ GPUとコストが決まる
- トラフィックは常時か散発か？ → GKE常時 vs Cloud Run従量
- 推論エンドポイントは内部限定にしたか？（基本Yes）
- ①②を別サービスに分離したか？（推論GPU・エージェントCPU）
- 重みはGCSにキャッシュしたか？（起動高速化）
- SAは役割別・最小権限か？ ツールの権限範囲は絞ったか？
- GPUオートスケールの上限を設定したか？（暴走課金防止）
- 観測（GPU/レイテンシ/トークン/コスト）を入れたか？
10. まとめ
GCPでHermesエージェントは十分実装可能。設計の核心は：
- 2層分離（推論GPU層 ＋ エージェントCPU層）
- サーブ基盤の選定（常時=GKE / 散発=Cloud Run+GPU / マネージド=Vertex）がコストと運用を決める
- 推論は内部非公開・SA最小権限でガバナンス
- 「マネージド vs 自前」「常時 vs 従量」の判断軸は、通常のGCPアーキ設計と同じ
モデルがオープンウェイトな分、「サーブ層をどう持つか」がアーキテクチャの主役。ここをコスト・トラフィック・ガバナンスで決めれば、残りは標準的なGCP構成に落ちる。