Amazon Bedrock现在为Kimi K3提供印度境内推理，同时继续支持全球推理和基于美国区域的推理。根据AWS的说明，组织可以通过选择推理配置文件，决定一次请求能够由哪些目标区域处理。对于需要将处理范围保留在印度境内的工作负载，指定配置文件为in.moonshotai.kimi-k3。该配置把推理处理严格限制在AWS孟买区域和海得拉巴区域。这意味着，应用在调用模型之前，可以先根据处理地点要求选择相应配置，而不是把目标区域当作调用之后才考虑的运行细节。

配置文件决定可用的处理边界

Kimi K3在Amazon Bedrock中通过跨区域推理配置文件提供。实际调用的配置文件会决定哪些目标区域有资格处理请求。因此，配置文件不仅是一个模型标识，它也是部署设计中的处理边界。印度配置覆盖两个印度区域；全球配置和美国配置则对应不同的处理地点需求。三类选择不能被视为同一种路径，因为它们允许使用的目标区域范围不同。

对于跨区域推理，数据在区域之间传输时会被加密，并且始终留在AWS网络中。用户无需自行建立跨多个区域的VPC基础设施。由此，应用团队可以把重点放在配置文件及其允许的区域范围上，而不必为了完成区域之间的推理转发，另外搭建一套多区域网络。这里涉及两个彼此相关但并不相同的概念：配置文件控制哪里可以处理请求，AWS网络则承载区域之间经过加密的传输。

印度配置的边界也应按其明确含义理解：它指向孟买和海得拉巴两个AWS区域。它并不改变全球或美国配置的存在，而是为需要印度境内处理的调用提供单独选择。应用若同时服务不同类型的请求，可以根据每次调用的地点要求选择配置文件；最终哪些区域符合条件，仍由被调用的配置决定。

通过Bedrock Runtime调用模型

应用可以通过Bedrock Runtime端点，使用多种API调用Kimi K3。AWS列出的方式包括Chat Completions API和Responses API，并支持流式传输、工具调用和结构化输出。流式传输适合逐步向应用交付响应；工具调用可把模型与已定义的工具连接起来；结构化输出则让下游程序能够按照预期格式接收结果。这些能力都属于同一运行时调用体系，但分别解决响应交付、外部工具衔接和结果格式三个方面的问题。

选择哪一种调用方式，取决于应用需要怎样消费模型结果。面向交互界面的调用可以使用流式响应，让内容持续返回；需要连接工具的流程可以使用工具调用；需要把结果交给后续程序的任务，则可要求结构化格式。相关支持并不局限于普通文本问答，而是覆盖从接收文件到输出机器可处理数据的完整交互过程。

图像、PDF与多语言文档

Kimi K3能够接收图像、PDF以及其他文件类型。输入文件可以直接使用base64编码发送，因此文档内容能够随请求交给模型。模型还可以直接读取并推理包含多语言文字的图像。按照AWS描述的文档处理方式，这使流程不必另外调用独立的OCR服务或翻译服务。模型可以面对带有不同文字系统的图像，读取其中内容并围绕内容进行处理。

这一能力把文件输入、文字识别与内容理解放在同一模型调用中。原始文档可以保留自身文字系统，而应用请求的结果可以采用另一种结构或语言形式。例如，原始文字的识别结果可以继续保留，特定字段则可组织成JSON，另行生成英文摘要，并在后续对话中回答问题。这里的重点不是把所有结果压缩成一种输出，而是让同一份文档产生面向不同用途的结果。

结构化输出便于连接后续步骤

Kimi K3在Amazon Bedrock上支持两种结构化输出途径：函数调用，以及基于JSON Schema的输出格式。如果响应将被另一个应用步骤读取，结构化输出比只有自然语言段落更容易直接处理。JSON Schema可以规定预期字段及其组织方式；函数调用则可以把模型生成的内容与可用工具或动作衔接起来。

可配置字段尤其适合文档内容并不完全相同、但应用希望结果遵循统一结构的情形。应用可以明确需要哪些字段，再把符合结构的结果交给后续流程。结构化输出与多语言图像理解结合后，一端可以接收原始文件，另一端可以交付由应用定义的字段，而不必把人工阅读作为每一步之间的固定环节。

