Foundation Models に関する新たなドキュメントが公開されたので読んだ。
Analyzing the runtime performance of your Foundation Models app | Apple Developer Documentation
Instruments によるパフォーマンス分析によって、Foundation Models を活用したアプリのレスポンシブさや、消費電力への影響について知る手がかりを得る手法の紹介。Instruments を用いて、どこに時間がかかり、トークンを消費しているかを正確に把握し、パフォーマンス改善のボトルネックを特定できる
- システムがいつモデルアセットを読み込んでいるか
- モデルからレスポンスを受け取り始めるまでどれだけの時間がかかっているか
- 個々のセッションにおけるトークンの使用状況
- アプリの提供するカスタムツールをどこで呼び出しているか
Instruments のスクリーンショット付きで、プロファイリングの操作方法が説明されている。
トークン使用について
- モデルはプロンプトの入力テキスト文を、トークンと呼ばれる小さなセグメントに分割する（それぞれが単語や、単語の一部）
- トークン数は、インストラクションやプロンプト、セッションインスタンスによるアウトプットを含む
- コンテクストウィンドウを超過した場合、
exceededContextWindowSize(_:)エラーが投げられる - アウトプットトークンが多いほど、生成時間がかかる
- タスク種別によっても生成時間が変動する
- 文書要約は新しい記事の生成よりも短く済む
- テキストに文字を含むことでより多くのトークンに分割される（e.g. 電話番号）
- トークン数に伴って、初期処理の時間や、メモリ使用量が増大する
- 1000トークンを超えると、古いデバイスでは顕著に生成速度が低下する
- Foundation Models instrument で トークン数を比較する
改善手法
- モデルローディングを事前ロードする
- モデル呼び出しの必要性がわかり次第
prewarm(promptPrefix:)を呼び出してモデルを事前ロードする（responseメソッドの呼び出し1秒前には） - ユーザーがリクエストしそうなことを prompt prefix で与えることで、類似のリクエストにモデルが備えられるようになり、最初のトークンまでの時間を短縮できる
- モデル呼び出しの必要性がわかり次第
- トークン消費を抑える
streamResponse(generating:includeSchemaInPrompt:options:prompt:)のincludeSchemaInPromptパラメタでGenerableの情報をリクエスト処理前にプロンプトに含めるかを指定可能- 含めることでアウトプット品質を高められるが、より多くのトークンが必要になる
- すでに同様のリクエストを行ったか、system instructions で例を提供している場合は、後続のリクエストで除外できる
- ネストされた
Generable型も多くのコンテクストを要するので、必要性を判断するべき
- 最適化を検証する
- 変更後は毎度アプリのプロファイリングを実施し、効果を検証する
- アセット読み込みがリクエスト生成の前に行われていること
- 最初のトークンがセッション開始直後に出現していること
- Inference detail エリアが少ないトークン数を示していること
- セッション全体やツールコーリングのレスポンス時間がユーザー体験を満たしていること
- 変更後は毎度アプリのプロファイリングを実施し、効果を検証する