Amazon Bedrock 上的 Kimi K3：通过托管 API 提供开放权重

Moonshot AI 将一款 2.8 万亿参数模型带到了 AWS，但更大的变化并非又一次刷新模型规模纪录。Amazon Bedrock 上的 Kimi K3 为开发者提供了托管式开放权重模型访问能力，具备原生视觉、100 万 token 上下文窗口和显式提示词缓存。

9 月 18 日的发布使 Kimi K3 从企业可自行托管的模型，转变为可通过熟悉的 Bedrock 接口调用的模型。其目标是长周期的编程和知识工作流，其中应用会反复处理代码仓库、文档、图像、指令和工具定义。

这一组合对两种既有方案构成了压力。Anthropic 和 OpenAI 的专有模型仍树立了重要的性能标杆。自行托管的开放模型提供更多基础设施控制权，但运行一个 2.8 万亿参数系统需要专业硬件和工程能力。Bedrock 如今提供了第三条路径：以托管服务方式交付开放权重。

Amazon Bedrock 上的 Kimi K3 改变了部署选择

AWS 让客户无需为目前规模最大的开放权重模型之一各自构建推理平台，也能使用 Kimi K3。

Kimi K3 于 2026 年 9 月 18 日在 Amazon Bedrock 上线。AWS 将其描述为 Moonshot AI 能力最强的模型，也是首个达到 2.8 万亿总参数的开放模型。Moonshot 于 7 月发布了该模型本身。

该模型采用混合专家架构，将能力分配给专门组件，并为每个 token 仅激活其中一部分。Kimi K3 包含 896 个路由专家，每个 token 选择其中 16 个。根据模型的技术报告，一次前向传播期间约有 1040 亿参数处于激活状态。

这一差异很重要，因为标题中的参数数量并不等于每个生成 token 所使用的计算量。该架构试图将庞大的已学习能力池与更小的活跃路径相结合。Moonshot 表示，与 Kimi K2 相比，这一设计将扩展效率提高了约 2.5 倍。

此次发布还包含原生视觉能力。应用可在同一工作流中发送文本和受支持图像，使 Kimi K3 能够结合文字上下文理解图表、截图、界面、文档及其他视觉材料。目前，Amazon Bedrock 不支持该模型的视频输入。

其 100 万 token 上下文窗口面向远超单次提问的任务。编程代理可携带代码仓库指令、源文件、问题上下文和此前操作。知识应用则可处理大量文档集合，同时在连续请求中保留工作线索。

大上下文窗口并不保证能够在每个 token 范围内准确检索或推理。它定义的是一次请求可以包含的材料数量。可靠性仍取决于提示词构建、信息放置、评估方法，以及模型在真实工作负载下的表现。

托管端点改变了围绕这些能力的运营决策。开发者可通过兼容 OpenAI 的 Responses 和 Chat Completions API，以及 Bedrock 的 Invoke 和 Converse 接口使用该模型。模型标识符为 moonshotai.kimi-k3。

AWS 提供美国地理区域和全球跨区域推理配置文件。美国配置文件会在受支持的美国区域之间路由请求，以满足适用的数据驻留要求。全球配置文件则可在受支持的商业 AWS 区域之间路由请求，适用于没有类似地理限制的工作负载。

这使 Amazon Bedrock 上的 Kimi K3 不只是一次目录更新。AWS 正将通常需要罕见基础设施的模型，置于客户已经用于其他基础模型的同一服务边界之后。

此次发布并未取消自行托管的选择，而是改变了自行托管变得必要的节点。团队如今可先测试模型、将其集成到应用中并评估生产环境表现，再决定是否承担自行运行其权重的运营负担。

真正的优势在于可复用上下文，而非仅仅是上下文规模

只有当应用可以避免在每次请求中重复处理相同的大型前缀时，100 万 token 窗口才会在经济上真正有用。

长上下文应用经常重复发送稳定信息。编程助手可能会在每一轮中包含代码仓库规范、架构文档、工具 schema 和相关源文件。研究系统则可能反复提交同一批报告，仅改变分析人员提出的问题。

如果没有缓存，模型每次都会处理这些重复上下文。即便请求中的大部分内容并未改变，应用仍需再次承担延迟和输入 token 成本。

Kimi K3 在 Amazon Bedrock 上同时支持隐式和显式提示词缓存。隐式缓存自动运行。显式缓存则允许开发者准确标记可复用提示词前缀与其后变化内容之间的边界。

