在 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）並保持編碼整潔：格式錯誤或截斷的圖像負載將返回驗證錯誤。