车端算力共享：从创新假设到商业判断

蔚来汽车 · 2024.02–2025.03 · 自动驾驶研发-云端工程部-架构方案团队

项目的起点是一个资源驱动的假设：大模型刚兴起的阶段，评测标准不稳定，大量应用还停留在调用接口做判断的层面，开源小模型开始变得有价值。与此同时，每辆蔚来汽车上都有一颗 Orin 芯片，而车辆每天平均行驶时间只有大约半小时——剩下的二十三个多小时里，这颗芯片什么也没干。我们的切入点不是"AI 能做什么"，而是"这里有一块闲置的算力，它还能创造什么价值"。

我的角色需要说清楚。这个项目最初是我的 +3（高三级上级）发起的方向，由我的 +2 承接后安排到我头上做名义上的项目负责人。配合我推进的有一位系统工程师负责把各领域方案串起来，一位产品经理负责业务侧和流程侧推进。系统工程师负责"串"，我负责"推"——测试、问题定位、问题分配、关键分歧处的技术博弈和方案落地，都在我这里收口。对外沟通的时候，我可以比较方便地借 +2 和 +3 的授权推动各团队。实际上我做的大部分工作是：给各个团队介绍目标，然后在无数次磨合中背下了所有其他领域的技术方案，以及在推不动的时候和各个团队吵架。

章一：机会与 POC

资源拆分与核心假设

第一步是把车辆的时间和算力拆开看。车辆的运行状态被划分为行车和停车两种；SoC 被拆成运行 SoC 和伴生 SoC 两个部分——这个概念在项目之前就已经存在。我们的核心假设很简单：伴生 SoC（Orin）在车辆闲置时是完全空转的，如果能把这块算力接入云端，就相当于拥有了一个分布在全国各地的边缘计算网络。

第一轮 POC：证明车可以成为计算节点

POC 阶段的目标非常单纯：证明车上的 Orin 算力可以作为云端可调度的推理节点。为了证明这一点，我们做了一整套基础设施，而不是只跑一个模型。

具体做法是：把车上的伴生 SoC 掏出来，在上面搭建了整套 ARM 版 K3s，用云原生服务化的方式来管理这个"节点"。搭建了开机自启流程，保证车辆启动时 K3s 自动拉起。开发了 DaemonSet 常驻 Agent，用来和云端保持通信——Agent 通过 MQTT 向云端发送心跳，云端据此管理车辆在线状态。云端定义需要在车上运行的服务（当时是开源大模型的推理服务），通过 MQTT 下发部署指令。然后打通了 Tunnel 网络，把车上的服务端口暴露出来，并在服务层做了一套负载均衡，保证云端对外的统一 API 可以调度到当前在线的车辆上。

最终效果：任何一辆测试车，只要启动并联网，就会自动加入计算集群。云端无需关心是哪辆车在线，只需要调用统一接口，调度层自动把请求转发到当前在线车辆上的推理服务。

K3s 的选型需要说清楚归属。当时主要在 K3s 和一个面向 IoT 设备管理的成熟框架之间做选择。这不是我个人拍板的决策，而是我所在的业务组和 Infra 团队共同讨论后做出的。选择 K3s 的核心考虑是：车辆环境与标准 IoT 场景差异较大，成熟 IoT 框架的完整管理体系反而成了包袱——很多功能在车上用不上，改造成本高；K3s 作为原生轻量框架更容易根据车辆实际情况裁剪和修改。方案取舍主要由我们业务组推动，Infra 提供基础设施能力和技术资源，并负责把 K3s 基础能力落到车端。我们业务组则负责在 K3s 之上构建车辆管理、调度和服务管理体系。MQTT 的具体技术方案由我拆给团队内部的一位成员负责。

技术架构：POC 阶段完整链路

车端（伴生 SoC / Orin）
┌────────────────────────────────┐
│  车辆启动                       │
│       │                        │
│       ▼                        │
│  ARM K3s 自动拉起               │
│       │                        │
│       ▼                        │
│  DaemonSet Agent 常驻           │
│  · 向云端发送 MQTT 心跳          │
│  · 接收云端部署指令              │
│       │                        │
│       ▼                        │
│  开源大模型推理服务启动           │
│  · Agent 调用 K3s API 拉起服务   │
│       │                        │
│       ▼                        │
│  Tunnel 网络                   │
│  · 车端服务端口暴露到云端        │
└────────────┬───────────────────┘
             │
云端
             ▼
