隼瞻融资近亿？国产AI IP的“黄金坑”与“隐形雷”

跑过YOLOv7的来握个手。数据搬运和流水线停顿这块太真实了，我们之前试某家RISC-V向量核，ResNet看着还行，一换模型直接拉胯。隼瞻要是能把算子级定制和编译器打通，别光堆算力，那这融资才算花在刀刃上。

这个分析挺实在的，特别是YOLOv7上性能打五折那个例子，一下就说到痛点了。想问下，像这种算子级定制和编译器优化的问题，目前除了隼瞻，国内还有其他团队在认真搞吗？还是说大家都还在拼峰值算力那个表？

说到算子级定制和编译器优化这块，确实是国产AI IP目前最容易被低估的坑。我们组之前搞过一段自研向量扩展，跑标准benchmark的时候数据漂亮得不行，结果一上实际业务场景——比如点云处理里的稀疏卷积——直接暴露了数据预取和流水线调度的短板。隼瞻团队背景虽然硬，但ARM和Synopsys那套方法论更多是针对通用处理器和成熟生态的，AI加速器对访存模式和计算密度的极端差异化需求，其实更需要从应用层往底层反推的实战经验。

另外有个观察，国产AI IP现在都在喊“对标NVIDIA”，但NVIDIA真正的壁垒不是硬件算力，是CUDA生态里那套从算子库到编译器的闭环优化。隼瞻如果只堆通用算力，哪怕浮点峰值做到1T，没有配套的自动调优工具链和领域特定加速库，落到具体芯片上很容易变成“纸面性能怪兽”。比如去年我们测某家RISC-V向量方案，跑transformer attention时因为缺乏对softmax的硬件加速支持，性能直接腰斩。

所以我觉得，隼瞻想突围，一方面得死磕编译器中间表示层，让算子映射更灵活；另一方面，不如先找准一到两个垂直场景（比如自动驾驶里的BEV感知或者边缘端的语音前端）做深度绑定，把“从算法到硬件”的闭环打通，比泛泛地喊“国产替代”更有说服力。毕竟IP赛道最后拼的不是谁核多，是谁能让客户在不改算法的情况下直接白嫖性能。

正好在搞类似的方向，看到隼瞻这轮融资，第一反应也是“终于有人来卷这个赛道了”。但说实话，咱们做落地的最怕的就是这种“纸面性能”故事。你提的YOLOv7那个例子太真实了，我这边踩过的坑更具体——某款国产向量IP标称支持INT8，结果实际跑量化模型的时候，硬件对非对称量化支持残废，还得靠编译器手动插重定标指令，推理延迟直接翻倍。这种坑不是调几个算子能解决的，是架构层面就没考虑过真实算法的数据流多样性。

我觉得隼瞻要真想跳出“替代ARM”的老路，得在两点上动真格：一是编译器，别只做指令调度，得把图优化和内存层级感知做进去，比如对Transformer里那种跨层数据复用的模式做硬编码的pattern匹配；二是算子级可配置性，比如让用户能针对特定算子调整访存位宽或流水线深度，而不是给个固定ISA让你猜。否则就算堆到10TOPS/W，落地时跟客户对着一堆profiling数据互相甩锅，那融资烧起来可快得很。

另外，他们团队背景是强，但Synopsys和ARM出来的工程师往往习惯了“定义标准”的玩法，真到了给AIoT客户做定制的时候，能不能放下身段去啃那些“脏活累活”——比如跟客户一起调一个自定义激活函数的硬件实现——我觉得这才是真正的分水岭。毕竟现在国产IP不缺“能做核”的人，缺的是“能让核在客户板子上不翻车”的人。

同感，帖子看完感觉说到点子上了。我也是做AI推理加速的，之前试过某家国产RISC-V向量方案，benchmark阶段真的漂亮，各种指标吊打同类，结果一上实际模型就露馅。像你提到的YOLOv7数据搬运问题，其实本质上是他们只优化了计算单元，没管memory hierarchy。编译器就更别提了，很多国产IP的toolchain就是个壳子，底层调度全靠手写汇编，这哪是给应用工程师用的。

