Hugging Face 联名 Baseten 上线 Inference Providers：模型路由 + Custom Key 双模式，Pi / OpenCode / Hermes Agents 已集成

笔名：小六 / 上海 / 1995 女 / 某互联网公司工程师

先说结论

2026-08-06，Hugging Face 官方博客发布《Baseten on Hugging Face Inference Providers 🔥》，作者署名 Alex Ker / Roland Crosby / Sid Shanker / Johan / Célina Hanouti / Simon Brandeis / Lucain Pouget / merve（八位 HF + Baseten 双边工程师）。这不是产品发布，是HF Hub 的”模型页面 → 直接调用第三方推理后端”路径从单一 provider 扩展到多 provider 路由：四件事对模型 API 选型 / Agent Harness 集成有立刻可用的事实点：

1. Baseten 成为 HF Inference Providers 的新成员——HF Hub 模型页面现在可以走 Baseten 跑推理（不再只走 HF 自己的 Inference Endpoints 或之前几家 provider）。Baseten 在这次首发里把”conversational + text-generation”任务类目上线，模型覆盖 Kimi K3、DeepSeek V4 Flash、GLM-5.2 等 open-weight LLM。
2. 用户可以按 provider 优先级排序——在 HF 用户账户设置里给已签约的 provider 配置自定义 API Key（否则走 HF 代扣），HF 模型页面的 widget + code snippet 会按用户配置的 provider 优先级路由请求。这意味着一次 SDK 调用，模型路由由用户偏好决定，不再被 HF 默认锁定。
3. 两种调用模式共存——Custom Key（请求直接打到 provider，用用户自己的 API Key 计费）+ Routed by HF（HF 代收 + 代扣，charges 走用户 HF 账户）。前者适合企业 / 已有 provider 合同的团队，后者适合想拿 HF 一站式发票的开发者。
4. Agent Harness 集成是这次最重的一项——HF Inference Providers 已经集成到主流 Agent Harness（Pi、OpenCode、Hermes Agents、OpenClaw 等）里——HF 的”模型页面 + provider 路由”被绑进 agent 的工具调用层，agent 选择模型 + provider 不需要硬编码，靠 HF SDK 解析模型元数据自动路由。

官方事实和我的判断分开：Baseten 上线 / provider 优先级排序 / Custom Key + Routed by HF 双模式 / Agent Harness 集成——这些是 HF 官方博客原文事实。**”这是 HF Hub 从’模型仓库’升级为’模型仓库 + 模型路由层’的关键事件”是我的判断，不是官方措辞。

发生了什么

按时间顺序把今天拿到的事实排一下：

• 2026-08-06（HF 官方博客发布日）：八位作者联名发文《Baseten on Hugging Face Inference Providers 🔥》，博客托管在 huggingface.co/blog/baseten。作者列表一半是 HF 团队（merve / Lucain Pouget / Simon Brandeis / Célina Hanouti），一半是 Baseten 团队（Alex Ker / Roland Crosby / Sid Shanker / Johan）——这是双边工程联名，不是 HF 单边公告。
• 同期：huggingface_hub >= 1.26.1 Python SDK + @huggingface/inference JavaScript SDK 已经包含 Baseten provider 适配器（不需要新装 provider 包，原生集成）。博客里给的代码示例用 huggingface_hub 调用 DeepSeek V4 Flash，自动路由到 Baseten。
• 首发任务覆盖：conversational + text-generation（注意：首发只有这两个任务类目——其他任务如 image / audio / embedding 暂未接入 Baseten）。

来源链接：

• 主体来源：Baseten on Hugging Face Inference Providers 🔥 — Hugging Face blog（2026-08-06，作者 Alex Ker + Roland Crosby + Sid Shanker + Johan + Célina Hanouti + Simon Brandeis + Lucain Pouget + merve，正文 ~6,800 字符）
• 取证来源：curl -x http://192.168.x.x:1091 -A "Mozilla/5.0" --max-time 30 https://huggingface.co/blog/baseten -o /tmp/baseten.html 一次拿到 191,997 字节完整 HTML，剥 nav 后正文 ~6,782 字符（HF blog 不在 CF 后、不限 IP、不限流，直连 / proxied 都能拿全文）

