企业官网建设流程全解析

最近被同一个问题问了很多遍："AI 应用要落地，计算芯片到底选哪家？" 问的人里有做工业视觉的，有做餐饮收银系统的，有在做边缘盒子创业的，还有想往手机里塞大模型的。这个问题根本没法一句话回答，因为 AI 计算芯片现在不是"选一家"的事，而是切成了云端、边缘、端侧三条完全不同的线。每条线的选型逻辑、成本模型、部署方式乃至踩坑姿势，差别比想象中大得多。

这篇文章想把三条线的真实格局讲清楚：每条线上有哪些主流玩家、各自主打什么场景、企业实际采购时到底在为什么买单，以及最关键的——你手上的项目应该往哪条线走。内容偏实战，适合正在做技术选型、准备立项，或者想评估"手里的设备能不能跑 AI"的团队参考。

1. 三条线的本质差异：不是芯片大小，是商业模式

很多人以为云端、边缘、端侧的区分就是"芯片大不大、功耗高不高"，其实这只是表象。真正的分界线是算力离数据源有多远、以及算力是租的还是买的。

1.1 三条线分别解决什么问题

云端这条线，本质是按需租算力。模型训练、海量数据处理、大并发推理，都适合丢到数据中心里跑。你不需要买显卡，按小时付费即可，典型代表是各云厂商的 GPU 实例。

边缘这条线，算力被放到离数据产生的地方很近的位置——工厂车间、变电站、门店、高速公路收费站。它解决的是"云端太远"的问题：网络延迟、带宽成本、数据隐私。边缘节点通常是一台小服务器或一个盒子，能独立跑推理，又不需要塞进消费级设备里。

端侧这条线，算力直接塞进设备本体：手机、摄像头、耳机、智能家电、车载中控。它连"边缘"都算不上，因为设备可能完全离线，只能在几瓦甚至零点几瓦的功耗里做推理。

1.2 一条线的三个维度拉开差距

把三条线放在同一张表格里，差别会更直观：

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/Trainium：AWS 自家的推理芯片，结合 Neuron SDK 用。对已经在 AWS 上深度扎营的公司来说，成本确实能压下来。前提是你的算子清单在 Neuron 支持列表里，冷门算子一旦缺失，就得手写算子或回退 CPU，体验很割裂。
• AMD MI300X：显存容量大（192GB），价格相对 H100 有优势，近几年 ROCm 在 PyTorch 下的兼容性进步明显。但社区生态、调试工具链、第三方库的完备度仍不如 CUDA，选择 AMD 通常意味着团队里有能啃底层的人。
• 昇腾（Ascend）910 系列：在部分云平台以实例方式提供，配套 CANN 工具链。其算子覆盖已经比早期完善很多，但冷门操作仍可能出现"不支持"的情况，迁移时需要评估算子映射表。对 PyTorch 模型，通常要走昇腾自家的迁移工具和适配流程，不能指望零成本跑通。

以上这些芯片各有忠实用户，但他们的共同点是：只在特定云环境里才划算。如果你没有被某个云深度绑定，选择面基本还是回到英伟达。

2.3 中小企业为什么宁愿租 4090

最近"便宜的 4090 云端"特别火，是有道理的。4090 有 24GB 显存，跑 7B 参数量模型的 Q4 量化版（大约 4.7GB 显存占用）绰绰有余，多 batch 推理、微调 7B 以下模型都够用，而且按小时计费的价格远低于 A100/H100。

我在实际项目里测过，租一台 4090 做 OCR 和检测类服务的并发推理，性价比非常好。但要注意它的几个硬伤：单卡没有 NVLink，多卡通信走 PCIe，跨卡模型并行性能很差；数据中心版和专业版散热设计更好，普通消费级 4090 在机房高负载下容易过热降频。所以它的定位很明确——中小团队做推理、做微调、做原型验证，而不是大规模训练。

2.4 云端选型的现实算法

我给团队做云端选型时，一般按三个问题走：

1. 模型多大？7B 以下量化模型，优先租 4090 或 A10；70B 以上，考虑多卡 A100/H100，或者干脆用 API。
2. 负载是持续还是突发？突发负载适合按量付费；持续 24 小时跑满的，可以考虑包月或自建，但要把运维折旧打进去。
3. 团队有没有底层迁移意愿？没有，就老实留在 CUDA 生态。

云端选型，本质是"用钱换时间"的生意。企业选择的不是最强芯片，而是让团队交付最快的那条路径。

3. 边缘线：机房之外那块"吃不掉又甩不开"的算力

边缘是我认为目前最值得投入精力研究的一条线。它的场景太杂了——工厂、门店、高速公路、变电站、通信基站，每一个都对功耗、温度、接口、可靠性有不同要求，没有一家芯片能通吃。

3.1 边缘算力的真实边界

边缘节点要回答的问题只有一个：在数据中心之外，能不能把这里的推理任务独立跑起来？

这个"独立"包括：网络断了也能跑、坏了一台不能全瘫、宽温环境下不降频、数据不出本地。边缘算力不需要最顶级的浮点性能，但需要高可用和环境适配。

3.2 Jetson 家族与 FPGA 网关的取舍

英伟达 Jetson 系列是边缘推理的明星级选择。当前主流是 Orin 系列，覆盖三个档位：

选择逻辑也很直接：项目有多少路数据流、模型多大、功耗上限多少。只跑一路 YOLOv8s 的 INT8 版本，Orin Nano 就够了；要同时处理 8 路 1080p 视频流并做跟踪，建议直接上 Orin NX；要边缘跑 7B 量化模型，老老实实 AGX Orin 64GB。

而 FPGA 在边缘的角色经常被误解。它不是用来"堆算力"的，而是提供确定时延和自定义数据通路。做通信测试终端、电力网关的团队喜欢用 ARM+FPGA 组合：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：天玑系列内置 NPU，NeuroPilot 工具链对 Android 端部署支持逐步完善，性价比主导中端市场。
• 昇腾、麒麟等手机芯片 NPU：在存量国产手机上有大量 NPU 算力，但工具链和模型支持度参差不齐，部署时务必先做算子兼容性验证。
• Rockchip RK3588 等嵌入式 NPU：6 TOPS 级别的 NPU 集成在 SoC 里，配 RKNN 工具链，是边缘盒子、门禁、家电最常用的国产嵌入式方案。注意 RKNN 和 ONNX 之间有算子映射表，冷门算子要手动切分到 CPU 或重写模型。
• AI PC 的独立 NPU：Intel 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 硬件部署链路

端侧部署和云端完全不一样，流程通常是这样：

1. 训练好的模型导出为 ONNX；
2. 通过厂商工具链（RKNN、QNN、NeuroPilot 等）做格式转换；
3. 做 INT8 量化并用目标硬件跑校准；
4. 集成对应 Runtime（TFLite Micro、ONNX Runtime、NPU 厂商 SDK）；
5. 在真机上做功耗、发热、时延和内存峰值测试。

每一步都可能翻车：量化后精度崩了、算子不支持导致 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 硬件选型，真正拉开差距的不是谁拿到了最新最强的芯片，而是谁用最短的时间证明了这套硬件在自己的真实场景里站得住。