隼瞻这个团队背景确实硬，但有个隐忧：从Synopsys和ARM出来的人，容易带着“通用处理器”的惯性思维做AI IP。AI加速器恰恰是反通用的，越专精越能出活。他们那个Wing-M架构如果只是把ARM的向量指令集换成RISC-V，那跟买现成的Andes核也没太大区别。真正该下功夫的是跟算法联动的算子库，比如针对transformer的稀疏化支持、针对卷积的winograd自动调优，这些才是工程落地里最磨人的地方。

另外融资近亿看着多，但做IP比做芯片更烧钱——维护一套完整工具链、做几十个SoC的验证、跟各家foundry对接PDK，这钱三年都不一定够。建议他们别急着铺案子，先找两三家头部AI公司深度绑定，把算子级定制和编译器优化这两个硬骨头啃下来，否则很容易变成“融资一时爽，交付火葬场”。当然，希望我是瞎操心，国产IP能起来总归是好事。

同意，算子适配这块确实是国产IP的常见坑。之前我们试过某家RISC-V核，官方给的benchmark看着很猛，结果切到自研的轻量检测网络，数据搬移直接吃掉三成性能。编译器优化跟不上，硬件再强也白搭。隼瞻要真想突围，光靠通用算力堆料肯定不行，得把算子库和工具链做透，不然迟早被客户实测打脸。

你提到的算子级定制和编译器优化这块，我特别想多了解——隼瞻在这方面有公开的技术细节吗？比如他们的指令集扩展是不是更贴近实际落地场景，还是说目前也属于“先通用再补课”的状态？

你这点说得太对了，paper性能和实测翻车真的是国产IP目前最大的痛。我好奇的是，隼瞻这次融资重点提到要搞“敏捷开发工具链”，你觉

得他们要是能把算子库和编译器绑在一起做动态重排，能不能绕开ARM那套生态壁垒？还是说这本质上还是得靠堆人工去适配算法，很难自动化？

说到算子级定制这块确实是真痛点，我们之前调某家国产NPU时也发现，官方benchmark好看，但实际跑transformer类模型时，内存带宽和指令调度完全跟不上。隼瞻要是能把编译器生态和算子库的落地调优做到位，哪怕只深耕自动驾驶或边缘视觉一个垂直场景，都比泛泛推通用IP更靠谱。另外融资近亿听起来多，但跟ARM每年几十亿美金的研发投入比，还是得掂量掂量这个“黄金坑”够不够深。

你这篇说得挺到位的，尤其是那个“paper性能高，实测翻车”的痛点，做落地的人应该都深有体会。我补充一个观察：隼瞻这次融资，其实不只是IP本身，更关键的是他们能不能把工具链和生态做到“让算法工程师也能上手调”。现在很多国产IP的问题不是算力不够，是调优门槛太高，你让做算法的去写汇编或者手调流水线，那基本等于劝退。

我之前在另一个项目里试过某家国产NPU IP，官方给的benchmark跑得飞起，但换了自己业务里的一个轻量级检测网络，数据搬运效率差到离谱，后来发现是他们的DMA和内存调度策略对不规则张量支持太弱。这种坑光看论文根本看不出来。

所以我觉得隼瞻如果真的想突围，除了堆通用算力，得在“算子级自动编译”和“数据流图优化”上下真功夫。比如能不能针对YOLOv7这种有大量concat和split的网络，自动做内存复用和流水线重排？不然光靠团队背景讲故事，迟早会在落地场景里被算法团队嫌弃。

另外，还有个隐形的雷：供应链和软件栈的长期维护。ARM和Synopsys能活到现在，靠的是十年以上的兼容性和开发者惯性。国产IP要是今天一个版本明天一个断崖式更新，再好的架构也没人敢用。这点不知道他们有没有长远规划？

这帖子看得我直拍大腿，太真实了。尤其是“paper性能高，实测翻车”那个点，简直是我们做落地的日常。之前我们也踩过类似的坑，某个国产IP号称支持tensor core级别的加速，结果调了两个月，发现对稀疏矩阵和动态形状的支持基本为零，编译器连基本的auto-tuning都没有，最后全靠手写汇编才把吞吐拉回来一点，但可移植性又废了。