示例流程展示了多阶段文档处理

AWS提供的示例管线首先在原始文字系统中执行OCR，然后提取可配置的JSON字段，生成英文摘要，并以Hinglish回答多轮问题。这个示例把四个阶段连在一起：保留原始文字的识别、面向程序的字段提取、面向阅读的摘要，以及可以连续追问的对话。多轮问题意味着后续提问能够形成连续交互，而不是每个问题都被描述成互不相关的单次处理。

该示例也说明，同一文档的不同输出可以服务不同读者或系统。原始文字识别保留来源内容的书写形式；JSON字段适合进入应用；英文摘要提供另一种阅读形式；Hinglish问答则用于多轮交流。这里描述的是AWS所提供示例管线的功能组成，并不是对识别准确率、摘要质量或问答效果所作的独立验证。

每次请求都可选择价格与队列特性

Amazon Bedrock服务层级允许应用针对每一次请求选择价格与性能组合。对于对延迟不太敏感的请求，flex层级相对默认standard定价提供百分之五十的折扣。priority层级则以更高价格提供更高的队列优先级。因此，应用不必让所有任务固定采用同一层级，可以依据一次调用的紧迫程度选择相应方式。

这一区分适合把后台任务与更紧迫的请求分开考虑。延迟敏感度较低的任务可以使用flex层级并接受其相应定位；需要更高队列优先级的任务可以选择priority层级并承担更高价格。服务层级是在每次请求上作出的选择，因此它与模型能力本身并不是同一维度：同一个Kimi K3调用可以根据任务需要采用不同层级。

提示缓存支持重复使用上下文

Kimi K3在Amazon Bedrock上还支持提示缓存命中时的折扣定价，并同时提供隐式和显式提示缓存模式。提示缓存与重复出现的提示上下文相关；当应用存在反复使用的内容时，缓存模式会成为调用设计的一部分。隐式与显式两种模式为集成方式提供不同选择，而缓存命中的折扣定价则直接关联到重复上下文的成本处理。

提示缓存和服务层级可以分别理解。服务层级用于选择某次请求的价格与性能取向，提示缓存则处理可复用提示内容及其命中。应用在设计多轮文档问答时，可以同时考虑请求的紧迫程度和上下文是否重复，但两者各自对应不同的控制机制。

日志所在区域不等于推理目标区域

无论最终由哪个目标区域完成处理，日志和指标都会保存在提交请求的源区域。也就是说，推理可能由配置文件允许的目标区域处理，但可观测性数据仍位于请求发出的区域。运行团队在核对区域信息时，需要区分源区域、目标区域以及配置文件允许的区域集合，不能仅凭日志存储位置推断实际处理地点。

可选的CloudTrail数据事件日志能够记录目标区域，具体信息位于additionalEventData.inferenceRegion字段。这个字段为需要查看实际推理区域的团队提供了对应记录，而常规日志和指标仍按源区域存放。对于印度配置，符合条件的处理区域限定为孟买和海得拉巴；请求从何处提交，则决定日志和指标存储在哪个源区域。

部署时需要分别处理三类选择

整体来看，这项服务把几类容易混在一起的决定明确分开。第一，推理配置文件决定哪些区域有资格处理请求；印度配置把范围限制在孟买和海得拉巴。第二，Runtime API、流式传输、工具调用、函数调用和JSON Schema决定应用怎样提交内容以及怎样接收结果。第三，服务层级和提示缓存分别影响每次请求的价格性能取向及重复上下文的处理方式。

对文档应用而言，这些部分可以组合成一条连贯流程：文件以base64形式随请求发送，模型读取包含多语言文字的图像或PDF，结果通过函数调用或JSON Schema形成结构化数据，并可继续生成摘要或开展多轮问答。处理地点由调用的推理配置约束，数据跨区域传输时保持加密并留在AWS网络中，日志与指标则回到源区域的运行视角。这样的组合既描述了模型如何被调用，也说明了地点、输出形式、队列优先级与运行记录分别由什么机制控制。