┌────────────────────────────────┐
│  MQTT Broker                   │
│  · 接收车端心跳 → 车辆在线管理   │
│  · 下发部署指令 → 车端 Agent     │
│                                │
│  车辆状态管理                    │
│  · 发现车辆上线                  │
│  · 维护在线车辆池                │
│                                │
│  服务层负载均衡                   │
│  · 统一对外 API                  │
│  · 请求路由到在线车辆推理服务      │
│                                │
│  效果：                         │
│  任何测试车启动 → 自动加入集群    │
│  云端调用统一接口 → 自动调度到车   │
└────────────────────────────────┘

POC 阶段证明了一件事：车可以成为计算节点。但真正难的问题还没开始——车辆不是数据中心里的稳定服务器，它随时会熄火、断网、被用户开走。接下来的所有工作，本质上都是在解决"不稳定节点组成的分布式计算网络"这个问题。

POC 完成之后，下一个问题是：什么时候用这块算力？答案把整个项目从技术验证推进到了整车系统改造。

章二：Compute Mode — 让量产车长出新的启动形态

为什么是停车而不是行车

处境

POC 阶段是在车辆行驶状态下验证的——车开着，伴生 SoC 有富余算力，我们借用一部分。但真正去分析资源约束之后发现，行车状态下的可利用空间非常有限。伴生 SoC 在行车时确实有富余的算力和内存，但网络和存储不行——尤其是网络，推理任务如果大量占用带宽，可能影响智驾相关的数据通信，这是不可接受的。更关键的是时间：统计下来，每辆车平均每天的驾驶时长只有大约半小时，行车闲置几乎不存在。

桌上的选项

一条路是继续在行车状态下做文章——精细化地隔离资源，控制推理任务对网络和存储的占用，在驾驶间隙见缝插针。这条路的天花板很低：半小时的驾驶时间里能挤出的算力非常有限，而为了隔离资源所需要的工程投入不小。另一条路是把目标瞄准停车状态——每天二十三个多小时的完全闲置，如果能用起来，规模完全不在一个量级。

我的选择

我选了停车闲置。半小时对二十三小时，算力规模差了两个数量级。但这个选择带来一个巨大的前置问题：车辆在停车状态下是不在线的。要用停车算力，就必须在车辆不行驶的时候把它"叫醒"，而且叫醒之后不能把整辆车都启动起来。

代价

代价是工程量级的跃升。从"借用行车时的富余资源"变成了"为车辆设计一种全新的运行模式"，涉及的团队从几个人扩展到十多个跨域团队。

结果

这个判断后来被验证是对的。停车闲置的算力确实是大头，行车时的可利用空间太小，不值得为此承担隔离和安全的复杂度。

回看

这个决策本身不难，难的是它打开了后面一连串的工程问题——每一个都需要和不同的团队去推、去吵、去达成共识。选对了方向，但低估了从方向到落地之间的组织阻力。

最小启动集：只启动算力、网络和冷却

处境

如果在停车状态下直接使用车辆的常规启动模式，车端会拉起标准的水冷单元、Orin 的自驾算力单元、座舱的监控仪表盘、车灯，以及各种各样的车辆功能。这带来两个严重问题：第一，如果车辆在用户不知情的情况下自己启动了这一大堆东西，用户会产生极大的困惑——"我的车怎么自己亮了？"；第二，这些功能对资源的消耗量非常大，我们只需要用算力，不应该为此承担整车的功耗。

桌上的选项

一条路是沿用常规启动流程，通过软件层面去选择性地关闭不需要的模块。这条路的问题是常规启动链路里各模块的启动依赖关系已经固化多年，选择性关闭某些模块可能引发未知的连锁问题，验证成本极高。另一条路是从头定义一种新的启动形态，只拉起真正需要的最小集合。

我的选择

分析下来，Compute Mode 真正需要的只有三类资源：算力模块（Orin）、网络模块（让车能联网）、冷却模块（Orin 全功率推理时的散热）。我主导定义了这个最小启动集，然后沿着启动链路逐层去找需要改动的团队。

代价

这等于要在量产车的 Boot Flow 层面新增一条全新的启动路径。涉及硬件工程师重新定义总线控制信号、底软团队支持特殊信号下的启动、网络团队增加远程唤醒能力、智驾软件团队承接新的启动顺序——每一个环节都需要对应团队改动现有系统。

结果

Compute Mode 最终被设计出来并落地到测试车上。车辆在停车状态下收到云端信号后，只启动算力、网络和冷却三个模块，不拉起座舱、仪表、车灯等任何与驾驶相关的系统。

回看

