前两天行业群里有人转了一条以萨和昇腾AI合作的消息说“又双叒有大动作”我笑着把标题读了三遍——确实这俩家这两年动作就没停过。做智慧交通AI的人应该都有同感算法模型早就不稀缺了真正稀缺的是能把这些算法按业务要求跑起来、且成本可控的算力底座。昇腾AI这两年已经补齐了从芯片、板卡到训练推理框架的全栈能力而以萨在交通视觉这个赛道里攒下的是成体系的全目标识别、事件检测和多维数据融合算法。这次双方面向智慧交通交出的“创新答卷”正好撞上了我一直在琢磨的几个痛点。这篇文章不聊发布会通稿聊点真正有用的合作背后到底解决了什么问题以及昇腾AI适配和落地时那些文档上不会写清楚的细节给打算走这条路的同行一个参考。1. 为什么这次合作消息让我这种“老交通AI”坐直了1.1 以萨手里那张王牌从“看清楚”到“看明白”以萨早期是靠多维大数据融合起家的但在交通这个方向站稳脚跟靠的是视频图像AI这块硬功夫。我最早接触他们家产品是在一个地市级的“两客一危”监管项目上当时最大的感受就是它的算法不只是给你画个框、贴个标签而是能持续输出“业务事件”——这辆车在哪个区间连续行驶超过四小时那辆渣土车有没有按审批路线走某条辅路上是不是有人违规停车堵住了消防通道。能把“看清画面”和“看懂业务”连起来的算法公司其实不多。传统电子警察和卡口把大量精力放在“抓拍准确”和“车牌识别”上但现在的交通管理者要的不只是证据还要预测、要预警、要能自动发现异常。以萨在车辆全目标识别上做得比较细车标、车型、颜色、天窗、挂饰、年检标这些属性都能结构化出来。这种细颗粒度属性一旦和轨迹数据叠在一起就能在“只看画面”的情况下还原一辆车的完整行为链这是他们后来能拿来做智慧交通复杂场景的基础。1.2 昇腾AI补齐的不仅是芯片是一整条工程链路昇腾AI这几年在行业里的存在感是肉眼可见地往上走。它不是一个单点硬件而是一整套从昇腾310/910芯片到Atlas系列计算硬件再到CANN异构计算架构、MindSpore框架和应用使能层的全栈体系。对算法公司来说昇腾的价值不只是“咱们有国产芯片可以用”而是给了你一个完整的推理部署规范模型要过ATC转换、算子要在CANN上编排、图像预处理要走AIPP这套链路一旦跑顺后续批量交付是非常稳的。我见过不少算法团队模型在训练机上跑得飞快一到客户机房就翻车。问题往往不是模型不行而是推理端的工程化没跟上。昇腾AI这种“把工程链路标准化”的做法恰好能把算法公司从“一个项目一套部署脚本”的泥潭里拽出来。以萨这次选择和昇腾深度绑定说明它看中的不只是芯片本身而是昇腾生态里那套“可以复制的推理工程路径”。1.3 “又双叒”背后的合作三步走翻一下两家的合作轨迹能看出来明显是分阶段的。早期应该是模型在昇腾设备上的跑通验证属于“能不能用”的阶段再往后是联合做试点项目把某个交通算法真正部署到Atlas边缘设备上属于“好不好用”的阶段这次面向智慧交通的“创新答卷”明显是冲着“规模化可交付”去的——有标准化的硬件形态、有算法包、有典型场景闭环甚至可能连运维更新机制都想清楚了。从试点到放量这才是“大动作”的真正含义。2. 智慧交通AI落地的三座大山算力账、迁移账、场景碎账2.1 算力账数百路视频放在通用GPU上成本先让你清醒智慧交通项目里最容易被低估的就是算力成本。一个区县要覆盖主要路口和重点路段几百路视频是起步量而且AI分析不是“抓拍一下”就完事是7x24小时不间断地对每一帧画面做目标检测、跟踪、属性识别和事件判定。这个算力需求摊开算一下传统方案往往要堆不少GPU推理服务器机房空间、功耗、散热、采购预算,全部都得重新做人。我参与过的一个项目起初规划用通用GPU卡做推理业务侧报来报去最后发现光是推理卡的预算就占了整个硬件采购的大头而且方案评审时客户对室外设备的环境适应性还有硬性要求。后来调整成边缘中心混合架构路口端的实时结构化放到昇腾边缘设备上做后台再放一台中心推理服务器做跨点位分析整体成本才压下来。昇腾在边缘侧有低功耗的310芯片方案中心侧有8卡甚至更高密度的Atlas 800系列这种“边缘小规模、中心高密度”的搭配在算力账上确实更有得算。2.2 迁移账换推理芯片不是换个牌子是重做一遍工程很多AI公司的模型是在GPU生态里训练和调试的突然要跑到昇腾硬件上并不是导出个模型文件那么简单。训练框架的算子实现、推理引擎的算子支持列表、数据预处理的位置——这些全是差异点。拿交通算法里最常见的模型结构来说检测头里的某些操作在昇腾平台上未必有原生高性能算子要么用等价组合去替换要么开发自定义算子。再比如模型输入尺寸训练时可能惯用动态shape拷贝到昇腾设备上如果不在ATC转换阶段把动态维度配置好推理时直接报错。还有颜色空间、归一化参数、数据布局哪一环没对齐精度和性能都会受影响。这不是“不能做”而是需要一套成熟的方法论和足够的耐心去做适配。以萨和昇腾的合作价值有一部分就在这——把迁移工程的风险提前趟平。2.3 场景碎账交通视觉是“一城一策、一路一况”做交通AI时间久了会发现同一个算法模型在A市好用换到B市立刻水土不服。南北方的光照差异、沿海和内陆的天气差异、老城区和新城区的路口物理结构差异还有摄像头架设的杆高、俯仰角、视野范围全都在挑战模型的泛化能力。更要命的是业务规则本身也是碎的。有的城市要求重点抓拍不礼让行人有的城市严查非机动车逆行有的城市更关心高峰期拥堵的自动识别。这种碎片化决定了“一个超大模型包打天下”不现实更务实的做法是把算法做成能力矩阵按场景去组装。这正是昇腾这种标准化底座能发挥优势的地方算力层统一了算法按需加载、灵活组合才能应对“一路一况”的现实。3. 拆解“创新答卷”昇腾算力上的全链路交通感知3.1 一张总图路口边缘计算 中心数据枢纽 云端模型迭代这次方案给我印象最深的一点是它不再是零散地“用AI替换某个旧功能”而是把交通感知做成了一张可以持续运营的网络。整个架构分了三层第一层是路口边缘侧用昇腾边缘设备接住摄像头的视频流完成实时视频结构化。车辆、行人、非机动车全部在本地识别和跟踪同时本地直接判定违停、逆行、拥堵、行车道内停车这类时效性要求高的事件。边缘侧搞定第一环能做到毫秒级响应也不需要把几十路原始视频全传回中心带宽压力小很多。第二层是中心数据枢纽负责跨路口、跨路段的轨迹缝合和二次分析。比如一辆车从A路口开到B路口用了多长时间中间是否在某处异常停留某个事故发生后前后各点位是否出现了大范围拥堵蔓延。这些分析需要在中心汇聚数据用Atlas推理服务器做批量计算。第三层是云端模型迭代。模型不是发布一次就完事而是定期在云端用新数据做增量训练验证通过后用自动化流程下发到边缘设备老模型热替换。这个闭环让整套系统的识别能力能随数据积累越用越准而不是上线三个月后开始“退化”。3.2 核心算法包的昇腾化改造检测、跟踪、属性识别怎么落全息路口这个概念不算新但真要把它跑起来每路视频都得同时处理三件事目标检测找出车、人、非机动车、多目标跟踪ID跨帧稳定、车辆属性识别颜色、车型、车标等。以萨的做法是把这些模型做成了可插拔的算法包再统一编排到昇腾的推理流程里。改造的第一步是模型转换把训练好的PyTorch或TensorFlow模型导出成ONNX再用ATC工具转成昇腾的OM模型。第二步是推理流程重构检测和跟踪涉及到的前后处理并不都是模型本身NMS、跟踪匹配这些逻辑要放在CANN的推理流里编排好避免在CPU和AI Core之间来回搬运数据。第三步是业务规则注入比如识别到异常停车后要计时、叠加预警等级再决定是否上报——这部分逻辑跑在边缘容器里跟推理任务并行。3.3 全天候事件检测实测白天晚上、晴天雨天都得hold住交通事件检测是这次方案里最考验功力的部分。违停、逆行、拥堵、行人闯入、道路遗撒、车辆慢行每种事件的时间特征和空间特征都不一样。过去这类功能误报率很高稍微有点阴影变化就触发警报运维人员很快就不再信这个系统了。以萨这套方案在事件检测上能往下走一是因为算法对目标的识别粒度和跟踪稳定性上来了二是业务判断加了很多时序约束比如单个目标连续停留在某区域超过设定阈值才判定违停多目标平均速度低于多少且持续多久才判拥堵。叠加昇腾边缘设备的多路实时推理能力和量化优化实测单路1080p视频从解码到输出分钟级事件识别端到端时延控制在百毫秒内单个边缘设备稳定并发多路这个表现已经具备代替人工视频巡检的基础。真正让我觉得“答卷”落到实地的是它不只是识别还能自动生成带证据链的事件记录直接对接到交通管理部门的业务流程里。4. 昇腾适配的实操链路口述模型转换、算子改造与性能调优4.1 从ONNX到OM我建议把动态shape这事放在第一位如果你的团队正准备把手里的交通模型迁到昇腾平台我给的第一个建议是先把动态shape问题想清楚。交通场景的输入分辨率五花八门摄像头输出可能是1080p也可能是4K下采样后的数据或者为了兼顾小目标而保留了较大分辨率。ATC转换时如果写死成固定分辨率后面接不同的视频源就会非常痛苦。以一次典型的模型转换为例训练端输出ONNX后ATC命令行大致长这样atc --modeltraffic_yolo.onnx \ --framework5 \ --outputtraffic_yolo_om \ --soc_versionAscend310P3 \ --input_shapeimages:1,3,640,640 \ --insert_op_confaipp.cfg \ --precision_modeallow_fp32_to_fp16 \ --logerror固定shape的转换通常一次就能过但在实际项目里我更建议预留动态维度的配置--input_shapeimages:-1,3,-1,-1 --dynamic_dims1,8,320,320;1,8,640,640;1,8,960,960动态shape会影响ATC转换时的编译优化也会让推理侧的Stream编排复杂一些但它换来的是“一套模型兼容不同路况分辨率”这个价值在交付阶段会体现得非常明显。转换完以后不要急着标定“精度达标”先用一批带标注的困难样本做精度比对很多问题在这一步就能暴露。4.2 算子兼容问题先改模型结构不要一上来写自定义算子昇腾平台上模型跑不通最常遇到的就是算子兼容。交通检测模型里那些自定义的轻量模块、特殊池化、复杂组合的激活函数都有可能踩到不支持或者性能拉胯的算子。我的经验是优先改模型结构用昇腾原生算子去等价替换而不是一上来就投入资源写TBE自定义算子。自定义算子的开发、编译、调试周期比想象中要长得多而且后续每次CANN版本升级都可能要跟着维护一遍对于业务团队来说性价比不高。遇到过具体案例模型里的ROI Align层在昇腾上跑得不够快我们分析了在检测任务中的作用后用若干标准池化加采样的组合做等价替换精度影响控制在可接受范围内速度反而提升明显。当然也有非自定义不可的场景但那应该是最后的手段而不是第一选择。4.3 性能调优三板斧AIPP预处理下沉、Stream编排、Int8量化取舍模型转换通过、精度达标离真正好用还差一步性能。昇腾上的性能调优绕不开三件事。第一件是数据预处理下沉。很多团队习惯在CPU上用OpenCV做缩放、归一化、颜色通道转换再把处理好的图喂给模型。在昇腾上这是浪费因为CANN的AIPP模块可以直接在AI Core上完成这些操作并且和模型推理流水线无缝衔接。把预处理挪进AIPP不光释放了CPU还省了多次内存拷贝。第二件是合理使用Stream编排多路视频。昇腾推理不是“一路一路排队算”而是可以多路并行调度的。把多路视频流构造成不同的Stream并通过Event做同步可以让多路推理更均衡地吃满硬件资源避免某一路卡顿导致整体掉帧。这一块是边缘设备能稳定跑多路并发、还保持低时延的关键。第三件是精度与速度的平衡取舍。昇腾支持FP16和Int8推理Int8量化通常能带来成倍的性能提升但量化校准做不好会掉精度。我的建议是先跑FP16版本验证业务指标确认模型本身没问题再基于真实业务数据做Int8量化校准最后用难样本集做回归比对。如果业务对精度极其敏感保FP16也是可以接受的不要为了跑分好看硬上Int8。优化动作解决的问题我的建议预处理下沉到AIPPCPU资源被浪费、内存拷贝多优先做改造成本低Stream多路编排多路并发时互相挤占、掉帧拿到硬件就先压测再定方案Int8量化并发拉高但精度波动用业务数据校准过不了就留FP165. 给准备走昇腾适配的同行几句掏心窝的话5.1 选硬件不是在选跑分是在选业务部署位置昇腾产品线铺得很开有板卡、有边缘小站、有训练服务器很多人一上来就在纠结“哪款性能最强”。实际项目里我更建议按部署位置来选路口、路段机房的设备要扛灰尘和温湿度波动要关注功耗、体积和无风扇设计中心机房的设备则优先看算力密度和扩展性如果是做训练和模型迭代又要考虑集群的scale-out能力。硬件选错后面交付和运维会一直难受。部署位置典型硬件形态侧重点路口/路边边缘侧昇腾边缘小站/工控机插推理卡低功耗、宽温、实时性区县级中心Atlas推理服务器多路并发、高密度算力训练/迭代侧Atlas训练服务器大模型、多卡扩展、数据吞吐5.2 算法团队的工程化习惯要尽早改在GPU生态里写模型写久了容易养成“能跑就提交”的习惯但在昇腾生态下模型从训练第一天开始就要考虑部署的算子友好性尽量少用或不用原生算子覆盖不到的冷门操作shape层面也要有意识地固定或者显式设计动态维度。等到交付前再改往往要返工。建议团队早点接触真实昇腾设备或者至少用昇腾的模拟验证环境把适配这道工序从“项目末期”挪到“开发周期内”。5.3 真正的护城河是懂业务闭环昇腾这个生态里算法合作方不少但真正能走得长远、能持续签单的是那些“懂算力、懂算法、懂场景”的组合型团队。以萨这几次和昇腾的合作能连续放出动作核心不是因为它的模型有多深、跑分有多高而是它始终在回答交通管理者真正关心的那个问题这套东西到底能不能帮我减负、提效率、防事故。我见过太多“为了AI而AI”的项目技术炫目但业务目标不清晰最后变成演示系统。以萨这次的方案至少把话题拉回到了“事件识别准确率提升、处置流程打通、日常运维真正可落地”这些业务词上。算力是底座、算法是工具、场景和业务懂行才是护城河。昇腾提供了一个还不错的底座能不能用好终究要看谁在底座上种出了真正有产出的庄稼。我个人在实际项目里的体会是昇腾适配不是一次性的“翻译工程”它更像是在重新思考硬件和软件的边界哪些结论应该由算法负责哪些性能该由算力底座兜底两边怎么分工直接决定了系统上限。以萨这次面向智慧交通的答卷至少在工程路径上给同行省了不少试错时间。最后再分享一个小技巧如果你也在做类似的迁移先从一两个最有业务价值的算法跑通全链路比一上来就追求全量算法适配要靠谱得多。