⚠️ 取证链路警告：本次取材是 HF blog 原文 → HTTP proxy 一次过拿到完整 HTML → python3 -c "import re..." 剥 nav 抽正文段落。读者若要验证，按主源 URL 直接 curl 即可，不依赖任何 CDN / 缓存。和 OpenAI 整站 CF 反爬需要走 Wayback 不同——HF blog 现在仍然是公开可读 + 可 curl 的状态。

技术细节

1. Baseten 成为新 Inference Provider：conversational + text-generation 两个任务首发

HF Inference Providers 是 HF Hub 2024 年开始建立的”模型页面 → 第三方推理后端”基础设施——之前已经有几家 provider 接入。这次 Baseten 是新加入的一家，首发任务覆盖：

1
2
3

✅ conversational（聊天补全）
✅ text-generation（文本补全）
❌ image / audio / embedding / 其他任务（暂未接入 Baseten）

Baseten 支持的模型范围（官方原文明确提到）：

• Kimi K3
• DeepSeek V4 Flash
• GLM-5.2
• 以及更多 open-weight LLM（博客里说”a wide variety of models with your preferred providers” + “many more”，完整模型清单在 huggingface.co/baseten）

对模型选型团队的立刻可用：如果团队正在用 Kimi K3 / DeepSeek V4 Flash / GLM-5.2 这几个 open-weight 模型做产品（这些是国内 + 海外都常见的 SOTA open-weight 选项），今天就能把推理后端从 HF Inference Endpoints / 自建 GPU 集群迁到 Baseten——只要在 HF 用户账户里配 Baseten 的 API Key，然后模型页面的 widget + code snippet 会自动按优先级路由。

注意首发任务覆盖限制：当前 Baseten 在 HF Inference Providers 体系里只能跑对话 + 文本补全——如果团队在做 image / audio / embedding 任务的推理，今天不能用 Baseten 这条路径。这是 Baseten 自己模型覆盖 + 任务覆盖共同决定的，HF 这边只是把”已签 provider 列表”暴露出来。

2. 用户配置 provider 优先级：HF 模型页面不再硬编码默认 provider

HF 用户账户设置里有两个动作直接影响模型路由：

1
2
3
4
5
6
7

动作 1: 为已签 provider 设置自定义 API Key（Custom Key）
  - 配了 Custom Key → 请求直接打到该 provider，用 Custom Key 计费
  - 没配 Custom Key → 请求走 HF（HF 代收 + 代扣，charges 进用户 HF 账户）

动作 2: 调整 provider 优先级顺序
  - "Order providers by preference" — 这个顺序决定 widget + code snippet 的路由
  - 优先级最高的 provider 在该模型兼容的 provider 列表里被首选

对调用方的含义：

• 一次 SDK 调用 = 一次模型路由：调用方不需要在代码里写”用哪个 provider”，HF SDK 解析模型元数据 + 用户配置，自动按优先级路由到合适的 provider
• provider 选择权下放给用户：企业可以为自己的 HF 账户配好”成本最优 provider 优先级”，员工代码不需要改
• 同一份代码在不同账户下走不同 provider——这是 HF “hub + 路由层” 的核心设计：模型代码和 provider 解耦

1
2
3
4
5
6
7
8
9
10
11
12

# huggingface_hub >= 1.26.1
from huggingface_hub import InferenceClient

client = InferenceClient(
    model="deepseek-ai/DeepSeek-V4-Flash",  # 模型 ID
    provider="baseten",  # 显式指定 provider（或省略 → 按用户优先级自动选）
)

response = client.chat.completions.create(
    messages=[{"role": "user", "content": "..."}],
    max_tokens=512,
)

1
2
3
4
5
6
7
8
9

// @huggingface/inference (JavaScript)
import { InferenceClient } from "@huggingface/inference";

const client = new InferenceClient(process.env.HF_TOKEN);
const response = await client.chatCompletion({
  model: "deepseek-ai/DeepSeek-V4-Flash",
  messages: [{ role: "user", content: "..." }],
  provider: "baseten",  // 可省略
});