这件事的核心不是"定义了一个新模式"，而是"对整车资源做了解构"——把一辆车从一个不可分割的整体，拆成了可以按需启动的模块组合。这个思路在后来的成本分析中也被复用：每个模块有自己的功耗、寿命和成本，可以独立核算。

启动链路的逐层拆解

Compute Mode 的落地不是一次性把所有团队拉进来开大会，而是沿着启动链路逐层找到真正需要改动的系统边界。

第一步找硬件工程师。车辆需要一个新的启动模式，这个模式需要新的总线控制信号。硬件工程师负责定义整个车辆启动方案的信号体系。

从控制信号设计开始，下一个问题是如何在远程触发这个信号。出发点是通过网络拉起，类似于待机唤醒模式。于是拉进网络模块团队，由他们定义什么时间点、什么接口、触发之后如何发起控制信号。

网络模块触发的控制信号由智能硬件的底软团队接收。底软团队负责在收到信号时拉起对应的服务，并给出新的服务启动顺序流。

新的启动顺序流需要智驾的车端软件团队承接——他们负责在新的启动序列下正确地拉起算力模块。

最后是冷却。因为算力模式下 Orin 全功率运行，功率和发热都较高，所以我去找了冷却相关的团队做确认。实际确认下来，冷却模块不需要冷却团队额外参与——底软侧已有现成的硬件能力可以直接控制冷却启动，不需要新增控制信号。

除了技术链路，还有一整条非技术链路需要同步推进：法务团队确认该模式的合规性和用户协议的合理性；运营团队设计手机端的交互模式——用户需要知道自己的车在做什么、需要有开关控制权；热管理团队和智能硬件团队评估频繁启动对车辆寿命的影响，并计算概率成本。

技术架构：Compute Mode 启动链路

云端触发
┌─────────────────────────────────────────────┐
│  云端判断：目标车辆处于停车状态               │
│  通过用户侧接口查询车辆当前状态               │
│  发起远程激活指令                             │
└──────────────────┬──────────────────────────┘
                   │
                   ▼
网络模块
┌─────────────────────────────────────────────┐
│  接收远程激活信号                             │
│  拉起车辆网络                                │
│  触发 PNC 控制信号 → 传递给底软               │
└──────────────────┬──────────────────────────┘
                   │
                   ▼
底软（智能硬件）
┌─────────────────────────────────────────────┐
│  接收控制信号                                │
│  启动高压供电                                │
│  启动液冷系统                                │
│  执行 Compute Mode 启动序列                  │
│  （不启动座舱、仪表、车灯等驾驶相关系统）      │
└──────────────────┬──────────────────────────┘
                   │
                   ▼
智驾车端软件
┌─────────────────────────────────────────────┐
│  承接新的启动顺序                             │
│  拉起 Orin 算力模块                          │
│  进入 Compute Mode（非智驾模式）              │
└──────────────────┬──────────────────────────┘
                   │
                   ▼
车端 K3s + Agent
┌─────────────────────────────────────────────┐
│  K3s 自动启动                                │
│  Agent 上线 → MQTT 心跳 → 云端感知车辆可用    │
│  等待云端下发计算任务                         │
└─────────────────────────────────────────────┘

同步进行的非技术链路：
· 法务 → 用户协议合规确认
· 运营 → 手机端交互设计（用户知情+开关控制）
· 热管理+智能硬件 → 车辆寿命影响评估+概率成本计算

Compute Mode 的方案定义和启动链路设计是一回事，真正推动各个团队把它实现出来是另一回事。接下来的工程冲突才是这个项目里最消耗精力的部分。

章三：工程冲突 — 从观点争论到证据推进

containerd 争议与重启决策

Compute Mode 的方案推到车端团队之后，第一个正面冲突发生在 containerd 上。

端侧团队的态度非常明确：你们在车上用了 containerd，这个不安全。至于为什么不安全，不展开说，就是"没有先例"。我和他们沟通，解释 containerd 在 Compute Mode 下是静态条件——只有车辆进入算力模式时才会启动，平时不触发，不会对正常行车产生任何影响。但他们不放心，坚持说可能会有残留。

推了好几轮都没有结果。最后为了让项目能继续推进，我拍了一个板：切换运行模式的时候必须做一次重启操作，确保系统清理干净。端侧团队接受了这个方案。

这是一个我后来认为的错误决策。

接受重启意味着：每次车辆从 Compute Mode 切换回正常行车模式，系统都要经历一次完整重启。这直接导致了后续一连串的体验问题——底软那边告诉我，重启需要 30 秒到 1 分钟。如果车主准备开车，发现要等一分钟才能用，这个体验是完全不可接受的。但这个代价在我做决策的时候已经被隐含地接受了。

