まずマシンに接続し、プロジェクトやモデルを移行して、最後にサービスを拠点上で稼働させます。このページのコマンドは納品済みのMac miniを対象としています。パブリックIP、ユーザー名、認証情報はコンソールのインスタンス情報を確認してください。
注文済みですか？まずコンソールでインスタンスの納品を確認し、以下の順に作業してください。
XCODEOPS / RUNBOOK
初めて利用する場合は「接続」「移行」「MLX」の順に読むのがおすすめです。すでに環境があるチームは、ネットワークの拠点選びやトラブルシューティングに進んでください。
接続情報はコンソールのインスタンス詳細からのみ取得してください。初回の認証情報をリポジトリ、CIログ、チームチャットに記載しないでください。まず鍵認証で接続を確認してから、ログイン方法を制限します。
コンソールにログインし、納品済みのインスタンスを開いて、拠点、パブリックIP、SSHポート、ログインユーザー名を控えます。インスタンスの状態を確認してから接続してください。実際の利用可否はコンソールに表示される最新情報をご確認ください。
ローカルで専用鍵を生成し、公開鍵をコンソールの鍵登録画面またはインスタンスアカウントのauthorized_keysに追加します。アップロードするのは公開鍵のみです。秘密鍵はご自身のデバイスから移動しないでください。
2つ目のターミナルで鍵認証によるログインを確認してから、チームのポリシーに従ってSSHのパスワードログインを無効にします。変更前に現在の接続を維持し、設定の構文を確認して、インスタンスに接続できなくなる事態を防いでください。
鍵を生成したら、 .pub ファイルの内容をアップロードします。以下の設定例にはドキュメント用の予約済みアドレスを使用しています。実行前に、コンソールに表示される実際のIP、ポート、ユーザー名に置き換えてください。
ssh-keygen -t ed25519 -f ~/.ssh/xops_node
cat ~/.ssh/xops_node.pub~/.ssh/config
Host xops-node
HostName 192.0.2.10
User mac-user
Port 22
IdentityFile ~/.ssh/xops_node
IdentitiesOnly yes保存したら chmod 600 ~/.ssh/configを実行し、続けて ssh xops-nodeを実行します。初回接続時はホストフィンガープリントを確認してください。接続に問題がある場合は、IP、ポート、鍵の権限、インスタンスの状態を確認します。
XcodeのGUIを使う、またはビルド成果物を確認する場合は、まずインスタンスで画面共有が有効になっていることを確認し、リモートの 5900 番ポートをローカルに転送します。SSHセッションが切断されると、トンネルも閉じます。
ssh -N -L 5901:127.0.0.1:5900 xops-nodeターミナルは開いたままにします。ローカルMacの「画面共有」またはVNC対応クライアントから、 vnc://127.0.0.1:5901に接続します。GUIのログイン権限とSSHの権限は個別に確認してください。両方で同じ認証情報が使えるとは限りません。
rsync などのファイル同期手段を使ってください。まず再構築できるプロジェクトファイルを同期し、次にツールチェーンを復元して、最後にCIへ接続します。モデルの重み、署名関連データ、ビルドキャッシュはそれぞれ扱いが異なります。ローカルマシンのユーザーディレクトリ全体を選別せずにコピーしないでください。
まず rsync でプロジェクトとモデルの重みを差分同期します。最初にテスト転送を行い、転送先ディレクトリ、ファイル権限、利用可能なストレージを確認してください。外付けドライブのイメージは、形式と容量を事前に確認したうえでのオフライン移行に限り適しています。
rsync -avh --progress ./project/ \
xops-node:~/work/project/大容量の重みは分割して転送し、完了後にファイルサイズとチェックサムを比較します。秘密鍵や一時トークンをプロジェクトディレクトリに含めないでください。
ローカルでHomebrew Bundleを使って Brewfileを書き出し、ノード上でインポートします。続けてXcodeのバージョン、コマンドラインツール、依存関係のロックファイルを確認してください。署名証明書は個別に転送し、インポート後はキーチェーンへのアクセスを制限します。
brew bundle dump --file=./Brewfile
rsync -av ./Brewfile xops-node:~/work/
ssh xops-node 'brew bundle --file=~/work/Brewfile'ローカルのPython仮想環境をそのままコピーしないでください。依存パッケージは移行先マシンに再インストールします。
既存のCIプロジェクトにセルフホストランナーを登録し、指定のリポジトリまたはチームに紐付けます。ビルドキャッシュは専用ディレクトリに保存し、メモリとビルド負荷に応じて同時実行数を設定してください。
これらは移行作業の所要時間の目安であり、インスタンスの納品時間ではありません。初回同期の前に空きディスク容量を確認してください。容量を追加する場合は、機種とオプションで選択可能な構成を確認できます。
Apple SiliconのユニファイドメモリはCPUとGPUで共有されます。モデルを配置できるかどうかは、量子化形式、コンテキスト長、他のプロセスの使用量にも左右されます。機種を選ぶ際はシステムとサービス用の余裕を確保し、公称メモリをすべてモデルの重みに割り当てないでください。
インスタンス上にサービス専用のPython環境を作成します。以下のモデルパスは、そのインスタンスに同期済みのローカルディレクトリを指定しています。起動後、まずインスタンス内からOpenAI互換APIを確認してください。
python3 -m venv ~/mlx-service/.venv
~/mlx-service/.venv/bin/python -m pip install mlx-lm
~/mlx-service/.venv/bin/python -m mlx_lm.server \
--model ~/models/quantized-model \
--host 127.0.0.1 --port 8080curl http://127.0.0.1:8080/v1/modelsモデルファイルが揃っていること、Python環境が使えること、ポートを他のプロセスが使用していないことを確認してください。 mlx-lm の引数はバージョンによって異なる場合があります。本番環境にデプロイする前に、インスタンスにインストールされたバージョンのコマンドヘルプを確認してください。
既定では 127.0.0.1のみをリッスンします。少人数での内部利用なら、各メンバーがSSHトンネルを作成できます。共通の入口が必要な場合は、認証、アクセス制御、TLSを備えたリバースプロキシを使い、保護されていない推論エンドポイントをインターネットに直接公開しないでください。
ssh -N -L 8080:127.0.0.1:8080 xops-nodeフォアグラウンドで安定して動作することを確認したら、サービス用のユーザー単位の launchd 設定を作成し、仮想環境内のPython、モデルパス、作業ディレクトリ、ログファイルを指定します。設定を確認してから現在のユーザーセッションに読み込み、インスタンスの再起動後にプロセスとエンドポイントを再確認してください。
plutil -lint ~/Library/LaunchAgents/com.xcodeops.mlx.plist
launchctl bootstrap gui/$(id -u) \
~/Library/LaunchAgents/com.xcodeops.mlx.plistメモリの目安：16GBは小型の量子化モデルの検証に適しています。24GBなら一般的な7B～8B量子化モデルを単一サービスで動作確認できます。64GBあれば、さらに大きなモデルや複数タスクに余裕を持たせられます。実際のスループットはモデル、コンテキスト、負荷によって異なるため、ご自身のリクエストデータで測定してください。
専有物理マシンは、Xcodeのコンパイル、シミュレータテスト、セルフホストランナーに適しています。同じマシンのCPU、GPU、ユニファイドメモリを他のテナントのタスクに使われることはありません。ただし、シミュレータでのテストに成功しても、実機のカメラ、Bluetooth、パフォーマンステストが成功するとは限りません。
Xcodeとシミュレータランタイムのバージョンを固定し、主要なデバイスサイズとOSバージョンを対象にテストマトリクスを作成します。まず xcrun simctl list devices available を実行して利用可能なデバイスを確認し、未インストールのランタイムをパイプラインで参照しないようにします。
まずランナーで再現性のあるテストとアーカイブを実行してから、チーム既定の署名手順でTestFlight用ビルドをアップロードします。証明書、プロビジョニングプロファイル、アップロード認証情報はアクセスを制御したストレージに保管し、リポジトリや永続化されるビルドログに書き込まないでください。
確認項目：署名 / アーカイブ / アップロード結果センサー、実際のネットワーク切り替え、消費電力、周辺機器との連携を含むテストケースは、チームが管理する実機での検証が必要です。クラウドノードでビルドと配布を行い、最後の回帰テストや問題の再現はローカルの実機で実施できます。
確認項目：デバイスログ / 再現手順シンガポール、東京、ソウル、香港の拠点を利用できます。チームメンバーの所在地、通信事業者の経路、夕方の混雑状況によって、実際の使い心地は変わります。推論APIではリクエストの往復時間とモデルの生成時間も測定し、pingだけで判断しないでください。
以下は指定条件に基づいてまとめた参考データで、単位はミリ秒です。どのユーザーの回線についてもリアルタイムの性能を保証するものではありません。ご自身のネットワーク環境で繰り返し測定してから拠点を選んでください。
| 測定元 | シンガポール | 東京 | ソウル | 香港 |
|---|---|---|---|---|
| 上海 | 76 ms | 58 ms | 53 ms | 41 ms |
| 深圳 | 62 ms | 72 ms | 65 ms | 29 ms |
| 台北 | 64 ms | 46 ms | 54 ms | 39 ms |
| バンコク | 43 ms | 109 ms | 98 ms | 66 ms |
| ジャカルタ | 38 ms | 109 ms | 115 ms | 74 ms |
| シドニー | 101 ms | 132 ms | 146 ms | 141 ms |
| 大阪 | 75 ms | 32 ms | 47 ms | 65 ms |
| 釜山 | 85 ms | 44 ms | 24 ms | 71 ms |
測定条件：ICMP往復時間の平均値、各経路で連続100回、平日夜間、家庭用ブロードバンド接続。初期の拠点選びにのみご利用ください。通信事業者や経路によって数値は変わるため、実際のインスタンスを職場のネットワークから測定する代わりにはなりません。
まず実際のインスタンスに連続してpingを送り、パケットロスとジッターも確認します。チームが複数の地域に分散している場合は、地理的に最も近い都市ではなく、リモートデスクトップを最も頻繁に操作する人や推論APIを呼び出す人を基準にしてください。
モデルの重み、メディア素材、ビルドキャッシュは差分同期に適しています。大容量データの転送は利用の少ない時間帯に行い、失敗した場合は途中から再開してください。VNCの操作が重い場合は、バックグラウンド同期が上り回線を占有していないか確認します。
Thunderbolt 5による複数台連携は、実際にマルチマシンでの処理が必要で、アプリケーションのワークフローも複数の物理マシンを活用できる場合に適しています。単一マシンのユニファイドメモリが自動的に統合され、モデルが使えるメモリプールになるわけではありません。構成を決める前にソフトウェアのアーキテクチャを確認してください。
インスタンスや注文に関する問題は、コンソールからチケットを送信してください。送信前にローカルネットワーク、インスタンスの状態、接続方法、障害の発生時刻を確認します。スクリーンショットやログに秘密鍵、完全なトークン、マスキングされていない機密情報を含めないでください。
コンソールにログインし、該当する注文またはインスタンスから、トラブルシューティングの情報を添えてチケットを送信してください。注文前の機種選びに関するご質問は、 support@xcodeops.comまでメールでお問い合わせください。インスタンスに関する問題は、注文と拠点を関連付けられるよう、チケットからのご連絡を優先してください。
専有物理Mac miniは3プラン。日・週・月・四半期単位で利用できます。まず機種を選び、実際のネットワーク測定結果をもとに拠点を決定してください。納品後の接続手順は、このページから始められます。