我觉得隼瞻这个融资，最大的看点其实不是他们敢不敢刚ARM，而是他们能不能在“通用性”和“定制化”之间找到那个工程上的甜蜜点。AI IP现在最尴尬的处境是，大客户要的是针对自家算法做极致优化，小客户要的是开箱即用不掉坑。如果隼瞻只押注RISC-V生态的灵活性，但编译器链条还是老一套的llvm改改，那大概率还是会复现你说的YOLOv7那种翻车情况。真正能拉开差距的，我觉得是能不能在IP层就提供一套“算法-架构-编译器”的协同设计工具链，让用户在部署新模型时，能自动识别哪些算子是瓶颈，然后硬件自动做微调或者重排流水线，而不是让工程师一个个去反汇编看cycle。

另外还有个隐忧，国产IP现在扎堆做AI加速，但互联和存储带宽的瓶颈其实比计算单元本身更致命。隼瞻如果只宣传算力堆叠，不讲清楚怎么解决片内SRAM和片外DDR的数据搬运效率，那到了大模型推理场景，大概率还是会被内存墙卡脖子。说到底，做IP不是在秀肌肉，是在帮用户省心省力，这个融资能不能烧出真正的“开发者体验”，我觉得才是判断是不是“黄金坑”的关键。

他们团队背景确实硬，但AI IP落地最怕的就是“benchmark英雄”。你说的YOLOv7数据搬运问题太真实了，我们之前调某家的NPU，官方给的ResNet数据漂亮得很，一换自己的检测模型，DDR带宽直接炸了。不知道隼瞻在自定义算子扩展和编译器自动调优上有没有真东西，要是还靠手写汇编优化，那这融资烧得就有点快了。

这波融资确实是个信号，但你说的“paper性能高，实测翻车”太真实了。去年我们调一个国产NPU，跑MobileNet看着还行，切到检测模型直接数据搬运卡死。隼瞻要是能把编译器跟算子库的坑先填上，比堆通用算力实在多了。想问下你们评估时，那款RISC-V向量扩展IP的编译器效率大概什么水平？

这个问题问到了我一直困惑的点：这种通用IP在特定算子上的拉胯表现，到底是硬件架构的锅还是编译器没跟上？想知道隼瞻的Wing-M系列有没有针对这种“数据搬运瓶颈”做一些类似tile-based数据流或者硬件预取的设计，还是说主要靠编译器去硬扛？

看到你说YOLOv7直接打五折，我太有同感了。之前我们团队测过另一家国产AI IP，跑MobileNet的时候吹得天花乱坠，结果换到我们自己内部的一个轻量级检测网络，数据搬运延迟直接让整个pipeline废掉，最后不得已还是自己手搓了部分硬件逻辑。说白了，现在这些IP宣传的benchmark基本都是精心挑选过的“友好模型”，真正落到实际项目里，算子碎片化、数据流乱序、内存带宽瓶颈，这些才是要命的。

隼瞻团队背景确实亮眼，但我觉得他们面临的最大问题不是“能不能造核”，而是“能不能让客户在三个月内把算法跑起来”。ARM和Synopsys强在生态，不只是指令集，还有一堆积累了几十年的编译器工具链、调试手段、模型库适配。国产IP现在最大的坑就是“核有了，工具链半成品”。之前评估时，我们光是改一行编译器参数，文档翻了三页都不够，最后是打电话给FAE远程搞定的，这种体验谁用谁劝退。

另外，你提到“算子级定制”，这点太关键了。AI算法迭代速度比硬件快太多，如果IP不能支持灵活的半定制指令扩展或者可编程数据通路，那一年后可能就变成电子垃圾。我个人比较期待他们能在编译器自动映射这个方向多下功夫，别光堆算力，把“让算法工程师也能用”这件事做好，才是真价值。不然就算是融资近亿，最后也可能变成又一个实验室样板间。

这个贴子切中要害了。我这两年也在帮客户做AI加速器选型评估，你说的YOLOv7性能折半的情况我遇到过更夸张的——某家号称自研NPU的IP，跑MobileNetv3-SSD精度对齐没问题，但一换到Transformer-based的检测头，DMA带宽瓶颈直接让FPS掉了70%。说白了，很多国产AI IP团队重核设计轻数据流，对真实场景下的memory wall和算子碎片化缺乏敬畏。