错在哪里：为了换取一个团队的点头，我把成本转嫁到了整个系统。原本争论的焦点是"containerd 在静态条件下是否安全"，这是一个可以用技术证据解决的问题；但我选择了妥协，结果把一个技术问题变成了用户体验问题，而用户体验问题比技术问题更难解决。

Reset：找一手证据改变讨论基础

重启的代价很快浮出水面。底软团队告诉我，从 Compute Mode 切回行车模式，重启过程可能让车主等 30 秒到 1 分钟——用户在自己车旁边"罚站"。这个体验我知道一定过不了运营和体验团队的评审，甚至都不用去问。

所以我提出了另一个方案：不做完整重启，而是用 Reset 的方式对系统进行重置。Reset 比重启快得多，可以把等待时间压到可接受的范围。

底软团队很愤怒，直接拒绝。理由是："除非 NVIDIA 的人同意。"——言下之意，Orin 的 Reset 行为是否安全，他们不敢确认，需要芯片供应商背书。

很多人听到"供应商不同意"就会停下来。我没有停。我直接去找了 NVIDIA 的人，作为芯片供应商方，问他们：我们想在特定场景下使用 Reset，是否会对系统产生影响？NVIDIA 最终回复：不会影响。

我拿着 NVIDIA 的回复回去找底软。底软团队换了一个理由：Reset 会伤害磁盘，不允许。

事情到这里，其实已经从技术争论变成了立场争论。双方谁都没有新的证据，只是在反复表达自己的观点。我知道继续在观点层面争论下去不会有结果。

转折来自一个偶然发现。我在内部团队的监控看板上看到了底软团队提供的一个指标——Reset 在实车上的执行次数。这个数字让我直接愣住了：单车平均每天大约 10 次。也就是说，同样的 Reset 操作，在量产车的日常运行中已经被频繁使用了，而且没有引发任何磁盘问题。

这意味着：如果 Reset 真的会伤磁盘，那今天所有量产车都在被伤害。论证瞬间反过来了——不是我需要证明 Reset 安全，而是他们需要解释为什么同一个操作在他们自己的系统里已经每天执行 10 次，到我这里就变得不可接受。

我立刻写了一份报告，重新拉底软团队的负责人开会，把这份监控数据摆在桌面上。最终底软团队同意开通此功能做验证，但要求在正式上线前再做一次 Review。我同意了。

同意的原因很务实：POC 阶段和量产上线是两个世界。POC 的目标是证明能力，量产阶段才开始讨论安全、可靠性和责任归属。上线前的 Review 是合理的——而且到了那个阶段，决策权已经不在底软团队一个团队手里了。

回看这两段冲突

整个过程体现的不是"吵赢了"，而是一种工作方式：当对方说"不行"的时候，不停留在观点层面反复争论，而是去找一手信息源——直接问 NVIDIA 而不是接受二手转述；当争论陷入僵局的时候，去找系统里的真实数据来改变讨论基础。这个方法在后来做成本模型和商业验证的时候也被反复使用。

工程冲突推进的同时，云端的计算平台也在同步建设。这部分是我直接负责整体设计和落地的。

章四：云车计算平台

双层状态机：车辆生命周期与服务生命周期解耦

处境

云端要管理的不只是"这辆车在不在线"，还有"这辆车上的服务在不在运行"。这两件事看起来相关，实际上是两个独立的维度：一辆车可能已经进入 Compute Mode 但还没有被分配任何任务（车在线，服务未运行）；一辆车上的服务可能正在运行，但车辆随时可能因为用户靠近而被唤醒回到行车模式（服务在运行，车辆即将退出）。如果把这两层混在一起管理，状态机会变得极其复杂，异常处理也会到处是特殊分支。

桌上的选项

一条路是用一套统一的状态机覆盖车辆和服务的所有组合状态。好处是只有一个状态源，坏处是状态数量爆炸——三种车辆状态乘以三种服务状态就是九种组合，每种组合都有不同的转移规则和异常处理逻辑。另一条路是把车辆状态和服务状态拆成两层独立管理，各自有自己的状态机，云端根据两层状态的组合来做调度决策。

我的选择

我把状态拆成了两层。

车辆状态层有三种状态：下电停车（程序完全不可运行）、行车 / 半生模式（部分算力可用，只能使用部分 Orin 计算资源）、算力共享模式（全部算力可用）。状态切换的触发方式是：停车状态下由云端触发信号，车端进入算力共享模式；算力共享模式下用户靠近车辆触发激活时，由车端元器件负责重启车辆，重新进入行车状态。

