12 KiB
12 KiB
Subapi 技术能力分析与用户供应场景补充
本文档回答关于 subapi 技术深度、供应商能力、风险评估，以及补充"用户分享LLM供应"的详细设计。
1. Subapi 技术深度评估
1.1 技术了解程度：足够深入
| 维度 | 评估 | 证据 |
|---|---|---|
| 协议支持 | ⭐⭐⭐⭐⭐ | OpenAI/Anthropic/Gemini 完整兼容 |
| 契约设计 | ⭐⭐⭐⭐⭐ | 已有详细的 Connector 契约文档 |
| 错误处理 | ⭐⭐⭐⭐ | 三类错误归一，重试机制完善 |
| 流式支持 | ⭐⭐⭐⭐ | SSE/WebSocket 均已实现 |
1.2 已掌握的技术细节
- Connector 契约：
subapi_connector_contract_v1_2026-03-17.md明确定义了请求/响应/错误归一模型 - 认证机制：支持 Bearer Token、x-api-key、x-goog-api-key
- 版本治理：生产环境锁定精确版本，周级升级窗口
- 风险点：已识别 2 个 P0 问题（内网隔离、query key 边界）
2. Subapi 当前供应商能力
2.1 已支持的供应商
| 供应商 | 模型支持 | 认证方式 | 状态 |
|---|---|---|---|
| OpenAI | GPT-3.5/4/5 全系列 | API Key | ✅ 稳定 |
| Anthropic | Claude 2/3/4 全系列 | API Key / OAuth | ✅ 稳定 |
| Google Gemini | Gemini 2/3 全系列 | API Key / OAuth | ✅ 稳定 |
| Antigravity | Claude 4.5+ / Gemini 2.5+ | OAuth | ✅ 稳定 |
| Sora | 图片/视频生成 | API Key | ✅ 稳定 |
| AWS Bedrock | Claude/Titan 等 | AWS 凭证 | ✅ 稳定 |
| 百度文心 | ERNIE 系列 | API Key | ✅ |
| 讯飞星火 | Spark 系列 | API Key | ✅ |
| 腾讯混元 | Hunyuan 系列 | API Key | ✅ |
| Perplexity | Pro/Labs | API Key | ✅ |
2.2 供应商能力总结
- 总计：10+ 供应商，100+ 模型
- 海外主力：OpenAI、Anthropic、Gemini（支持 OAuth 授权）
- 国内支持：百度、讯飞、腾讯（API Key 方式）
- ⚠️ 注意：subapi 不支持用户自己挂载账号给平台，只支持平台统一管理上游账号
3. 关键发现：Subapi 不支持"用户分享LLM供应"
3.1 Subapi 现有模式
平台方（管理员）→ 添加上游账号 → 分发给用户使用
- 平台方统一管理所有 LLM 供应商账号
- 用户使用平台生成的 API Key 调用
- 优点：统一管理、计费简单
- 缺点：无法实现"用户分享多余配额"
3.2 用户想要的模式
用户A（供应方）→ 挂载自己账号的剩余配额 → 平台售卖 → 用户B（需求方）使用
- 任何用户可以把自己的 LLM 账号/配额挂载到平台
- 平台验证账号有效性后接受供应
- 平台将配额卖给其他用户
- 供应方获得收益分成
3.3 结论
Subapi 没有实现"用户分享LLM供应"功能！
这意味着用户的独特场景需要在我方平台层实现，而不是依赖 subapi。
4. 风险评估
4.1 Subapi 集成风险
| 风险项 | 级别 | 缓解措施 |
|---|---|---|
| 内网隔离缺失 | P0 | 新增 SEC-007/008 任务 |
| query key 边界歧义 | P0 | 新增 SEC-009 强制测试 |
| 接管率口径冲突 | P1 | COMP-007 统一 canonical |
| CN 平台硬编码 | P1 | COMP-008 配置表驱动 |
4.2 商业风险
| 风险项 | 级别 | 说明 |
|---|---|---|
| 用户供应功能需自研 | 高 | 供应侧功能不在 subapi 范围内 |
| ToS 合规风险 | 高 | 需严格审查各供应商条款 |
| 供应商账号封禁 | 中 | 需多账号冗余 + 备用通道 |
5. 用户分享LLM供应 - 完整设计补充
5.1 功能定位
这是平台独有功能，不在 subapi 范围内，需要我方平台层实现。
5.2 业务流程
┌─────────────────────────────────────────────────────────────────────────┐
│ 用户供应LLM配额业务流程 │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ 供应方（用户A） 平台 需求方（用户B） │
│ │ │ │ │
│ ▼ │ │ │
│ 1. 注册/登录 │ │ │
│ │ │ │ │
│ ▼ │ │ │
│ 2. 挂载LLM账号 │ │ │
│ (API Key/OAuth) │ │ │
│ │ │ │ │
│ ▼ │ │ │
│ 3. 平台验证账号 │ │ │
│ (有效性/额度/合规) │ │ │
│ │ │ │ │
│ ▼ │ │ │
│ 4. 设置供给配额 │ │ │
│ (挂载量/售价) │ │ │
│ │ │ │ │
│ ▼ │ │ │
│ 5. 供应上线 │ │ │
│ │───────────────────────┼───────────────────────────┤ │
│ │ │ │ │
│ │ ▼ │ │
│ │ 6. 平台展示 │ │
│ │ (套餐列表) │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ │ 7. 购买套餐 │
│ │ │ │ │
│ │ ▼ │ │
│ │ │ 8. 获取平台调用凭证 │
│ │ │ │ │
│ │ ▼ │ │
│ │ │ 9. 调用LLM服务 │
│ │ │◀──────────────────────────┘ │
│ │ │ │
│ ▼ ▼ │
│ 10. 收益到账 11. 平台抽成 │
│ │
└─────────────────────────────────────────────────────────────────────────┘
5.3 核心模块设计
5.3.1 账号挂载模块
| 功能 | 说明 |
|---|---|
| 挂载方式 | API Key 手动输入 / OAuth 授权 |
| 支持的供应商 | 与平台支持列表一致 |
| 账号验证 | 调用供应商 API 验证有效性 |
| 额度获取 | 调用供应商 API 获取剩余额度 |
| 合规检查 | 检查是否违反供应商 ToS |
5.3.2 套餐发布模块
| 功能 | 说明 |
|---|---|
| 最小挂载量 | 平台设定最低额度（如 $10） |
| 最大挂载量 | 根据账号类型和历史表现设定 |
| 定价规则 | 供应方设置售价，平台设定最低价 |
| 有效期 | 可选择日/月/永久 |
| 状态管理 | 上架/下架/售罄/过期 |
5.3.3 调度与计费模块
| 功能 | 说明 |
|---|---|
| 请求调度 | 优先用低价/空闲供应，保障成功率 |
| 额度扣减 | 实时扣减供应方额度 |
| 账单生成 | 记录每笔交易的 token 量和费用 |
| 收益计算 | 供应方收益 = 售价 × 消耗量 × 60% |
5.3.4 风控模块
| 功能 | 说明 |
|---|---|
| 账号健康 | 监控账号可用性、额度消耗异常 |
| 欺诈检测 | 检测恶意套现、虚假额度 |
| ToS 合规 | 检测供应商禁止的调用模式 |
| 保证金 | 供应方需缴纳保证金（防违约） |
5.4 数据模型
-- 供应方账号表
CREATE TABLE supply_accounts (
id BIGINT PRIMARY KEY,
user_id BIGINT NOT NULL,
platform VARCHAR(50) NOT NULL, -- openai/anthropic/gemini/baidu/...
account_type VARCHAR(20) NOT NULL, -- api_key/oauth
encrypted_key VARCHAR(500), -- 加密存储
display_name VARCHAR(100),
status VARCHAR(20), -- pending/active/suspended
verified_at TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW()
);
-- 供应套餐表
CREATE TABLE supply_packages (
id BIGINT PRIMARY KEY,
supply_account_id BIGINT NOT NULL,
model VARCHAR(100) NOT NULL,
available_quota DECIMAL(20, 6), -- 可用额度
sold_quota DECIMAL(20, 6) DEFAULT 0, -- 已售额度
price_per_1m DECIMAL(20, 6), -- 每百万tokens价格
status VARCHAR(20), -- active/sold_out/expired
valid_until TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW()
);
-- 供应方收益表
CREATE TABLE supply_earnings (
id BIGINT PRIMARY KEY,
user_id BIGINT NOT NULL,
supply_package_id BIGINT NOT NULL,
consumption_tokens BIGINT NOT NULL,
consumption_amount DECIMAL(20, 6) NOT NULL,
platform_share DECIMAL(20, 6) NOT NULL, -- 平台抽成
supplier_share DECIMAL(20, 6) NOT NULL, -- 供应方收益
created_at TIMESTAMP DEFAULT NOW()
);
5.5 与现有系统的集成
| 模块 | 集成点 | 说明 |
|---|---|---|
| 认证系统 | 复用现有用户体系 | 供应方需完成实名认证 |
| 计费系统 | 复用账务引擎 | 供应方收益计入用户余额 |
| 风控系统 | 复用合规引擎 | 账号需通过 ToS 检查 |
| API 网关 | 新增路由规则 | 识别供应来源，调度到对应账号 |
5.6 实施计划
| 阶段 | 时间 | 任务 | 交付 |
|---|---|---|---|
| S0-a | W1-W2 | 账号挂载模块开发 | 挂载/验证/下架功能 |
| S0-b | W3-W4 | 套餐发布模块开发 | 上架/定价/展示功能 |
| S0-c | W5-W6 | 调度与计费模块开发 | 实时调度/扣减/账单 |
| S0-d | W7-W8 | 风控模块开发 | 健康监控/欺诈检测 |
| S0-e | W9-W10 | 内部测试与修复 | 试运行 |
| S0-f | W11-W12 | 首批供应方引入 | 10家供应方 |
6. 结论与建议
6.1 结论
- Subapi 技术掌握充分：已有详细的契约文档，可以完成集成
- Subapi 供应商覆盖全：10+ 供应商，100+ 模型
- 用户供应功能缺失：Subapi 不支持，需平台层自研
6.2 建议
- ✅ 继续推进 Subapi 集成（技术可行）
- ✅ 补充用户供应功能的自研计划（当前规划缺失）
- ✅ 将 S0 阶段延长，增加供应侧功能开发
- ✅ 优先在 S0-e 阶段引入首批供应方进行验证
文档状态：补充说明 关联文档：
llm_gateway_subapi_evolution_plan_v4_1_2026-03-18.mdsubapi_connector_contract_v1_2026-03-17.md