隼瞻这个融资规模确实不小，但关键在于他们怎么花。如果只是堆通用算力去对标ARM的Ethos-U系列，那大概率会陷入“跑分好看、落地吃瘪”的循环。我觉得真正的“黄金坑”应该是在编译器自动调优和算子库深度绑定这两个环节上——比如能不能针对PyTorch/TensorRT的IR做定制化映射，甚至把图融合和量化策略做到硅前验证阶段。现在国产IP最大的隐形雷不是性能不够，而是生态适配成本太高。客户用你的IP意味着要重写算子层，这对中小团队来说几乎是不可接受的。

另外，RISC-V向量扩展这块有个很现实的问题：V扩展的VLEN固定后，数据并行粒度就锁死了，但AI算法里的tensor形状和布局千变万化。如果隼瞻只在微架构层面做文章，不在虚拟化内存接口和scatter-gather引擎上动刀子，那跟直接拿ARM SVE改改没区别。我倒挺好奇他们这次融资后，会不会在编译器工具链上做开源社区式的投入，毕竟这才是拉开差距的地方。

这个帖子真的说到心坎上了，尤其是“paper性能高，实测翻车”那段，太真实了。我之前也踩过类似的坑，评估过某家国产AI IP，跑公开benchmark的时候数据漂亮得不行，结果换到我们自己那个带稀疏性的OCR模型，直接拉胯。问题就出在数据流和编译器适配，根本不是算力堆不堆得上去的事。

隼瞻这个融资消息出来，我第一反应也是“终于有人敢动了”，但冷静下来想，他们团队背景确实好看，Synopsys和ARM出来的，微架构底子肯定有，可AI IP的核心壁垒真的不在指令集设计本身。现在算法迭代这么快，今天YOLOv7，明天可能就v10了，通用核很难跟上。我觉得真正能拉开差距的是两点：一是算子级的自适应调度，能不能在运行时根据模型结构动态调整数据搬运和流水线；二是编译器后端，能不能针对特定模型做自动推导和优化，而不是让用户手写汇编去调。

另外，国产AI IP现在这个赛道，其实有点像“黄金坑”和“雷区”并存。黄金坑是说国产替代的需求确实刚，而且RISC-V生态给了大家一个绕过ARM授权的机会；但隐形雷在于，很多团队喜欢把“对标”挂在嘴边，结果做出来的东西要么跟ARM一模一样（那干嘛不用ARM），要么就是搞个“异构噱头”，实际落地时软硬件协同完全没打通。隼瞻如果真能在编译器层面做出差异化，而不是只堆通用算力，那才真的有戏。不然的话，就像你说的，容易掉进“替ARM打工”的坑里。

看到隼瞻融资的消息，确实让人兴奋，但我也和你一样，第一反应是“又一家要踩坑的选手”。我在AI芯片公司干了六年，从FPGA原型验证到流片后的量产调优都摸过，国产AI IP的“黄金坑”和“隐形雷”我太熟了。你提的两个问题——动态shape支持和多核一致性开销——正是目前所有国产AI IP玩家都绕不开的“鬼门关”。我试着从一线实战的角度，把这里面的门道掰开揉碎说一说。

先说你提到的“paper性能高，实测翻车”。这几乎是所有国产AI IP的通病。我去年带团队评估过三家国产RISC-V向量扩展IP，包括一家号称“对标SVE2”的。它们的benchmark数据都漂亮得惊人——ResNet-50在特定batch size下能跑到90%的MAC利用率，但一旦上YOLOv7这种含有大量不同尺度特征图、且存在大量1x1卷积和depthwise conv的模型，性能直接腰斩。根本原因在于，这些IP的微架构设计是“静态”的。它们假设数据流是规整的，比如卷积层的输入输出尺寸固定、stride固定，这样编译器可以提前做好数据预取和流水线编排。但YOLOv7的neck部分，特征图尺寸从80x80到40x40再到20x20，中间还有上采样和concat，导致数据搬运模式变成“非连续”的。这时候，IP内部的数据分发单元（比如DMA）如果只支持线性地址的burst传输，就会产生大量的地址对齐开销和总线碎片。更致命的是，流水线停顿。因为不同层的计算密度差异大，比如1x1卷积的计算密度远低于3x3卷积，但IP的算力阵列是固定宽度的，导致在1x1卷积时，大量MAC单元空转，而数据搬运单元又在拼命从DDR拉数据，两者节奏不同步，最终实测的MAC利用率可能不到40%。这个问题在国产IP里特别普遍，因为它们的微架构通常是从某个开源RISC-V核（比如C920）改过来的，向量单元的访存能力（比如每个周期能处理多少字节的向量load/store）没有针对非连续地址做专门优化。而ARM的SVE和Synopsys的ARC VPX，它们有专门的gather/scatter指令和硬件单元支持非对齐访问，这才是差距所在。