对 Agent Harness 的含义：agent 工具调用层里”调哪个模型 + 哪个 provider”这两个问题第一次可以在不写死代码的情况下解决——agent 拿到 model ID + HF SDK，自动按用户账户的 provider 优先级路由。这是后面 §4 的核心。

3. 两种计费模式：Custom Key vs Routed by HF

1
2
3
4
5
6
7
8
9
10
11

Custom Key:
  - 请求直接打到 provider
  - 用用户自己 provider 账户的 API Key 鉴权
  - 计费走 provider 的发票 / 用量
  - 适用: 企业 / 团队已和 Baseten 有合同

Routed by HF:
  - 请求经过 HF 代理层
  - 用 HF Token 鉴权
  - 计费走 HF 账户（HF 给用户开发票）
  - 适用: 个人开发者 / 想拿 HF 一站式发票的团队

对 Agent Harness 集成的含义：

• 走 Custom Key 路径 → provider 直接收到鉴权请求，HF 中间层开销最小（只做路由解析，不做鉴权）
• 走 Routed by HF 路径 → HF 中间层做鉴权 + 代扣，每个请求都过一次 HF API gateway

关键取舍：

• 延迟敏感场景（实时语音 / 实时聊天）→ Custom Key 更合适（少一跳）
• 用量分散 + 不想维护多 provider 合同 → Routed by HF 更合适（HF 一张发票）

4. Agent Harness 集成：HF Inference Providers 在 Pi / OpenCode / Hermes Agents / OpenClaw 里被原生支持

这是这次公告里最被低估的一项。原文：

“Hugging Face Inference Providers are integrated in most Agent Harnesses — including Pi, OpenCode, Hermes Agents, OpenClaw, and more.”

对 Agent / 工具调用层的事实点：

• HF Inference Providers 在主流 agent harness 里已经被原生集成——agent 不需要写代码就能用上多 provider 路由
• Agent 拿到一个模型 ID + HF SDK 后，自动按用户账户的 provider 优先级路由——不需要 hard-code provider 名字
• provider 切换不需要改 agent 代码——企业改一次账户设置，agent 自动跟

对 Agent 团队的具体场景：

• 多团队协作：每个团队的 HF 账户配置自己的 provider 优先级（成本 / SLA 偏好不同），agent 代码一套，多团队共用
• cost routing：低成本模型任务路由到便宜 provider；高复杂度任务路由到强 provider——agent 拿到模型 ID 时按复杂度模型路由
• A/B 测 provider：用户可以临时调整 provider 优先级，agent 自动跟——A/B 测不需要改 agent 代码

为什么 Agent Harness 集成是这次最重的一项：HF Inference Providers 的”模型 + provider 解耦”在 Agent Harness 层落地，意味着agent 不再被绑死在某一个 provider 的 SDK 上。以前 agent 集成 Kimi K3 要么写 Kimi SDK、要么自建 HTTP；现在 agent 只需要写 HuggingFace SDK，Kimi K3 / DeepSeek V4 Flash / GLM-5.2 等都可以走同一套 SDK 自动路由。

5. SDK 集成现状：Python huggingface_hub >= 1.26.1 + JS @huggingface/inference

1
2
3
4
5
6
7
8
9

Python SDK: huggingface_hub >= 1.26.1
  - InferenceClient 类
  - chat.completions.create() 方法
  - provider 参数（可省略）

JS SDK: @huggingface/inference
  - InferenceClient 类
  - chatCompletion() 方法
  - provider 参数（可省略）

对 SDK 升级的工程含义：

• 已经是 huggingface_hub 用户的团队 → 升级 huggingface_hub 到 ≥ 1.26.1 就拿到 Baseten provider 支持
• 已经是 @huggingface/inference 用户的团队 → 升级 JS SDK 拿到
• 不需要新装 provider 包——provider 适配器在 SDK 内部，升级 SDK 就启用 provider

HF 的设计哲学：所有 provider 都通过同一个 SDK 暴露，用户不需要为每个 provider 装一个包——这是”hub” 模型的核心价值。和 OpenAI 的”一个 SDK 一个 provider”思路相反——HF 这边是”一个 SDK 一堆 provider”。

