端侧推理芯片定制化：通用NPU的困境与场景化破局

1. 从"一颗芯片打天下"到场景定制：端侧推理的路线之争

过去几年，端侧AI芯片的叙事逻辑基本是"堆算力、拼TOPS"。厂商发布一颗通用NPU，标称几十甚至上百TOPS，然后指望它同时搞定手机、车载、机器人、工业相机所有场景。但真正做过端侧部署的工程师都清楚，这套逻辑在落地时经常碰壁——同样一颗标称40TOPS的芯片，跑ResNet-50可能很漂亮，换成Transformer类的检测模型或者多模态小模型，实际帧率直接腰斩，功耗还压不住。

淬思科技拿到过亿融资这件事，放在这个背景下看就很有意思。复旦博士潘鸿洋带队，核心思路不是做一颗"全能冠军"芯片，而是为不同端侧场景定制专属推理芯片。这个方向选择本身就值得拆解：为什么通用NPU路线在端侧越来越吃力？定制化推理芯片到底定制的是什么？它和RISC-V、Agentic EDA这些热词之间又是什么关系？

这篇文章不打算复述融资新闻，而是想从一个做过端侧模型部署的从业者视角，把"端侧推理芯片定制化"这件事的技术逻辑、关键取舍、实操中会遇到的坑，尽量讲透。如果你正在选型端侧推理方案、评估NPU部署可行性，或者单纯想搞明白为什么你的模型在NPU上跑不出预期性能，下面的内容应该对你有用。

2. 通用NPU为什么在端侧"水土不服"

2.1 算力标称值和实际吞吐之间的鸿沟

先讲一个很多人踩过的坑。你拿到一颗标称算力X TOPS的NPU，兴冲冲把PyTorch模型转过去，结果发现实际推理延迟是理论值的3到5倍。这不是厂商虚标，而是算力标称值本身有前提条件：它通常是在特定数据类型（比如INT8）、特定算子组合、理想内存带宽下测出来的峰值。

端侧场景的真实约束完全不是这样。以RK3588升级NPU这个热词为例，很多人在社区里问怎么把NPU利用率提上去，核心矛盾在于：模型里的算子并不都是NPU友好的。像动态shape、非标准卷积、复杂的后处理（NMS、ROI Align），NPU要么不支持，要么需要回退到CPU。一旦发生算子回退，数据在NPU和CPU之间来回搬运，带宽和延迟开销直接把收益吃掉。

我实测过一个典型情况：一个YOLO系列模型，主干网络在NPU上跑得飞快，但后处理部分回退CPU后，整体延迟反而比纯CPU推理还高。这就是"算力标称"和"端到端吞吐"之间的鸿沟。

2.2 不同端侧场景的约束差异有多大

把手机、车载、机器人、工业视觉这几个场景摆在一起，你会发现它们对推理芯片的要求几乎是互相矛盾的：

手机要的是"每瓦性能"，车载要的是"确定性"和"安全"，机器人要的是"低延迟多路并行"，工业场景要的是"稳定和长供货周期"。一颗通用NPU想同时满足这些，结果往往是在每个场景都做到70分，但没有任何一个场景做到95分。而端侧客户要的恰恰是那95分——因为端侧部署的竞争，往往就是延迟差20毫秒、功耗差0.5瓦的竞争。

2.3 定制化定制的到底是什么

很多人以为"定制推理芯片"就是改改算力规模，其实远不止。真正的定制至少包含四个层面：

• 算子集定制：针对目标场景的主流模型，把高频算子做成硬件加速单元，砍掉用不上的通用算子，省面积省功耗。
• 数据流定制：根据模型的层间依赖关系，设计片上缓存和DMA调度策略，减少片外访存。
• 精度定制：手机场景可以激进用INT4，车载可能必须保留FP16冗余，工业场景甚至要考虑定点化的数值稳定性。
• 接口定制：机器人要MIPI多路输入，车载要CAN/以太网，工业要低功耗常开接口。

