车载场景的端云协同 AI 架构怎么设计？哪些能力上车、哪些留在云端？

先这样答

划分原则只有两条：安全和实时性要求高的必须端侧，模型大、更新快、算力 hungry 的放云端。

端侧清单：唤醒词检测、基础语音识别（断网可用的车控指令）、车控指令的意图执行、疲劳检测这类视觉安全功能、导航的离线兜底。这些功能的共性是失效代价高（车控失灵、安全检测中断）或延迟要求严苛，端侧芯片的算力经过量化压缩的轻量模型可以覆盖。

云端清单：开放域对话、多轮复杂理解、个性化推荐、内容生成、模型的大版本迭代。云端可以上旗舰模型，按车载场景做定向微调，更新频率不受整车验证周期限制。

链路设计的三个要点。降级路径：云端不可达时，端侧能力要无缝接管，用户感知是「变笨了但能用」，提示话术要清晰设定预期。结果缓存：常用请求（周边充电桩、天气、通勤路况）的结果缓存端侧，弱网时命中缓存。OTA：端侧模型的更新走 OTA 通道，要考虑升级失败的回滚、灰度放量（先小批量车型再全量）、版本兼容（不同代际硬件的模型包不同）。

成本视角：端侧算力是一次性硬件成本，云端推理是持续运营成本，用户规模大后云端成本占比上升，架构上要持续做「云下沉」——把云端验证稳定的轻量能力下沉到端侧。

面试官会怎么追问

• 「端侧模型的精度损失怎么权衡？」 量化压缩会掉点，用车载高频场景的测试集验证掉点幅度，掉到不可接受的层不压缩或换更小的架构。端侧模型不求全面，求高频场景的准确率。
• 「OTA 灰度怎么做？」 按车型批次、地区、用户自愿报名分批推送，每批监控崩溃率和功能指标，异常自动暂停。模型包的回滚版本常驻端侧，升级失败自动回退。
• 「哪些数据允许出车？」 经过脱敏聚合的诊断和使用统计数据可以，用于改进模型；舱内影像和对话原始数据默认不出车，出车要用户明确授权。数据合规是架构设计的先决条件。

回答的坑

• 只按「模型大小」划分端云。安全性和实时性才是第一判据，大模型量化后也可能必须端侧。
• 不提降级和 OTA。断网兜底和持续迭代能力是车载架构的两大生命线。