6. 当前不支持：image / audio / embedding 任务

博客明确说：

“Support for additional tasks will roll out soon!”

也就是说——Baseten 这次首发只覆盖 conversational + text-generation 两个任务。如果团队今天的 agent 推理需求是：

• ✅ chat / 文本补全 → 今天能迁
• ❌ image generation → 暂不能迁（任务不在 Baseten HF 接入范围）
• ❌ audio / TTS → 暂不能迁
• ❌ embedding / retrieval → 暂不能迁

对 agent 团队的含义：如果团队今天的工具调用只依赖 chat / text-generation 模型，今天就能把 Baseten 加入备选 provider 列表；如果 agent 还依赖 image / audio / embedding，今天不要急着迁——等 Baseten HF 接入任务范围扩展。

对 Agent / 工程的影响

立刻能用的场景

1. 正在用 Kimi K3 / DeepSeek V4 Flash / GLM-5.2 做产品 + 不想维护自建 GPU 集群的团队 → 把推理后端从自建迁到 Baseten，HF 一站式接入，不需要写 Baseten SDK。配 Custom Key 后走 Baseten 直接扣费，或者走 Routed by HF 拿 HF 发票。
2. agent harness 想支持多 provider + 不硬编码 provider 名字 → 直接接 huggingface_hub 的 InferenceClient，provider 选择由用户账户配置决定。Pi / OpenCode / Hermes Agents / OpenClaw 都已原生集成，agent 代码不需要改。
3. 多团队协作 + 每个团队成本 / SLA 偏好不同 → 每个团队用独立 HF 账户 + 自己的 provider 优先级，agent 代码一套。多团队共用同一份 agent 代码。
4. 个人开发者 / side project / 教育场景 → 走 Routed by HF 路径，HF Token + HF 一张发票搞定，不需要和 Baseten 单独签合同。
5. 延迟敏感场景（实时语音 / 实时聊天） → Custom Key 路径，少一跳 HF 代理，延迟更低。
6. SDK 升级不破坏现有代码 → 升级到 huggingface_hub >= 1.26.1 是后向兼容的，不传 provider 参数也能按用户优先级路由——已有代码升级 SDK 就生效。

需要进一步验证

1. Baseten 推理的真实延迟 + 吞吐量 — 博客没有给具体数字（首 token 延迟 / 每 token 生成延迟 / 每秒请求数）。做实时 / 高并发 agent 之前要自己 A/B 测一下 Baseten vs HF Inference Endpoints vs 自建集群。
2. Custom Key 路径的鉴权安全性 — 用户把 Baseten API Key 存进 HF 账户，HF SDK 在转发请求时带这个 Key。HF 这边的 Key 存储加密机制 + Key 撤销链路需要实测。
3. provider 优先级路由的实际生效逻辑 — 博客说”Order providers by preference”，没明示优先级匹配的细节——是 model-compatible provider 列表里按用户顺序找第一个？还是 round-robin？还是按 cost + SLA 选？实测前不知道。
4. 任务扩展时间表 — Baseten 接入 image / audio / embedding 的具体时间，博客说”soon”但没给日期。生产 plan 之前要 HF 官方查 roadmap。
5. Baseten 的地理覆盖 — 博客没提 Baseten 数据中心分布。延迟敏感 + 数据合规场景下要确认 Baseten 数据中心是否在预期区域。
6. HF 中间层的可用性 SLA — 走 Routed by HF 路径时 HF 是中间代理，HF API gateway 挂了整条链路就挂。生产 plan 前要查 HF API gateway SLA。

短期不要碰

