krisolo/boss
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
de6257a819571f7a2038f5564b0391afe871945c
boss/docs/source-material/设备直连方舟方案提炼与备选落地方案.md
kris 90cb6b7ff1 feat: ship native boss android console
2026-03-26 23:16:56 +08:00

13 KiB
Raw Blame History

设备直连方舟方案提炼与备选落地方案

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. 风控策略文档
    • 限流规则
    • 黑名单
    • 人工处置流程

如果后续继续往下做，建议优先把“接口定义 + 时序图 + 账本模型”补齐，这三样最直接影响开发能不能落地。