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优化的计算例程，将推理响应时间从原来的8-19秒大幅缩短至1-3秒。此举不仅提升了交互体验，更将应用开发周期缩短了6周，使开发者能更专注于功能创新，而非底层软件优化。

在开发阶段，团队利用Arm虚拟硬件，在AWS云上快速获取树莓派等物联网开发板的虚拟实例。这有效支持了全球团队协作，并在物理设备受限时，加速了嵌入式应用的开发与测试流程。相同的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 KleidiAI是一个面向AI框架开发者的开源库，其使命明确：为Arm CPU提供一系列经过极致优化的核心计算例程。自2024年5月发布以来，它已支持包括32位浮点、Bfloat16及4位定点在内的多种数据格式的矩阵乘法优化。

这些优化充分释放了Arm CPU的硬件潜能，例如利用SDOT和i8mm指令加速8位计算，以及利用MLA指令提升32位浮点运算性能。在本演示使用的树莓派5（搭载四核Cortex-A76）上，KleidiAI充分发挥了SDOT指令的优势。SDOT指令是Arm在AI计算领域持续投入的体现，它早在2016年的Armv8.2-A架构中引入，后续又陆续推出了i8mm、Bfloat16等指令，持续提升CPU处理AI工作负载的效能。

llama.cpp 中的 Q4_0 量化格式

在本演示中，模型通过llama.cpp的Q4_0格式进行量化以提升效率。简而言之，该格式在计算矩阵乘法时：

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

这里存在一个技术细节：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应用在车载场景下的可行性与优越性。

未来的汽车技术，必然是边缘计算、物联网与人工智能深度融合的产物。随着汽车系统日益复杂，文中所述的解决方案将成为连接尖端汽车功能与用户日常认知的关键桥梁。这场变革，正在加速进行。