# 设备直连方舟方案提炼与备选落地方案 ## 1. 文档目的 这份文档用于沉淀此前关于“设备端直连火山方舟 API / RTC 时，如何做授权、配额、监测、续授权、风控和服务端落地”的讨论结果，并补充几套可执行的备选方案，便于后续做产品决策、技术评审和开发拆分。 适用范围： - 设备端直接访问大模型或实时交互云服务 - 希望按照用户、设备、套餐做差异化限制 - 既关心用户体感，也关心成本、风控和可运营性 --- ## 2. 前面对话的核心结论 ### 2.1 已经基本达成共识的判断 1. 云厂商的 `API Key`、平台 `token` 或 RTC 入房 `token`，都不能直接当“每台设备的额度控制器”。 2. 设备端是天然不可信环境，不能把长期主密钥或可无限调用的真实能力长期保存在设备里。 3. 真正的控制应该拆成两层： - 云厂商鉴权层：只解决“能不能调云服务”。 - 业务授权层：由你自己的服务端控制“这台设备、这个用户、这个套餐此刻还能用多少”。 4. 精确用量不能只靠设备心跳、事件上报或会话时长估算，最终必须用云厂商侧的 `usage`、任务事件、账单或回流数据闭环。 5. 如果续授权做成同步阻塞，长内容生成时一定会卡；如果做成低水位异步预取，用户体感可以做到接近无感。 ### 2.2 前面对话里识别出的主要漏洞 1. Token 泄露后，在有效期内可能被滥用。 2. 设备固件可被逆向，设备上报数据可伪造。 3. 如果不做单设备单活会话限制，同一设备可能并发开多个会话。 4. 如果 `/token/request` 一类接口不做风控和限流，容易被刷爆。 5. 如果所有设备在同一时刻续授权，容易产生惊群。 6. 如果授权与真实计费脱钩，会导致账单不可控。 7. 如果把“估算用量”直接拿来做结算，财务和用户侧都会出争议。 ### 2.3 前面对话里形成的推荐主方向 推荐的基础方向是： - 控制面在你自己的服务端 - 推理面或媒体面尽量直连云厂商 - 设备只拿短期业务授权，不拿长期主密钥 - 服务端做配额预占、风控、续权、用量回收和最终结算 这套方向的核心思想可以概括为一句话： `设备直连推理面，服务端掌控授权面。` --- ## 3. 推荐主方案：控制面在服务端，推理面尽量直连 ### 3.1 方案概述 设备在发起一次会话前，先向你的服务端申请“业务授权切片”。 服务端完成设备校验、用户校验、套餐校验、预算预占和风控检查后，再给设备发一个短期授权。 设备拿着这份短期授权去直连方舟 API 或 RTC 服务。 会话过程中，设备根据本次切片预算和实时用量做低水位预警，在快耗尽时后台静默申请下一片。 最终结算不以设备上报为准，而以云侧用量数据回流为准。 ### 3.2 为什么推荐这套方案 优点： - 延迟低，首包和流式输出更接近设备直连 - 服务端带宽压力小，不用全量转发模型输出 - 更容易扩容到 1000 台、1 万台甚至更多设备 - 风控和套餐控制权仍然在你自己手里 缺点： - 系统设计复杂度高于“纯代理” - 授权切片、用量回流、续授权、会话状态管理都要自己做 - 不能把设备上报当真，需要额外做闭环和审计 ### 3.3 推荐的数据模型 建议至少有下面几类核心表： 1. `device_registry` - 设备基础信息、激活状态、固件版本、设备指纹、公钥或签名信息 2. `user_subscription` - 用户订阅档位、有效期、套餐预算、超额策略 3. `device_binding` - 用户和设备的归属关系、多设备限制、共享规则 4. `session_grant` - 一次业务授权切片，记录授权预算、过期时间、状态、续权关系 5. `device_session` - 设备会话生命周期，包含开始时间、最后心跳、关闭原因、会话状态 6. `quota_ledger` - 预算预占、释放、回补、扣减、人工修正的流水账 7. `vendor_usage_raw` - 云厂商原始回流数据，按任务、请求或账单粒度保存 8. `device_usage_derived` - 归因后的设备级、用户级、套餐级统计结果 ### 3.4 推荐的授权流程 1. 设备启动会话，请求 `/session/grants/issue` 2. 服务端校验： - 设备身份 - 用户身份 - 设备归属关系 - 套餐剩余额度 - 当前是否已有活跃会话 - 风控规则是否触发 3. 服务端预占一笔预算 4. 服务端签发短期业务授权切片 5. 设备带切片去直连云服务 6. 设备在低水位时后台请求 `/session/grants/renew` 7. 云侧回流真实用量 8. 服务端做最终扣减、释放未用完的预占额度、落账和统计 ### 3.5 推荐的额度控制方式 建议不要只做“单一 token 池”，而是同时做三层配额： 1. 用户总额度 - 代表这个用户在一个计费周期内的总预算 2. 设备子额度 - 防止同一用户多台设备把总额度瞬间打穿 3. 单会话切片额度 - 防止单次长会话在短时间内无限消耗 推荐同时限制以下维度： - 日预算 - 月预算 - 单次会话最大预算 - 单分钟最大请求次数 - 单设备并发会话数 - 单用户并发设备数 ### 3.6 推荐的续授权策略 续授权不要等到额度耗尽再做，建议采用“低水位异步预取”： 1. 初次只发一小片预算 2. 设备本地维护剩余额度估算 3. 当剩余额度低于阈值时，后台静默续片 4. 当前生成链路继续跑，不等待续权结果 5. 下一片到账后无缝衔接 建议阈值： - 文本生成：剩余 20% 到 30% 时触发 - 语音对话：剩余 30% 到 40% 时触发 - 长故事、长文本类任务：按分段生成边界提前预取 ### 3.7 推荐的风控策略 至少做以下规则： - 单设备单活会话限制 - 单用户同时在线设备数限制 - 单 IP / 单设备 / 单账号的授权请求速率限制 - 异常高频续权检测 - 授权后未消费比例过高告警 - 设备版本黑名单 - 签名失败或时间戳异常直接拒绝 - 同一授权切片重复使用检测 --- ## 4. 服务端和设备端的开发边界 ### 4.1 服务端应该负责什么 服务端负责： - 设备注册与激活 - 用户和设备绑定关系 - 套餐和额度管理 - 业务授权切片签发 - 会话生命周期管理 - 用量回流接收和结算 - 风控和审计 - 运营报表和客服排障 服务端不应该依赖设备端做最终结算。 ### 4.2 设备端应该负责什么 设备端负责： - 安全保存设备身份证明和短期授权 - 会话发起和会话结束 - 低水位续授权预取 - 本地缓存当前切片剩余额度估算 - 断网重连和授权失效的兜底逻辑 - 心跳和状态上报 设备端可以做“估算”和“提示”，但不应该成为最终计费真相来源。 --- ## 5. 其他有效落地方案 下面这些方案都能落地，只是权衡不同。 ### 方案 A：全量代理网关方案 #### 方案定义 设备不直连方舟。所有模型请求先到你的网关，由你的网关统一转发到云厂商。 #### 适用场景 - 你最在意配额控制和审计 - 你需要做内容审核、提示词裁剪、统一缓存、统一日志 - 设备数量暂时不大，或者可以接受增加服务端带宽成本 #### 优点 - 控制力最强 - 真实用量和业务扣费天然更容易对齐 - 最容易做黑名单、限流、熔断和回放审计 - 不需要把云厂商调用能力直接暴露给设备 #### 缺点 - 服务端流量和带宽成本明显上升 - 首包和流式链路会多一跳 - 需要处理更多高并发连接和转发问题 #### 推荐度 如果你当前最担心的是“被刷爆”和“账单不可控”，这是最稳的方案。 --- ### 方案 B：双通道混合方案 #### 方案定义 短请求、常规请求走设备直连。 长故事、长文本、长语音、多轮复杂任务走你的代理网关。 #### 适用场景 - 想兼顾用户体感和强控制 - 任务类型差异很大 - 部分任务天然更容易超预算或更需要审计 #### 优点 - 兼顾速度和控制 - 高风险场景可切到可控链路 - 能把最贵、最不稳定的任务单独隔离 #### 缺点 - 路由逻辑变复杂 - 设备端和服务端都要知道“什么时候切换通道” - 运营和排障会比分单一路径稍复杂 #### 推荐做法 可以把以下任务默认走代理： - 长故事生成 - 长时语音陪伴 - 需要强审计的企业客户任务 - 高价值套餐用户的高级功能 --- ### 方案 C：边缘接入节点方案 #### 方案定义 设备不直接连中心控制服务，而是先连最近的区域接入节点。 接入节点负责授权校验、会话保持、低延迟续权和短期缓存；中心服务负责总账和全局策略。 #### 适用场景 - 设备分布地域广 - 网络质量不稳定 - 对低延迟和高在线率要求高 #### 优点 - 授权和续权时延更低 - 对弱网和抖动更友好 - 可缓解中心服务压力 #### 缺点 - 系统复杂度更高 - 要做多节点状态同步 - 部署和运维成本增加 #### 什么时候值得上 当你设备规模较大，且终端网络质量参差不齐时，这个方案很有价值。 --- ### 方案 D：套餐桶包方案 #### 方案定义 不是每次都按精细 token 去分，而是先把套餐设计成“桶包”。 例如： - 基础版：每月 300 次短对话 - 标准版：每月 1000 次中等对话 - 高级版：每月 300 次长故事生成 服务端内部再把每类任务映射成预算扣减规则。 #### 适用场景 - 你现在还不想让用户看到复杂的 token 概念 - 你希望先快速商业化 - 你的业务更适合卖“能力包”而不是卖“token” #### 优点 - 产品表达清晰 - 用户更容易理解 - 客服和销售更容易沟通 #### 缺点 - 需要你自己维护任务到成本的映射 - 某些边界场景会有估算误差 #### 推荐度 如果你短期内更想先做商业闭环，这是非常有效的落地方案。 --- ### 方案 E：企业租户隔离方案 #### 方案定义 针对 B 端、渠道商或大客户，给每个租户单独做配额池、单独风控策略，必要时单独接入点、单独结算域。 #### 适用场景 - 有渠道商、OEM、品牌合作方 - 需要租户级对账 - 需要更强的安全隔离和 SLA #### 优点 - 财务和运营边界清晰 - 某租户异常不会拖垮全部业务 - 易于做分账和差异化商务策略 #### 缺点 - 配置和运维复杂度增加 - 需要更好的控制台和运维体系 #### 推荐度 如果未来会走 B2B2C，这是很值得提前预留的架构方向。 --- ## 6. 各方案对比 | 方案 | 用户体感 | 控制力 | 实施复杂度 | 服务端成本 | 推荐场景 | | --- | --- | --- | --- | --- | --- | | 控制面在服务端，推理面直连 | 高 | 高 | 中高 | 低到中 | 当前最平衡的主方案 | | 全量代理网关 | 中 | 很高 | 中 | 中到高 | 最重视安全和结算闭环 | | 双通道混合 | 高 | 高 | 高 | 中 | 想同时兼顾体感和强控制 | | 边缘接入节点 | 很高 | 高 | 很高 | 中到高 | 多地域、大规模、弱网 | | 套餐桶包 | 高 | 中 | 中 | 低到中 | 先做商业闭环 | | 企业租户隔离 | 中到高 | 很高 | 高 | 中到高 | B 端或渠道业务 | --- ## 7. 我对落地顺序的建议 如果要尽快做出第一版可上线系统，建议按下面顺序推进： ### 第一阶段：先把主方案做出来 先实现： - 设备注册和激活 - 用户与设备绑定 - 套餐总额度 - 单会话授权切片 - 单设备单活会话 - 低水位异步续权 - 云侧用量回流 - 账本式扣减 ### 第二阶段：补风控和运营能力 补上： - 刷授权风控 - 异常续权检测 - 黑名单和熔断 - 设备版本治理 - 对账报表 - 人工纠偏工具 ### 第三阶段：按业务形态选择备选方案 根据业务方向再补： - 想更稳：增加全量代理通道 - 想更快：增加边缘接入节点 - 想更好卖：增加套餐桶包表达 - 想做渠道：增加租户隔离 --- ## 8. 最终建议 如果你现在的目标是“尽快做出能上线、能控成本、体感也不错的一版”，我建议选择： `主方案 + 套餐桶包表达` 也就是： 1. 技术底层用“控制面在服务端，推理面尽量直连” 2. 产品层面对用户不直接卖 token，而是卖套餐额度和能力包 3. 结算层内部仍然用真实用量和预算账本做闭环 这样做的好处是： - 技术上能控住 - 运营上讲得清 - 用户侧更容易理解 - 后续还能平滑切到双通道或企业租户隔离 --- ## 9. 建议的后续产出 下一步建议继续补这四类文档： 1. 接口定义文档 - `issue grant` - `renew grant` - `heartbeat` - `close session` - `usage callback` 2. 时序图文档 - 首次授权 - 异步续权 - 断网重连 - 授权失败兜底 3. 数据库设计文档 - 表结构 - 索引 - 状态机 4. 风控策略文档 - 限流规则 - 黑名单 - 人工处置流程 如果后续继续往下做，建议优先把“接口定义 + 时序图 + 账本模型”补齐，这三样最直接影响开发能不能落地。