Fireworks AI API 怎么接入？双兼容端点与模型 ID 写法
Fireworks AI 的 base_url 是 https://api.fireworks.ai/inference/v1，Bearer 鉴权。它比多数同类平台多一件事：官方文档说明它同时提供 OpenAI 兼容端点和 Anthropic SDK 兼容端点——这意味着不管你现有代码用的是哪一边的 SDK，都有一条低成本的迁移路径。
本文的接口地址、鉴权方式、兼容性与模型 ID 形式均以 Fireworks 官方文档 docs.fireworks.ai 为准（核对于 2026-08-06）。价格、免费额度与完整模型清单不在本文范围，请以官方控制台当次显示为准。
接入三步
第一步：拿密钥。 控制台注册后生成 API 密钥。官方示例用环境变量 FIREWORKS_API_KEY 传递，照做即可。
第二步：配 base_url。 官方文档给出的地址是：
https://api.fireworks.ai/inference/v1
注意这个地址比多数平台多一段 inference，是最容易抄漏的地方。抄漏的表现通常是 404，而不是鉴权错误——遇到 404 先回头核对地址，别急着怀疑密钥。
第三步：写鉴权头。 标准 Bearer 形式，把密钥作为 token 放进 Authorization 头；用 SDK 的话传给 api_key 参数即可。
双兼容端点意味着什么
官方文档明确说明 Fireworks 提供 OpenAI 兼容端点，同时也提供与 Anthropic SDK 兼容的端点。对工程上的实际意义有两条：
一是迁移路径更宽。 你的现有代码无论是围绕 OpenAI SDK 写的还是围绕 Anthropic SDK 写的，都能以较小改动指过来，不用重写调用层。
二是多模型路由更容易。 如果你的系统里同时有走 OpenAI 协议和走 Anthropic 协议的链路，接一家就能覆盖两边，减少了封装层要处理的协议差异。路由层的设计见 Agent 的多模型路由策略。
但要记住一条通则：兼容的是协议，不是能力。工具调用的严格程度、结构化输出的支持、错误响应结构这些仍可能有差异，迁移时要按清单实测，见 OpenAI 兼容端点是什么。
模型 ID 是三段式的
Fireworks 的模型标识符形式比较特别，官方示例是：
accounts/fireworks/models/deepseek-v3p1
这是一个带账户路径的三段式标识符，不是单纯的模型名。两个注意点：
一、必须逐字照抄官方文档里的标识符。 自己按印象拼「deepseek-v3.1」这类写法会失败——注意示例里版本号的写法本身就和常见记法不同。
二、路径里的 accounts 段是有含义的。 平台提供的公共模型走 accounts/fireworks/...，如果你有自己部署的模型，路径会不同。填之前确认你调的是哪一类。
部署形态：Serverless 与专用 GPU
官方文档提到 Fireworks 支持多种部署选项，包括 Serverless 与 Dedicated GPU 等。这一点在选型时值得单独考虑：
Serverless 按调用付费、无需预留资源，适合流量不稳定、还在验证阶段的项目。
专用 GPU 适合流量稳定且体量较大、或者对延迟稳定性有要求的场景——独占资源不受邻居影响，但要为闲置时间付费。
两者的选择本质上是一道算术题：把你的日均用量和峰值分布代进月成本估算器，再和专用资源的固定成本比。流量越平稳、利用率越高，专用越划算。
功能面：先确认再依赖
官方文档提到平台支持流式响应、函数调用、结构化输出、推理等能力。这些是接入后要逐项实测的重点，尤其是：
结构化输出的严格程度决定了你的解析失败率。用你真实的 schema 跑一批脏样本测一次成功率，方法见结构化输出解析失败怎么办。
函数调用的行为（参数遵守度、并行调用支持）是 Agent 类应用的命门，务必用真实工具定义测。
流式的事件格式细节要用你自己的解析代码跑一遍，别只看能不能连上——中断处理见流式输出中断了怎么办。
接入后的四项验证
效果：二三十条真实样本盲评，别看榜单。 速度：首 token 延迟与输出速率分开测，见大模型 API 的速度怎么测。 成本：用 token 计算器量单次请求，代进月成本估算器，单价去官方定价页当次核。 容量：拿到 RPM/TPM 后用并发与限流计算器倒推并发配置。
四项都过了，这家才算真正进入你的候选名单。
Serverless 还是专用，怎么算这笔账
这是接入之后第一个需要拍板的架构问题，算法其实很直白。
Serverless 的成本 = 实际用量 × 单价，随流量线性变化，闲置不花钱。适合流量波动大、还在验证阶段、或者日均用量不高的项目。
专用资源的成本 = 固定费用 × 时长，和你用不用没关系。它划算的前提是利用率足够高——如果你的流量集中在每天几个小时，其余时间资源闲置，那实际单位成本会被闲置时段稀释得很难看。
判断方法：把你的日均用量和峰值分布代进月成本估算器，算出 Serverless 的月成本，再和专用资源的固定成本比。利用率越高、流量越平稳，专用越有优势；反过来就留在 Serverless。
还有一个非成本因素值得考虑：延迟稳定性。专用资源不受邻居影响，P95 延迟通常更稳。如果你的产品对延迟有硬性要求，这一点可能比省钱更重要，测法见大模型 API 的速度怎么测。
接入后先把这三个数记进日志
无论用哪家，上线第一天就该记的三个字段：
模型标识符——出问题时能立刻回答「当时走的是哪个模型」。多模型路由的系统里，这一条不记等于放弃排查能力。
输入 / 输出 token 数（从响应的 usage 字段取）——成本归因、缓存命中率、异常检测全靠它。
结束原因与错误码——区分正常完成、达到 max_tokens、限流、超时。混在一起统计会掩盖真实问题。
有了这三样，后续所有优化（缓存、分流、限流调优）才有数据支撑，见 API 成本监控。
三个高频问题
问：base_url 抄错最常见的表现是什么？ 404。因为地址里多一段 inference，漏了就会打到不存在的路径上。遇到 404 先核地址，别先怀疑密钥。
问：Anthropic 兼容端点是不是意味着能用 Claude？ 不是。兼容的是协议——你可以用 Anthropic 风格的 SDK 去调 Fireworks 上托管的模型，能调到哪些模型以官方模型清单为准。
问：结构化输出能直接依赖吗？ 先用你真实的 schema 跑一批脏样本测一次成功率再依赖，见结构化输出解析失败怎么办。
数据来源说明
本文的 base_url（https://api.fireworks.ai/inference/v1）、鉴权方式（Bearer token，环境变量 FIREWORKS_API_KEY）、OpenAI 兼容端点与 Anthropic SDK 兼容端点的说明、示例模型标识符（accounts/fireworks/models/deepseek-v3p1）、部署形态（Serverless / Dedicated GPU 等）与功能清单（流式、函数调用、结构化输出、推理）均来自 Fireworks 官方文档 docs.fireworks.ai，核对日期 2026-08-06。
未核实、故本文不写的内容：具体定价、免费额度、完整模型清单、各模型上下文长度与速率限制。以官方文档与控制台当次为准。
本文只写核到的部分。核不到的宁可留白——尤其是价格和额度这类高频变动项，任何第三方转述都可能在你读到时已经过期。
一句话记住
地址多一段 inference、模型 ID 是三段式——这两个细节是 Fireworks 接入时最容易踩的坑，且报错都不是「看起来该有的那个错」。照官方文档逐字抄，剩下的时间留给效果实测和 Serverless / 专用的成本对比。