这四层里，算子集和数据流是决定实际性能的关键，也是通用NPU最难做好的部分。淬思科技选择"为不同端侧场景定制专属推理芯片"，本质上就是在这四个层面做场景化取舍，而不是用一颗芯片去适配所有场景。

3. RISC-V在端侧推理芯片里扮演什么角色

3.1 为什么端侧芯片越来越爱用RISC-V

RISC-V指令集这个热词在端侧芯片领域出现频率越来越高，不是没有原因的。传统端侧SoC里，主控通常用ARM Cortex-A系列，但ARM的授权模式和成本结构对初创芯片公司不太友好。RISC-V的开源特性让芯片公司可以自由扩展指令集，这对推理芯片特别有价值。

具体来说，端侧推理芯片里通常有一个"控制核"负责调度、后处理、算子回退。这个核不需要很强的通用算力，但需要能灵活扩展自定义指令。比如你可以给RISC-V核加一条"做NMS后处理"的向量指令，或者加一条"量化反量化"的专用指令。这种扩展在ARM上要么做不了，要么成本很高。

3.2 RISC-V link.ld背后的工程细节

热词里出现"risc-v link.ld"，说明很多人在实际做RISC-V开发时卡在链接脚本上。这其实是个很典型的工程问题：端侧推理芯片的RISC-V核通常有多块不连续的内存区域——片上TCM、共享SRAM、片外DDR。link.ld要做的就是把这些区域正确映射，并把关键代码段（比如中断向量表、推理调度循环）放到最快的TCM里。

我踩过的一个坑是：把推理调度代码默认放到了DDR区域，结果每次调度都要走片外访存，延迟比预期高了40%。后来在link.ld里显式把.text.fast段定位到TCM，延迟直接降下来。这类细节在通用芯片文档里往往一笔带过，但在定制推理芯片里，内存布局本身就是性能设计的一部分。

3.3 RISC-V + NPU的协同模式

端侧推理芯片的典型架构是"RISC-V控制核 + NPU加速核"异构。RISC-V负责：模型加载、算子调度、不支持算子的CPU回退、后处理。NPU负责：卷积、矩阵乘等密集计算。

这种协同模式的关键在于任务划分边界。划分得好，NPU利用率高、CPU不空转；划分得不好，两边互相等，整体延迟反而上升。一个实用的经验是：把"数据准备"和"结果后处理"尽量做成流水线，让RISC-V核在NPU算当前层的时候，提前准备下一层的输入。这需要编译器在生成调度代码时就做好依赖分析，也是定制芯片相比通用方案能做出差异的地方。

4. Agentic EDA：芯片设计方式本身在变

4.1 从"人写RTL"到"Agent辅助设计"

Agentic EDA这个热词值得单独聊。传统芯片设计流程是：架构师画框图、设计工程师写RTL、验证工程师写testbench、后端做综合布局布线。这个流程周期长、迭代慢，对初创公司尤其不友好——你融了资，但芯片流片一次就是几百万，迭代一次就是半年。

Agentic EDA的核心思路是用AI Agent辅助甚至自动化部分设计环节。比如：让Agent根据算子集描述自动生成RTL框架、自动生成验证用例、自动做PPA（功耗性能面积）探索。这不是要取代芯片工程师，而是把重复性、探索性的工作交给Agent，让人聚焦在架构决策上。

对淬思科技这类做定制推理芯片的公司来说，Agentic EDA的价值在于：定制化意味着要做的芯片型号多、每颗规模不一定大，但迭代速度要快。如果每颗芯片都走传统全流程，成本和时间都撑不住。用Agent辅助设计，能把单颗定制芯片的设计周期压缩，这才是"为不同场景定制"在工程上可行的前提。

4.2 Agentic EDA在推理芯片设计中的具体切入点

结合端侧推理芯片的特点，Agentic EDA比较现实的切入点有几个：

• 算子到硬件的映射探索：给定一组目标模型和算子集，让Agent自动搜索最优的硬件数据流和缓存配置。
• 验证用例生成：推理芯片的验证重点是数值正确性和边界情况，Agent可以根据算子定义自动生成覆盖用例。
• PPA快速评估：在RTL完成前，用Agent做架构级PPA估算，快速筛掉不可行的方案。

