この構成でできること
- Mac miniからのClaude Code操作
- Mac miniによるGateway/Queue/管理DB(メタデータ・履歴)/k3s Master/監視
- Node1での軽量LLM推論・RAG検索
- Node2でのOCR・物体検出・画像分類・画像バッチ処理
- Node3での映像フレーム抽出・フレーム選別・軽量物体検出
- k3sによる各ノードへのサービスデプロイ・ヘルスチェック
- 各ノードの温度・負荷・推論レイテンシ・ログの監視
- NASへのモデル/データセット保管・バックアップ
全体構成
各ノードの内部構成
Mac mini(クライアントPC + 管理ノード)
Node1: ROCK 5B+(軽量LLM / RAG)
Node2: Orange Pi 5 Plus(OCR / 画像前処理 = エッジ側の一次処理)
Node3: Jetson Orin Nano Super(映像取得 / フレーム選別 = エッジトリアージ)
Mac mini(クライアントPC + 管理ノード)の役割
- クライアントPC: Claude Codeの実行環境
- API Gateway: 認証・レート制限・ルーティングの一元化
- Queue / Job Manager: 各ノードへの非同期タスク分配
- 管理DB: メタデータ・処理履歴・ジョブ状態の保持
- k3s Master: 各ノードをクラスタ化し、Claude Codeが開発したサービスのデプロイ・再起動・ヘルスチェックを一元管理
- 監視/ログ集約: 各ノードの温度・負荷・推論レイテンシ・エラーログを一元収集
役割分担
- Mac mini: クライアントPC(Claude Code実行)+ 管理ノード(Gateway/Queue/管理DB/k3s Master/監視)
- Node1: 軽量LLM/RAG(低レイテンシが必要な軽量タスク)
- Node2/Node3: カメラ・スキャナ等の現場に近い位置で、フィルタリング・フレーム選別のみ行い、必要なデータだけMac miniに送信
Mac miniスペック(標準構成)
| 項目 | スペック |
|---|---|
| チップ | Apple M4(4P+6E、10コアCPU) |
| GPU | 10コアGPU |
| Neural Engine | 16コア |
| メモリ帯域幅 | 120GB/s |
| メモリ | 16GBユニファイドメモリ |
| ストレージ | 256GB SSD |
| ネットワーク | ギガビットEthernet(10Gb Ethernetに変更可能) |
| Wi-Fi/Bluetooth | Wi-Fi 6E / Bluetooth 5.3 |
| ポート | Thunderbolt 4 ×3、USB-C(USB3) ×2、HDMI |
| 最大消費電力 | 155W |
| OS(標準) | macOS |
| 筐体 | 5.0×12.7×12.7cm、0.67kg |
NAS: Synology DS220+
| 項目 | スペック | 影響 |
|---|---|---|
| ベイ数 | 2ベイ(3.5"/2.5") | 3.5TB運用ならRAID1(例: 4TB×2で実効約3.6TB)を推奨。単発ディスクだと故障時に全データ喪失リスク |
| CPU | Intel Celeron J4025(2C/2T) | 非力。NFS/Sambaのファイル共有用途に留め、重いコンテナ処理をNAS上で動かすのは避ける |
| RAM | 2GB(最大6GBまで換装可) | 同時アクセスが増える(5台からNFSマウント)なら6GBへの増設を推奨 |
| ネットワーク | 1GbE ×2(リンクアグリゲーション対応) | 2.5GbE非対応。スイッチがLAG対応なら理論値2Gbpsまで束ねられるが、実効はそれより下がる |
機器スペック一覧(エッジノード)
| 項目 | Node1 | Node2 | Node3 |
|---|---|---|---|
| 機種 | Radxa ROCK 5B+ | Orange Pi 5 Plus | Jetson Orin Nano Super |
| SoC/CPU | RK3588 (A76×4+A55×4) | RK3588 (A76×4+A55×4) | Cortex-A78AE ×6 |
| GPU | Mali-G610 MP4 | Mali-G610 MP4 | NVIDIA Ampere (CUDA 1024基/Tensor 32基) |
| NPU / AI性能 | 6 TOPS | 6 TOPS | 67 TOPS (INT8) |
| RAM | 最大32GB | 最大32GB | 8GB LPDDR5 (統合メモリ) |
| ストレージ | NVMe M.2 | M.2 NVMe | 通常NVMe/microSD |
| ネットワーク | 2.5GbE ×1 | 2.5GbE ×2 | 1GbE(標準構成) |
| CUDA/TensorRT | 非対応 | 非対応 | 対応 |
| 想定役割 | 軽量LLM/RAG(低レイテンシ用) | OCR/画像前処理(エッジ一次処理) | 映像取得/フレーム選別(エッジトリアージ) |
できること / できないこと
Mac mini(クライアントPC + 管理ノード)
- できる: Claude Codeの実行環境、Gateway/Queue/管理DB/k3s master/監視の同時運用
- できない/苦手: LLM推論(本構成では実施しない)
Node1(ROCK 5B+)
- できる: 3B〜7B級LLMのQ4量子化推論(CPU/NEON中心)、RAGのベクトル検索
- できない/苦手: 13B以上のLLMを実用速度で回すこと、高並列リクエストへの対応
Node2(Orange Pi 5 Plus)
- できる: OCR・軽量物体検出・画像分類の一次フィルタリング、OpenCVベースの前処理
- できない/苦手: 重い画像解析処理の最終判断(Mac miniに委譲する前提)
Node3(Jetson Orin Nano Super)
- できる: 動画フレーム抽出、軽量YOLOによる一次フィルタリング、必要なフレームだけMac miniへ転送
- できない/苦手: 大型VLMのフル精度推論(RAM8GB制約)
懸念事項
- Mac miniのクライアントPC用途と管理ノード用途の同居: Claude Code(開発作業)と、Gateway/Queue/管理DB/k3s Master/監視が同一機に同居する。開発作業中の負荷が管理系サービスの応答性に影響する可能性がある。
- Node1のNPUがLLM推論の主力にならない: RK3588のNPUは対応モデル・量子化形式が限定的(rkllm-toolkit経由)なため、実質CPU推論が中心。
- Node3のRAM制約: 8GBの統合メモリで映像デコード+フレームバッファを同時に走らせるとメモリ圧迫が起きやすい。フレーム選別のみに役割を絞ることで軽減。
- ネットワーク帯域差: Node3が1GbE想定のため、フレーム選別を経ずに生データを送ると帯域を圧迫する。エッジトリアージの徹底が重要。
- 発熱・スロットリング: RK3588系ボードは高負荷継続時にアクティブ冷却がないとクロック低下が起きやすい。