自社アプリにLLMを組み込むとき、推論基盤を自前で組むか、APIだけ借りるかで悩む場面は多いです。2026年6月23日、Modalの創業者エリック・バーナードソン氏が、管理型のプライベートLLMエンドポイントが全ユーザー向けに利用可能になったと発表しました。UIから数クリック、CLIから数コマンドで本番向けエンドポイントを立ち上げられ、下層のコードもダッシュボードから確認できる点が特徴です。

この記事でわかること

  • Modal Auto Endpoints(管理型LLMエンドポイント)の概要と公開範囲
  • CLI・ダッシュボードでのデプロイ手順
  • コード公開やメトリクスなど、従来のマネージド推論との違い
  • 料金体系と運用時の注意点

Modal Auto Endpointsとは

Modal Auto Endpointsは、Modalのマネージドインフラ上にLLM推論エンドポイントをデプロイする機能です。公式ブログでは「Optimized inference you actually own(実際に所有できる最適化推論)」と位置づけられています。

従来、推論基盤を自前で持つにはvLLMやSGLangなどの推論エンジン選定、GPU選定、オートスケール、ルーティング、メトリクス収集まで一式を担う必要がありました。一方、マネージド推論APIは手軽ですが、裏側のサーブスタックが見えない「ブラックボックス」になりがちです。Modalはこの中間を狙い、OpenAI互換の本番向けAPIを提供しつつ、裏側のModal Appとソースコードへアクセスできる設計にしています。

全ユーザー向けに何が変わったか

バーナードソン氏の投稿(2026年6月23日)では、「Managed private LLM endpoints, now available for everyone in @modal」と述べられています。これまで一部の顧客向けに提供されていた機能が、セールス窓口を通さず誰でも使える形に広がった点が大きな変化です。

公式ブログでも「talk to salesボタンの裏に隠れない」と明記されており、GLM 5.2のようなフロンティア級オープンモデルもCLIコマンドかダッシュボード操作だけでデプロイできます。Cognition、Decagon、Fathom、DoorDashなどのチームが既に利用してきた基盤が、一般ユーザーにも開かれた形です。

デプロイ手順

CLIからの作成

プロキシトークンを用意したうえで、次の1コマンドでエンドポイントを作成します。

modal endpoint create --model Qwen/Qwen3.5-4B

--nameを省略すると、モデル名から自動でエンドポイント名が付きます(Qwen/Qwen3.5-4Bqwen3-5-4b)。名前を付ける例は次のとおりです。

modal endpoint create --name agent --model zai-org/GLM-5.2-FP8

コマンド実行後、エンドポイントIDとダッシュボードへのリンクが表示され、プロビジョニングの進捗を追えます。

ダッシュボードからの作成

ダッシュボードのEndpointsタブからも同じ設定項目をフォームで指定できます。CLIと同等のオプションが揃っており、UI操作だけで立ち上げ可能です。

エンドポイントの呼び出し

エンドポイントが稼働すると、OpenAI Chat Completions API互換の/v1エンドポイントが公開されます。デフォルトでは認証付きで、リクエストごとにModal-KeyModal-Secretヘッダーが必要です。テスト用途ではmodal curlユーティリティも使えます。

modal workspace proxy-tokens create

認証なしで公開する場合は--unauthenticatedフラグを付けます。本番運用では認証付きを推奨します。

コードとメトリクスが見える理由

バーナードソン氏が「these are not black boxes」と強調した点は、ダッシュボードの「Source」パネルから下層コードを確認できることに表れています。GPU選定、リージョン設定、推論エンジンのフラグ、エンジンパッチまで共有されるため、負荷に合わせたチューニングが可能です。

メトリクス面では、サーバーメトリクス(GPU温度・利用率など)に加え、推論エンジン由来のTTFT(初回トークンまでの時間)、ITL(トークン間レイテンシ)、キュー長、投機的デコードのacceptance lengthなどがダッシュボードやOTELエクスポートで取得できます。公式ブログでは、負荷急増時にレプリカが自動追加され、レイテンシが回復する様子をダッシュボードで追える例が示されています。

対応モデルとカスタムウェイト

カタログにはQwen、Kimi、Gemma4、DeepSeek、Nemotron、GPT-OSS、GLMなどのファミリーが含まれます。Hugging FaceのリポジトリやModal Volume上のファインチューン済みウェイトも、ベースモデルを指定したうえで--custom-hf-*--custom-volume-*フラグで差し替えられます。

推論エンジンはSGLangなどのオープンソース実装が使われ、DFlashブロック拡散ドラフターによる投機的デコードがレシピ対応モデルで有効化されます。公式ブログでは、互換モデルごとにベンチマーク結果がデプロイ前に表示されると説明されています。

インフラ面の特徴

Modal Serversという新コンポーネントにより、HTTPリクエストのオーバーヘッドは約5msとされています。キューイングを排し、リージョン単位で配置される設計です。コンテナは1秒未満で起動し、需要に応じて数千GPUまでスケールします。アイドル時はゼロにスケールダウンするため、使っていない間のコンピュート課金は発生しません。

リージョンは--routing-regionus-westがデフォルト、us-easteu-westap-south)で指定し、--colocate-computeでプロキシとコンテナを同一リージョンに固定できます。後者はレイテンシ低減に有効ですが、リージョン選択の料金乗数がかかります。

料金とセキュリティ

エンドポイントは稼働中のGPU・CPUに対してModalの標準コンピュート料金が課金されます。Starterプランでは月30ドル分の無料クレジットが付与され、従量課金で使い分けられます。SOC2・HIPAA準拠、ゼロデータ保持などのエンタープライズ向けセキュリティ機能も公式に掲げられています。

既存のマネージド推論APIとの違い

OpenAIやAnthropicのAPIは手軽ですが、サーブスタックの中身は見えません。自前のvLLMデプロイは自由度が高い一方、インフラ運用の負荷が大きいです。Modal Auto Endpointsは、OpenAI互換APIの手軽さと、ソースコード・エンジンメトリクスへのフルアクセスを両立する中間層として設計されています。「APIを借りる」でも「全部自前」でもない、推論基盤の所有権を重視するチーム向けの選択肢です。

運用時の注意点

エンドポイント停止はmodal endpoint stop <name>で行い、コンテナ破棄と課金停止が連動します。一覧確認はmodal endpoint listです。認証用プロキシトークンのシークレットは作成時のみ表示され、後から再取得できないため、安全な場所に保管してください。用途ごとに最適な推論設定は異なるため、公式が提示する初期レシピを起点に、本番トレースを見ながらチューニングする流れが想定されています。

自社プロダクトにLLMを組み込みつつ推論スタックの透明性を保ちたい開発チームにとって、Modal Auto Endpointsの全ユーザー公開は実運用の選択肢を広げる動きです。まずは小さなモデルでエンドポイントを立ち上げ、ダッシュボードのSourceパネルとメトリクスを確認するのが着手しやすい第一歩になります。