4つのチーム、4つのワークフロー

1. コードをプッシュ

   Windowsで開発し、確定したコミットをリポジトリにプッシュします。依存関係のロックファイルも一緒にコミットすれば、リモート環境で別の依存関係が解決されるのを防げます。

2. アーカイブを作成

   東京ノードでコードを取得し、必要な依存関係をインストールして、 flutter build ipaを実行します。署名証明書、プロビジョニングプロファイル、アクセス権はご自身で設定してください。

3. 配信用にアップロード

   バージョン番号とビルド番号を確認したら、 fastlane pilot でTestFlightにアップロードします。ipa、ログ、対応するコミットIDは、ご自身の成果物ストレージに保存してください。

前提：TestFlight配信に必要な有効な開発者資格、署名関連ファイル、App Store Connect API Keyはご自身でご用意ください。リモートノードを使っても、これらは不要になりません。

1. ランナーを登録

   シンガポールノードにGitHub Actions self-hosted runnerをインストールし、ラベルでmacOSジョブを割り当てます。実行を許可するリポジトリとブランチも制限してください。

2. 優先度を分ける

   main のマージ時にビルドと基本チェックを実行し、リリースブランチには専用ジョブを設定します。nightly には時間のかかるシミュレーターUIテストを割り当てます。

3. 作業ディレクトリを分ける

   ブランチやジョブごとに作業ディレクトリとDerivedDataを分けます。メモリ使用量のピーク、ディスク使用量の増加、待ち時間を記録し、並列数を増やすかノードを追加するか判断しましょう。

リージョンはチームの所在地だけでなく、リポジトリの取得、依存関係のダウンロード、成果物のアップロード経路を基準に比較しましょう。異なるリージョン間で連携する場合も、まずはご自身のプロジェクトで試してください。

1. 互換性を確認

   推論フレームワークがApple Siliconと必要な演算子に対応しているか確認します。モデルの重み、コンテキスト長、ランタイムのオーバーヘッドからメモリ使用量を見積もり、モデルファイルのサイズだけで判断しないでください。

2. 評価用の入力を固定

   利用許諾のあるモデルをダウンロードし、バージョン、量子化パラメーター、プロンプトセットを記録します。毎回同じ入力を使い、初回ロードとその後の推論にかかる時間を分けて計測しましょう。

3. 実験結果を保存

   スループット、メモリ使用量のピーク、品質評価の結果を出力し、ご自身のストレージに保存します。モデルが動作することを確認してから、環境を月単位で維持するか判断してください。

これは計算ワークフローの例であり、特定のモデルの速度や精度を保証するものではありません。試す際はメモリ使用量、初回ロード、連続推論を測定し、単発の結果だけで判断しないようにしましょう。

1. 転送とサンプル確認

   処理する権利のある素材をアップロードし、まず短いクリップでコーデック、カラー設定、書き出しパラメーターを検証します。アップロード時間もバッチ全体の納期に含めて見積もりましょう。

2. 書き出しキューを組む

   スクリプトやアプリのバッチ処理機能でタスクを整理します。並列数を少しずつ増やし、メモリとディスクの読み書きを確認して、複数の書き出しが互いに遅くならないようにしましょう。

3. 転送して整理

   音声と映像の同期、長さ、ファイルの完全性を確認し、完成データとジョブログを転送します。バックアップを確認したら中間ファイルを削除し、次のバッチ用に容量を確保してください。

標準搭載の2TB SSDで、素材、キャッシュ、書き出しファイルの最大使用量を見積もります。容量が足りないと確認できた場合に限り、+2TB SSDを追加してください。最初から追加する必要はありません。