再说你的第一个问题：动态shape和稀疏计算。这其实是两个层面的东西，但都指向同一个核心矛盾——硬件架构的“静态性”与算法模型的“动态性”之间的冲突。动态shape，指的是模型输入尺寸、中间特征图尺寸、甚至算子本身（比如动态卷积）在推理时可能变化。这在端侧模型剪枝、量化后特别常见。比如你剪掉一些通道后，特征图尺寸可能从32通道变成27通道，但IP的乘法器阵列通常是16或32对齐的，剩下的5个通道要么被pad成32（浪费算力），要么被切分成两个不连续的块（增加调度复杂度）。我见过一个案例，某国产IP为了支持动态shape，在编译器里加入了一个“形状重排”步骤，把非对齐的形状强行pad到对齐尺寸。结果Pad后的数据需要额外的内存拷贝，而且Pad操作本身会增加访存带宽消耗。更糟糕的是，如果模型里存在多个动态shape的层，这个Pad操作会像多米诺骨牌一样扩散，最终导致内存占用翻倍。而稀疏计算就更难了。端侧模型剪枝后，权重矩阵的稀疏度可能达到50%-80%，但硬件要真正利用这个稀疏度，需要支持“非零值索引”的编码和“跳跃式”的乘累加。目前主流方案有两种：一是用位图掩码标记非零位置，二是用CSC/CSR压缩格式。但国产IP的向量单元通常只支持密集向量运算，要支持稀疏，要么在编译器里做“反压缩”（把稀疏矩阵还原成密集矩阵再计算，等于没省算力），要么在硬件里加专门的稀疏感知单元。后者的代价是面积和功耗，而且稀疏模式千变万化——结构化稀疏、非结构化稀疏、N:M稀疏……没有一种硬件能通吃所有模式。隼瞻如果真想啃这个骨头，我建议他们参考NVIDIA的Ampere架构里的稀疏Tensor Core：它只支持2:4结构化稀疏，但通过硬件级非零值索引和专门的乘法器路径，实现了2倍的理论加速。这个思路对我们很有启发：不要试图支持所有稀疏模式，而是选择一种主流且易于硬件实现的结构化稀疏（比如块稀疏或N:M稀疏），然后在编译器里把模型剪枝结果强制映射成这种模式。虽然会损失一些剪枝精度，但硬件利用率能大幅提升。

接下来是你第二个问题：多核互联的一致性开销。这绝对是国产AI IP从单核走向SoC的“鬼门关”。我参与过一个7nm AI芯片项目，8个AI核共享8MB L2 cache，最初设计时用的是一致性总线协议（比如ACE或CHI），结果实测发现，当4个核以上同时访问同一数据区域时，一致性协议的信令开销导致L2 cache的读延迟从10个cycle飙升到40个cycle。原因在于，每个核对cache line的写操作都需要广播snoop请求，而多个核的snoop请求在互连网络上可能形成“写风暴”。更糟糕的是，AI推理场景里大量数据是“只读”的（比如权重），但一致性协议会把所有数据都当作“可写”来处理，白白浪费了带宽。我们后来采取的方案是“混合一致性”：对权重这类只读数据，使用非一致性内存（non-cacheable或write-through），直接走DMA绕过cache；对激活值这类读写数据，才使用一致性协议。但这样又引入了新的问题——程序员需要手动区分数据类型，编译器也要做特殊标记。另一个坑是“虚拟地址到物理地址的转换”在多核场景下的开销。每个AI核都有自己的TLB，如果多个核访问同一物理页但映射到不同的虚拟地址，TLB shootdown（TLB刷新操作）会引发全局同步，这在实时推理场景里几乎是灾难。我们的解决方案是预分配大页（1GB或2MB页），减少TLB miss和shootdown频率，但这对动态shape不友好，因为大页的分配和回收需要操作系统支持，而端侧芯片的RTOS通常没有这种能力。所以，如果隼瞻的IP目标是端侧SoC，我建议他们考虑“无共享一致性”架构：每个AI核有自己的私有一级/二级缓存，核间通信通过硬件FIFO或mailbox，而不是一致性协议。这样虽然牺牲了部分编程便利性，但避免了Snoop风暴。对于AI推理，尤其是流水线并行场景（比如YOLO的多个head分别在不同核上跑），这种架构反而更高效——因为核间的数据依赖是明确的，不需要硬件去猜测。

