在 Amazon Bedrock 上推出 Grok

xAI 的 Grok 4.3 現已透過 Amazon Bedrock 正式可用，為構建 AI Agent 和工作流的團隊提供了一個能夠可靠推理長輸入內容的模型。此次釋出標誌著 xAI 成為 Amazon Bedrock 的模型提供商。Grok 4.3 具有可配置的推理力度，提供強大的工具使用和指令遵循能力以構建 Agent，並具備高效 token 處理能力以支援高吞吐量推理。該模型支援文本和影像輸入，擁有 100 萬 token 的上下文視窗，可用於長文件和多輪對話。模型執行在 Amazon Bedrock 的下一代推理引擎 Mantle 上。

為什麼 Grok 4.3 非常適合 Agent 和推理工作負載？

據 xAI 稱，Grok 4.3 專為需要準確性的企業工作而構建。在其釋出時的基準測試中，xAI 報告其超越了多個行業基準。Grok 4.3 在 Artificial Analysis Omniscience 基準測試中排名第一，在比較的頂級模型中幻覺率最低。它還在客戶支援場景的工具呼叫基準測試 Artificial Analysis Tau2 Telecom 中排名第一，並在 Vals AI Case Law 和 Corporate Finance 基準測試中排名第一。xAI 還將其置於智慧與成本帕累託前沿，稱其每美元智慧度是其他前沿模型的 2 到 10 倍。

透過 Grok 4.3，您可以在每次請求中控制模型在回答前的思考程度，透過設定推理力度（無、低、中、高）來實現。分類呼叫可以設定為無以保持低延遲；合同分析或判例法任務可設定為高，當深度比響應時間更重要時。Grok 4.3 接受文本和影像輸入並返回文本，其 100 萬 token 上下文視窗為長文件和擴充套件的多輪對話留出空間。模型擅長工具呼叫和指令遵循，這對於依賴函式呼叫來執行操作的 Agent 非常實用。這些特性適用於合同審查、信用協議分析和金融文件問答等用例。在這些情況下，模型對長輸入進行推理，然後呼叫記錄系統。

如何在 Amazon Bedrock 上訪問 Grok 4.3

Grok 4.3 執行在 Mantle 上，其訪問方式與使用 Amazon Bedrock Runtime API 的模型不同。Mantle 使用 OpenAI 相容的 API。您可以透過 OpenAI SDK 或直接 HTTPS 請求到 Chat Completions API 或 Responses API 來呼叫 Grok 4.3。

Mantle 端點 URL 是區域特定的，遵循特定模式。例如，在 us-west-2 區域，基礎 URL 為 https://bedrock-mantle.us-west-2.api.aws/openai/v1。請注意，Mantle 端點的 Responses API URL 路由與 Runtime 端點略有不同。

要使用 Grok 4.3 設定 SDK，需按照上述描述設定基礎 URL 和區域。使用 Grok 時，注意上下文視窗為 100 萬 token，預設值在三個方面與標準 OpenAI 規範不同：temperature 預設為 0.7，top_p 預設為 0.95，max_completion_tokens 預設為 131072。如果您的應用程式需要不同行為，請顯式設定這些引數。

認證並執行第一個請求

您有兩種方式對 Mantle 端點進行認證，兩者都適用於相同的 OpenAI SDK。對於生產環境，我們建議使用從 IAM 憑據生成的短期 bearer 令牌，因為它們會自動過期並保持訪問與您的 IAM 身份繫結。對於快速探索和入門，請使用長期 Amazon Bedrock API 金鑰。將長期金鑰限制於此用途，而不是嵌入到生產應用程式中。

以下示例展示瞭如何使用長期 Amazon Bedrock API 金鑰進行認證以訪問模型。視為僅用於探索的憑據。您可以從 Amazon Bedrock 控制台生成一個，然後安裝 OpenAI SDK。將客戶端指向區域性的 Mantle 端點並使用 API 金鑰進行認證。模型 ID 為 xai.grok-4.3。

當您準備好將 Amazon Bedrock 整合到需要更高安全性的應用程式中時，建議使用短期憑據。您可以在請求時使用 Amazon Bedrock 令牌生成器從現有的 AWS 憑據生成短期 bearer 令牌。這使認證與您的 IAM 身份繫結，並避免使用長期金鑰。

配置推理輸出

您可以透過 Responses API 上的 reasoning 引數控制模型使用的推理力度。力度級別為 none（停用推理）、low（預設）、medium 和 high。更高的力度通常有助於解決多步問題，但代價是生成更多的輸出 token。

Chat Completions API 不返回推理軌跡。如果您希望模型的推理在多個輪次中可用，請使用 Responses API。在預設的有狀態模式下，設定 store=True 並透過 previous_response_id 鏈式呼叫，服務會自動保留每個輪次的推理並將其反饋，因此您無需自行管理。加密推理用於無狀態情況。如果您設定 store=False（例如，工作負載要求輪次不在伺服器端持久化），請使用 include=["reasoning.encrypted_content"] 請求推理。在下一個請求的輸入中將其傳回，以將模型自身的先前推理作為上下文提供。

一個實用模式是：將分類、提取和簡短事實查詢設定為 none 或 low 力度，將 high 保留給規劃步驟、數學和鏈式任務，其中單個早期錯誤會破壞整個任務。

使用 Grok 4.3 呼叫工具

工具呼叫對於 Agent 工作負載至關重要，Grok 4.3 透過相同的 OpenAI 相容介面支援它。您描述可用的工具，模型決定何時呼叫，並返回一個結構化請求，您的程式碼執行該請求並反饋結果。Grok 4.3 遵循標準的 OpenAI 工具呼叫格式，因此您使用 JSON Schema 為每個工具定義引數。

以下示例提供了一個 get_weather 工具並詢問一個應觸發它的問題。模型從問題中解析出城市並生成了一個與 schema 匹配的有效引數物件。然後您執行函式，新增工具角色訊息，並再次呼叫模型以使結果融入自然語言回覆。這是 Grok 4.3 上多步 Agent 的構建塊。

結構化輸出

當您需要模型返回程式碼可直接解析的資料時，請使用帶有 JSON Schema 的結構化輸出。Grok 4.3 支援 json_schema 響應格式並帶有嚴格模式，因此響應將符合您提供的 schema，而不是給出自由文本。將 strict 設定為 True 並將 additionalProperties 設定為 False 可將響應限制在您所請求的鍵內，當下遊系統期望固定記錄格式時，這與工具呼叫配合良好。測試中的一個操作注意事項：即使是無害輸入，請求偶爾也會從自動內容安全檢查返回 400 錯誤，因此請在生產呼叫中構建簡短的重試。

影像輸入

Grok 4.3 接受影像作為輸入並返回文本，適用於文件理解、圖表閱讀和視覺問答。您可以使用與 OpenAI Chat Completions API 相同的模式傳遞影像，作為包含 base64 編碼位元組的 data: URL 或公共影像 URL 的內容部分。文本和影像部分位於同一個 content 陣列中，以便模型同時看到問題和圖片。在測試中，模型正確讀取了生成的測試影像並命名了其主要顏色。請使用受支援的影像格式（如 PNG 或 JPEG）並保持編碼整潔：格式錯誤或截斷的影像負載將返回驗證錯誤。