AWS 表示，Kimi K3 是 Bedrock 上首个支持显式提示词缓存的开放权重模型。正是这一机制，将该模型的大上下文窗口与实际的编程和知识工作流连接起来。

开发者可以在包含至少 1,024 个 token 的稳定前缀之后放置一个 prompt_cache_breakpoint。Bedrock 会在初始请求中处理并存储该前缀。后续包含匹配内容的请求可复用缓存状态，而无需重新计算。

缓存至少保留 30 分钟。目前，显式缓存可通过 Responses 和 Chat Completions API 使用。根据 Bedrock 模型卡，匹配的缓存读取不会计入应用的每分钟输入 token 配额。

这一设计有利于持续会话。设想一名开发者要求代理检查代码仓库、追踪失败的测试、提出补丁并审查结果。代码仓库指引和工具定义保持稳定，而即时指令和执行输出会在每一步发生变化。

显式缓存允许应用将稳定材料置于受控边界之前，将变化消息保留在边界之外。这样可以减少重复处理，而不必迫使开发者缩短上下文或丢弃有用指令。

知识工作遵循同样的模式。团队可以一次性加载政策库、产品文档或研究报告集合。随后，用户可在缓存有效期内针对这个共享前缀提出不同问题。

这同样适用于个人信息系统。可搜索知识库必须在广泛上下文与选择性检索之间取得平衡。即使模型能够接受，持续在每一轮发送所有可用文档也很少是最佳策略。

缓存不能替代检索。检索决定哪些信息应被纳入请求；缓存则在应用组装出有用且稳定的上下文后，减少重复处理。

这一差异避免了对百万 token 模型的一种常见误解。目标不是因为空间存在就填满整个窗口，而是在控制重复、延迟和成本的同时，为长周期任务保留足够的相关状态。

提示词缓存也引入了工程选择。团队必须决定哪些指令应保持稳定、何时创建新的缓存键，以及如何处理代码仓库文件或参考文档的更新。前缀发生变化可能导致缓存未命中，并需要重新写入。

跨区域推理增加了另一项考量。AWS 会路由请求以提升容量和可用性，但分布式路由可能影响可复用缓存状态的命中位置。应用应检查缓存读取和缓存写入使用情况，而非假设每次重复请求都会命中缓存。

AWS 更广泛的提示词缓存指南建议监控这些响应字段。对于 Kimi K3，这种可观测性将决定该功能是带来实际节省，还是仅仅增加配置工作。

100 万 token 上下文窗口吸引了关注，但显式控制才是更具影响力的 Bedrock 功能。它让开发者能够塑造上下文在真实工作流中的复用方式。

托管开放权重给专有模型带来新的压力

Kimi K3 缩小了开放权重模型与专有模型之间的运营差距，但并未抹去它们的性能差异。

核心竞争并不只是 Kimi K3 与某一个具名聊天机器人的对抗，而是托管式开放权重访问与专有 API、自行托管基础设施这一传统选择之间的竞争。

专有服务历来提供了获取先进模型的最简单路径。团队向 API 发送请求，由提供商负责服务、扩展、硬件和模型更新。代价是依赖一个权重和内部实现均不可获取的封闭模型。

开放权重模型则提供另一种形式的控制。组织可以检查可用工件，在选定基础设施上部署模型，并修改周边技术栈的部分组件。然而，这种自由可能伴随大量硬件和运维要求。

Kimi K3 让这种对比格外直观。其总规模达到 2.8 万亿参数。尽管每个 token 仅激活其中一部分，服务系统仍需访问完整的专家池，并必须在大内存加速器之间协调计算。

AWS 单独提供的部署演练使用配备八块 NVIDIA B300 GPU 的 ml.p6-b300.48xlarge 实例。该设计还依赖专用 vLLM 容器、张量并行、量化权重、集群编排和预留加速器容量。

这些要求并不意味着自行托管对所有组织都不切实际。但它们表明，可下载权重并不等同于易于部署的软件。模型的开放性将控制权转向用户，但其规模也集中化了运维工作。

Amazon Bedrock 消除了大量服务负担。客户调用托管端点并选择推理配置文件，AWS 则处理底层容量、请求路由、模型可用性，以及与该服务所支持 API 的集成。

AWS 还表示，客户数据会保留在其数据边界内，不会与 Moonshot AI 共享，也不会用于训练模型。该公司称，推理请求适用零数据保留，零运营人员访问则可防止 AWS 人员访问提示词和补全内容。

这些是 AWS 的服务声明，不能替代每个客户自身的合规审查。企业仍需审查区域路由、日志配置、身份权限、数据分类以及自身的法律义务。

