自动驾驶和具身机器人这类端侧场景，不能被理解成“把云端推理系统缩小部署到车上或机器人上”。真正的差异不在部署位置，而在模型闭环：云端首先面对请求流，端侧首先面对控制周期。所以端侧 AI OS 的第一问题，往往不是吞吐，而是“这组关键模型在每一拍里能否稳定、可预测地完成”。

先说结论

• 云端 AI OS 的中心对象更像 request / batch / token / session，端侧 AI OS 的中心对象更像 model graph / deadline / accelerator slot / persistent feature state / fallback path。
• 当前端侧系统更适合在 model / subgraph / state ownership / mode / fallback contract 这组粗粒度对象上组织自己。
• 真正值得继续展开的端侧子层，会自然落到 framework、state runtime、placement、mixed-criticality scheduler 和 fallback runtime 上。

前面几篇文章，主线基本都建立在云端服务这个语境上。

无论是大模型 serving、KV cache、continuous batching，还是 token、request、QoS、distributed runtime，这些问题的中心都比较明确：系统面对的是持续到来的请求流，要在算力、显存、吞吐、尾延迟和多租户之间做平衡。

但如果把视角切到端侧，尤其是自动驾驶和具身机器人场景，问题的形态会发生根本变化。

这次我想把讨论严格收在“模型运行时”这一层，不去展开传感器、时间同步、DSP、ISP 或前端预处理链路。默认这些前置都已经正常工作，真正的问题是：

当所有关键模型都已经落在 GPU / NPU 上之后，端侧 AI OS 到底应该围绕什么对象组织自己？

我的判断是：

云端首先是吞吐机，端侧首先是延迟机。

而且这句话在端侧并不只是“低延迟更重要”这么简单。更准确地说，在自动驾驶和具身机器人里，系统的主目标已经不是“单位时间内服务多少请求”，而是：

• 每个控制周期内，关键模型能否稳定完成
• 在 batch 接近 1 的情况下，整条模型链是否还能保持确定性
• 多个 NPU、多个 NPU core、甚至双 GPU/双 Orin 之间，模型图到底该如何切分、放置、调度和降级

一旦把问题收缩到这层，你会发现端侧 AI OS 的中心对象，和云端非常不一样。

云端系统更像在围绕这些对象组织自己：

• request
• batch
• token
• session
• KV cache
• QoS

而端侧模型系统更像在围绕这些对象组织自己：

• model graph
• deadline
• accelerator slot
• persistent feature state
• fallback model path
• actuation-critical output

这也是为什么我更愿意把端侧 AI OS 理解成：

一个以模型编排、异构执行和 deadline 保证为中心的系统层

而不是“小一号的云推理系统”。

但这里必须把一个现实约束先说死：今天很多端侧平台虽然也有多个 NPU core、多个 GPU、甚至双 Orin，但系统层通常并没有云端那种“统一可编程多 GPU 机器”的语义。

更准确地说：

• 双 Orin
   在很多真实系统里更像通过网络互连的双节点
• 多 core NPU
   往往是编译器和驱动内部消化的执行资源，而不是系统层稳定可见的 layer-level scheduler object

所以端侧当前真正稳定可操作的粒度，通常不是：

• layer
• tensor shard
• collective group

而更像：

• model
• subgraph
• state ownership
• node role
• fallback contract

一、云端和端侧的真正区别，不是部署位置，而是模型契约不同

很多时候，大家会把“云端 vs 端侧”理解成一种资源差异：

• 云端：算力多，显存大，机器多
• 端侧：算力小，功耗紧，带宽受限

这个区别当然存在，但它还不够本质。

更关键的区别是：云端和端侧面对的模型契约不同。

云端服务里的模型契约更像：

• 有请求进来
• 尽量合并 batch
• 尽量吃满 GPU
• 在给定成本下把吞吐做高
• 在吞吐优先前提下控制尾延迟

而端侧的模型契约更像：