1. 不要把 image / audio / embedding 任务迁到 Baseten — 当前任务覆盖只有 chat + text-generation，其他任务迁过去会直接 404。
2. 不要把 Baseten 当成”万能 provider” — Baseten 在 HF 体系里是新增的一家，不是唯一的。provider 优先级应当至少配 2-3 家，避免单 provider 故障 = 整条路由断。
3. 不要忽略 Custom Key 路径的密钥管理 — 用户 Baseten API Key 存 HF 账户，HF 内部加密 + 审计 + 撤销链路不明确前，不要把企业核心 API Key 存进去。
4. 不要把 provider 优先级当成”成本最低的永远第一” — 有些模型只在特定 provider 上有（比如某个 fine-tuned 版本只在 Baseten）。provider 优先级应当按”模型可用性 + 成本 + SLA”三维评估，不是单纯按价格排序。
5. 不要照搬 HF SDK 到生产 agent — huggingface_hub >= 1.26.1 是 SDK 最低版本要求，生产前要 lock 具体小版本（比如 1.26.3），不要让 SDK 自动升级到 breaking 版本。

我的判断

1. 这是 HF Hub 从”模型仓库”升级为”模型仓库 + 模型路由层”的关键事件。HF Hub 的核心定位从”存模型 + 让用户下载”扩展到”存模型 + 路由到合适的 provider + 计费透明”——Hub 变成了一个”模型 + 推理”的统一接入层。这是 HF 和 OpenAI / Anthropic 在生态层面最大的差异：HF 不直接做闭源模型（让用户选 provider），OpenAI / Anthropic 是”我的模型走我的 SDK”。**对企业 agent 团队来说，HF 这条路径意味着”不被单一 provider 锁定”**——这是企业采购最看重的能力。

2. Agent Harness 集成是这次最被低估的一项。”Inference Providers are integrated in most Agent Harnesses — including Pi, OpenCode, Hermes Agents, OpenClaw, and more”——这一行让 HF 路径在 agent 生态里变得事实标准。Agent Harness 现在不需要写多 provider 集成代码，一套 HF SDK 拿所有 provider。Pi / OpenCode / Hermes Agents / OpenClaw 这些 harness 的作者主动集成 HF Inference Providers，意味着 agent 工具调用层的”多 provider 路由”成为行业共识。

3. 首发只覆盖 chat + text-generation 是有意为之。Baseten 在 HF 体系首发两个最高频任务，先验证 + 跑通 + 用户教育，再扩展到 image / audio / embedding。这是产品发布的渐进路径，不是技术限制。对 chat-heavy agent（客服 / 代码生成 / 文本总结）来说，今天就能用——对 image-heavy agent（视觉 / 多模态）来说，再等几个月。

4. Custom Key + Routed by HF 双模式是 HF “hub 模型” 在计费层的落地。HF 不做模型（不抢 provider 生意），但 HF 做”鉴权 + 计费 + 一站式发票”——用户在 HF 一处签合同，HF 后端调度多家 provider。对企业财务团队来说，这是关键能力——一家供应商、一张发票、多个底层 provider，财务流程比”和 3 家 provider 各签一次合同”简单一个量级。

5. 和 OpenAI Codex Cloud / Anthropic cloud agents 比，HF Inference Providers 是”中立 provider 路由”，不是”我的模型走我的 SDK”。OpenAI Codex Cloud 把 GPT-5.x 模型集成到 IDE，但不暴露多 provider 路由——你想用 Kimi K3 就走不了 OpenAI Codex Cloud。Anthropic cloud agents 同理，只走 Claude 系列。HF Inference Providers 是当前公开生态里唯一一个”中立 provider 路由”——做企业 agent 平台，HF 是当前唯一可选的中立方案。

6. Baseten 的 Open-weight 模型覆盖 + HF 中立路线 + Agent Harness 集成 = 三件套。单独看 Baseten 上 HF 是一件小事；放在”HF 中立 provider 路由 + Baseten 补全 Open-weight 模型覆盖 + Agent Harness 集成”三件套里看，这是企业 agent 平台从”单 provider 绑定”过渡到”多 provider 路由”的关键事件。对正在评估 agent 平台路线的企业 CTO，今天开始评估 HF + Baseten 路径比”再等一家新闭源模型”更重要——路由层一旦上生产，比”再发一个新模型”的商业价值高一个量级。

Q1：来源/出处？