服务状态层也有三种状态：待机（车辆已进入算力模式，但业务未就绪）、运行（服务已下发并在执行）、停止（服务被主动停止）。如果车辆在服务运行期间关机，下一次重新进入算力模式时，可以直接恢复到运行状态。

代价

两层状态机意味着云端在做调度决策的时候需要同时查两个维度，代码层面需要处理两层状态的组合逻辑。但这比九种组合状态的单层状态机要清晰得多。

结果

这个设计在后续的开发和调试中证明是对的。车辆状态和服务状态的异常可以独立处理——车辆掉线了，服务状态保持原样等待恢复；服务崩溃了，不影响车辆本身的状态判断。两层解耦让调试和运维的复杂度都降了一个台阶。

回看

"车辆是否可计算"和"某个计算服务是否正在运行"是两个不同的问题。把它们拆开管理这件事不复杂，但如果一开始就混在一起，后面再拆就很痛苦了。

云车通信与任务下发

车辆进入 Compute Mode 之后，底层 K3s 基础设施被拉起，Agent 随之启动。Agent 做的第一件事是通过 MQTT 向云端发送心跳，云端收到心跳就知道这辆车进入了可用状态。

当云端决定给一辆车下发任务时，链路是这样走的：云端把部署指令放到 MQTT 中，车端的 Agent 主动拉取 MQTT 消息，知道它需要拉起一个新任务，然后调用 K3s 的 API 启动对应的服务。任务启动之后就是一个标准的 K3s 工作负载，由具体运行的服务通过 Metric 接口上报执行状态，车端的 Metric Server 采集这些数据并通过 MQTT 回传到云端。

控制链路和状态回传链路是分开的：任务下发走控制通道（云端 → MQTT → Agent → K3s），任务状态走数据通道（服务 → Metric → Metric Server → MQTT → 云端）。

当车辆处于未激活的下电状态时，车端 Agent 不存在，不能靠自己的链路获取状态。这时通过用户侧的接口查询车辆当前状态（是否在下电、是否在行驶），再根据结果决定是否触发远程激活。

实例数控制器

车辆进入云端之前需要经过一套注册流程：通过 BI 能力从大量车辆池中按筛选条件选出备选车辆，放入备选仓库。从备选仓库中选择车辆触发首次注册运行，用户收到通知，车辆启动后在云端完成注册认证，正式纳入资源池。

在此基础上，我设计了实例数控制器。工作方式是：服务侧提出目标实例数（比如"我需要 20 个实例"），控制器实时检查当前可用车辆的运行状态，如果在线实例不足就选择合适的车辆拉起，如果在线实例超出目标就通过业务关机指令释放多余车辆。

车辆并不是完全同质的。不同版本的车辆存在硬盘数量和内存容量的差异，这些信息在车端启动后由 Agent 整理并上报云端。云端据此知道不同车辆的资源配额，下发任务或服务时会考虑车辆的实际资源情况来选择合适的目标。

不稳定节点的调度困境

处境

车辆不是数据中心服务器。车辆的启动时间、网络质量、用户行为和硬件安全流程都会造成状态延迟。测试过程中频繁出现一个问题：云端发起车辆拉起指令后，车辆实际上已经开始启动了，但因为车端网速慢或者启动流程长，状态迟迟没有上报到云端。云端等不到状态，认为这辆车没有启动成功，于是又去拉起其他车辆。最终出现的现象是车辆数量不确定、部分车辆频繁启停。

桌上的选项

一条路是在车端做优化——缩短启动时间、加快状态上报。但车端版本处于锁版状态不可轻易修改，车辆的启动时长又受到硬件安全流程约束，不适合调整。另一条路是在云端适配——既然车端的物理约束改不了，就让云端的调度节奏去适应车端的响应速度。

我的选择

我选了调整云端。把调度策略从高频实时调度改成 5 到 10 分钟一个周期的批量调度。每个周期内统一评估当前车辆状态、决定拉起和释放，不在周期中间频繁发起启停指令。

代价

调度的响应速度变慢了——从"需要一辆车就立刻拉"变成"等到下一个调度周期再统一处理"。对于需要快速扩容的场景不够灵活。

结果

频繁启停的问题基本消失了。批量调度给了车辆足够的时间完成启动和状态上报，云端不再因为短暂的状态延迟而做出错误判断。

回看

这是一个典型的"用云端系统设计适配物理世界约束"的案例。当系统的一端是不可控的物理设备时，把灵活性和容错留在云端，比强行要求设备端配合要务实得多。

