Japan Azure User Group 14周年イベントに参加して、Azure App Service on Linux の Sidecar に Phi-3 を配置するアーキテクチャの話をしてきました。
App Service の Sidecar に SLM をセルフホストするアーキテクチャを中心に、Sidecar の使いどころの考察も含めて話しました。
まだ Preview なので、実運用には足りない機能や制約もありますが、これからのインテリジェントアプリケーション開発において注目したいアーキテクチャです。
X（Twitter）での反応は比較的好評で楽しんでいただけたようですし、数名の方から直接フィードバックをいただくこともできたので、話して良かったなと思いました。
フィードバックをいただいた内容のうち、２点ほど補足しておきます。
どのくらいの App Service Plan が必要になるのか？
Sidecar で SLM を動かすためには、相応の SKU の App Service Plan が必要です。デモしたアプリは Premium v3 P3V3（CPU 8、Memory 32GB）を選択していました。
とくに初回起動時は、Phi-3 イメージのプルと展開で負荷がかかるので、デフォルトの SKU の Premium v3 P0V3（CPU 1、Memory 4GB）ではアプリを起動できませんでした。
セッションでは AOAI と比較したコスト削減のメリットを挙げていましたが、App Service Plan にそれなりのコストがかかることは知っておいてください。
Sidecar がリソースを消費しすぎてメインアプリに影響を与えそう
Sidecar の SLM が多くのリソース（CPU と Memory）を消費してしまうことで、メインのアプリケーションに影響を与えてしまうリスクがあります。
Kubernetes には Pod 内のコンテナーに対して Resource limits を設定できるので、このような機能が App Service の Sidecar にも必要だと思います。
kubernetes.io
公式フォーラムにフィードバックしておきました。
https://feedback.azure.com/d365community/idea/83acbe10-6584-ef11-9442-6045bd8115dc
今回のイベントでは、JAZUG に初参加の方が多くいました。お仕事でも趣味でも Azure が好きな人たちが集まって楽しめるコミュニティになるように、15周年に向けて盛り上げていきたいです。
