AWS Machine Learning Blog 于 2026 年 9 月 28 日发表文章，宣布 xAI 的 Grok 4.7 已在 Amazon Bedrock 提供。文章列出了模型能够接收的输入、返回的输出、上下文窗口、可用的调用接口，以及用于调用的推理配置文件。对于正在阅读这项发布消息的人，这些项目需要放在一起理解：知道模型已经提供，并不能单凭这一点确定请求应包含什么内容、应走哪个接口，或者应填写哪个配置文件名称。下文所述具体参数均归于 AWS 这篇文章，而不是对模型表现作独立判断。

输入、输出与上下文窗口

按照 AWS 的说明，Amazon Bedrock 上的 Grok 4.7 可以接收文本和图像输入，返回的是文本。这里的方向十分明确：图像出现在输入一侧，文章所列的输出形式则是文本。因此，在考虑带有图像的请求时，可以依据这项说明确认图像属于所列输入类型；但不能把它扩展解释为文章也宣布了图像输出。读者若只看到“支持图像”几个字，容易忽略输入与输出在公告中分别受到怎样的描述。把两者写开，有助于准确界定这项发布消息实际覆盖的内容。

AWS 同时写明，Grok 4.7 的上下文窗口为 500K token，也就是以 50 万 token 表述的窗口大小。这是关于模型上下文范围的一个参数。它本身没有说明某一次调用会产生多长的回答，也没有说明某个具体任务会得到什么结果。阅读这一数字时，可以把它用于识别公告给出的上下文规格，同时避免从窗口大小推断未在材料中说明的效果。这里的关键不是对长文本处理结果作预测，而是准确记录 AWS 给出的数值和它所描述的对象。

公告列出四档推理强度，名称分别为 low、medium、high 和 xhigh，并说明默认档位是 high。这些名称提示调用者，请求所使用的档位可以是需要留意的设置。如果准备一份供他人阅读的调用配置，明确写出所选档位，就能让配置与公告中的四个名称直接对应；如果采用默认设置，则应按 AWS 所述将其理解为 high。公告给出了档位列表和默认值，但这些信息并未量化各档在质量、耗时或成本上的差异。读者不宜仅凭档位名称为各档添加文章没有提供的比较结论。

调用接口与推理配置文件

AWS 表示，Grok 4.7 通过 bedrock-runtime 端点提供服务，并使用跨区域推理配置文件。文章列出的受支持接口包括 Responses API、Chat Completions API、InvokeModel 和 Converse API。四个名称共同说明了公告所列的调用路径，但在阅读某个调用示例时，仍需先确认示例实际采用哪一个接口。这样做的原因在于，文章对某些路径的身份验证方式及返回的推理内容分别给出了具体说明。不能因为它们同时出现在受支持列表中，就推定每个接口在这些细节上完全相同。

文章给出的两个推理配置文件名称是 global.xai.grok-4.7 和 us.xai.grok-4.7。AWS 对美国地理配置文件的表述是，处理会保持在美国地理范围内。这一说明指向美国地理配置文件，因此在核对处理位置相关要求时，完整的配置文件名称比单看 Grok 4.7 这个模型名称更有辨识作用。公告同时说明了三个服务层级，名称为 Standard、Priority 和 Flex。这里可以确认的是层级名称及其数量；仅凭这些名称，不能确定某一次具体请求在某个层级中的实际表现或其他未列出的条件。

将端点、接口与配置文件分开看，也能减少对公告内容的误读。bedrock-runtime 是 AWS 所述的服务端点；Responses API、Chat Completions API、InvokeModel 和 Converse API 是文章列出的接口；两个带有 grok-4.7 的完整字符串则是文章列出的推理配置文件名称。它们都与调用有关，却回答不同的问题。准备请求时，读者可以分别核对自己选择了哪条接口路径、使用了哪个完整配置文件名称，再对照文章中与该路径有关的其他说明。公告没有要求把这些不同层面的名称视作可以互相替换的同一项设置。

身份验证与推理内容

在身份验证方面，AWS 说明，兼容 OpenAI 的调用可以把 Bedrock API 密钥用作 bearer token；而通过 boto3 发起的 Converse 调用使用 AWS 凭证和 SigV4。文章把这两种方式分别归于不同的调用情形。对于准备客户端的人，实用的读法是先确定采用的调用路径，再对应查看公告写明的验证方式。如果只摘出“API 密钥”或“SigV4”而省略其适用路径，就可能失去文章所提供的重要限定。这一差异是公告中的具体信息，并不需要额外推断其他接口如何验证。

关于推理内容，AWS 又指出一个与接口相关的区别：Responses API 在提出请求时可以返回加密的推理内容，而 Chat Completions API 不返回推理 token。两句话应分别按各自所指的接口阅读。Responses API 中“按请求返回加密内容”的说明，并不等于 Chat Completions API 也会给出相同内容；后者在公告中的描述恰恰是不返回推理 token。即使两个接口都列为受支持选项，读者仍需注意这项输出差异。文章提供的是这些接口的具体声明，而不是所有返回内容都一致的概括。

如果要把公告转化为一份可检查的调用计划，可以依次核对几件事。第一，输入是文本、图像，还是两者都在公告所列的输入范围内；第二，预期返回形式是否与公告给出的文本输出相符；第三，调用将采用四个列出的接口中的哪一个；第四，选用的完整推理配置文件名称是什么；第五，推理强度是明确设置，还是沿用 high 这个默认值。若还需要考虑身份验证方式或推理内容，则要继续按所选接口阅读 AWS 对相关路径的具体表述。这样逐项核对，只是在整理公告已给出的信息，并不预设实际任务的结果。

以上信息来自 AWS Machine Learning Blog 的发布文章。这篇文章宣布 Grok 4.7 在 Amazon Bedrock 提供，并列明上下文窗口、推理强度、输入输出、接口、推理配置文件、服务层级，以及若干接口相关的验证和返回内容细节。它让读者能够区分公告中已经明确的配置项，也提醒读者把没有在这些事实中得到说明的具体效果留待具体情境判断。对这则消息最稳妥的理解，是以 AWS 实际列出的范围和条件为准，逐项对应自己的请求，而不从名称或单个参数延伸出额外能力声明。