车辆状态验证与实车测试

调度逻辑在代码层面跑通是一回事，车辆在真实环境下是否按预期行为又是另一回事。测试过程中我们频繁遇到一类问题：车辆的启动和关闭与预期不符。

典型的情况是：云端判断某辆车应该已经正常启动了，但实际上车辆只完成了部分启动流程——某些模块起来了，另一些没有，或者不同模块之间的状态出现了不同步。这不是单一的 Bug，而是一个系统性的问题：整车有多个独立控制的子系统（底软、网络、智驾软件、K3s），每个子系统有自己的启动时序和健康检查逻辑，当它们的实际行为和设计时序产生偏差时，整体状态就会出现不一致。

这类问题没有办法在云端远程定位，必须到车端实测。我们经常需要去实车上接调试设备，把各个子系统的实际启动时间点和状态变化采集出来，和云端记录的状态时间线对齐，才能看清楚到底是哪个环节的行为偏离了预期。

因为车端的软件和硬件分别由不同团队负责，我们在这个过程中的角色是：负责状态验证和异常发现，定位到具体是哪个子系统的行为不符合预期，然后把问题和现象推送给对应的车端软件或硬件团队去解决。这个"测试→定位→分发→跟进"的循环跑了很多轮，直到各个子系统在 Compute Mode 下的启动行为逐步稳定下来。

技术架构：云车计算闭环

                        ┌──────────────────┐
                        │    BI 筛选引擎    │
                        │ 从车辆总池筛选候选 │
                        └────────┬─────────┘
                                 │
                                 ▼
                        ┌──────────────────┐
                        │   车辆备选仓库    │
                        │ 触发首次注册运行   │
                        └────────┬─────────┘
                                 │
              ┌──────────────────┼──────────────────┐
              │                  │                  │
              ▼                  ▼                  ▼
    ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
    │  车辆 A       │   │  车辆 B       │   │  车辆 C       │
    │  Agent + K3s  │   │  Agent + K3s  │   │  Agent + K3s  │
    │  ↕ MQTT 心跳  │   │  ↕ MQTT 心跳  │   │  ↕ MQTT 心跳  │
    └──────┬───────┘   └──────┬───────┘   └──────┬───────┘
           │                  │                  │
           └──────────────────┼──────────────────┘
                              │
                              ▼
               ┌────────────────────────────┐
               │     云端车辆资源池          │
               │                            │
               │  在线车辆状态（双层状态机）   │
               │  · 车辆状态：下电/行车/算力  │
               │  · 服务状态：待机/运行/停止  │
               │  · 资源配额：按车型版本区分  │
               └──────────┬─────────────────┘
                          │
                          ▼
               ┌────────────────────────────┐
               │    实例数控制器（我设计）     │
               │                            │
               │  服务目标：需要 N 个实例     │
               │  当前在线 < N → 选车拉起     │
               │  当前在线 > N → 释放多余     │
               │  调度周期：5-10 分钟批量     │
               └──────────┬─────────────────┘
                          │
                          ▼
               ┌────────────────────────────┐
               │  任务下发（控制链路）        │
               │  云端 → MQTT → Agent → K3s  │
               │                            │
               │  状态回传（数据链路）        │
               │  服务 → Metric → MQTT → 云端 │
               └────────────────────────────┘

技术体系建起来之后，项目进入了另一个维度：这件事到底能不能赚钱。

章五：商业验证 — 可行域持续收窄

成本模型的诞生

推进到一定阶段后，智能硬件的大老板要和智驾大老板沟通成本问题，让我准备一份汇报材料。我去找智能硬件团队牵头，联系热管理和芯片团队，逐一计算每个元器件的使用时长和损坏概率，由这些数据反向推导出每辆车在什么条件下应该启动多久，再根据启动时长计算收益率曲线是否划算。

材料写完之后，先给我的老板过目。老板的反应让我记忆深刻。他问了几个问题："是谁要汇报？是对面的老板。那你为什么要汇报？为什么不让他们汇报？汇报的材料为什么不赚钱？为什么这些成本要我们团队承担？这些成本不应该存在，需要把它做掉。"

这次被喷之后，我进入了为期一个月的数据磨合。这个月的工作方式和之前完全不同——不是写代码、不是推方案，而是反复和热管理、芯片、硬件团队坐在一起核对数据。