• 当前控制周期必须完成哪些模型
• 哪些模型是硬 deadline，哪些可以降级
• 哪些输出一旦迟到，就直接失去物理意义
• 哪些模型必须长期常驻某个加速器
• 哪些模型只能在次优路径上运行

也就是说，云端更像在做请求履约，端侧更像在做周期履约。

这个差别会直接改写系统设计。

在云端，你关心的是：

• request arrival
• batching
• memory pressure
• GPU utilization
• cost per request / token

在端侧，你关心的则是：

• deadline miss
• jitter
• accelerator arbitration
• graph completion time
• fallback correctness

所以端侧 AI OS 的第一问题不是“如何吃满算力”，而是“如何让关键模型在每拍都按时完成”。

二、batch≈1 意味着什么：吞吐目标让位于 deadline 目标

用户前面提到一句非常关键的话：

端侧和云端最大的业务区别是 batch 是 1，吞吐机变为了延迟机。

这句话我非常认同，但还想再往前推一步。

端侧很多时候不是简单意义上的 batch = 1，而是：

• 空间批次接近 1
• 时间批次被控制周期锁死
• 系统几乎没有靠“攒请求”换吞吐的空间

这会导致很多云端有效的优化，到了端侧不再成立，甚至会反过来伤害系统。

比如云端常见的想法是：

• batch 大一点更划算
• 多个请求合并更划算
• 某些路径等一等更划算
• 平均延迟差一点可以接受

但端侧很多时候恰恰相反：

• batch 做不大
• 不一定有可合并对象
• 等一等常常不是“体验差一点”，而是直接 miss deadline
• 平均延迟不是关键，最坏情况才关键

所以端侧真正关心的不是：

• throughput
• average latency

而是：

• worst-case latency
• determinism
• deadline guarantee
• jitter bound

这和云端 serving 的世界观几乎是两套语言。

云端系统怕的是“卡利用率不够”；
端侧系统怕的是“这一拍没跑完”。

这也是为什么端侧 AI OS 的调度核心，不会是 continuous batching，而会更接近：

• 静态图执行
• 周期槽位分配
• mixed-criticality scheduling
• accelerator reservation

三、端侧真正的一等对象，不是 request，而是 model set

云端系统最自然的一等对象是 request。因为一切围绕请求到来、请求排队、请求完成展开。

端侧则不同。

在自动驾驶和具身机器人里，真正更像一等对象的，往往不是单个输入，也不是单次推理调用，而是：

一个控制周期里必须完成的模型集合

换句话说，端侧要管理的不是 request queue，而是 model set。

这组 model set 可能包括：

• perception model
• occupancy / scene representation model
• tracking / prediction model
• planning model
• control policy model
• world-model update block
• safety-check block

自动驾驶和具身机器人在具体业务上差异很大，但在系统结构上却有一个很强的共同点：

• 都不是“跑一个大模型”这么简单
• 都是多个模型或多个图共同组成闭环
• 真正难的是这些模型之间的先后关系、共享状态、驻留位置和 deadline 竞争

所以如果说云端 AI OS 更像 request scheduler，
端侧 AI OS 更像 model-set orchestrator。

一旦你接受这个判断，很多系统问题就会自然浮出来：

• 哪些模型必须每拍执行
• 哪些模型可以降频执行
• 哪些模型可以在降级模式下切成更小版本
• 哪些模型必须固定在某个 NPU core
• 哪些模型适合跨两个 GPU 分工执行

这已经不是“部署模型”问题，而是“组织模型系统”问题。

四、自动驾驶和具身机器人的共同点：都在逼出多模型、异构、分级的 runtime

很多时候，自动驾驶和具身机器人会被理解成很不一样的两类系统。

从业务和模型内容上看，它们当然不一样：

• 自动驾驶更偏场景理解、预测、规划
• 具身机器人更偏操作、接触、动作生成

但如果只从模型运行时和系统角度看，它们有几个非常强的共同点。

第一，都是多模型系统。
不是一个模型接管一切，而是多个模型或多个子图共同形成闭环。

