Arm KleidiAI与AWS联手优化AI定义汽车解决方案

汽车行业正迎来一场由人工智能驱动的深刻变革。生成式AI技术的突破性进展，正在重新定义智能汽车的交互体验与功能边界。麦肯锡最新行业调研数据显示，超过40%的汽车与制造业高管已在生成式AI研发领域投入高达500万欧元，更有超过10%的受访者投资规模突破2000万欧元。这不仅是技术投资，更是面向未来出行生态的战略布局。

这一趋势与“软件定义汽车”（SDV）的演进方向深度契合。行业预测显示，到2030年，单辆汽车的代码行数将从目前的约1亿行激增至3亿行。当生成式AI的强大内容生成与理解能力，与SDV高度可扩展的软件架构相结合，将为车载性能优化与个性化驾乘体验的创新，开辟前所未有的空间。

本文将深入解析一个由Arm与亚马逊云科技（AWS）共同实现的车载生成式AI落地应用案例，完整呈现其从技术架构到实际部署的全过程，为行业提供可借鉴的实践路径。

车载智能助手：解决功能认知鸿沟

现代汽车日益成为搭载复杂软件的智能终端，通过OTA（空中升级）可不断新增与优化功能。然而，一个普遍存在的痛点随之而来：车主如何快速、便捷地掌握这些日益丰富的车辆新功能？传统的纸质手册或静态电子文档更新滞后、查询繁琐，导致大量实用功能处于“沉睡”状态，严重影响用户体验与车辆价值发挥。

针对这一核心痛点，AWS与Arm联合演示了一个创新的“车载智能问答助手”解决方案。该应用本质上是一个部署于车内的本地化知识库，驾驶员通过自然语言语音或文字提问，即可实时获得关于车辆功能、操作指南的最新、精准解答。其核心技术是一个在车端离线运行的小型语言模型（SLM）。

“离线可用”是其关键优势。无论网络状况如何，驾驶员都能即时获取信息，这对行车安全与连续性体验至关重要。卓越性能是体验基础，该应用集成了经过Arm KleidiAI深度优化的计算内核，将AI推理响应时间从原来的8-19秒大幅缩短至1-3秒。这不仅提升了交互流畅度，更将整体应用开发周期缩短了约6周，使开发者能更专注于业务逻辑创新，而非底层性能调优。

在开发阶段，团队利用Arm虚拟硬件加速流程。该服务允许开发者在AWS云上快速创建树莓派等流行嵌入式开发板的虚拟实例，在全球协同开发或硬件资源紧张时，极大提升了嵌入式AI应用的开发、测试与迭代效率。相同的KleidiAI优化亦可无缝应用于这些虚拟环境。

该方案的先进性更体现在其全生命周期管理能力。通过仅占用约5MB内存的轻量级边缘运行时——AWS IoT Greengrass Lite，应用可实现安全的OTA软件更新。系统还内置了一套自动化质量监控与反馈闭环：持续评估AI回答的相关性与准确性，将低置信度或异常响应自动标记并上报。整车厂的质保团队可通过一个近实时的AWS仪表板，直观监控全局表现，快速定位问题环节，并触发后续的模型微调与重新部署流程。

这远不止是一个“语音版说明书”。它代表了SDV时代一种全新的产品运营与用户服务范式：整车厂可以基于真实的用户交互数据，持续优化产品功能，甚至主动向用户个性化推荐新特性或增值服务。通过深度融合生成式AI、物联网与边缘计算，未来的汽车将变得更智能、更贴心，真正成为懂用户的移动智能空间。

端到端架构实现详解

如此智能的系统是如何构建并落地的？下图完整展示了从模型训练、边缘部署到质量监控的闭环系统架构。

图：基于生成式AI的汽车智能问答助手解决方案架构图

整个工作流可分解为以下六个关键阶段：

1. 领域模型微调： 团队选取TinyLlama-1.1B-Chat-v1.0作为基座模型，并为其注入专业的“汽车知识”。通过精心准备的约1000组车辆功能问答数据集，在Amazon SageMaker Studio平台上对模型进行监督微调，确保其输出简洁、准确，符合行车场景下的交互需求。

2. 模型存储与验证： 微调后的模型存储在Amazon S3对象存储服务中，并首先部署到一个Ubuntu系统的Amazon EC2云服务器实例上进行功能与效果的初步验证。

3. 边缘化优化处理： 在EC2实例上，团队使用llama.cpp框架对模型进行量化（采用Q4_0方案），并集成KleidiAI优化库。这一组合优化效果显著，模型文件大小从3.8GB压缩至约607MB，为在资源受限的车载边缘设备上运行扫清了障碍。

4. 虚拟环境测试： 优化后的应用与模型被部署到由Arm虚拟硬件提供的虚拟树莓派环境中，进行全面的集成测试与性能验证，确保其稳定可靠。