水冷系统是第一个要啃的硬骨头。每一次 Compute Mode 启动都需要开启液冷循环，而液冷系统有自己的寿命曲线——启停次数越多，密封件和泵体的磨损越快。我需要从热管理团队那里拿到具体的启停寿命数据，然后反向推算：如果每辆车每天启动 N 次，水冷系统的预期寿命会缩短多少？这个缩短对应多少维修成本？维修成本分摊到每次算力使用上是多少钱？

同样的逻辑套到高压供电模块、Orin 芯片本身的功耗和热循环寿命、存储设备的读写损耗。每一个元器件都有自己的寿命模型和损坏概率曲线，我需要把这些曲线叠加在一起，计算出一辆车在不同使用强度下的综合损耗成本。然后把这个成本和算力收益放在一起，画出收益率曲线——在什么使用强度下收益最大化，超过什么阈值后损耗成本开始吃掉收益。

这个过程中我逐渐对车上每一个相关元器件的寿命和成本如数家珍——水冷的启停次数上限、不同环境温度下的冷却效率衰减、高压供电模块在反复通断下的概率失效率、Orin 在不同工况下的能耗曲线和热降额行为。这些知识不是从文档里读来的，而是在和各个团队反复对数据的过程中一点点积累的。

老板的那些问题本质上是在要求我从"成本分析"转向"商业模型"——不只是算花多少钱，而是这个模式到底能不能赚钱。这个转变对我的影响很深：以前做工程决策的时候，我的思维终点是"系统跑起来了"；从这个月开始，思维终点变成了"这件事在经济上是否合理"。

经济性测算

最终形成的经济性模型把以下变量放在同一个框架里：

车辆可利用时间方面，从全量车辆的运行数据中调出每辆车的实际驾驶时长，平均每天约半小时。剩余时间按用户画像做错峰分析，避开早晚高峰，识别出夜间等大段可利用时段。

算力价值方面，以首 Token 延迟和推理吞吐为指标，对标市场上的在线推理服务价格。

成本方面：电费按 0.5 元/kWh 计算，车辆在全功率推理状态下的功耗约 500W。水冷是车辆寿命的主要约束之一——频繁启动会加速水冷系统磨损，最终测算出每个调度周期约启动 2 次是比较合适的平衡点。此外还有车辆折旧、元器件概率损坏等长期成本。

算下来的结论是：勉强能赚一点。

工程验证结果

在百辆车的测试场景下：最高约 60 辆车同时在线，能够提供一批相对稳定的计算服务。请求时延约 120 毫秒，推理首 Token 约 240 毫秒。

这些数字证明了技术可行性——车辆确实可以作为推理节点提供服务，而且延迟在可接受范围内。

场景收窄与客户验证

技术跑通之后，接下来是找到真正适合这种算力的业务场景。

第一个发现是 Orin 跑长上下文的推理时偏慢。长文处理不好用，那是不是可以做一些简单的判断——比如 True/False 分类这种低延迟的场景？内部确实有一些团队存在这种需求。但进一步测算输入输出的时延，加上网络传输、Tunnel 中转等开销，和内网直连的标准推理服务对比，发现接口延迟成了新的瓶颈。

与此同时，和云厂商的 4090 等标准化算力对比，车端算力在稳定性和资源质量上都存在劣势。算力不稳定带来的额外调度、启停和资源浪费成本，很难在简单的算力价格模型里合理消化。

我和 +2 一起多次出去拜访客户，走访了包括快手和金山在内的多家公司。其中金山的反馈比较明确：如果算力足够便宜，并且实际可用，会有使用意愿。双方完成了真机测试验证。下一步本来应该是业务真正跑通、上量后再进行一轮面向客户的技术验证，但因为车端版本、项目优先级和推进节奏等原因，没有进入下一阶段。

可行域在持续收窄。每多做一轮验证，适合的场景就少一些，市场规模就小一些。从"很多场景可以"到"几十个场景可以"到"只有特殊场景可以"——路子越来越窄。最终我进入了一种自己也很难说服自己的状态。

最终商业结论

这个项目最终的商业判断不是"车端算力完全没价值"，而是当时的商业模型存在几个结构性问题：

供给侧：车端提供的是低价、低端但不稳定的算力。

需求侧：很多业务场景对这种算力的需求量并不够大，难以形成规模。

竞争侧：和云厂商 4090 等标准化算力相比，车辆算力在稳定性和资源质量上存在劣势。

成本侧：车辆不稳定带来的调度、启停、资源浪费等隐性成本，很难完全反映到简单的算力价格模型里。

所以结论是：技术成立，但在当时的数据下，商业经济性不足。

这个结论不是我主动叫停项目得出的——我没有项目终止的权限。老板一直要求继续探索，我就一直在不同维度上做验证。最终项目是随着公司战略调整而停止的。