尽管如此，托管选项改变了团队评估 Kimi K3 的方式。企业不再需要在测试该模型是否能在其代码库、文档、视觉输入或智能体工具上良好运行之前，预留一个集群。

这降低了多模型架构中的切换阻力。Bedrock 已提供来自多家供应商的模型，包括 Amazon、Anthropic、Google、Meta、Mistral AI、OpenAI 以及其他开放模型开发者。Kimi K3 进入的是一个允许应用将不同工作负载路由至不同模型的环境。

该模型本身并未宣称拥有无可争议的性能领先优势。Moonshot 的技术报告称，Kimi K3 在整体性能上仍落后于 Claude Fable 5 和 GPT-5.6 Sol。该公司表示，它超过了其评测套件中纳入的其他开放和专有系统，但这些结果仍需独立测试验证。

这种克制的定位很重要。Kimi K3 无需在每项基准测试中击败所有闭源模型，便能形成压力。它只需在有价值的工作负载上表现足够出色，同时提供部署灵活性和可控的运行特性。

编程提供了一个早期检验。Kimi K3 在前端编程评测中取得较强排名后获得关注。Arena 联合创始人兼 CEO Anastasios Angelopoulos 在与 Associated Press 讨论这些结果时，称其为一次重要发布。

排行榜表现只是一个信号，并非生产环境保证。企业级编程智能体必须处理私有代码库、正确使用工具、从失败操作中恢复、遵守安全边界，并产出可维护的改动。这些行为很难用单一分数来体现。

不过，Bedrock 让对比评估变得更容易。团队可以创建一组固定的代码库任务、文档问题、视觉检查和工具使用场景，随后衡量各模型在准确率、完成率、延迟、缓存行为和人工审查时间方面的表现。

这正是专有模型提供商面临的压力点。托管开放权重模型可以在同一套企业采购和治理流程中竞争，而无需在评估开始前先部署独立的基础设施项目。

一百万 Token 无法解决可靠性或容量问题

此次发布降低了部署阻力，但并未解决输出质量、缓存效率和持续服务能力等更棘手的问题。

Moonshot 所披露的架构颇具雄心。Kimi Delta Attention 旨在提高长序列效率，而 Attention Residuals 则致力于在模型深度中保持信息流。Stable LatentMoE 控制系统如何选择活跃专家。

这些机制支撑了模型的规模，但架构声明并不能揭示它在每个应用中的实际表现。长上下文模型仍可能遗漏细小事实、混淆相似段落、遵循过时指令，或给予无关内容过多权重。

原生视觉能力也存在类似的不确定性。能够接收图像，并不意味着它能在截图、密集图表、扫描文档、设计稿或专业技术图中稳定可靠地运行。每种使用场景都需要有代表性的测试。

模型的推理行为和长程执行能力同样需要审查。智能体可能在早期步骤中显得很有能力，随后却会随着观察结果、工具输出和修正不断累积而偏离方向。更大的上下文可以保留更多历史，但保留下来的历史也可能包含错误。

因此，团队应评估完整的任务轨迹，而非孤立的回答。有用的衡量指标包括：模型是否选择了正确工具、是否遵守权限、是否识别失败状态，以及是否在所请求的工作完成后停止。

容量是另一项相关风险。Kimi K3 最初公开发布后不久，Moonshot 曾暂时暂停新订阅，因为需求在 48 小时内接近其可用容量上限。该公司表示将增加容量，并分批重新开放订阅。

Omdia 分析师 Lian Jye Su 向 Associated Press 表示，该模型对计算资源要求很高，而 Moonshot 似乎没有预料到需求激增。这一事件表明，模型可用与服务容量可靠并不是一回事。

Bedrock 提供了由 AWS 基础设施支持的另一条服务渠道。然而，不应假设托管端点消除了所有容量约束。跨区域路由、服务配额、缓存位置和需求模式仍可能影响延迟和吞吐量。

模型卡还展示了另一项边界。Kimi K3 通过美国地理和全球跨区域配置文件提供，而不是常规的区域内推理。对于必须将处理严格限定在某一特定 AWS 区域内的组织而言，需要评估这些路由选择是否符合其政策。

显式缓存也有自身的权衡。首次请求必须写入可复用前缀，而这一写入会涉及额外处理。后续请求很少的工作流，可能无法产生足够多的缓存命中来证明这项设置的价值。

快速变化的前缀也会削弱优势。如果应用在缓存边界之前重新排列工具定义、修改指令，或插入不断变化的元数据，就可能使复用失效。稳定的提示词构造将成为性能工程的一部分。