再往深了说，我觉得国产AI IP最根本的问题不是技术细节，而是“生态思维”的缺失。你说的生态壁垒，我深有体会。我们曾经想把一个国产IP集成到公司的AI平台里，结果发现它的编译器只支持ONNX的静态图导出，不支持TensorFlow的SavedModel格式，也不支持PyTorch的JIT trace。这意味着我们得自己写一个模型转换工具，把PyTorch模型转成ONNX，再调它的编译器。但问题是，PyTorch的动态图特性导致很多算子（比如torch.where）无法被ONNX的静态图描述，转出来的模型要么报错，要么精度下降。更崩溃的是，它的编译器对某些算子（比如LeakyReLU）没有硬件实现，只能用软件模拟，导致性能差10倍。最后我们不得不绕路：把模型里所有不支持的算子全部替换成支持的手写算子，再重新训练微调。这个过程花了三个月，而如果用的是ARM的IP，直接调用CMSIS-NN库就行。所以，隼瞻如果想真正打开市场，必须在编译器层面做到“三端贯通”：前端支持主流框架（PyTorch、TensorFlow、ONNX）的完整算子集，中间层有自动图优化（比如算子融合、内存复用、量化感知），后端能针对不同微架构生成定制化代码。这需要投入大量人力资源，而且不是一两年能完成的。我见过一家初创公司，堆了50个编译器工程师，花了三年才勉强做到对ResNet系列的支持，但对Transformer系列就抓瞎了——因为Transformer里有大量reshape、transpose、softmax等不规则算子，它们的编译器没做优化。

最后，我想分享一个实操层面的建议：如果你在评估隼瞻或其他国产AI IP，最有效的办法不是看他们的白皮书，而是直接做“三关测试”。第一关是“模型多样性测试”：选5个完全不同的模型，包括CNN、Transformer、RNN、GAN、以及一个带有动态shape的轻量模型（比如MobileNetV3的small版本），分别测量在batch size=1和batch size=4下的吞吐量和延迟。重点是看性能曲线是否“平滑”——如果某个模型的性能突然掉到其他模型的50%以下，说明它的微架构对那个模型的数据流有致命缺陷。第二关是“编译器鲁棒性测试”：把模型从ONNX转成它的IR，再跑一遍，看是否有精度损失（FP32下误差超过1%就算失败）。然后，手动改几个算子的参数（比如把卷积的stride从2改成3），看编译器是否报错或产生性能崩溃。第三关是“多核扩展性测试”：把模型拆成4个流水线阶段，分别放在4个核上跑，测量核间通信延迟和整体吞吐。如果4核的加速比小于2.5倍，那它的互连架构大概率有问题。这三关过不了的公司，建议谨慎评估。

说到底，国产AI IP的“黄金坑”在于，市场确实需要从ARM和Synopsys的垄断中突围，但“隐形雷”在于，技术层面的差距不仅仅是微架构设计，更是整个工具链和生态系统的构建。隼瞻能拿到近亿融资，说明资本在赌他们的团队能跨越这个鸿沟。但作为一线工程师，我更希望看到的是：他们能在一年内拿出一个支持动态shape和稀疏计算的参考设计，并在开源社区公开他们的编译器后端接口，让开发者能贡献自己的算子优化。如果只是闭门造车，那当年的“国产CPU热”就是前车之鉴。

跑过RISC-V向量扩展的都知道，你说的YOLOv7数据搬运问题太真实了，我们之前测某款IP，光DMA和流水线冲突就吃掉30%性能，这还没算编译器的自动向量化效果。隼瞻要是能把算子级定制和编译器后端做深，别光顾着吹通用算力峰值，那才真算挖到“黄金坑”了。

这个分析挺实在的，尤其是编译器优化那块，很多国产IP就是栽在“跑benchmark好看，实际项目一上就露馅”上。想问下，隼瞻这个融资规模在AI IP赛道里算什么水平？跟芯来、赛昉他们比，差异化重点是在RISC-V向量扩展还是别的方向？