需要清醒的是，Agentic EDA目前还在早期，它擅长的是"探索"和"生成候选"，不擅长"最终决策"。芯片架构的最终取舍，仍然需要人来拍板。把它当成一个超级加速的助手，而不是全自动流水线，预期会更合理。

4.3 定制化芯片对EDA流程的新要求

定制推理芯片和通用芯片在EDA流程上有个显著差异：通用芯片追求PPA的全局最优，定制芯片追求特定workload下的最优。这意味着EDA流程里要更早、更重地引入workload驱动的评估。

传统流程是"设计完再跑benchmark"，定制流程应该是"先定workload，再反推架构，再设计"。Agentic EDA如果能把这个"workload到架构"的映射做快，对定制芯片公司就是实打实的效率提升。

5. 端侧部署实操：从模型到NPU的完整链路

5.1 模型转换环节的隐藏成本

不管你用哪家的NPU，模型转换都是第一道坎。PyTorch训练出来的模型，要经过ONNX导出、图优化、量化、算子映射，才能变成NPU能执行的格式。这个链路里每一步都可能出问题。

以"npu is selected as device, but torch_npu is not available"这个热词为例，这是典型的环境配置问题：代码里指定了NPU设备，但运行时找不到对应的torch_npu扩展。这类问题的根因通常是：torch版本和torch_npu版本不匹配、环境变量没配、或者驱动没装对。排查顺序应该是：先确认驱动版本，再确认torch和torch_npu的版本对应关系，最后检查设备可见性。

模型转换里更隐蔽的坑是量化精度损失。INT8量化后，某些对数值敏感的层（比如检测头的回归分支）精度掉得厉害。解决办法通常是混合精度：敏感层保留FP16，其余用INT8。但哪些层敏感，需要逐层做误差分析，这个工作量不小。

5.2 算子回退的代价与规避

前面提到算子回退会吃掉NPU收益，这里展开讲怎么规避。

第一步是提前做算子覆盖分析。在模型转换前，把模型的所有算子列出来，对照NPU支持列表，标出哪些会回退。这个分析越早做越好，最好在模型设计阶段就做。

第二步是算子替换。很多回退算子其实有等价的高效实现。比如某些非标准卷积可以拆成标准卷积组合，某些动态shape操作可以固定shape后消除。

第三步是后处理下沉。NMS、TopK这类后处理，如果能用NPU的向量单元实现，就不要放CPU。有些NPU提供了后处理加速库，值得花时间研究。

我个人的经验是：一个模型在NPU上的实际性能，70%取决于算子覆盖率和数据流设计，30%才取决于NPU峰值算力。所以选型时不要只看TOPS，要看算子覆盖和工具链成熟度。

5.3 监控与调优：别让NPU"空转"

热词里出现"prometheus+grafana监控npu资源"，这是个很实用的工程实践。端侧部署上线后，你需要知道NPU的实际利用率、内存带宽占用、温度、功耗。没有监控，你根本不知道瓶颈在哪。

一个典型的调优场景：NPU利用率只有30%，但延迟下不来。可能的原因有：输入数据准备太慢（CPU瓶颈）、输出搬运太慢（带宽瓶颈）、或者调度间隔太大（软件开销）。用监控数据定位到具体环节，才能对症下药。

Prometheus + Grafana这套组合在端侧可能偏重，但思路是对的：把NPU利用率、DDR带宽、CPU占用、温度这几个指标采出来，做成时序图。哪怕用轻量方案，也比盲调强。

6. 定制推理芯片的选型与评估框架

6.1 评估一颗端侧推理芯片该看什么

如果你在选型端侧推理方案，下面这个框架比单纯看TOPS有用得多：

这个框架的核心逻辑是：端侧部署的成败在"端到端"，不在"峰值"。一颗算子覆盖率高、工具链顺的芯片，哪怕峰值算力低一点，实际体验可能更好。

6.2 什么场景适合定制芯片，什么场景用通用方案

