ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

openai-node 接入 Amazon Bedrock:Provider 配置、SigV4 认证与端点选型完全指南

openai-node 接入 Amazon Bedrock:Provider 配置、SigV4 认证与端点选型完全指南 openai-node 接入 Amazon BedrockProvider 配置、SigV4 认证与端点选型完全指南【免费下载链接】openai-nodeOfficial JavaScript / TypeScript library for the OpenAI API项目地址: https://gitcode.com/GitHub_Trending/op/openai-node本文是基于 openai-node 官方仓库 docs/bedrock.md 整理的实战指南讲解如何让标准OpenAI客户端通过 Bedrock Provider 接入 Amazon Bedrock 的 OpenAI 兼容 API。读完本文你将掌握 Mantle 与 Runtime 两种区域端点的选型规则、Bearer 与 AWS SigV4 两套认证方式的完整配置、CRIS 推理档位的调用方法以及遗留BedrockOpenAI类的兼容用法与安全边界。快速上手用 Provider 构造客户端Bedrock 的 OpenAI 兼容 API 不需要单独的客户端类。只需从 AWS 入口导入bedrock(...)工厂函数把它作为provider传给标准的OpenAI客户端所有常规资源client.responses、client.chat.completions等即可指向 Bedrockimport OpenAI from openai; import { bedrock } from openai/providers/bedrock/aws; const client new OpenAI({ provider: bedrock({ region: us-west-2 }), }); const response await client.responses.create({ model: openai.gpt-5.4, input: Say hello!, }); console.log(response.output_text);两点注意必须选择支持 Responses API 的模型。注意 Models API 返回的模型未必支持 Bedrock 的 OpenAI 兼容推理接口可能只支持 Bedrock 的原生推理 API。该示例的完整可运行版本见 examples/bedrock/responses.ts它会打印出output_text并注释了如何切换为tokenProvider方式获取可刷新的 Bearer 令牌。从源码看bedrock(...)返回的是一个 Provider 对象其configure()阶段解析出最终的baseURL和认证处理器见 src/providers/bedrock/aws.ts。也就是说认证与端点解析都是惰性的只有实际发请求时才会解析凭证、签名、拼装 URL。端点选型Mantle 与 Runtimeendpoint选项决定使用 Bedrock 的哪个区域端点家族endpoint默认 API 根地址SigV4 签名服务mantle默认https://bedrock-mantle.region.api.aws/openai/v1bedrock-mantleruntimehttps://bedrock-runtime.region.amazonaws.com/openai/v1bedrock两种端点模式都会暴露 SDK 的常规资源但这不代表 AWS 在每个端点上支持全部资源。AWS 自行控制各部署可用的模型、推理配置档inference profile、API 路由、认证方式与流式行为不支持的调用会以 Provider 正常的 HTTP 错误形式透出到 SDK。端点与区域的解析优先级区域默认依次取region选项 →AWS_REGION→AWS_DEFAULT_REGION见 src/internal/bedrock.ts。没有可用的区域时构造会直接抛出OpenAIError。API 根地址优先级为baseURL→AWS_BEDROCK_BASE_URL→ 按区域推导出的端点地址。baseURL显式传null可跳过环境变量覆盖。端点家族推断当endpoint未指定时若baseURL/AWS_BEDROCK_BASE_URL是官方规范的 AWS 主机名包括 Runtime FIPS 与 dual-stack 变体SDK 会自动识别其端点家族与签名服务否则默认使用 Mantle。从源码看SDK 会解析主机名中的bedrock-mantle.region.api.aws与bedrock-runtime[-fips].region.suffix模式见 src/internal/bedrock.ts并按区域推导对应的 AWS partition DNS 后缀。例如us-west-2→amazonaws.comeusc-de-east-1→amazonaws.eu中国、ISO 分区等区域也会推导到各自的专属后缀amazonaws.com.cn、c2s.ic.gov等规范主机名的覆盖还有一些强约束官方 FIPS / dual-stack 端点覆盖必须使用 HTTPS且主机名中嵌入的区域必须与配置的区域一致否则抛错。当把请求签名发往自定义或代理主机时必须显式设置endpointSDK 才能选择正确的 SigV4 签名服务const client new OpenAI({ provider: bedrock({ region: us-west-2, endpoint: mantle, baseURL: https://bedrock.example.com/openai/v1, }), });注意在 AWS 入口下如果用了自定义baseURL却没有显式endpoint且主机名无法被识别为规范的 Bedrock 主机名构造会在使用 AWS 凭证认证时报错见 src/providers/bedrock/aws.ts。安全边界凭证只发给配置的 originBedrock 凭证Bearer 或 SigV4 签名只发送给配置的 API 根地址所在 origin。任何指向其他 origin 的绝对资源 URL 都会被拒绝——这一检查在assertBedrockRequestOrigin中实现见 src/internal/bedrock.tsbedrock.ts的 Provider 入口与遗留BedrockOpenAI类都会调用它。对应的隐私与重定向安全测试见 tests/lib/bedrock-bearer-credential-privacy.test.ts 与 tests/lib/bedrock-bearer-redirect-security.test.ts。同时所有 Bedrock 认证模式Bearer、SigV4、以及遗留BedrockOpenAI都会禁用自动重定向包括同源重定向——即使客户端或单次请求的fetchOptions显式指定了redirect: follow也一样。原因很直接重定向目标需要新的签名或重新鉴权。请直接把最终 API 根地址配到baseURL上。Amazon Bedrock RuntimeCRIS 推理档位与 Chat Completions设置endpoint: runtime即可使用 Bedrock Runtime 端点。例如us-west-2的默认 API 根是https://bedrock-runtime.us-west-2.amazonaws.com/openai/v1。CRIS 推理档位模型 IDus.openai.gpt-5.6-sol、us.openai.gpt-5.6-terra、us.openai.gpt-5.6-luna这三个 OpenAI Runtime 标识符是跨区域推理CRIS配置档 IDus.前缀选择 US CRISglobal.前缀如global.openai.gpt-5.6-sol选择 Global CRIS。对这些部署Runtime 要求使用推理配置档 IDAWS 会拒绝裸模型 ID如openai.gpt-5.6-sol。可用性取决于你的 AWS 账户与所选区域。非流式 Chat Completions 示例对于三个 US 配置档新版 Provider 已验证的集成路径是/openai/v1/chat/completions上的非流式 Chat Completions使用 AWS SigV4签名服务bedrock认证。为避免环境里残留的 Bearer 令牌盖过 AWS 凭证需要显式apiKey: nullimport OpenAI from openai; import { bedrock } from openai/providers/bedrock/aws; const client new OpenAI({ provider: bedrock({ region: us-west-2, endpoint: runtime, apiKey: null, }), }); const completion await client.chat.completions.create({ model: us.openai.gpt-5.6-sol, messages: [{ role: user, content: Say hello from Amazon Bedrock Runtime! }], }); console.log(completion.choices[0]?.message.content);流式 Chat CompletionsSDK 也可以把流式请求发往同一个 Chat Completions API。不过文档明确提示某个 Runtime 部署、模型与推理配置档的流式支持尚未经过线上验证取决于 AWS 侧const stream await client.chat.completions.create({ model: us.openai.gpt-5.6-sol, messages: [{ role: user, content: Say hello from Amazon Bedrock Runtime! }], stream: true, }); for await (const chunk of stream) { process.stdout.write(chunk.choices[0]?.delta?.content ?? ); }仓库中有对应的单元测试覆盖 Bearer 与 SigV4 两种认证下的 Runtime 流式 Chat Completions 逐块输出顺序见 tests/lib/bedrock-runtime-streaming.test.ts也有非流式的端点、认证组合测试见 tests/lib/bedrock-runtime-provider.test.ts。但单元测试只能证明 SDK 侧行为真正的部署支持仍以 AWS 为准。可运行的示例脚本examples/bedrock/runtime-chat.ts 是一个开箱即用的示例默认走 SigV4 认证、忽略过期的AWS_BEARER_TOKEN_BEDROCK、默认使用us.openai.gpt-5.6-sol。支持以下运行方式AWS_REGIONus-east-1 pnpm tsn examples/bedrock/runtime-chat.ts AWS_REGIONus-east-1 BEDROCK_MODELus.openai.gpt-5.6-terra BEDROCK_STREAM1 pnpm tsn examples/bedrock/runtime-chat.ts AWS_REGIONus-east-1 BEDROCK_AUTHbearer BEDROCK_MODELus.openai.gpt-5.6-luna pnpm tsn examples/bedrock/runtime-chat.ts脚本内部读取的环境变量AWS_REGION/AWS_DEFAULT_REGION区域默认us-east-1BEDROCK_MODEL模型 ID默认us.openai.gpt-5.6-solBEDROCK_STREAM1启用流式输出BEDROCK_AUTHsigv4|bearer认证方式默认sigv4AWS_PROFILE指定 AWS 共享配置文件SigV4 模式下AWS_BEARER_TOKEN_BEDROCKBearer 模式必需的令牌。Bearer 示例必须配置AWS_BEARER_TOKEN_BEDROCK。流式保持可选取决于所选 AWS 部署与模型的支持情况。/v1与/openai/v1路由差异SDK 默认使用 AWS OpenAI 模型文档中描述的/openai/v1路由而 AWS 的 Chat Completions 文档描述的 Bedrock Runtime 路由是/v1。如果你的模型或端点要求后者请显式覆盖 API 根const client new OpenAI({ provider: bedrock({ region: us-west-2, endpoint: runtime, baseURL: https://bedrock-runtime.us-west-2.amazonaws.com/v1, }), });已验证范围务必读文档对线上验证范围做了非常严谨的界定一次独立的线上验证通过遗留的 Bearer 认证BedrockOpenAI客户端对us.openai.gpt-5.6-sol与global.openai.gpt-5.6-sol执行了非流式 Runtime Responses它没有覆盖新版bedrock(...)Provider、SigV4 或 Runtime 流式。因此Bearer 认证、Runtime Responses、流式这些路径都是**部署相关deployment-dependent**的除非你在自己的 AWS 账户、区域、模型与推理配置档组合上实际验证过否则不要假设它们可用。认证方式总览Bedrock Provider 同时支持 Bearer 认证与 AWS SigV4 认证两者都可用于 Mantle 和 Runtime 端点。AWS 决定某个部署接受哪种认证方式。AWS 入口openai/providers/bedrock/aws按以下顺序选择认证传给bedrock(...)的显式模式apiKey或tokenProviderBearer、静态 AWS 凭证、profile、或credentialProviderAWS_BEARER_TOKEN_BEDROCK中的 Bedrock API key默认 AWS 凭证链。规则与约束显式 Bearer 与显式 AWS 凭证互斥AWS 凭证模式内部也只能二选一静态凭证 /profile/credentialProvider同时配置多个会抛OpenAIError见 src/providers/bedrock/aws.ts。apiKey与tokenProvider互斥见 src/internal/bedrock.ts。过期的AWS_BEARER_TOKEN_BEDROCK会优先于默认 AWS 凭证链从而遮蔽本可正常工作的 AWS 凭证。要么unset AWS_BEARER_TOKEN_BEDROCK要么传apiKey: null来禁用环境 Bearer 回退、强制走默认 AWS 凭证链的 SigV4 认证import OpenAI from openai; import { bedrock } from openai/providers/bedrock/aws; const client new OpenAI({ provider: bedrock({ region: us-west-2, endpoint: runtime, apiKey: null, }), });apiKey: null也可以与profile: my-profile组合显式选择命名 AWS 配置档。Bearer 认证三种配置 Bearer 的方式直接传 API key、设置AWS_BEARER_TOKEN_BEDROCK、或使用tokenProvider在每次请求尝试前解析新鲜令牌// 方式一直接传 key const client new OpenAI({ provider: bedrock({ region: us-west-2, apiKey: process.env[BEDROCK_API_KEY], }), }); // 方式二可刷新的令牌提供器 const client new OpenAI({ provider: bedrock({ region: us-west-2, tokenProvider: async () refreshBedrockToken(), }), });tokenProvider在每次请求尝试包括重试之前都会被调用适合短时效令牌的场景。从源码看Bearer 令牌还会经过 HTTP 头合法性校验拒绝首尾空白与不可打印字节见 src/internal/bedrock.ts并且禁止与自定义Authorization头共存见 src/internal/bedrock.ts。免依赖入口openai/providers/bedrock如果不需要 SigV4可以从免依赖入口导入bedrock它不加载任何 AWS SDK 包import { bedrock } from openai/providers/bedrock; const client new OpenAI({ provider: bedrock({ region: us-west-2, endpoint: runtime, apiKey: process.env[AWS_BEARER_TOKEN_BEDROCK], }), });该入口只支持apiKey、tokenProvider与AWS_BEARER_TOKEN_BEDROCK要使用 SigV4 认证必须走 AWS 入口openai/providers/bedrock/aws实现见 src/providers/bedrock.ts。由于不依赖 AWS 包它也可以在浏览器等运行时中使用配合dangerouslyAllowBrowser而 SigV4 目前只支持 Node.js 及兼容的服务端运行时。AWS 凭证与 SigV4安装 peer 依赖使用 SigV4 需要先安装 AWS 入口的三个 peer 依赖npm install aws-sdk/credential-provider-node smithy/hash-node smithy/signature-v4AWS 入口使用静态 import因此 Vite、Webpack、serverless 打包器都能把这三个依赖打进产物。只要缺一个导入openai/providers/bedrock/aws会立刻以运行时的标准 module-not-found 错误失败例如Cannot find module aws-sdk/credential-provider-node依赖完整性的测试见 tests/lib/bedrock-provider-dependencies.test.ts。使用默认凭证链或命名 profile导入 AWS 入口后省略显式认证即可走默认 AWS 凭证链也可以用profile指定共享配置档import { bedrock } from openai/providers/bedrock/aws; const client new OpenAI({ provider: bedrock({ region: us-west-2, endpoint: runtime, apiKey: null, profile: my-profile, }), });签名服务的选择Runtime 请求用bedrock服务签名Mantle 请求用bedrock-mantle见 src/providers/bedrock/aws.ts。当baseURL或AWS_BEDROCK_BASE_URL指向自定义/代理主机时务必显式设置endpoint否则签名服务无法确定。临时凭证与凭证提供器可以直接传入包含 session token 的临时 AWS 凭证const client new OpenAI({ provider: bedrock({ region: us-west-2, accessKeyId: process.env[AWS_ACCESS_KEY_ID], secretAccessKey: process.env[AWS_SECRET_ACCESS_KEY], sessionToken: process.env[AWS_SESSION_TOKEN], }), });注意静态凭证的约束accessKeyId与secretAccessKey必须成对提供sessionToken只有在两者都提供时才能使用src/providers/bedrock/aws.ts。对于会轮换的凭证用credentialProvider——它在每次请求尝试包括重试之前被调用const client new OpenAI({ provider: bedrock({ region: us-west-2, credentialProvider: async () { const sessionToken process.env[AWS_SESSION_TOKEN]; return { accessKeyId: process.env[AWS_ACCESS_KEY_ID]!, secretAccessKey: process.env[AWS_SECRET_ACCESS_KEY]!, ...(sessionToken undefined ? {} : { sessionToken }), }; }, }), });SigV4 的运行时与请求体限制运行时SigV4 仅支持 Node.js 与兼容的服务端运行时其他运行时请用 Bearer 认证AWS 入口在非 Node.js 进程里会直接抛OpenAIError见 src/providers/bedrock/aws.ts。请求体必须可重放当前 SigV4 模式要求可重放、可缓冲的请求体例如字符串、ArrayBuffer或 TypedArray 视图。SDK 标准的 JSON API 方法天然满足。自定义FormData、可读流等不可重放请求体在发送前就会被拒绝响应流式不受影响。不跟随重定向签名请求不会自动跟随重定向因为重定向目标需要新的签名。Mantle 的扩展签名模式Mantle 还支持UNSIGNED-PAYLOAD与 AWS-chunked 请求签名但本 SDK 不启用这些模式。另外 Mantle 会在收到完整请求体后才做认证与授权因此流式上传请求体并不会降低请求延迟。认证与取消Abort的协作一个值得注意的实现细节Bearer 令牌解析与 SigV4 签名都是异步的SDK 会让它们在等待期间响应AbortSignal用户取消请求时签名/取令牌会以APIUserAbortError中止且不会在重试时复用错误的签名见 src/internal/bedrock.ts。相关取消安全测试见 tests/lib/bedrock-provider-bearer-cancellation.test.ts。遗留BedrockOpenAI类BedrockOpenAI类保留给现有的 Bearer 认证应用。它接受awsRegion与bedrockTokenProvider选项名默认使用 Mantle/openai/v1端点import { BedrockOpenAI } from openai; const client new BedrockOpenAI({ awsRegion: us-west-2, apiKey: process.env[AWS_BEARER_TOKEN_BEDROCK], });关于遗留类需要知道的几点仅支持 Bearer构造函数中传入adminAPIKey、workloadIdentity、x509Transport或dataResidency会直接抛错见 src/bedrock.ts。凭证默认值apiKey默认取AWS_BEARER_TOKEN_BEDROCKbaseURL默认取AWS_BEDROCK_BASE_URL否则由awsRegion/AWS_REGION/AWS_DEFAULT_REGION推导 Mantle 地址。流式 Responses 的兼容修复Bedrock 流式响应可能省略output_text便捷属性该类会对responses.stream(...)的最终响应做一次补齐见 src/bedrock.ts。线上验证范围遗留类已验证的路径是显式设置 RuntimebaseURL、使用 US 或 Global CRIS 推理配置档 ID 的非流式 Bearer Runtime Responses。重定向与 origin 校验与新版 Provider 一致请求强制redirect: manual并校验所有请求 URL 与配置的 origin 一致。对于使用 AWS 凭证的新应用官方建议优先使用new OpenAI({ provider: bedrock(...) })配合openai/providers/bedrock/aws入口。README 中也有对应的总览与免依赖入口说明见 README.md。配置速查表配置项作用默认值 / 优先级region推导端点并参与 SigV4 签名AWS_REGION→AWS_DEFAULT_REGIONendpoint选择mantle或runtime端点家族mantle规范 AWS 主机名可自动推断baseURL覆盖 API 根地址AWS_BEDROCK_BASE_URL→ 按区域推导apiKey显式 Bearer 密钥null禁用环境回退AWS_BEARER_TOKEN_BEDROCKtokenProvider每次请求前解析新鲜 Bearer 令牌无accessKeyId/secretAccessKey/sessionToken静态 AWS 凭证SigV4无必须成对profileAWS 共享配置档SigV4默认凭证链credentialProvider每次请求含重试前解析的 AWS 凭证提供器无结语openai-node 的 Bedrock 集成把「端点解析、凭证解析、SigV4 签名、origin 校验、重定向禁用」全部收敛在bedrock(...)Provider 内部业务代码几乎零侵入。实践中最重要的三条纪律是按部署验证模型与接口的可用组合尤其是 Runtime 的 CRIS 配置档、/v1路由与流式支持、警惕过期AWS_BEARER_TOKEN_BEDROCK遮蔽 AWS 凭证用apiKey: null显式隔离、以及为自定义/代理主机显式指定endpoint以保证签名服务正确。按照本文的配置速查与示例脚本组合即可稳定接入 Mantle 或 Runtime 任一端点家族。【免费下载链接】openai-nodeOfficial JavaScript / TypeScript library for the OpenAI API项目地址: https://gitcode.com/GitHub_Trending/op/openai-node创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表