最近被同一个问题问了很多遍AI 应用要落地计算芯片到底选哪家 问的人里有做工业视觉的有做餐饮收银系统的有在做边缘盒子创业的还有想往手机里塞大模型的。这个问题根本没法一句话回答因为 AI 计算芯片现在不是选一家的事而是切成了云端、边缘、端侧三条完全不同的线。每条线的选型逻辑、成本模型、部署方式乃至踩坑姿势差别比想象中大得多。这篇文章想把三条线的真实格局讲清楚每条线上有哪些主流玩家、各自主打什么场景、企业实际采购时到底在为什么买单以及最关键的——你手上的项目应该往哪条线走。内容偏实战适合正在做技术选型、准备立项或者想评估手里的设备能不能跑 AI的团队参考。1. 三条线的本质差异不是芯片大小是商业模式很多人以为云端、边缘、端侧的区分就是芯片大不大、功耗高不高其实这只是表象。真正的分界线是算力离数据源有多远、以及算力是租的还是买的。1.1 三条线分别解决什么问题云端这条线本质是按需租算力。模型训练、海量数据处理、大并发推理都适合丢到数据中心里跑。你不需要买显卡按小时付费即可典型代表是各云厂商的 GPU 实例。边缘这条线算力被放到离数据产生的地方很近的位置——工厂车间、变电站、门店、高速公路收费站。它解决的是云端太远的问题网络延迟、带宽成本、数据隐私。边缘节点通常是一台小服务器或一个盒子能独立跑推理又不需要塞进消费级设备里。端侧这条线算力直接塞进设备本体手机、摄像头、耳机、智能家电、车载中控。它连边缘都算不上因为设备可能完全离线只能在几瓦甚至零点几瓦的功耗里做推理。1.2 一条线的三个维度拉开差距把三条线放在同一张表格里差别会更直观维度云端边缘端侧算力位置数据中心数据源附近的节点/网关设备内部典型功耗数百瓦到数千瓦几十瓦到一百多瓦0.5W 到 10W商业模式按小时/按量租赁一次性购买硬件持续运维芯片嵌入设备随设备出货网络依赖必须在线可离线/弱网可用完全离线典型延迟几十毫秒到秒级十毫秒以内几毫秒关键瓶颈带宽与成本功耗/散热/环境内存、功耗、算子支持1.3 为什么企业经常三条线混合用我接触过不少项目最后都不是只选一条线而是混合架构。举个例子一套视频监控系统端侧摄像头做低级移动侦测边缘盒子跑 YOLO 检测云端只负责跨区域的模型迭代和报表分析。三条线各干各擅长的事。所以这篇文章后面的内容与其说是帮你选一家芯片不如说是帮你想清楚每条线上各自该押谁。2. 云端线CUDA 生态的护城河与非英伟达们的生存空间云端 AI 芯片市场格局一句话就能概括英伟达一家独大其他家都在用不同姿势抢边缘份额。但抢能不能成功取决于生态而不是参数。2.1 企业选英伟达买的其实是 CUDA 生态很多团队选英伟达理由很粗暴因为模型是用 PyTorch 写的PyTorch 默认调用 CUDA。你训练时用 CUDA推理时转 TensorRT中间几乎不用改代码。换成别的芯片光是把 PyTorch 模型迁移过去、补齐不支持的算子就得烧掉几周人力。云端场景里英伟达的 A100、H100 依然是训练主力L4、L20、A10 这类推理卡则是大批量 API 服务的标配。企业的真实心态是贵但省心。2.2 大厂自研芯片的策略各不相同谷歌 TPU参数很漂亮端到端时延也能打。但它只在谷歌云上按专用 TPU Pod 方式开放你要用就得把整套训练流水线迁到 GCP等于锁死。真正选择 TPU 的多数是已经在谷歌云里跑大业务、能把迁移成本摊薄的团队。AWS Inferentia/TrainiumAWS 自家的推理芯片结合 Neuron SDK 用。对已经在 AWS 上深度扎营的公司来说成本确实能压下来。前提是你的算子清单在 Neuron 支持列表里冷门算子一旦缺失就得手写算子或回退 CPU体验很割裂。AMD MI300X显存容量大192GB价格相对 H100 有优势近几年 ROCm 在 PyTorch 下的兼容性进步明显。但社区生态、调试工具链、第三方库的完备度仍不如 CUDA选择 AMD 通常意味着团队里有能啃底层的人。昇腾Ascend910 系列在部分云平台以实例方式提供配套 CANN 工具链。其算子覆盖已经比早期完善很多但冷门操作仍可能出现不支持的情况迁移时需要评估算子映射表。对 PyTorch 模型通常要走昇腾自家的迁移工具和适配流程不能指望零成本跑通。以上这些芯片各有忠实用户但他们的共同点是只在特定云环境里才划算。如果你没有被某个云深度绑定选择面基本还是回到英伟达。2.3 中小企业为什么宁愿租 4090最近便宜的 4090 云端特别火是有道理的。4090 有 24GB 显存跑 7B 参数量模型的 Q4 量化版大约 4.7GB 显存占用绰绰有余多 batch 推理、微调 7B 以下模型都够用而且按小时计费的价格远低于 A100/H100。我在实际项目里测过租一台 4090 做 OCR 和检测类服务的并发推理性价比非常好。但要注意它的几个硬伤单卡没有 NVLink多卡通信走 PCIe跨卡模型并行性能很差数据中心版和专业版散热设计更好普通消费级 4090 在机房高负载下容易过热降频。所以它的定位很明确——中小团队做推理、做微调、做原型验证而不是大规模训练。2.4 云端选型的现实算法我给团队做云端选型时一般按三个问题走模型多大7B 以下量化模型优先租 4090 或 A1070B 以上考虑多卡 A100/H100或者干脆用 API。负载是持续还是突发突发负载适合按量付费持续 24 小时跑满的可以考虑包月或自建但要把运维折旧打进去。团队有没有底层迁移意愿没有就老实留在 CUDA 生态。云端选型本质是用钱换时间的生意。企业选择的不是最强芯片而是让团队交付最快的那条路径。3. 边缘线机房之外那块吃不掉又甩不开的算力边缘是我认为目前最值得投入精力研究的一条线。它的场景太杂了——工厂、门店、高速公路、变电站、通信基站每一个都对功耗、温度、接口、可靠性有不同要求没有一家芯片能通吃。3.1 边缘算力的真实边界边缘节点要回答的问题只有一个在数据中心之外能不能把这里的推理任务独立跑起来这个独立包括网络断了也能跑、坏了一台不能全瘫、宽温环境下不降频、数据不出本地。边缘算力不需要最顶级的浮点性能但需要高可用和环境适配。3.2 Jetson 家族与 FPGA 网关的取舍英伟达 Jetson 系列是边缘推理的明星级选择。当前主流是 Orin 系列覆盖三个档位型号算力稀疏 INT8功耗范围典型用途Orin Nano 8GB约 40 TOPS7–15W1–2 路摄像头检测、OCR、小型控制器Orin NX 16GB约 100 TOPS10–25W多路视频分析、工业视觉、轻量模型服务AGX Orin 32/64GB约 275 TOPS15–40W端侧 LLM、多传感器融合、车路协同选择逻辑也很直接项目有多少路数据流、模型多大、功耗上限多少。只跑一路 YOLOv8s 的 INT8 版本Orin Nano 就够了要同时处理 8 路 1080p 视频流并做跟踪建议直接上 Orin NX要边缘跑 7B 量化模型老老实实 AGX Orin 64GB。而 FPGA 在边缘的角色经常被误解。它不是用来堆算力的而是提供确定时延和自定义数据通路。做通信测试终端、电力网关的团队喜欢用 ARMFPGA 组合ARM 跑 Linux 和上层 AI 推理FPGA 做报文解析、协议转换、精确时间戳等对确定性要求极高的事。比如一个边缘网关既要采集毫秒级的传感数据、又要跑识别模型纯 NPU 方案在接口灵活性上就吃亏FPGA 能把采集和预处理做成硬件流水线。代价是开发周期长、人才要求高判断标准很简单你的场景有没有非它不可的定制 I/O没有就别上 FPGA。3.3 边缘节点和机房一个普遍误解有人问一个边缘计算节点是不是一个机房这个问题很典型。不是。云机房是一个楼层级别的数据中心边缘节点通常就是一个壁挂盒、一台小服务器、或者一个带 GPU/NPU 的网关。也有场景叫边缘一体化机柜——里面塞几台服务器、交换机和 UPS那是介于机房的边缘形态但它仍然部署在用户现场而不是集中式数据中心。这个区别影响选型现场空间有多大、有没有空调、能不能接市电直接决定你选 Jetson 还是 x86 边缘服务器。3.4 边缘部署 YOLO 的高误检率问题从芯片到算法链路的连锁反应YOLO 边缘部署监控误检率高是边缘圈高频吐槽。表面看是模型问题实际根源往往在芯片和算法之间的衔接层。常见原因有三个第一量化精度损失。边缘算力为了提吞吐普遍把 FP16 换成 INT8。如果只用一张通用校准集做量化对现场光影、反光、雨雾等特征根本没有覆盖量化后误检率涨几个点很正常。解决方式是采集现场真实样本做量化校准必要时对困难样本做二次校准。第二散热降频导致推理时间抖动。边缘盒子密封在工业柜里夏天 60 度环境温度下芯片降频会让推理从 30ms 变成 80ms整个追踪链路出现漏检跳变看起来就像误检变多。这类问题要从散热设计下手加鳍片、风扇、铝壳导热并在软件里监控芯片温度。第三NMS 阈值和场景不匹配。工厂密集货架场景默认的 IoU 阈值容易产生大量重叠框远距离小目标默认置信度阈值又偏低。边缘场景必须用现场数据重新调阈值而不是沿用 COCO 上的经验值。另外很多人问RapidOCR 的 ONNX 模型是云端的还是本地的答案是既可以本地也可以云端。RapidOCR 的 ONNX 模型本身不带云端依赖完全可以用 onnxruntime 在 CPU 上本地跑也可以在边缘盒子上通过 ONNX Runtime 的提供商接口用 NPU 加速。所谓云端一般指调用在线 API比如把图片传上去返回文字而本地部署只需要几十 MB 的模型文件和 onnxruntime 库这对门店单据识别这种私密性强的场景非常合适。边缘选型的核心结论是先定场景约束功耗、环境、数据量再选芯片最后才是选模型。顺序反了后面全是坑。4. 端侧线手机、PC、家电里的算力硬约束端侧 AI 是门槛最高、也是最容易被参数表误导的一条线。很多团队看着手机芯片 NPU 的 TOPS 值很高真把模型部署进去才发现寸步难行。4.1 NPU 战争现状端侧主流芯片玩家不少苹果 Neural Engine闭源、只服务自家生态系统能力很强但外部团队基本无法直接调用底层 NPU只能通过 Core ML 间接部署。高通 Hexagon NPU安卓旗舰标配配套 QNN 工具链和 AI Engine Direct API第三方可通过 ONNX Runtime 的高通执行提供方调用。联发科 APU天玑系列内置 NPUNeuroPilot 工具链对 Android 端部署支持逐步完善性价比主导中端市场。昇腾、麒麟等手机芯片 NPU在存量国产手机上有大量 NPU 算力但工具链和模型支持度参差不齐部署时务必先做算子兼容性验证。Rockchip RK3588 等嵌入式 NPU6 TOPS 级别的 NPU 集成在 SoC 里配 RKNN 工具链是边缘盒子、门禁、家电最常用的国产嵌入式方案。注意 RKNN 和 ONNX 之间有算子映射表冷门算子要手动切分到 CPU 或重写模型。AI PC 的独立 NPUIntel Core Ultra、AMD Ryzen AI 系列都集成了低功耗 NPU主打本地办公辅助、会议转写、本地 RAG 检索但目前软件生态还在早期很多机型实际只能跑固定几个模型。4.2 端侧跑模型的资源红线端侧最硬的约束不是算力是内存带宽和内存容量。一块手机 NPU 标称 30 TOPS但模型权重从 DRAM 搬到 NPU 缓存的那条路是共享的实际推理速度往往被带宽卡住。7B 模型的 Q4 权重大约 4.7GB手机光加载权重就快把运行内存吃光了推理时还要留给系统和摄像头至少 4–6GB所以 12GB 内存以下的手机跑 7B 模型基本是幻想。1.5B 级别的 Q4 模型大约 1GB中高端手机可以勉强跑但生成速度大概在每秒几个 token只适合演示。端侧真正的舒适区是唤醒词识别几 MB、小型分类器、轻量检测、端侧 OCR 的裁剪版。比如智能门铃的人脸检测、家电的语音降噪、键盘的输入预测这些模型体积小适合塞进 1W 级功耗里。4.3 端侧 AI 硬件部署链路端侧部署和云端完全不一样流程通常是这样训练好的模型导出为 ONNX通过厂商工具链RKNN、QNN、NeuroPilot 等做格式转换做 INT8 量化并用目标硬件跑校准集成对应 RuntimeTFLite Micro、ONNX Runtime、NPU 厂商 SDK在真机上做功耗、发热、时延和内存峰值测试。每一步都可能翻车量化后精度崩了、算子不支持导致 CPU 兜底、内存峰值超过阈值被系统杀掉。所以端侧评估芯片不要只看 TOPS直接用你自己的模型在真机跑一遍用电量监控软件看稳态功耗和推理时延。端侧这条线的潜规则是芯片选型只是在给软件工作量的多少定价。生态好的平台一周部署完生态差的平台一个月还在调算子。5. 项目角度三条线到底怎么选我的一套决策清单讲了这么多厂商和芯片最终还是回到一个问题我的项目该选哪条线我不建议一上来就比参数。先回答下面五个问题答案组合基本就把路定死了。5.1 五个必问的问题问题一实时性要求多高需要毫秒级响应的机械臂避障、语音交互、工业急停端侧或边缘能容忍 1 秒以上的云端完全够。问题二数据能不能出本地医疗影像、财务单据、生产数据很多行业规定不能传云。这类项目直接锁定边缘或端侧云端再便宜都不参与。问题三负载是持续的还是突发的7×24 小时连续推理比如产线质检适合边缘买断一天只有十几个请求的云端按量付费更划算。问题四设备量级多大卖一万套终端产品端侧芯片的成本均摊优势巨大只做一套系统集成项目边缘盒子反而更省事。问题五模型还要不要迭代云端升级最方便边缘次之端侧每次更新都要走 OTA 和存量设备兼容成本最高。5.2 用天平算一笔真实账拿最常见的7×24 视频检测场景算一笔账云端 4090 按量租一天 24 小时跑满按目前常见价格大概一个月一千多元一台能跑多路检测的边缘盒子比如 Orin NX 模块加外壳电源一次性成本几千块。粗略算下来只要项目生命周期超过三四个月边缘就回本了。但如果只是做一次持续一周的临时活动安保云端反而省钱。反过来如果模型是 70B 级别、需要多卡并行边缘方案根本排不上号AGX Orin 64GB 连权重都塞不下只能云端。这就是我之前说 R1-7B Q4 的边缘部署——4.7GB 的权重Orin Nano 8GB 版本内存勉强够但推理极慢实际至少要 Orin NX 16GB 以上才谈得上体验。模型大小是筛选路线的最快指标。5.3 混合方案把模型拆开跑最近很火的一种思路是不选单线而是把模型按任务阶段拆给不同位置。比如云端—终端混合餐饮服务系统这是很多系统设计考题里的典型场景实际落地也同样合理收银终端本地跑 OCR 识别菜单、会员即时校验断网也能点单云端负责菜品推荐、供应链预测和经营报表。又比如视频监控项目端侧摄像头做区域移动侦测边缘节点做目标识别云端做跨点位的模型更新。还有一个容易被忽略的价值点边缘节点上做去重。多路摄像头或传感器汇聚到边缘后先做数据去重、抽帧、压缩再回传云端能省下大量上行带宽。边缘侧去重算法配合存储本身就是一条独立的优化线很多团队靠这一步把带宽成本砍掉 70% 以上。这种端侧预处理、边缘去重、云端分析的混合链路可能是未来两年最主流的架构。6. 我踩过的坑和几条实操建议最后说点掏心窝的话。下面这些坑不是从文档里看来的是实打实踩过、也看着别人踩过的。6.1 坑一只看 TOPS不看真实吞吐TOPS 是理论峰值很多厂商标注的是稀疏值还要乘以稀疏率才等于实际值。同一个 INT8 模型在标称 40 TOPS 的芯片上跑到 20 帧还是 2 帧差距巨大。正确做法是拿自己的模型、自己的输入分辨率、自己的 batch在目标板卡上跑一遍稳态吞吐。永远用自己的基准集说话。6.2 坑二低估了量化带来的精度损失INT8 量化在检测和分类任务上通常问题不大但在回归类任务、细粒度识别、OCR 小字识别上很容易损失 5% 到 10% 的精度。如果不愿意花精力做校准集宁可在边缘侧保留 FP16 推理用多核 CPU 或更大的 NPU 扛住吞吐也别急着上 INT8。6.3 坑三硬件的AI 能力不等于部署能力很多 NPU 只有固定算子集Transformer 里一个注意力算子的实现方式多个平台各不相同。买硬件之前先把模型的算子清单和平台的算子映射表过一遍留意哪些算子会回退到 CPU。一次回退可能让整条链路的延迟从 15ms 变成 150ms。6.4 踩过几次坑之后的固定流程我现在接手任何 AI 硬件项目都会先做这几件事把 JetPack、RKNN、QNN 之类的 SDK 版本固定到容器里并记录完整版本号在硬件的通风和散热方案确认前不做长期负载测试所有选型邮件都附带I 我们团队用自有基准数据实测的结论而不是厂商白皮书截图。这些看起来繁琐的习惯能省掉大量后期排查时间。如果项目还在早期我的建议永远是能租就先租能借用就先借用确认性能和成本都合适再批量采购硬件。同时准备一个小而全的基准测试集里面包含现场最脏最难的数据它会在你未来每次升级硬件或换平台时成为最靠谱的裁判。做 AI 硬件选型真正拉开差距的不是谁拿到了最新最强的芯片而是谁用最短的时间证明了这套硬件在自己的真实场景里站得住。