unified

用 APIShare 统一接入多家免费 API

📅 2026-08-19 00:00:00 +0000 UTC 👁 6212 浏览 📂 unified

⚠️ 待更新·2026-08-29核验 · 更新时间待核验 · 本文信息可能已过期，请以官方文档为准更新时间：2026-08-29 · 核验状态：待更新 · 官方溯源待补

背景

免费 API 散落在 OpenRouter、Groq、DeepSeek、Gemini、Hugging Face 等十余家平台,各自有 base_url、Key 格式、限流规则与模型命名习惯。让客户端各自接,意味着每个项目都要重写一遍接入逻辑。APIShare 作为统一网关,把所有免费端点拉到自己的 /v1 下,客户端只需要一个 APIShare token 就能切换任意模型。

接入流程

在 APIShare 控制台登记各家 Provider,填入 base_url 与 api_key。
选择模型映射表:把 openrouter/deepseek-r1:free、groq/llama-3.3-70b 等真实模型 ID 暴露为统一别名。
网关生成一个用户级 APISHARE_TOKEN,客户端用这个 token 调 /v1/chat/completions。
网关根据请求里的 model 字段查路由表,转发到对应上游,自动处理鉴权、重试、限流。

代码示例

from openai import OpenAI

# 客户端只看到 APIShare 一个端点,一个 token
client = OpenAI(
    base_url="https://api.apishare.dev/v1",
    api_key="apshare-xxxx",
)

# 同一段代码,切到任何免费模型都只是改 model 字段
for model in ["groq/llama-3.3-70b-versatile",
              "openrouter/deepseek-chat:free",
              "gemini/gemini-2.0-flash"]:
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": "用一句话解释向量数据库"}],
    )
    print(model, "->", resp.choices[0].message.content[:40])

别名设计

统一接入的真正难点不在转发,而在别名稳定性。模型上游一个月改名三次(如 DeepSeek 的 deepseek-coder → deepseek-coder-v2 → deepseek-v3-coder),如果客户端代码直接引用真实 ID,每次改名都要改代码。APIShare 的别名层把真实 ID 藏到内部映射表,对外暴露如 apishare/code-large 这样的稳定别名。改名时只动映射表,客户端无感。别名设计要领:按能力(code-large、chat-fast、reasoning-deep)而非厂商命名,避免将上游变动传递给客户端。

权衡与最佳实践

延迟换便利:多一跳网关换来密钥集中、限流统一、统计可视,几乎总是划算的。
别名要稳定:模型上游常改名,APIShare 的别名层让客户端代码不随上游变动而崩。
配额可视化:在控制台看每个 Provider 的剩余免费额度,据此调路由权重。
导出 schema:对外暴露统一的 OpenAPI schema,客户端代码生成器(SDK、type 定义)可以一键产出。
冷启动数据:新 Provider 接入时先走 5% 灰度,观察成功率再逐步放量,避免"新 Provider 接入即事故"。

把 APIShare 当成"模型超市的收银台":一次接入,任何免费或付费模型都能扫一遍码就走。

⚠️ Pending Update · 2026-08-29 Verification · Content may be outdated, please refer to official docs Updated: 2026-08-29 · Status: Pending Verification

Background

Free APIs are scattered across OpenRouter, Groq, DeepSeek, Gemini, Hugging Face, and a dozen other platforms, each with its own base_url, key format, rate-limit rules, and naming conventions. Letting each client integrate them directly means re-implementing the same plumbing in every project. APIShare acts as the unified gateway: it pulls every free endpoint under its own /v1, so clients manage only a single APIShare token while still switching between any model.

Onboarding Flow

Register each provider in the APIShare console, supplying base_url and api_key.
Configure a model alias map: expose openrouter/deepseek-r1:free, groq/llama-3.3-70b, and similar real model IDs under unified aliases.
The gateway issues a user-level APISHARE_TOKEN; clients call /v1/chat/completions with it.
The gateway looks up the routing table by the request's model field, forwards to the right upstream, and handles auth, retries, and rate limits automatically.

Code Example

from openai import OpenAI

# The client sees only APIShare: one endpoint, one token
client = OpenAI(
    base_url="https://api.apishare.dev/v1",
    api_key="apshare-xxxx",
)

# The same code switches between any free model by changing only the model field
for model in ["groq/llama-3.3-70b-versatile",
              "openrouter/deepseek-chat:free",
              "gemini/gemini-2.0-flash"]:
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": "Explain a vector DB in one sentence."}],
    )
    print(model, "->", resp.choices[0].message.content[:40])

Alias Design

The hard part of unified access is not forwarding but alias stability. Upstream models rename themselves three times in a month (e.g. DeepSeek's deepseek-coder → deepseek-coder-v2 → deepseek-v3-coder); if client code references the real ID directly, every rename breaks it. APIShare's alias layer hides the real ID behind an internal mapping table and exposes stable aliases like apishare/code-large. Renames touch only the mapping table — clients never notice. The naming rule: name aliases by capability (code-large, chat-fast, reasoning-deep) rather than by upstream branding, so upstream churn never propagates to clients.

Trade-offs and Best Practices

Latency for convenience: an extra hop buys centralized keys, unified rate limits, and visible statistics; the trade is almost always worth it.
Stable aliases: upstream providers rename models often. APIShare's alias layer insulates client code from upstream churn.
Quota visibility: the console shows each provider's remaining free quota, letting you tune routing weights intelligently.
Export a schema: expose a unified OpenAPI spec so client-side code generators (SDKs, type definitions) produce bindings in one shot.
Cold-start data: when onboarding a new provider, route 5% gray traffic first, observe success rate, then ramp up — never "integrate-then-incident."

Treat APIShare as the "checkout counter of the model supermarket": integrate once, and any free or paid model can be scanned and dispatched on demand.