5. 边缘侧部署与编排： 通过AWS IoT Core的设备管理任务功能，将生成式AI应用软件包下发至物理树莓派设备。由AWS IoT Greengrass Lite运行时负责从S3下载、安装并启动应用。

6. 交互与质量监控闭环： 部署完成后，用户即可通过语音与设备自然交互。同时，所有交互日志被收集，经由Amazon Kinesis Data Streams流式处理管道和Amazon Data Firehose传输服务，回传并存储至S3。整车厂团队通过Amazon QuickSight构建的业务智能仪表板，即可对模型回答质量进行持续监控与分析。

接下来，我们将深入该演示中的两个核心技术细节：Arm KleidiAI优化库及其所加速的量化方案。

Arm KleidiAI：释放Arm CPU的AI算力

Arm KleidiAI是一个面向AI框架开发者的开源高性能计算库。其核心目标是为Arm架构的CPU提供一系列经过极致优化的基础计算例程。自2024年5月发布以来，它已支持对32位浮点（FP32）、Bfloat16（BF16）及4位定点（INT4）等多种数据格式的矩阵乘法进行硬件加速。

这些优化充分挖掘了Arm CPU的硬件潜力，例如利用SDOT和i8mm指令加速8位整数运算，利用MLA指令提升32位浮点性能。在本演示采用的树莓派5（搭载四核Cortex-A76处理器）上，KleidiAI便有效利用了SDOT指令的优势。SDOT指令是Arm持续加码AI计算领域的一个标志，其最早随Armv8.2-A架构引入，后续又陆续推出了i8mm、BF16等扩展指令集，持续提升CPU处理AI工作负载的能效与性能。

llama.cpp中的Q4_0量化格式解析

在本案例中，模型通过llama.cpp的Q4_0格式进行量化以提升效率。该格式在计算矩阵乘法时的数据组织方式如下：

• 左侧矩阵（LHS，激活值）以32位浮点数（FP32）格式存储。
• 右侧矩阵（RHS，权重）则被压缩为4位定点（INT4）格式。具体而言，每32个连续的4位权重共享一个16位浮点数（FP16）表示的缩放因子。

这里存在一个技术融合点：KleidiAI的SDOT指令专为8位整数点积设计，而本方案中权重是4位，激活值准备阶段是32位浮点，它们如何协同工作？

答案是“动态量化”与“即时解压”。对于LHS矩阵（激活值），在计算前会实时将其量化为8位定点格式（同样采用分块量化策略）。对于RHS矩阵（权重），那些4位权重在参与计算前，会被高效地“解压”还原为8位数值。既然最终都用8位计算，为何不直接使用8位量化？

采用4位量化主要带来两大核心优势：

第一，模型存储体积减半。这对于内存资源紧张的车载边缘设备至关重要。

第二，显著提升文本生成速度。文本生成是典型的“内存带宽受限”型任务，其性能瓶颈往往在于将权重数据从内存搬运至处理器的速度，而非处理器本身的算力。将权重数据量减少一半，意味着传输相同计算量所需的数据更少，从而能更快地完成文本生成任务。

如何将KleidiAI集成到llama.cpp？

对于开发者而言，集成过程极为简便。KleidiAI的优化已直接内置于llama.cpp的主干代码中。这意味着，开发者在基于Arm架构的移动设备、嵌入式平台或云服务器上部署llama.cpp时，无需任何额外配置，即可自动获得针对Arm CPU的极致性能加速。

除了llama.cpp，还有哪些框架支持？

当然。llama.cpp是在Arm CPU上高效运行大语言模型的优秀选择之一，但生态支持更为广泛。目前，包括ExecuTorch、MediaPipe、MNN以及PyTorch在内的多个主流生成式AI与移动端推理框架，均已集成KleidiAI的优化。开发者只需确保使用这些框架的最新版本，即可为部署在Arm平台上的AI应用带来显著的性能提升。

总结与展望

软件定义汽车与生成式AI的深度融合，正在开启汽车智能化与个性化体验的新篇章。本文剖析的由Arm KleidiAI优化与AWS云服务共同赋能的车载AI助手案例，不仅是一个技术原型，更是一套解决行业真实痛点的完整方案——它将响应时间压缩至1-3秒，并缩短数周开发周期，证明了高效、离线可用的车载生成式AI应用不仅是可行的，更是提升用户体验的关键。

未来的汽车技术，必然是边缘计算、物联网与人工智能技术无缝融合的产物。随着汽车软件复杂度的指数级增长，类似本方案的智能交互与知识管理平台，将成为连接尖端汽车功能与用户日常使用之间的重要桥梁。这场由AI驱动的汽车产业变革，已然加速驶来。