斑马把23B模型塞进了车里

斑马智能发布 AutoOmni 2.0，端侧大模型进入“全模态”竞争

9月23日，云栖大会期间，斑马智能正式发布新一代全模态端侧大模型 AutoOmni 2.0-23B-A3B。

这不是一次单纯的参数升级。斑马智能想解决的问题，是把原本依赖云端完成的视觉理解、语音交互、任务规划和座舱控制，尽可能搬到车端运行。模型总参数规模达到23B，但通过 MoE（Mixture of Experts，混合专家）架构，将单次推理的激活参数压缩到约3B，让一套看起来“23B”的模型能够在车载芯片上工作。

按照斑马智能公布的信息，AutoOmni 2.0 在智能座舱普通任务上的能力，可以对标参数规模约为其10倍的云端模型；对于更复杂的任务，整体能力达到同类云模型的80%至90%。这组说法仍然属于厂商发布口径，缺少公开评测集、延迟、功耗和芯片配置等关键数据，但它至少说明一个趋势：车载大模型的竞争，正在从“能不能接入大模型”转向“多少能力可以留在车里”。

23B-A3B，重点不在23B，而在3B

AutoOmni 2.0 的型号里，23B-A3B 有两个数字：23B 代表模型总参数规模，A3B 通常指单次推理时实际激活约3B参数。

两者的区别，可以类比成一家拥有23个专家的公司，但每次接到任务时只安排其中3位相关专家处理。其他专家并不是不存在，而是不会在每次请求中同时参与计算。这样做的好处是，在保持较大模型容量的同时，降低单次推理对算力、显存和带宽的需求。

对于车载场景，这一点尤其重要。云端模型可以依赖大规模 GPU 集群，车端模型却受到芯片功耗、散热、内存和成本的多重约束。汽车不是数据中心，车机也不可能无限堆叠显卡。一个模型即使在服务器上表现出色，只要无法在车载平台上稳定运行，就很难真正转化成产品能力。

MoE 因此成为端侧大模型的重要路线之一：模型总容量可以继续扩大，但通过稀疏激活控制推理成本。不过，MoE 并不等于“免费获得更大模型”。它仍然需要保存完整的专家参数，对内存容量、模型加载、专家路由和芯片调度提出更高要求。车端部署真正难的地方，不只是把模型量化到能跑，而是要让不同专家在有限带宽下快速切换，并且避免多轮对话、连续视觉输入和语音流式处理把系统拖慢。

换句话说，AutoOmni 2.0 的看点不是简单地把云模型缩小，而是试图在模型容量和端侧实时性之间做一次工程折中。

全模态不是“多一个看图功能”

过去的车载语音助手，更多是一个语音入口：用户说一句话，系统识别文本，再匹配指令或调用服务。遇到车外环境、车内物体、仪表信息、连续对话和复杂上下文时，这套架构很快会暴露局限。

全模态模型的目标，是让系统同时理解多种输入，并把这些输入放在同一个上下文里处理。比如，用户可以指着中控屏上的某个图标询问用途，也可以让系统结合当前导航路线、车辆状态和此前对话给出建议；在更复杂的情况下，系统还需要理解视觉信息、语音内容、环境变化以及用户的隐含意图，然后决定是直接回答、调用车控能力，还是继续追问。

这与传统的“语音识别 + 意图识别 + 固定指令”不同。后者像一张很大的菜单，用户必须说出系统预设的表达；全模态模型则更像一个能够理解上下文的调度层，负责把自然语言、画面和车内服务连接起来。

但也要看到，全模态在汽车里的价值并不只取决于模型能不能识别图片或声音。车载场景要求系统做到三件事：

1. 理解要准：误把路牌、行人、车辆状态或驾驶员意图识别错，代价可能高于普通聊天场景。
2. 响应要快：驾驶过程中，几秒钟的等待就足以让用户放弃使用语音交互。
3. 动作要稳：模型不能只会说，还要能安全地调用空调、车窗、导航、座椅和娱乐系统等能力。

因此，AutoOmni 2.0 的实际竞争力，最终要看它能否把感知、推理和执行串成一个稳定闭环，而不是发布会上的单轮演示效果。

为什么斑马要把能力放到端侧

端侧推理最直接的优势是低延迟。用户说完一句话后，语音识别、意图判断和部分回答可以在本地完成，不必把每一帧音频或图像都上传到云端。对于连续对话和实时视觉理解，这种差别会非常明显。

第二个优势是网络依赖更低。车辆经常处于信号不稳定、网络切换或没有连接的环境中。如果所有智能能力都依赖云端，一旦网络抖动，助手就可能从“反应慢”变成“完全不可用”。端侧模型至少可以兜住基础能力，让导航辅助、车况问答、车控指令和部分视觉交互在弱网甚至离线情况下继续工作。

第三是隐私。座舱内部包含大量个人信息，包括家庭成员对话、行程、位置、偏好和车内影像。把更多数据留在本地，可以降低原始数据持续上传的需求。当然，端侧并不自动等于隐私安全，模型日志、云端同步、远程升级和第三方服务调用仍然需要完整的权限和审计机制。

