開發工具與代理平台
Foundry Toolkit 1.6.13、ACR以外のプライベートイメージレジストリに対応し、Windows MLランタイムを変更
新版のVS Codeツールでは、接続設定済みのプライベートコンテナレジストリからマネージドエージェントをデプロイできるようになったほか、AMD NPU向けFara 7BとAionの量子化adapterも追加された。Windows MLは`windowsml` 2.3へ更新され、既存プロジェクトではexecution providersと依存パッケージの確認が必要となる。
Microsoftは9月16日、Foundry Toolkit for VS Code 1.6.13をリリースし、エージェントのデプロイ、オンデバイスモデル、ファインチューニング成果物に関する複数の経路を更新した。デプロイへの影響が最も大きい変更は、マネージドエージェントで、Azure Container Registry以外のプライベートレジストリに保存されたビルド済みイメージを選択できるようになったことだ。ただし、Foundryプロジェクトに対応するregistry connectionが作成済みであることが前提となる。Microsoftの外部レジストリ向けドキュメントでは、OIDCを使用して短期トークンを交換し、ユーザー名、パスワード、長期access tokenを設定内に残さない仕組みが説明されている。
これは、あらゆるプライベートイメージをそのまま実行できるという意味ではない。Foundryのマネージドエージェントでは、引き続き`linux/amd64`コンテナが必要だ。閉域ネットワーク、イメージをpullする権限、プロジェクトIDに対するRBACも個別に検証しなければならない。規制対象のチームにとって、この新しい経路の価値は、JFrog Artifactoryやセルフホスト型Docker Distributionなど既存のサプライチェーンを継続利用でき、エージェントプラットフォームのためだけにイメージをACRへ複製する必要がなくなる点にある。ただし、CIにはOIDC、イメージ署名、pull失敗に関するテストを追加する必要がある。
オンデバイス関連では、Fara 7BのVitisAI INT4版が追加され、Windows x64、AMD NPU、画像入力をサポートする。Aionのファインチューニングワークフローでは、従来の`adapter_model.safetensors`を維持しながら、`quantized_adapter.safetensors`もダウンロードできるようになった。後者では、パッケージに対応するテンプレートが含まれていることも必要なため、adapterファイルだけを移動してもワークフローを再構築できるとは限らない。
アップグレードテストが必要なのはWindows MLだ。ツールチェーンは`windowsml` 2.3と更新版のexecution providersへ移行し、Windows App SDKへの必須依存が削除された。更新履歴には、既存プロジェクトで調整が必要であり、完全に無停止で置き換えられるわけではないことが明記されている。1.6.13ではこのほか、応答完了後にAgent Inspectorが出力またはエラーを失う問題や、ツールの承認およびサインイン手順によってcontinuationが中断される問題も修正された。エンジニアリングチームは今後、拡張機能のバージョンを固定し、ローカルNPU、adapterのダウンロード、プライベートイメージのデプロイをそれぞれ回帰テストすべきだ。これらの新しい経路について、公式からエンドツーエンドの性能データや失敗率はまだ提示されていない。