# 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 数据模型 ```sql -- 供应方账号表 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 结论 1. **Subapi 技术掌握充分**：已有详细的契约文档，可以完成集成 2. **Subapi 供应商覆盖全**：10+ 供应商，100+ 模型 3. **用户供应功能缺失**：Subapi 不支持，需平台层自研 ### 6.2 建议 1. ✅ 继续推进 Subapi 集成（技术可行） 2. ✅ 补充用户供应功能的自研计划（当前规划缺失） 3. ✅ 将 S0 阶段延长，增加供应侧功能开发 4. ✅ 优先在 S0-e 阶段引入首批供应方进行验证 --- **文档状态**：补充说明 **关联文档**： - `llm_gateway_subapi_evolution_plan_v4_1_2026-03-18.md` - `subapi_connector_contract_v1_2026-03-17.md`