最少 1,024 Token 的前缀还意味着，缓存面向的是大量重复上下文。对于本来就能快速处理的简短提示词，它几乎没有多少价值。

安全声明也值得精确解读。AWS 提供账户控制、数据边界保护和服务级隔离。但应用仍需负责决定哪些内容进入提示词，以及模型可以借助工具执行哪些操作。

一个可访问代码库和执行环境的编程智能体，如果权限过宽，可能泄露密钥或修改敏感系统。知识助手则可能在检索过滤或授权检查失效时返回受限信息。

更安全的模式是分层防护。使用范围有限的凭据、隔离执行环境、验证工具输入、记录操作，并对重大变更要求人工批准。模型能力不应决定其权限边界的大小。

开放权重并不能消除这些应用风险，托管服务同样不能。将 Kimi K3 引入 Amazon Bedrock，为团队带来的是一个更易访问的模型，而不是一套自动生成的生产架构。

三个信号将表明 Kimi K3 是否会在 Bedrock 上产生影响

下一阶段将由生产证据决定，而不是模型参数量或其上下文窗口的新颖性。

第一个信号是持续工作负载下的缓存性能。团队应衡量缓存命中率、首 Token 时间、总响应延迟，以及由缓存提供的输入 Token 占比。

成功的结果应表明，稳定的代码库指令、文档集合和工具模式能够在多步骤会话中持续复用。频繁的缓存未命中将削弱将显式缓存与 100 万 Token 窗口结合的实际价值。

测试应纳入真实的变化。开发者会编辑文件，智能体会追加工具输出，知识集合也会接收更新。重复完全相同提示词的评估，会低估维护有效缓存边界的难度。

第二个信号是独立的任务可靠性。Kimi K3 需要在完整的编程和知识工作流中接受测试，包括失败的运行。完成率、错误恢复、引用准确性、工具选择和审查者投入，比单次基准测试获胜更重要。

这些证据还应比较不同的上下文策略。团队可以使用大型未经筛选的提示词、检索筛选后的上下文，以及结合显式缓存的检索方式来测试同一任务。这种比较能揭示百万 Token 窗口是否改善结果，还是仅仅扩大了请求规模。

视觉评估也应纳入同一流程。应用应测试用户实际可能提供的截图、图表和文档。只有当原生视觉能力能够提升任务完成率，同时不引入不可接受的错误时，它才具有实际意义。

第三个信号是通过 Bedrock 实现的企业采用。最有力的证据将是其在编程智能体、文档分析、支持系统和研究应用中的持续生产使用。一次性的试验场实验无法确立该模型的地位。

采用情况还将揭示客户偏好的部署路径。一些组织会使用 Bedrock 获取托管访问；另一些组织在需要直接控制权重、服务软件和预留基础设施时，可能会转向 SageMaker HyperPod 或 Amazon EKS。

这种迁移可以双向发生。团队可能先在 Bedrock 上构建原型，再自行托管稳定工作负载。另一个团队则可能先自行托管，之后发现集群运维会分散应用开发的注意力，因而迁移至 Bedrock。

竞争对手的回应构成第三个信号的一部分。专有模型提供商可以改善长上下文可靠性、缓存、编程准确性和企业控制能力。其他开放模型开发者则可以发布更小的系统，以更低的基础设施需求实现相近的任务性能。

对开发者而言，眼下的行动很明确：建立受控评估，而不是基于声誉迁移。使用有代表性的代码库和文档，定义成功结果，记录失败情况，并将 Kimi K3 与当前为应用提供服务的模型进行比较。

对企业买家而言，问题在于托管开放权重是否能带来有意义的议价能力。如果 Kimi K3 能在现有 AWS 控制体系中满足质量要求，它将为模型采购和工作负载路由增加一个可信选项。

对知识工作者而言，重要变化不那么显眼。更长的上下文和可复用前缀可支持保留更多项目材料的会话，减少反复从头开始的需要。但这一收益仍取决于应用如何选择、组织和保护这些信息。

将 Kimi K3 引入 Amazon Bedrock 值得关注，因为它结合了此前彼此分离的三种特质：开放权重模型、异常大的工作上下文，以及托管式企业访问。未来一到三个月将显示，显式缓存是否能将这些特质转化为更快、更可靠的工作流。

请在一个答案已知、审查流程可重复的有限任务上测试该模型。然后提出更棘手的问题：Kimi K3 是否减少了完成工作所需的总投入，还是仅仅能接收更多上下文？