不是所有场景都值得定制。判断标准大致是：

• 出货量足够大：定制芯片有NRE成本，量不够摊不平。
• workload足够稳定：模型结构长期不变，定制才有意义。
• 通用方案确实卡脖子：如果通用NPU已经能满足，没必要定制。
• 有差异化需求：比如极致功耗、确定性延迟、特殊接口。

淬思科技选择"为不同端侧场景定制"，说明它判断这些场景的workload足够稳定、量足够大、通用方案确实有短板。这个判断是否成立，最终要看落地案例。

6.3 从"芯片"到"方案"的思维转变

做端侧推理，最容易犯的错是"只盯着芯片"。实际上客户要的是能跑起来的方案：芯片 + 工具链 + 参考模型 + 技术支持。一颗芯片再好，如果工具链难用、模型转换老出问题，客户也用不起来。

这也是为什么定制芯片公司往往要配一支很强的软件团队。硬件定制是差异化的基础，但软件体验才是客户感知到的价值。Agentic EDA能加速硬件设计，但工具链和部署体验，仍然需要大量工程投入。

7. 我在端侧推理部署中踩过的几个真实坑

7.1 版本地狱：torch、驱动、工具链的三方匹配

这个坑我踩过不止一次。端侧NPU的软件栈通常是：驱动 + 运行时 + 框架扩展（比如torch_npu）+ 模型转换工具。这四个组件的版本必须严格匹配，错一个就报错。

最坑的是，有些版本的对应关系文档里没写清楚，得靠试。我的做法是：锁定一个已知可用的版本组合，做成Docker镜像，所有部署都基于这个镜像。这样至少保证环境一致，不会出现"我这儿能跑你那儿不能跑"。

7.2 量化后的精度回归测试不能省

有一次为了压延迟，把模型全INT8量化，离线测试精度只掉了0.5%，看起来没问题。上线后发现某些边缘case误检率明显上升。后来分析发现，量化误差在特定输入分布下会被放大。

教训是：量化后的精度测试，不能只用标准测试集，要覆盖边缘case和真实分布。而且最好做逐层误差分析，找出敏感层，做混合精度。省这个测试时间，后面要花十倍时间擦屁股。

7.3 别忽视散热和功耗墙

端侧设备空间小，散热差。NPU满载跑一会儿就撞功耗墙或温度墙，频率降下来，延迟就上去了。所以评估芯片时，要看持续性能，不是峰值性能。有些芯片峰值很漂亮，但持续跑几分钟就降频，实际体验很差。

实测时建议跑长稳测试：连续推理30分钟以上，看延迟和频率是否稳定。这个数据比跑分有意义得多。

8. 定制推理芯片这条路，难在哪、机会在哪

定制推理芯片的逻辑是成立的：端侧场景差异大，通用方案难以在每个场景都做到最优，定制化能带来实际的性能和能效优势。但这条路也确实难：

难在工具链。硬件定制相对容易，软件生态难建。客户习惯了CUDA或某家NPU的工具链，迁移成本高。

难在迭代速度。定制意味着型号多，每颗都要流片验证，对资金和团队都是考验。Agentic EDA如果能显著压缩设计周期，会是关键变量。

难在场景判断。定制哪个场景、定制到什么程度，需要对场景有极深的理解。判断错了，芯片做出来没人用。

机会则在于：端侧AI的workload正在快速分化。手机、车载、机器人、工业，每个场景的模型结构、精度要求、实时性要求都在往不同方向走。通用方案会越来越难兼顾，定制化的空间会越来越大。RISC-V提供了灵活的指令扩展能力，Agentic EDA提供了快速迭代的可能，这两者结合，让"为不同场景定制推理芯片"在工程上变得可行。

至于淬思科技能不能跑出来，最终要看它的芯片在真实场景里的端到端表现，以及工具链能不能让客户用得顺手。融资是起点，不是终点。对做端侧部署的工程师来说，多一个定制化选项总是好事——至少在选择NPU时，不用再被迫接受"什么都能跑但什么都跑不好"的通用方案了。