第二，都是异构加速系统。
单一 GPU 或单一 NPU 很难长期优雅承接全部路径。

第三，都是分级系统。
不是所有模型都同样关键，有的属于硬路径，有的属于增强路径，有的属于可选路径。

第四，都是状态系统。
模型不是每拍从零开始跑，前后周期之间存在持续状态、特征缓存、世界模型 latent 或短期记忆。

这四点叠起来，几乎天然会逼出一个新的 runtime：

• 它必须理解模型优先级
• 必须理解异构放置
• 必须理解状态驻留
• 必须理解 deadline
• 必须理解 fallback

这也是为什么端侧 AI OS 的核心创新，不会首先落在“模型参数更大”上，而会落在“这组模型如何作为一个系统运行”上。

五、端侧真正要先面对的，不是单个优化点，而是四类系统压力

前面已经把端侧和云端在目标函数上的差异立住了。接下来如果继续往下压，一篇总论最该做的，不是提前把 placement、state、scheduler、fallback 的细节全部展开，而是先把端侧系统真正面对的四类压力框出来。

1. 模型集合压力

端侧通常不是“跑一个模型”，而是在一个控制周期里维护一组必须共同成立的模型集合。

2. 状态压力

端侧不是 stateless inference。很多关键 feature、latent、hidden state 都要跨拍持续存在。

3. 放置压力

即使今天系统层通常只能稳定在 model / subgraph 粒度上做编排，模型图到底放在哪个执行域、状态归谁所有，仍然会直接影响行为闭环。

4. 接管压力

端侧不能把错误简单理解成服务失败，而必须考虑 degraded mode、fallback path 和行为接管。

这四类压力，才是端侧 AI OS 真正的骨架。
后面的 14-19，其实都只是在分别展开这四根骨架。

六、当前现实下，端侧系统更适合按粗粒度对象理解

在今天的大多数工程现实里，更稳妥的写法仍然应该是：

• 双 Orin
   更像双节点
• 多 core NPU
   更像 compiler / driver 内部资源
• 系统层更稳定可见的对象是：
• model
• subgraph
• persistent state ownership
• mode
• fallback contract

这意味着端侧总论篇不应该提前滑向：

• layer-level placement
• tensor sharding
• 细粒度 collective 语义

这些问题当然很重要，但它们更适合放到后面的边界探索和愿景篇里讨论，而不是在总论里提前假设已经成立。

七、自动驾驶和具身机器人的共同点，够支撑一条统一的端侧主线

虽然自动驾驶和具身机器人业务差别很大，但从系统层看，它们已经足够共享同一条主线：

• 都是多模型闭环
• 都是强 deadline
• 都依赖 persistent state
• 都需要 mixed-criticality 调度
• 都必须考虑 fallback / degraded mode

这也是为什么我一直坚持把端侧问题收在“模型系统”这一层，而不是沿着具体传感器、具体硬件接口或某个单独任务去写。

因为只要把这几个共同压力抽出来，自动驾驶和具身机器人就已经足够共享同一套系统语言。

八、所以端侧 AI OS 更像会长出哪些子层

如果非要在这篇总论里先给一个骨架，我会把端侧 AI OS 的核心子层先压成下面这几块：

• model-set orchestration
• persistent feature-state runtime
• graph placement runtime
• mixed-criticality scheduler
• fallback / degraded-mode runtime

注意，这里只是列骨架，不在这篇里展开细节。

因为一旦展开细节，就会自然进入后面的：

• 14
   framework anatomy
• 16
   state runtime
• 17
   graph placement
• 18
   mixed-criticality scheduler
• 19
   fallback runtime

这也是这篇作为总论篇最该保持的克制：
只定义问题和骨架，不提前把后面子层写完。

九、自动驾驶和具身机器人在系统形态上的差异，只需要点到为止

这篇里还有一个需要克制的点，就是不要过早把自动驾驶和具身机器人的分叉写得太细。

在总论层面，更重要的是指出：

• 自动驾驶更偏固定周期和更强冗余
• 具身机器人更偏更大 policy / state 和更强任务切换

