最近大模型上车这件事讨论热度一直很高。某新势力车企内部做了一次很务实的工程实践通过硬件协同设计算出了一个真正跑在车规级边缘设备上的最佳边缘模型而不是把云端大模型直接砍一刀后硬塞进车机。大模型上车最难的其实不是模型本身而是算力、带宽、功耗这几条硬约束算法、芯片、系统三个角色必须一起做决策。这篇文章把整个思路、评价方法、实操流水线和常见的坑理一遍。适合正在做车载AI、边缘部署或者想搞懂端侧大模型落地门槛的工程师。1. 为什么大模型上车必须谈“硬件协同设计”而不是单谈模型调优1.1 车端的资源账单算力、功耗、带宽和成本先看一组现实数据。车规域控里给AI芯片的持续功耗通常在20W到50W之间而且大多数方案是被动散热没有数据中心那种暴力风扇芯片一旦热起来频率往下掉算力也跟着缩水。这跟云端动辄几百瓦的GPU完全是两个物种。算力方面现在车规SoC动不动宣传“几十TOPS、上百TOPS”但那是峰值是短时间能冲到的高度。真正持续运行时会受功耗墙、温度墙限制通常要打个六到八折。带宽更紧张一颗车规级SoC的内存带宽很少超过100GB/s而云端的HBM带宽动辄几TB/s。这个差距让很多在云端跑得飞起的模型上车后直接卡死。还有一个常被忽略的问题显存和内存容量。一个7B参数的模型FP16权重就14GB普通车规域控总共才8GB到16GB内存模型都塞不进去。就算把模型压到1B参数、INT8量化权重也有1GB仍然要在一次推理里被完整读一遍。边缘部署不是“能不能跑”的问题而是“在功耗、带宽、时延都有限的情况下还能不能稳定跑”的问题。我见过太多项目模型在云端精度漂亮上车后延迟直接超预期三倍原因就是只看算力不看访存。真正上车之前必须把车端的资源账单拉出来功耗预算多少、内存预算多少、带宽预算多少、P99延迟要求多少。这些数字不是装饰是后面所有技术决策的边界条件。1.2 算法与芯片到底在协同什么传统的做法是算法团队先训一个模型训完了再丢给部署团队做适配。适配团队一看发现模型里有个算子NPU不支持就换成CPU回退CPU太慢就改模型结构改完结构精度掉了再回头调模型。这个循环非常痛苦经常一个模型来回拉锯两三个月。硬件协同设计解决的就是这个错位。它的核心思想是在模型结构设计阶段就把硬件行为放进约束条件里。比如芯片提供多少 MAC 运算能力、内存带宽多少、哪些算子有硬件加速、哪些只能CPU走、缓存大小和内存对齐规则是什么。算法团队选骨干网络、定层数、选激活函数时就要对着这份“硬件成本清单”打分。我用一个生活类比解释装修房子如果先按图纸买好沙发和柜子再发现插座位置不对、承重墙不能拆只能返工。协同设计相当于水电工、木工、设计师在开工前坐在一起定好点位和尺寸后面才不用砸墙。具体到模型上协同设计至少包含三个层面一是模型结构选择比如把密集的Transformer模块换成更规整的卷积混合结构二是算子层适配比如把复杂动态范围的归一化算子替换成硬件友好的近似实现三是部署优化比如做模型分块、算子融合、内存复用。这三件事必须在同一个迭代闭环里同时发生才能找到真正的“最佳边缘模型”。2. 算出“最佳边缘模型”之前先定义评价指标2.1 评价边缘模型的四类关键指标很多人一说边缘模型就只看精度这是最容易翻车的。精度只是其中一个维度边缘场景必须同时看四类指标。精度类指标还好理解分类任务看Top-1/ mAP语音意图理解看准确率和F1多模态模型要看最终业务指标。但光有精度没用还要看性能类指标单帧延迟、P99延迟、吞吐而且必须是在目标硬件上的真实测量值。第三类是资源类指标权重文件大小、峰值内存、NPU占用率、功耗增量这些决定模型能不能和其他任务共存。第四类是稳定性指标温度升高后延迟是否抖动、极端光照输入下精度是否断崖式下跌、多模型并发时是否稳定。指标类别典型指标为什么重要怎么测精度准确率 / mAP / F1决定业务可用性离线数据集 车端回灌性能P99延迟 / 帧率决定用户体验和行车安全真机或硬件仿真器实测资源内存占用 / 功耗 / NPU占用决定能否与其它任务共存功耗仪 内存监控稳定性温度降频 / 多路争抢抖动决定量产可用性长时间老化 台架压力测试这四个维度不能分开看。一个模型可能精度最高但内存占用超过预算另一个模型精度略低但P99延迟非常稳。所谓“最佳”一定是四项约束的交集不是排行榜上的最高分。2.2 模型压缩三板斧量化、剪枝、蒸馏的硬件收益要把一个大模型塞进车规级边缘设备模型压缩是绕不开的。最常用的三个手段是量化、剪枝、蒸馏但它们对硬件的收益差异很大。量化是目前收益最直接的手段。把FP32模型变成INT8权重和激活的访存量直接减少四倍计算单元也能用上定点的MAC阵列整体性能提升非常明显。INT4甚至更低比特能进一步压缩但精度风险高而且在车规安全场景下我一般不建议全面铺开。量化有两种路线PTQ训练后量化和QAT量化感知训练。PTQ快但对敏感层很不友好QAT精度稳但需要训练资源和更多时间。两者不是单选我后面会讲一种混合做法。剪枝要分清结构化还是非结构化。非结构化剪枝就是把不重要的权重置零参数稀疏了但很多NPU加载权重时仍然按稠密矩阵读内存带宽一点没省硬件收益很低。结构化剪枝则是直接剪掉整个通道、头或者层让矩阵形状变小访存和算力都降配合硬件对齐效果好得多。所以选剪枝方案前先问芯片的稀疏加速支持到什么程度。蒸馏则是用一个大的教师模型去教一个小学生模型小模型结构可以重新设计走硬件友好的路线精度又比从头训练好很多。它通常是前三板斧里最后的兜底手段。实际项目里我先量化再结构化剪枝最后用蒸馏补精度三者也按这个顺序决定改动幅度。2.3 一道算术题用Roofline模型判断瓶颈在选模型之前我强烈建议先做一次Roofline模型分析。这个概念听起来高深其实特别简单一块芯片能达到的实际性能等于“算力峰值”和“带宽×算术强度”两者中较小的那个。算术强度就是一次推理中“计算量/访存量”单位是MACs/Bytes。比如一个1.2B参数的Transformer模型每处理一个token大约要执行1.2B MACs。这个模型INT8量化后权重文件大约1.2GB推理时至少要把这些权重从DDR里读一遍。那么它的算术强度就是算术强度 1.2B MACs / 1.2GB ≈ 1 MAC/Byte这是一个非常“内存密集”的数字。假设芯片的NPU峰值是50G MAC/s内存带宽是60GB/s。只按算力算单token延迟下限是 1.2B / 50G ≈ 24ms只按带宽算单token延迟下限是 1.2GB / 60GB/s ≈ 20ms。还没算激活读写、中间结果搬运和缓存命中率真实延迟已经逼近30ms以上。如果换成INT4量化权重降到约0.6GB带宽时间变成10ms瓶颈一下子就移到了算力边界。方案权重大小每token计算量算力时间下限访存时间下限主要瓶颈FP162.4GB1.2B MACs24ms40ms带宽INT81.2GB1.2B MACs24ms20ms算力接近带宽INT40.6GB1.2B MACs24ms10ms算力所以光看“芯片有几TOPS”没有意义。很多车规模型跑不快不是算力不够而是权重访存把DDR带宽吃满了。这也是硬件协同设计存在的根本原因算法选型时必须知道自己到底算力密集还是访存密集才能针对性地压缩访存量而不是盲目增大模型。3. 实操从候选模型池到车规级部署的完整闭环3.1 定义场景需求与硬件基线实操的第一步不是选模型而是把需求写清楚。某新势力车企这个项目做的场景是一位座舱多模态语义理解输入的是摄像头图像和语音文本输出的是用户意图和关键属性。业务侧给出的硬指标是端侧单帧P99延迟小于80ms整机功耗增量不超过5W内存占用小于1.5GBINT8量化后的准确率相对云端模型掉点小于1%。拿到需求后我们先把目标硬件的能力基线梳理出来。芯片是一颗车规级SoC内置NPUINT8定点算力大概有80G MAC/s但持续运行只能按六成算DDR带宽标称60GB/sL2缓存只有几MB算子层面支持Conv、MatMul、Elementwise等常见算子LayerNorm、Softmax这类归一化算子有基础实现但动态shape支持非常差。这些特征直接决定候选模型的结构不能太“花哨”。建议你也这样做把硬件基线整理成一张表贴在项目墙上。每次模型结构改动都对照这张表问一句新增的算子硬件支持吗访存会不会爆功耗预算够不够3.2 构造候选模型池并快速筛除不要只拿一个大模型调研要做候选池。我们当时挑了三种典型结构一个是0.8B的纯Transformer编码器适合处理文本一个是1B的CNNTransformer混合结构适合图像和文本联合输入还有一个是0.5B但带额外跨模态注意力模块的结构。这一步不能用“看起来精度差不多”来选要直接跑硬件编译器提供的profiler统计每个候选模型在NPU上的算子级延迟、内存占用、带宽消耗以及是否有算子落到CPU回退。跑完之后那个0.8B纯Transformer模型因为动态序列长度导致NPU需要反复重新分配缓存P99延迟高得离谱直接被淘汰。筛完后剩下两个候选进入量化环节。我建议候选池不要超过五个否则后面每一步的迭代成本都会倍增。快速筛除的核心标准只有一个在硬件上跑过的真实profile而不是纸面FLOPs。3.3 校准数据采集与量化候选模型确定后量化是最关键的一环。我们的做法是先做PTQ并保留混合精度的可能性。第一步是准备校准集。可以从车端真实采一些数据覆盖白天、夜晚、雨天、地下车库等场景数量不一定多500到2000条足够但一定要覆盖模型部署后的数据分布。直接用云端训练集做校准是常见错误——云端数据和车端摄像头拍到的数据分布完全不一样校准出来的量化参数根本不靠谱。第二步是导出计算图插入量化节点用校准集跑PTQ。跑完以后不能只看最终精度要逐层比较量化前后的feature map余弦相似度定位掉点严重的层。比如我们遇到某个归一化算子量化后相似度只有0.9单独给它保留FP16整体精度就回来了。这种“敏感层少量高精度、非敏感层INT8”的混合精度方案在车规场景里非常实用。如果PTQ后整体精度仍然掉点超过1%再考虑QAT。QAT需要在训练框架里模拟量化误差微调几个epoch不是从头训练成本可控。实际经验是85%的模型用PTQ加敏感层混合精度就能过关真正需要QAT的只有少数结构特殊的模型。3.4 算子映射与结构微调量化完了模型要真正落到NPU上这时算子映射问题会浮出水面。很多NPU对Transformer的支持并不完美尤其是Softmax和LayerNorm这类带归约的算子在硬件上实现要跨行读写访存很慢。我们的做法是尽量把模型结构改造成硬件友好的形态。比如用近似归一化替代标准LayerNorm、把GELU换成SiLU或ReLU、限制Attention的序列长度、把动态shape固定成静态长度。还有一个很实用的手段是算子融合把“ConvBNReLU”或者“线性层激活”融合成单个NPU指令减少中间结果写回DDR。这一步其实是硬件协同设计的核心模型结构不是不能改而是要在精度和硬件效率之间找到最优折点。我们当时为了适配NPU把原始的12层Transformer精简成8层加了一个轻量视觉塔并在最后一层做通道剪枝最终业务精度只掉了0.3%但端侧延迟直接降了40%。这种结构调整不能靠感觉要每次改完都在硬件上跑一遍。我们内部定了一个规矩任何模型结构的修改必须附一份NPU延迟和内存变化报告否则不进入下一轮。3.5 编译、部署与验收模型结构固定后进入编译部署阶段。流程通常是这样的先把模型导出成通用的中间表示再由硬件编译器做算子映射、内存分配和调度最终生成目标芯片的二进制文件。这里我放一个通用步骤示例具体指令名称各家工具链不同但思路一致edge_compile --model model.onnx \ --quant int8 \ --calib_path ./calib_data/ \ --output ./deploy_model.bin \ --target soc_npu_v2 \ --memory_budget 1.5G编译完成后先不要上车一定要在台架或者域控开发板上验证。需要测的数据包括P99延迟、内存峰值、整板功耗、连续运行24小时后的温度曲线。同时还要做多任务并发测试因为车端不可能只跑一个大模型DMS、OMS、语音唤醒都在抢同一块芯片和同一份带宽。4. 常见问题与排查技巧实录4.1 上板精度“崩了”先查前后处理一致性这是所有人都绕不过去的坑。我们在PTQ校准阶段精度已经接近99%但上板之后识别错误率突然增高。一开始怀疑是量化问题后来逐层对比才发现根因是前处理完全不一致。PC端用了双线性插值Resize和RGB输入车端ISP默认输出BGR而且YUV转RGB的系数也不一样。排查方法很简单固定一张图分别经过PC端的预处理管线和车端管线把输入张量导出来比对再逐层dump特征图计算余弦相似度。第一个出现显著差异的层往往就是问题源头。这类问题大部分时候与模型无关却会浪费你两三天时间先排查它永远是最高优先级。4.2 算子被“静默替换”看懂编译器IR还有一个诡异现象模型上板后精度下降但日志里明明显示“所有算子已支持”。后来发现有些归一化算子、Softmax算子被工具链悄悄替换成了低精度近似实现比如把指数函数做成查表、把LayerNorm的倒数用近似指令替代精度损失被隐藏在了编译产物里。遇到这种情况要善用编译器提供的调试模式保留每一层算子输出与原始模型逐层比对。同时要检查中间表示看看哪些算子被替换成了什么。另外尽量在模型设计阶段就选用硬件明确支持的算子组合不要给编译器太多“自由发挥”的空间。4.3 多个模型并发抢带宽内存与调度问题车端AI任务不是单个模型独享NPU。实测发现语音模型和视觉模型并发时大模型延迟从50ms飙升到110ms原因就是两者同时读DDR带宽被占满。解决方法分两层软件层面给大模型预留固定物理内存池避免动态分配碎片同时利用硬件优先级机制给安全相关视觉模型更高带宽配额。系统层面把轻量级周期性任务调度到CPU或DSP上减少与主推理任务的资源竞争。切记边缘模型不是孤岛它的“最佳”一定是站在整个域控资源视角下的最佳。4.4 常见问题速查表现象可能原因排查方法上板后精度明显下滑预处理不一致 / 算子被近似替换逐层特征图对比检查IR延迟比标称性能高出一倍带宽争抢 / 访存密集算子过多跑Roofline分析和per-op profile内存占用超标动态shape / KV Cache未限制固定输入长度使用静态内存池高温下性能下降功耗墙触发降频限制多核并发增加温控调度偶发死锁或崩溃动态shape越界 / 内存越界静态化输入开启边界保护4.5 避坑小建议最后分享几条实践经验第一从项目第一天就让硬件编译器介入不要等模型训练完再找适配第二每次修改模型结构都跑一次真实NPU延迟用数据代替感觉第三不要盲目追求4bit量化车规安全场景优先INT8或混合精度第四校准集一定不要怕麻烦真实车端数据比干净数据集重要一百倍。我个人做下来最大的感受是硬件协同设计不是摆在PPT上的概念而是实打实的迭代流程。最佳边缘模型本身也会随着芯片迭代、场景数据变化而移动所以最好把它当作一个持续演进的基线而不是交付物。如果你也在做类似的事建议第一周就把功耗和延迟预算贴在工位上让模型师、编译器工程师、系统工程师每天都看到很多返工其实可以靠这张预算表提前避免。