这也是 AutoOmni 2.0 与普通云端大模型接入方案最大的差异：它不是单纯增加一个聊天入口，而是试图成为车机系统的本地智能中枢。

“媲美10倍云模型”，还需要更多数据证明

斑马智能给出的性能表述很有吸引力：普通座舱任务能力相当于10倍参数量的云模型，复杂任务达到其80%至90%。但开发者需要对这类说法保持谨慎。

首先，“普通任务”和“复杂任务”的定义并不清晰。普通任务可能包括车控、媒体控制、简单问答和固定场景导航；复杂任务则可能涉及多轮推理、跨模态理解和多个工具调用。如果任务集合经过定向优化，端侧模型可能在特定场景中表现很好，但这不等于它在通用知识、长上下文、开放式推理和异常输入处理上全面追平云端模型。

其次，参数规模并不是衡量模型能力的唯一指标。训练数据、后训练方法、工具调用框架、量化精度、推理引擎、上下文长度和芯片适配都会影响最终结果。一个针对智能座舱进行深度优化的3B激活模型，在车控任务上击败通用云模型并不奇怪；但让它承担开放领域问答或长链路规划，结论可能完全不同。

再次，车端模型的评测不能只看回答是否正确，还要看平均响应时间、首 token 延迟、持续运行功耗、温升、内存占用、弱网表现和错误恢复能力。车机每天运行数小时，偶发一次卡顿、崩溃或错误执行，都会直接影响用户对系统的信任。

所以，AutoOmni 2.0 目前更像是一款面向座舱落地的专用基础模型，而不是要在所有能力上挑战通用云端旗舰模型。它的优势应当放在场景深度、响应速度和系统整合，而非单纯比较参数规模。

对开发者意味着什么

如果 AutoOmni 2.0 最终能够在量产车上稳定运行，车载应用的开发方式可能会发生变化。

过去，开发者往往需要为每一项功能单独设计语音指令、意图分类和槽位抽取逻辑。未来，模型可以承担更多自然语言理解工作，开发者则把重点转向工具定义、权限控制和执行结果校验。车控能力不再只是“打开空调”这种固定命令，也可能变成带有条件和上下文的任务，例如根据车内温度、乘员位置和剩余电量调整空调策略。

但这也会带来新的工程要求：

• 工具调用必须有边界：涉及驾驶、安全和高风险操作的指令，不能完全交给模型自由决策。
• 需要分级确认机制：低风险操作可以自动执行，高风险操作应要求用户确认。
• 模型输出必须可观测：开发者需要知道模型调用了哪个工具、使用了哪些上下文、在哪一步出现错误。
• 端云协同仍然必要：本地模型适合实时和隐私敏感任务，复杂知识问答、长文本生成和跨设备服务仍可能交给云端。
• 更新机制要可靠：模型升级不能像手机 App 更新一样简单，必须考虑车辆生命周期、回滚、安全签名和不同芯片版本的兼容性。

这意味着，端侧大模型落地后，汽车软件栈不会变得更简单，而是从传统规则系统转向“模型 + 工具 + 安全策略 + 端云协同”的组合架构。

端侧大模型的下一场竞争：谁能量产，谁才算赢

从行业视角看，AutoOmni 2.0 的发布符合一个明确趋势：大模型正在从云端 API 竞争，进入终端设备的系统级竞争。

手机、PC、汽车和机器人都在争夺本地推理能力。汽车的特殊之处在于，它既是移动终端，也是一个高安全要求的实时系统。模型不能只追求“聪明”，还要满足持续运行、低延迟、可解释、可回滚和可验证。

斑马智能选择用23B总参数、3B激活的 MoE 架构切入，路线是合理的：既保留较大的知识和能力容量，又尽量控制端侧推理成本。但这条路线是否成功，最终不取决于发布会上的模型规模，而取决于三件事：第一，能否适配主流车载芯片并保持稳定帧率；第二，能否在真实道路和复杂噪声环境中持续工作；第三，能否进入量产车型，而不是停留在演示车和实验室环境。

如果这些问题能够解决，AutoOmni 2.0 会成为车载智能从“云端助手”转向“本地代理”的一个重要节点。反过来，如果公开信息始终停留在参数和能力对标，缺少延迟、功耗、评测集与量产计划，那么它更像是一次方向性宣告，而不是已经完成验证的产品答案。

目前可以确认的是，9月23日发布的 AutoOmni 2.0，已经把端侧全模态模型的参数规模和能力目标推到了一个更高位置。接下来，行业真正关心的不是它有多少参数，而是这23B模型能否在一辆真实运行的汽车里，持续、快速且安全地理解“我的世界”。

参考来源

• 知乎站内检索：AutoOmni 2.0 —— 用于查看相关行业讨论与公开信息交叉线索。
• GitHub站内检索：AutoOmni —— 用于查看是否存在公开模型仓库、推理代码或开发者项目。

注：本文依据2026年9月23日云栖大会期间公开发布信息及题述参考资料整理。关于模型具体输入模态、适配芯片、量化精度、上下文长度、延迟、功耗和量产车型等细节，斑马智能目前尚未在题述材料中完整披露，文中相关判断不等同于官方性能承诺。