落地与团队

项目持续约一年（2024.02–2025.03），从 POC 一路推到百辆车规模测试和商业验证。

我的角色经历了一次变化：前期是虚线的项目负责人，负责跨团队推进；后期因为需要有一个实体团队来持续探索，变成了实线的技术团队 Leader。项目无限期搁置之后，我把团队拆散并入了计算加速组。

涉及的团队包括：云端平台（我负责）、Infra（K3s 基础设施）、智驾系统（Compute Mode 启动序列）、底软 / 智能硬件（控制信号、启动流程）、网络控制（远程唤醒）、热管理（冷却和寿命评估）、芯片（Orin 相关确认）、法务（合规和用户协议）、运营（手机端交互）、产品经理（业务推进）、系统工程师（方案串联）。

核心验证数据：百辆车级测试，最高约 60 辆同时在线；请求时延约 120ms；推理首 Token 约 240ms；全功率推理功耗约 500W；水冷最优启动频率约每周期 2 次。

回看这个项目

这个项目走完了一条很少有人完整走过的验证链：

创新假设（车端闲置算力有价值）
       │
       ▼
技术可行性（POC：车可以成为计算节点）
       │
       ▼
工程可行性（Compute Mode + 整车系统改造）
       │
       ▼
组织可行性（十余个团队协同推进）
       │
       ▼
规模验证（百辆车测试，60 辆同时在线）
       │
       ▼
成本模型（元器件寿命、功耗、水冷、ROI）
       │
       ▼
客户验证（快手、金山等实际沟通和测试）
       │
       ▼
商业判断：技术成立，商业在当时条件下不成立

很多团队停在第一步或第二步。这个项目一路走到了最后——用真实数据给出了完整的商业判断。

如果重来，我认为在局部技术决策上最大的遗憾是接受了重启方案。软件层面的清理方案是可以推得动的，但在争论过程中我没有把这个技术判断论证到底，导致后面只能转向和硬件团队硬拼 Reset 方案。虽然 Reset 最终通过了，但路径绕了一大圈。

在项目层面，最大的体会是：技术可行性和商业可行性是两件完全不同的事。我把一个从技术上可以做的东西做出来了，但做成之后通过完整验证发现它在当时的条件下不值得做。这不是一个失败的结论，而是一个用数据支撑的判断——它告诉我，以后面对任何创新方向，"能不能做"只是第一个问题，"值不值得做"才是真正需要回答的问题。

回头看自己在这个项目里的角色变化，其实比任何一个技术决策都更值得记录。

项目刚开始的时候，我的身份很清楚：一个做基础设施的工程师。POC 阶段我干的事情是搭 K3s、写 Agent、调 Tunnel——这些都是我的舒适区，边界清晰，产出可度量。

到了 Compute Mode 阶段，我的工作开始变了。我不再只是写代码，而是在定义一个不存在的系统应该长什么样——哪些模块需要启动、哪些不需要、启动顺序是什么、各团队的职责边界在哪里。这更接近系统架构师的角色，但又不完全是，因为没有人给我一个明确的"架构设计"任务，我是在推进项目的过程中被迫去做这些定义的。

再到跨团队推进阶段，我发现自己大部分时间不是在写代码或画架构图，而是在理解各个团队的技术方案、识别真正的约束、在分歧中找到可以用证据推进的突破口。containerd 争议、Reset 推进、和底软团队反复交锋——这些工作的本质不是协调，而是技术博弈。我需要理解对方的技术语言，才能判断他们说的"不行"到底是真的不行还是不想做。

最后到商业验证阶段，我的工作又变了一次。被老板喷完之后的那个月，我每天面对的不是系统设计问题，而是成本曲线、收益模型、元器件寿命概率——这些东西和我之前十年的工程训练完全不在一个维度上。但正是这段经历让我意识到，"能不能做出来"只是创新项目的起点，"做出来之后值不值得"才是终点。

从基础设施工程师到系统架构，再到跨团队的技术博弈推进者，最后到用数据做商业判断——这条线不是我规划出来的，而是项目一步步推着我走到的。这个项目留给我的不是 K3s 或 GPU 的技术经验——那些随时可以学。真正留下的是三件事：第一，对整车计算架构、安全、电力、冷却和硬件寿命模型的实际理解，这些不是写代码能学到的；第二，一种从"观点争论→找一手证据→用数据改变讨论基础"的工作方法；第三，从工程可行性推导到商业可行性的完整思维链——这是后来加入创业公司之后能快速判断方向的底层能力。