一只 99 元 AI 玩具的成本账：本地与云的边界是算出来的
一、把价格摊成四段，账才算得下去
有一条消息值得从成本结构的角度读：据公开报道，一只 99 元的同类毛绒玩具拆开来是棉花、指甲盖大小的一块电路板、不到 7 元的芯片和一段外购代码；从普通毛绒玩具的九块九到 99 元，多出来的部分花在传感、联网和语音链路上。这些价格只是公开报道里的转述，不是本篇的判断依据。本篇要看的是它的形状：多出来的钱并不集中在芯片上，而是散在链条的三段里，其中还有一段在打样阶段根本看不见。
我们习惯把带联网能力的硬件产品成本切成四段：硬件物料、联网与通信、云端推理与存储、运营与维护。前三段在打样和小批量阶段就能估出来，报价时会体现在物料单和接口调用单价上。第四段要等产品活进用户家里才显形，所以最容易被低估，原因有三层。它不是一次性成本而是按月发生的成本，估的时候容易按“单次调用单价乘以预估次数”处理，而真实次数由使用习惯决定；它跟活跃时长而不是销量走，卖得多且留得久的产品，第三段与第四段会一起涨，硬件卖得好反而是成本的放大器；它没有账单提醒，云端调用有明细，运营投入只有工时，客诉、内容抽审、故障排查这些人工成本不会出现在任何一张采购单上。
端云边界怎么划，本质就是这四段的分配问题。我们的做法是两遍筛：先按“必须留在本地”筛一遍，再按“值得放云上”筛第二遍，剩下的中间地带才需要讨论。顺序反了就会得出“能上云的都上云”的方案，那是把成本和责任一起推给未来。
二、第一遍筛：必须留在本地的四条判据
第一条是离线可用。要问的其实不是技术问题，是产品定义问题：断网的时候这台设备还要不要给出任何响应。如果答案是“断网就变回一块棉花”，那它就不该被宣传成有交互能力的产品；如果答案是要保留基本应答，那这部分能力必须在设备端，没有讨论空间。
第二条是交互时延。唤醒之后的应答窗口、被打断时的停止响应、常用短句的反馈，这些环节对往返时间敏感。网络抖动的表现不是慢一点，是节奏被打散：用户说完半句设备才开口，或者用户已经打断它还在讲。这类体验问题在评测里往往归因给“模型不行”，实际是链路时间预算没算够。
第三条是隐私，尤其是含儿童与家庭成员语音的原始音频。原始音频一旦离开设备，就要面对完整的一套流程：告知、同意、留存期限、删除响应、导出请求、被误采集的第三方人声。这条判据的作用是把“上传什么”定死，而不是留给工程师在联调时临时决定。设备端先做一次过滤、只上传文本或者只上传特征，是同一件事的不同实现，选择哪一种要按第一、第二条一起判断。
第四条是降级边界。断网、弱网、服务端异常时设备保留哪些功能、以什么方式告诉用户，这些必须在设计阶段写成状态而不是临场报错。降级边界清楚了，后面测试才有依据。
三、第二遍筛：值得放上云的四条判据
模型体积是第一条。设备端的内存和功耗上限决定了放不下的那部分只能放云上，这类环节包括较大的对话模型、多语种识别和复杂的内容生成。
持续更新是第二条。能力要迭代、内容库要换、安全规则要改，靠召回设备来解决的代价太高。把可更新的部分放在服务端，硬件的寿命和能力的寿命就解耦了，这是端云分工里最实用的一条。
多设备共享是第三条。同一个使用者在家里另一台设备上要继续之前的内容、偏好和进度，状态只能放在服务端；放在设备端，就等于把归属权和迁移成本都锁死在一块电路板上。
需要人审的内容安全是第四条。生成内容的过滤、抽检、申诉复核要有留痕和可回滚，这类工作必须在服务端做，因为设备端没有“复核”这件事的执行者。
四、语音链路的三种落法，各有各的失败模式
第一种，本地唤醒加云端识别。设备端只放关键词唤醒，识别与理解全部上云。它的硬件成本最低，芯片档位可以下探；云端成本随使用量近似线性增长。失败模式集中在链路上：网络差时整条链一起失败，隐私暴露面最大，接口或配额变动会让产品当场哑掉。
第二种，全本地小模型。唤醒、识别、有限应答都在设备端完成。代价是硬件成本前移：内存容量与算力要上台阶，功耗与散热要重算，芯片档位一上去整机成本结构就变了。它的失败模式不是断网，是天花板：能力被内存和功耗封死，后期只能通过固件更新做有限改善，而更新本身又是负担。好处也很明确：断网可用，隐私流程大幅缩短。
第三种，全云端。硬件最便宜，实现最快，效果上限最高。失败模式最难治：弱网下的重试风暴会把服务端成本推高，活跃时长高的品类上服务端成本会失控，离线即完全失效，同时把全部语音数据推到云侧，隐私流程一条都省不掉。
常见的折中是分层：唤醒与常用短句留在本地，长回答与内容生成上云。这不算第四种方案，它只是把上面三种的判据按环节各自用了一遍。
五、核心交付物：四段成本、决定项与可验收字段
| 成本段 | 由什么决定 | 容易被低估的地方 | 可验收字段 |
|---|---|---|---|
| 硬件物料 | 是否在设备端跑识别、内存与算力档位、麦克风与功放数量、外购代码的授权方式 | 为留后路而加的那部分余量很少被回收 | 单机物料成本、峰值内存占用、待机功耗 |
| 联网与通信 | 连接方式、心跳频率、是否必须常连、重连策略 | 弱网重试带来的额外请求量 | 单设备月均流量、连接成功率、断线重连次数 |
| 云端推理与存储 | 哪些环节上云、一次交互调用几次模型、音频与文本是否留存、留存多久 | 一次交互往往不止一次调用，链路长度少被算进单价 | 单次交互调用成本、每设备月均云端成本、月活跃时长 |
| 运营与维护 | 内容安全与人审、模型与固件更新、故障排查与客诉、服务存续安排 | 人工工时不出现在任何采购单上；卖得越好这一段越贵 | 更新成功率、人审工时占比、单台年均运维成本、离线兜底是否存在 |
这张表里唯一要强调的字段是“每设备月均云端成本”。它是把第三段和第四段收敛成一个可评审的数字，也是唯一能在产品还在评审阶段就把端云方案吵清楚的字段。
六、联网带来的长期责任，与儿童场景的额外三件事
联网是把责任一起接进产品的。云端额度耗尽、接口调整或者服务停止之后设备变成什么，这个问题要有明确答案：能不能给出离线兜底，兜底保留哪些功能，兜底方案是在设计阶段就留在设备里，还是事后临时补一段代码。存续期与变更方式要不要告诉购买者，也要在设计评审时定下来，而不是等到出问题时写公告。这一段的成本落在上表的第四段里，这也是我们坚持把“离线兜底是否存在”作为验收字段的原因。
面向儿童的产品要额外做三件事。第一是数据留存与删除：默认不上传原始音频，留存期限写成配置而不是注释，删除请求要能被执行并可核对。第二是可听内容过滤：设备端要有一层不依赖云端可达性的过滤，因为弱网时云端过滤是不可达的，而恰恰是弱网时更容易出现未审内容。第三是家长侧可见与控制：能查看设备记录了什么、能关闭采集、能设使用时段，这三项要能在没有网络辅助的情况下也能生效一次。
这套账搬到企业自研硬件上是同一套算法，只是字段换了位置。我们的做法是两条硬要求：把每台设备的月均云端成本作为可验收字段进入方案评审，与物料成本同权重比较；把停服兜底方案和固件更新责任写进合同条款，包括谁提供更新、更新支持到什么时候、服务端变更提前多久通知。洹拓科技在给做自有终端的客户算这笔账时，通常先问一句：云端服务不可用的那天，这台设备还能做什么。这个问题答不出来的方案，硬件做得再漂亮都只是把风险推到量产后。
低价不是靠压缩芯片档位做到的，是靠把每一段能力放在它最便宜的位置上做到的。