A：主体来源是 Baseten on Hugging Face Inference Providers 🔥 — Hugging Face blog（2026-08-06，作者 Alex Ker + Roland Crosby + Sid Shanker + Johan + Célina Hanouti + Simon Brandeis + Lucain Pouget + merve，HF + Baseten 双边工程联名），正文 ~6,782 字符；HF blog 不在 CF 后，curl -x http://192.168.x.x:1091 -A "Mozilla/5.0" --max-time 30 一次过拿到 191,997 字节 HTML。

Q2：能不能复现 / 怎么验证？

A：分四步：(1) 升级 huggingface_hub 到 ≥ 1.26.1（Python）或 @huggingface/inference 到最新版（JavaScript）；(2) 在 HF 用户账户设置里给 Baseten 配 Custom Key（或者走 Routed by HF 路径用 HF Token）；(3) 调一次 InferenceClient(model="deepseek-ai/DeepSeek-V4-Flash").chat.completions.create(...)，验证请求被自动路由到 Baseten；(4) 调整 provider 优先级顺序（HF 账户设置），再调一次，验证 widget + code snippet 路由结果按新顺序变化。

Q3：适用边界？

A：本文只覆盖 HF 官方博客公开内容 + 我的分析。Baseten 推理真实延迟 / Custom Key 鉴权安全细节 / provider 优先级路由的实际匹配逻辑 / 任务扩展具体时间表 / HF API gateway SLA — 这五个边界博客都没给，需要实测 + 查官方 roadmap。

Q4：和其他类似项目对比？

A：和 OpenAI Codex Cloud 比，HF Inference Providers 是中立 provider 路由，OpenAI Codex Cloud 是单 provider 绑定（GPT-5.x 走 OpenAI SDK）。和 Anthropic cloud agents 比，HF 是中立，Anthropic 是 Claude 单一 provider。和 Google Vertex AI Model Garden 比，Vertex AI 也是多 provider 路由，但走 GCP 生态；HF Inference Providers 走 HF Hub + 多 provider（不绑定任何云厂商）——HF 的中立性是当前公开生态里最强的。

Q5：风险/坑？

A：(1) 首发任务覆盖只有 chat + text-generation，image / audio / embedding 任务今天不能迁。(2) Custom Key 路径把 API Key 存 HF 账户，HF 内部加密 + 审计 + 撤销链路不明确前不要把企业核心 Key 存进去。(3) provider 优先级排序没说实际路由逻辑（按 model-compatible list 顺序？还是 cost 优先？），实测前不要假设。(4) Baseten 地理覆盖没提，数据合规 + 延迟敏感场景要确认数据中心分布。(5) 走 Routed by HF 路径时 HF 是中间代理，HF API gateway 挂了整条链路就挂——生产 plan 前要查 HF SLA。

参考资料（按权威性排序）：

1. Baseten on Hugging Face Inference Providers 🔥 — Hugging Face blog（2026-08-06，主体来源——Baseten 上线 HF Inference Providers / conversational + text-generation 首发 / 用户配 provider 优先级 / Custom Key + Routed by HF 双模式 / Agent Harness 集成 / huggingface_hub ≥ 1.26.1 / Kimi K3 + DeepSeek V4 Flash + GLM-5.2 模型覆盖）
2. Hugging Face Inference Providers — Hugging Face Docs（API 文档主入口 — InferenceClient 类 / provider 参数 / Custom Key vs Routed by HF 鉴权细节 / huggingface_hub 版本要求）
3. Baseten — Hugging Face Hub（完整模型清单 — 当前 Baseten 在 HF Inference Providers 接入的全部模型，包括 Kimi K3 / DeepSeek V4 Flash / GLM-5.2 等 open-weight LLM）

字数自检：≥1500 个中文字符（不含 frontmatter）
隐私自检：未写入个人姓名、用户相关代号、内部网络细节、商业秘密、未脱敏的内部身份字段；保留的 HF / Baseten 官方作者署名是 HF blog 公开字段（Alex Ker / Roland Crosby / Sid Shanker / Johan / Célina Hanouti / Simon Brandeis / Lucain Pouget / merve），模型名 Kimi K3 / DeepSeek V4 Flash / GLM-5.2 是公开模型名
封面 seed：2026-08-07-hugging-face-baseten-inference-providers-routing（唯一）
coverWidth/Height：1600 / 900
categories：ai_tech