这已经足够。

更细的：

• policy hidden state 怎么组织
• VLA 在端侧怎么落
• safety head 怎么接管

这些都应该留到后面专门的篇章里，而不是在总论里抢跑。

十、为什么“粗粒度对象”并不意味着系统层次更浅

这里还值得补一个很容易被误解的点。

很多人一看到端侧当前更适合围绕：

• model
• subgraph
• state ownership
• mode
• fallback contract

这些粗粒度对象组织自己，就会下意识觉得：

• 这是不是说明端侧系统层次更浅
• 这是不是说明它只是“没条件做到更细”

更准确地说，粗粒度对象不等于浅层系统，
它只意味着：

当前最值得被作为一等对象管理的，不是更细的 layer/tensor，而是这些更贴近业务闭环的系统对象。

十一、为什么当前现实和未来边界必须分层看

端侧这条线里必须始终保持一个清醒判断：

• 当前现实里，系统更自然围绕粗粒度 model / subgraph / state / mode 组织自己
• 未来如果边界继续松动，一等对象和调度粒度可能还会继续变化

也正因为如此，端侧总论最稳的姿态不是只写今天，也不是直接写未来，而是明确分成：

• 当前现实
• 未来边界

只要这两层分清，端侧这条线就会比单纯趋势判断更稳，也比只停在当前工程限制上更有长期价值。

十二、为什么这篇总论必须先限定讨论边界

端侧这个话题特别容易失焦。
一旦说到自动驾驶和具身机器人，讨论很快就会滑向：

• 传感器
• 时间同步
• ROS
• 控制器
• 整车整机架构

这些都重要，但如果总论篇一开始就把所有问题混在一起，读者很快就会失去系统抓手。

所以这篇总论刻意只收在：

• 模型运行时
• 一等对象
• 系统目标
• 当前边界
• 未来边界

这样后面再去拆 framework、operator、state、placement、scheduler、fallback，整条线才不会互相打架。

十三、为什么端侧总论最好先从模型闭环进入，而不是先从硬件参数进入

端侧话题还有一个很容易出问题的地方，就是一上来就谈：

• TOPS
• 内存大小
• 带宽
• NPU core 数

这些当然重要，但如果总论篇首先从这些指标进入，文章很容易迅速滑向“硬件综述”。
而这条线真正想讨论的，是系统在服务什么闭环、哪些对象成为一等对象、哪些子层会自然长出来。

所以总论更好的进入方式，仍然应该是：

• 先立模型闭环
• 再看硬件边界怎样约束它

这样后面 14-21 才会显得是一条系统线，而不是一组围绕平台参数展开的工程笔记。

这也是这篇总论刻意保持“先立对象、再立边界、最后才留出子层展开空间”的原因。

也正因为如此，它更适合作为端侧线的第一篇入口，而不是后面子层的压缩版。

入口篇真正的职责，是把系统主语先讲稳。

这也是它最重要的系统价值。

十四、结语：端侧 AI OS 的第一问题不是请求调度，而是模型闭环如何稳定落地

这篇文章的核心判断可以收成一句话：

端侧 AI OS 首先不是请求系统，而是模型闭环系统。

但这个模型闭环系统和云端最大的区别在于：

• batch≈1
• 吞吐退居次要
• deadline 成为主目标
• 一等对象从 request 变成 model set
• 中心状态从 KV cache 变成 persistent feature state
• 调度从 request priority 转向模型集合与模式相关的调度问题

如果说云端 AI OS 更像“围绕 request、batch、cache 和 QoS 组织算力”，
那么端侧 AI OS 更像“围绕 model graph、accelerator placement、persistent state、deadline 和 fallback 组织智能系统”。

这两者不是谁替代谁，而是在两种完全不同业务闭环下，长出来的两条系统主线。

而且越往后看，后者只会越来越重要。因为只要 AI 真正进入车、机器人以及所有需要直接承担物理后果的系统，操作系统层面的创新就不可能只停留在云端 request-serving 这一种范式上。