MAI-Thinking-1は、Microsoftが開発した推論モデルで、Microsoft Foundryからパブリックプレビューとして利用できます。35Bアクティブ、総パラメーター約1Tの疎なMixture of Experts（MoE）構成を採用し、256Kトークンのコンテキスト、関数呼び出し、開発者指示、Chat Completions API互換の呼び出し方式に対応しています。(Microsoft AI)
ただし、パブリックプレビューは無料体験を意味するものではありません。利用には有効な支払い方法を登録したAzureサブスクリプション、Microsoft Foundryプロジェクト、デプロイ権限が必要です。また、現時点ではGlobal Standardデプロイのみで、PTUには対応していません。プレビュー機能にはSLAがなく、Microsoftも運用環境での利用を推奨していないため、まずは検証環境で試すのが適切です。(Microsoft Learn)
MAI-Thinking-1とは
MAI-Thinking-1は、数学、コーディング、分析、計画立案など、複数の段階を経て答えを導くタスクを主な対象とするテキスト生成モデルです。
単純な文章生成だけでなく、コードを読み、修正案を考え、テスト結果を踏まえて再検討するといったエージェント型の処理も想定されています。Microsoftは、複雑な推論、ソフトウェア開発、財務モデリング、統計分析、予測などを代表的な用途として挙げています。(Azure AI)
主な仕様は次のとおりです。
| 項目 | 内容 |
|---|---|
| モデル名 | MAI-Thinking-1 |
| 提供元 | Microsoft |
| モデル種別 | 推論モデル、Chat Completion |
| アーキテクチャ | 疎なMixture of Experts |
| アクティブパラメーター | 35B |
| 総パラメーター | 約1T |
| モデルバージョン | 2026-06-01 |
| 入力 | テキスト |
| 出力 | テキスト |
| コンテキスト上限 | 入力と出力を合わせて256Kトークン |
| 最大出力 | 64Kトークン、または残りのコンテキスト容量 |
| 関数呼び出し | 対応 |
| ストリーミング | 対応 |
| API | Chat Completions API互換 |
| デプロイ方式 | Global Standard |
| 提供段階 | パブリックプレビュー |
仕様はMicrosoft Foundryのモデルカタログおよび公式ドキュメントに基づきます。(Azure AI)
35Bアクティブ・約1T総パラメーターの意味
MAI-Thinking-1には、全体として約1兆のパラメーターがあります。一方、推論時に主に利用されるアクティブパラメーターは35B、つまり約350億です。
MoEでは、入力に応じてモデル内部の一部のエキスパートだけを選択して処理します。そのため、全パラメーターを毎回使う密なモデルと比べて、総規模を大きくしながら推論時の計算量を抑えやすい構成です。
ただし、「35Bアクティブだから必ず高速」「1Tだから必ず高精度」とは限りません。実際の応答速度や費用対効果は、プロンプトの複雑さ、生成トークン数、混雑状況、クォータなども含めて評価する必要があります。(Microsoft AI)
モデルバージョンと公開日は異なる
MAI-Thinking-1のパブリックプレビューは2026年8月12日に発表されていますが、Microsoft Foundryで指定するモデルバージョンは2026-06-01です。
Azure CLIでデプロイするときに、発表日の2026-08-12をモデルバージョンとして入力しないよう注意してください。(Microsoft AI)
Microsoft Foundryで利用するための条件
MAI-Thinking-1をMicrosoft Foundryで利用するには、次の条件を満たす必要があります。
| 条件 | 確認する内容 |
|---|---|
| Azureサブスクリプション | 有効な支払い方法が登録されていること |
| Microsoft Foundryへのアクセス | Foundryポータルを利用できること |
| Foundryプロジェクト | MAI-Thinking-1対応リージョンに作成されていること |
| デプロイ権限 | モデルのデプロイを作成・管理できるRBACロールがあること |
| 認証方法 | Microsoft Entra IDまたはAPIキー |
| デプロイ方式 | Global Standard |
| クォータ | 実際にAPIを呼び出せるTPM・RPMが割り当てられていること |
| プレビュー条件 | SLAがないことを了承し、検証用途を基本とすること |
デプロイ権限には、Cognitive Services Contributor、日本語表示では「Cognitive Services 共同作成者」ロールを利用できます。認証方法はAPIキーにも対応していますが、MicrosoftはMicrosoft Entra IDを推奨しています。(Microsoft Learn)
日本東部と日本西部からデプロイできる
Global Standardの対応リージョン一覧には、japaneastとjapanwestの両方が掲載されています。そのため、日本東部または日本西部にある対応リソースからMAI-Thinking-1をデプロイできます。リージョン対応は変更される可能性があるため、作業前にFoundryのモデルカタログで再確認してください。(Microsoft Learn)
ただし、Global Standardでは、プロンプトと応答がデプロイ先と同じリージョンだけで処理されるとは限りません。Microsoftの説明では、Globalデプロイの推論データは、モデルが配置されている任意のAzureリージョンで処理される可能性があります。
「リソースを日本東部に作成すれば、推論処理も必ず日本国内に限定される」とは考えないでください。厳格なデータ所在地要件がある場合は、Global Standardが社内規定や契約条件を満たすか、導入前に確認が必要です。(Microsoft Learn)
PTUは利用できない
MAI-Thinking-1では、予約容量を使うProvisioned Throughput Unit、いわゆるPTUデプロイは現在サポートされていません。利用できるのはGlobal Standardです。(Microsoft Learn)
そのため、次のような要件があるシステムでは慎重な判断が必要です。
- 専用の予約スループットを確保したい
- 月間性能を一定に保ちたい
- 大量アクセス時も予測可能な処理能力が必要
- 地域を限定して推論処理を行いたい
- SLAが必要な本番システムに組み込みたい
これらが必須の場合は、MAI-Thinking-1の一般提供や対応デプロイ方式の拡大を待つか、要件を満たす別モデルと比較する必要があります。
パブリックプレビューにはSLAがない
MAI-Thinking-1はパブリックプレビューです。公式ドキュメントでは、プレビューにSLAはなく、運用環境には推奨されないと明記されています。一部機能が未対応だったり、仕様変更が行われたりする可能性もあります。(Microsoft Learn)
用途ごとの判断目安は次のとおりです。
| 利用シーン | 判断 |
|---|---|
| 社内検証、技術評価 | 適している |
| 既存モデルとの精度比較 | 適している |
| 少人数の限定パイロット | 人による確認と障害時の代替手段があれば検討可能 |
| SLA必須の業務システム | 現時点では不向き |
| 医療・法務・採用などの自動判断 | 単独の判断基盤として使わない |
| 日本国内処理が必須の機密データ | Global Standardの処理条件を踏まえ慎重に判断 |
| 画像・音声を扱う処理 | 対象外 |
MAI-Thinking-1は、高い影響を伴う法務、金融、医療、雇用、教育、住宅、信用、安全関連の意思決定を単独で行うモデルとして設計・評価されていません。また、入力と出力はテキストのみで、画像、音声、動画には対応していません。(Azure AI)
MAI-Thinking-1の料金
パブリックプレビューであっても、Microsoft FoundryでのAPI利用には料金が発生します。
2026年9月確認時点のGlobalデプロイの参考価格は次のとおりです。
| 種別 | 100万トークンあたりの参考価格 |
|---|---|
| 入力 | 2米ドル |
| キャッシュ済み入力 | 0.20米ドル |
| 出力 | 8米ドル |
価格は変更される可能性があり、実際の請求額は契約、通貨、地域、税、Azureの料金設定によって異なります。デプロイ画面とAzureの最新料金表で確認してください。(マイクロソフト アジュール)
たとえば、1回の処理で入力が50,000トークン、出力が5,000トークンだった場合、単純計算では次のようになります。
入力料金：50,000 ÷ 1,000,000 × 2ドル = 0.10ドル
出力料金： 5,000 ÷ 1,000,000 × 8ドル = 0.04ドル
合計：約0.14ドル実際には、会話履歴、ツール定義、開発者指示、暗号化された推論状態などもコンテキストに含まれます。画面に表示された質問文と回答文だけで費用を見積もらないことが重要です。
クォータを確認してからデプロイする
MAI-Thinking-1のAPI制限は、1分あたりのトークン数を表すTPMと、1分あたりのリクエスト数を表すRPMで管理されます。
公式ドキュメントには、次の階層が掲載されています。
| デプロイ | Tier | TPM | RPM |
|---|---|---|---|
| Global Standard | Low・既定値 | 0 | 0 |
| Global Standard | Medium | 100,000 | 100 |
| Global Standard | High | 250,000 | 250 |
利用できる階層は、Azureサブスクリプションとデプロイ構成によって異なります。特に、既定のLowが0 TPM・0 RPMとされている点に注意してください。モデルをデプロイできても、利用可能なクォータがなければAPIを呼び出せません。(Microsoft Learn)
デプロイ後に429エラーが出る場合は、プログラムを修正する前に次を確認します。
- MAI-Thinking-1用のTPMとRPMが割り当てられているか
- 同じサブスクリプションの別デプロイがクォータを消費していないか
- 長い入力を短時間に連続送信していないか
- 指数バックオフを実装しているか
- クォータ引き上げを申請できる状態か
Microsoft FoundryでMAI-Thinking-1を試す手順
Foundryポータルからデプロイする
最初の検証では、Microsoft Foundryのモデルカタログからデプロイする方法が分かりやすいでしょう。
- Microsoft Foundryにサインインします。
- 検証用のFoundryリソースとプロジェクトを作成するか、既存プロジェクトを選択します。
- モデルカタログを開きます。
MAI-Thinking-1を検索します。- Microsoft提供のモデルカードを開きます。
- デプロイの作成を選択します。
- モデルバージョンが
2026-06-01であることを確認します。 - デプロイ方式に
GlobalStandardを選択します。 - 分かりやすいデプロイ名を指定します。
- 料金、クォータ、利用条件を確認してデプロイします。
- Playgroundで簡単なプロンプトを送信します。
- API利用に必要なエンドポイントとデプロイ名を控えます。
ポータルの表示名やボタン配置は更新によって変わる可能性がありますが、モデルカタログでMAI-Thinking-1を選び、Global Standardとしてデプロイする流れは同じです。(Microsoft Learn)
Azure CLIでデプロイする
自動化する場合は、Azure CLIからデプロイできます。
az cognitiveservices account deployment create \
--name <ACCOUNT_NAME> \
--resource-group <RESOURCE_GROUP> \
--deployment-name <DEPLOYMENT_NAME> \
--model-name "mai-thinking-1" \
--model-format Microsoft \
--model-version 2026-06-01 \
--sku-name GlobalStandard \
--sku-capacity 1<ACCOUNT_NAME>、<RESOURCE_GROUP>、<DEPLOYMENT_NAME>は自分の環境に置き換えます。モデル名の表記とデプロイ名は別物です。APIのmodelには、MAI-Thinking-1ではなく、ここで指定したデプロイ名を渡します。(Microsoft Learn)
作成済みのデプロイは、次のコマンドで確認できます。
az cognitiveservices account deployment list \
--resource-group <RESOURCE_GROUP> \
--name <ACCOUNT_NAME> \
-o tableChat Completions APIから呼び出す方法
MAI-Thinking-1のAPIエンドポイントは次の形式です。
https://<resource-name>.services.ai.azure.com/mai/v1/chat/completionsOpenAI SDKを利用する場合は、ベースURLを次のように設定します。
https://<resource-name>.services.ai.azure.com/mai/v1通常のAzure OpenAIで使われるURLをそのまま流用すると、404エラーになる可能性があります。MAI用の/mai/v1が含まれているか確認してください。(Microsoft Learn)
PythonからMicrosoft Entra IDで呼び出す
必要なパッケージをインストールします。
pip install openai azure-identityPowerShellでは、環境変数を次のように設定します。
$env:AZURE_ENDPOINT="https://<resource-name>.services.ai.azure.com"
$env:DEPLOYMENT_NAME="<your-deployment-name>"Pythonコードは次のようになります。
import os
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
from openai import OpenAI
token_provider = get_bearer_token_provider(
DefaultAzureCredential(),
"https://cognitiveservices.azure.com/.default",
)
client = OpenAI(
base_url=f"{os.environ['AZURE_ENDPOINT']}/mai/v1",
api_key=token_provider,
)
response = client.chat.completions.create(
model=os.environ["DEPLOYMENT_NAME"],
messages=[
{
"role": "user",
"content": (
"社内システムをクラウドへ移行する計画を、"
"準備・移行・安定化の3段階に分けて作成してください。"
),
}
],
max_completion_tokens=8192,
)
print(response.choices[0].message.content)modelに指定する値はモデル名ではなく、Microsoft Foundryで作成したデプロイ名です。Microsoft Entra IDを利用する場合は、実行ユーザーまたはマネージドIDに、推論を実行するための適切なRBAC権限も必要です。(Microsoft Learn)
APIキーを使う場合
APIキーを利用する場合、OpenAI SDKのapi_keyにAzureのキーを直接渡すのではなく、公式例ではapi-keyヘッダーとして指定します。
import os
from openai import OpenAI
client = OpenAI(
base_url=f"{os.environ['AZURE_ENDPOINT']}/mai/v1",
api_key="unused",
default_headers={
"api-key": os.environ["AZURE_API_KEY"],
},
)APIキーはソースコードに直接書き込まず、環境変数やAzure Key Vaultなどで管理してください。長期運用では、キーの漏えいリスクを減らせるMicrosoft Entra ID認証が適しています。(Microsoft Learn)
Chat Completions互換でも完全な置き換えではない
MAI-Thinking-1は、OpenAI SDK形式のChat Completions APIに対応しています。そのため、既存のChat Completions利用コードを比較的移行しやすい構成です。(Microsoft AI)
ただし、「Chat Completions互換」は、すべてのOpenAI APIパラメーターがそのまま使えるという意味ではありません。
公式ドキュメントで示されている主な要求パラメーターは次のとおりです。
| パラメーター | 用途 |
|---|---|
model | Microsoft Foundryで作成したデプロイ名 |
messages | 会話メッセージ |
max_completion_tokens | 推論トークンを含む最大生成トークン数 |
tools | 呼び出し可能な関数の定義 |
stream | ストリーミングの有効化 |
reasoning_display | 暗号化された推論状態の取得 |
特に、max_tokensではなくmax_completion_tokensを使用します。公式のトラブルシューティングでも、max_tokensのような未対応パラメーターを送ると400エラーになる例が示されています。(Microsoft Learn)
既存アプリから移行するときは、次のようなパラメーターを無条件にコピーしないでください。
max_tokens
temperature
top_p
response_format
旧Azure OpenAI固有のURL形式使用したいパラメーターがMAI-Thinking-1の現行API仕様に含まれているか、一つずつ確認する必要があります。
256Kコンテキストを利用するときの注意点
MAI-Thinking-1の256Kコンテキストは、入力だけに使える容量ではありません。入力メッセージと生成される出力を合わせた、1リクエストあたりの総トークン予算です。(Microsoft Learn)
最大出力は、次のうち小さい方になります。
- 64,000トークン
- 入力後に256Kコンテキスト内へ残っているトークン数
たとえば、入力が220Kトークンある場合、出力に利用できる理論上の残りは約36Kトークンです。そこでmax_completion_tokensを64Kに設定すると、合計が256Kを超えてリクエストが失敗する可能性があります。
また、max_completion_tokensには、利用者に表示される回答だけでなく、モデルが内部で使用する推論トークンも含まれます。値を小さくしすぎると、複雑な問題で推論や最終回答が途中終了する可能性があります。(Microsoft Learn)
長文をすべて入れればよいとは限らない
256Kまで入力できても、毎回大量の文書を送る運用が最適とは限りません。
実務では、次のように使い分けると費用と精度を管理しやすくなります。
- 契約書1冊や大規模な設計書を横断的に確認する場合は長いコンテキストを使う
- 社内文書検索では、検索結果だけを渡すRAGを併用する
- 会話履歴が長くなったら、古いターンを要約する
- ツール定義は必要なものだけ送る
- 同じ長い接頭辞を繰り返す場合はキャッシュ利用状況を確認する
- 実際の業務文書で、参照漏れや誤引用を評価する
コンテキスト上限は「常に使い切る目標」ではなく、「必要なときに使える最大容量」と考えるのが適切です。
関数呼び出しを利用する方法
MAI-Thinking-1は関数呼び出しに対応しています。ただし、サポートされるツール種別は関数ツールです。(Microsoft Learn)
たとえば、業務システムの情報を取得する関数を次のように定義できます。
{
"model": "<deployment-name>",
"messages": [
{
"role": "user",
"content": "申請番号A-1024の現在の処理状況を確認してください"
}
],
"tools": [
{
"type": "function",
"function": {
"name": "get_application_status",
"description": "申請番号から現在の処理状況を取得する",
"parameters": {
"type": "object",
"properties": {
"application_id": {
"type": "string"
}
},
"required": [
"application_id"
]
}
}
}
]
}モデルは関数そのものを実行しません。返されたtool_callsをアプリケーションが読み取り、引数を検証してから外部システムを呼び出します。その実行結果を会話へ追加し、再びモデルを呼び出す必要があります。モデルにどの権限を与えるか、引数をどこまで信用するかは、連携アプリケーション側の責任です。(Azure AI)
finish_reasonだけでツール呼び出しを判定しない
MAI-Thinking-1では、ツール呼び出しを含む応答でもfinish_reasonがstopになる場合があります。
そのため、次のような判定は避けてください。
if choice.finish_reason == "tool_calls":
execute_tool()代わりに、アシスタントメッセージのtool_callsが存在するかを確認します。
message = response.choices[0].message
if message.tool_calls:
for tool_call in message.tool_calls:
print(tool_call.function.name)
print(tool_call.function.arguments)Microsoftのドキュメントでも、finish_reasonではなくchoices[].message.tool_callsを確認するよう案内されています。(Microsoft Learn)
暗号化された推論状態をターン間で引き継げる
MAI-Thinking-1では、reasoning_displayをencryptedに設定すると、暗号化された推論状態を取得できます。
response = client.chat.completions.create(
model=os.environ["DEPLOYMENT_NAME"],
messages=[
{
"role": "user",
"content": "基幹システム移行計画を3段階で作成してください",
}
],
max_completion_tokens=8192,
extra_body={
"reasoning_display": "encrypted",
},
)返されるreasoning.encrypted_contentは、モデルの生の思考内容を表示するものではありません。アプリケーションから見れば不透明な暗号化データであり、次のターンにそのまま返すことで、過去の推論状態を引き継ぐために使用します。(Microsoft Learn)
取り扱いでは次の点を守ります。
- 受け取った値を変更しない
- デコードや解析を試みない
- 利用者向け画面に表示しない
- デバッグログへ不用意に出力しない
- フィールドを手作業で再構築しない
- 完全なアシスタントメッセージとして保持する
暗号化された推論状態を次のリクエストへ含めると、その分もコンテキスト上限にカウントされます。長いエージェント処理では、会話履歴と合わせてトークン使用量を監視してください。(Microsoft Learn)
ストリーミング応答にも対応する
streamをtrueにすると、Server-Sent Events形式で応答を順次受け取れます。
stream = client.chat.completions.create(
model=os.environ["DEPLOYMENT_NAME"],
messages=[
{
"role": "user",
"content": "この移行計画のリスクを分析してください",
}
],
max_completion_tokens=8192,
stream=True,
)
for chunk in stream:
if not chunk.choices:
continue
delta = chunk.choices[0].delta
if delta.content:
print(delta.content, end="", flush=True)途中のチャンクでは、使用量や終了理由がnullになることがあります。使用量情報は最終チャンクで確認する設計にしてください。(Microsoft Learn)
また、ストリーミング中でもコンテンツ安全性の評価が行われます。入力がブロックされた場合は生成開始前にHTTP 400となり、出力が途中でブロックされた場合は、それまでのチャンクを受信した後にSafetyBlockedErrorで終了する可能性があります。
「ストリームが開始されたので最後まで成功する」とは限りません。途中終了した回答を完成済みとして保存しないよう、終了イベントとエラーイベントを処理してください。(Microsoft Learn)
MAI-Thinking-1が向いている用途
MAI-Thinking-1は、回答までに複数段階の検討が必要な処理に向いています。
コードの調査と修正
単独のコード補完よりも、複数ファイルの関係を読み、障害原因を推定し、修正案を作り、テスト結果から再修正するような流れに適しています。
具体例としては、次のような用途があります。
- リポジトリ全体を踏まえたバグ調査
- 大規模なリファクタリング計画
- テスト失敗原因の分析
- API移行時の影響範囲調査
- セキュリティ修正案の比較
複雑な業務分析
条件が多い計画や定量的な分析でも活用できます。
- システム移行の段階計画
- 投資案や予算案の比較
- 売上予測と前提条件の整理
- 複数の制約を踏まえたスケジュール作成
- 大量文書からの論点抽出
ただし、財務、法務、医療などの判断では、最終決定をモデルに任せず、根拠の確認と専門家によるレビューを組み込む必要があります。(Azure AI)
長文を参照する社内アシスタント
256Kコンテキストを生かし、長い規程、仕様書、議事録、障害記録などを参照するアシスタントにも利用できます。
一方で、すべての社内文書を毎回プロンプトに含めると費用が増えます。文書検索、アクセス制御、引用元表示、キャッシュ、会話履歴の圧縮を組み合わせることが重要です。
MAI-Thinking-1が向いていない用途
次の用途では、別モデルまたは別方式を検討した方がよい場合があります。
単純で大量の定型処理
短い分類、定型文生成、簡単な要約など、深い推論を必要としない処理では、小型モデルの方が高速で安価になる可能性があります。
モデル選定では、最高精度だけでなく次の要素を比較します。
- 1件あたりの入力・出力トークン数
- 応答時間
- 同時実行数
- 正答率
- 再試行率
- 人による修正時間
- 月間総費用
画像や音声を含む処理
MAI-Thinking-1はテキスト専用です。画像の解析、音声認識、動画理解には対応していません。マルチモーダル処理が必要な場合は、Foundry内の対応モデルと組み合わせる必要があります。(Azure AI)
完全自律型の高リスクエージェント
外部から取得した信頼できない内容をもとに、確認なしでメール送信、契約処理、支払い、アカウント変更などを実行する構成には注意が必要です。
関数呼び出しを使う場合でも、次の制御をアプリケーション側に実装します。
- 実行可能な関数を限定する
- 引数をスキーマだけでなく業務ルールでも検証する
- 読み取りと更新の権限を分離する
- 重要操作には人の承認を必須にする
- 外部コンテンツを命令として扱わない
- 操作ログと監査記録を保存する
- 二重実行を防ぐ冪等性を設ける
モデル自体にネイティブなツール実行環境があるわけではなく、ツール呼び出しの安全境界は連携アプリケーションが管理します。(Azure AI)
よくあるエラーと対処方法
| エラー | 主な原因 | 確認すること |
|---|---|---|
| 400 Bad Request | 未対応パラメーター、入力形式の誤り、安全性フィルター | max_tokensではなくmax_completion_tokensを使用しているか |
| 401 Unauthorized | APIキー、トークン、認証ヘッダーの誤り | APIキーはapi-key、Entra IDはBearerトークンになっているか |
| 403 Forbidden | RBAC権限またはモデルアクセス不足 | ロール割り当てと対象リソースを確認 |
| 404 Not Found | エンドポイントまたはデプロイ名の誤り | /mai/v1とデプロイ名を確認 |
| 422 Unprocessable Entity | APIスキーマ不一致 | メッセージやツール定義のJSONを確認 |
| 429 Too Many Requests | TPM・RPM超過、利用可能クォータなし | クォータ確認、バックオフ、リクエスト分散 |
| 500・502・503 | 一時的なサービス障害や依存サービス障害 | 指数バックオフで再試行し、Azure Service Healthを確認 |
公式ドキュメントでは、500番台や429に対してバックオフ付きの再試行が案内されています。ただし、400、401、403、404は設定や要求内容を直さない限り、同じリクエストを繰り返しても解決しません。(Microsoft Learn)
導入前に確認すべき実務チェックリスト
MAI-Thinking-1を評価するときは、次の順序で進めると失敗を減らせます。
- 本番とは分離したAzureサブスクリプションまたはリソースグループを用意する
- Global Standardのデータ処理条件が社内規定を満たすか確認する
- Japan EastまたはJapan Westなど、対応リージョンにFoundryプロジェクトを作成する
- デプロイ権限と推論権限を最小限で割り当てる
- MAI-Thinking-1の利用可能クォータが0でないことを確認する
- Global Standard、モデルバージョン
2026-06-01でデプロイする - Playgroundで基本的な応答を確認する
- 実際の業務データを匿名化した評価セットで比較する
- 精度だけでなく、応答時間、トークン数、費用、拒否率を記録する
- 関数呼び出しでは、引数検証と人による承認を実装する
- 400、429、500番台のエラー処理を実装する
- 一般提供前に本番採用する場合は、代替モデルと停止手順を準備する
MAI-Thinking-1の強みは、35BアクティブのMoE構成、256Kコンテキスト、最大64K出力、関数呼び出し、暗号化された推論状態、Chat Completions API互換性をMicrosoft Foundry上で利用できる点です。
一方で、パブリックプレビューでSLAがなく、Global Standardのみ、PTU未対応という制約があります。まずは検証用プロジェクトでデプロイし、自社の代表的なタスクを使って、既存モデルとの精度、速度、費用、安全性を比較することが次の行動になります。
コメント