4.1 硬件平台选型

4.1 硬件平台选型

本节摘要：同样的算法，跑在云端大 GPU、一台边缘小盒子或一部手机上，体验天差地别。本节把三类硬件平台——云服务器、边缘计算设备、移动终端——的算力、延迟、成本与功耗摊开对比，并给出一条"按场景选平台"的判断路径，让你知道该把人脸识别放在哪一层算。

一张账单，算清该把识别放哪层

理想状态下，谁不想把所有计算都扔给超算？可现实会敲你三下：摄像头装在千里之外、几万路人同一秒要刷，你总不能把每帧都背回机房再传回来。网络延迟、带宽成本、数据不出境的合规、离线必须能用的刚需，都在逼你把计算放"离现场更近"的地方。硬件选型，本质是在"算力够不够"和"离现场近不近、钱花得值不值"之间做一笔平衡账。

另一个常见误区：把"算力大"当最重要的维度。实际上很多项目死于延迟或数据出境合规，而不是模型精度——硬件选型要四个秤砣一起上秤，不是只有算力一件。

云服务器：算力管够、离场远

云端的算力几乎无上限，可配大 GPU 或强力 CPU，最适合跑重型识别主干、做大规模向量检索（千万级库）、集中式训练与更新。代价是每一帧都要把数据传上来，延迟受网络牵制，隐私数据也要飞越公网。它适合"能接受往返、需要集中管理"的场景，比如银行总行的统一核身接口、集中式的人脸库比对。

上云还有个隐形的账：进出带宽和 GPU/CPU 时长是持续成本，且随流量线性涨。评估云方案时，把"单次核身的带宽成本 × 日均次数"也算进去，往往比买设备更接近真实成本。

边缘设备：离现场近、数据不出门

门禁、闸机这类边缘盒子，把检测甚至识别塞进设备本地。优势是延迟低、断网可用、数据不出设备，正好回避隐私出海问题；约束是算力和内存紧张，通常只能跑轻量主干、低频识别。典型取舍是：把"检测＋轻识别"放边缘、把"千万库比对"交给云端，两端配合。

选边缘盒子时，别只看盒子的标称算力（TOPS 一类），要看它实际跑你的那个模型能到多少帧、内存够不够装下模型和特征缓存——纸面算力和真实帧率经常差一截。

移动终端：算力局促、体验先行

手机这类移动端算力最紧、还要管功耗和发热，通常只能跑极致轻量模型（MobileFaceNet 一档）。但它的优势是"设备即入口"——解锁、支付这类高频交互都在本地完成，数据几乎不出设备。移动端一般配合"端上活体＋注册特征上云检索"的混合架构，兼顾隐私与库规模。

端上跑还有一个特殊约束：在弱网、电话占用等场景下，端上模型必须能独立完成"活体＋1:1"这套最低限度的判断，否则用户体验会随网络崩盘。

一张对比账本

按场景选平台的判断路径

• 大库＋要精准 → 云端检索；实时＋要离线 → 边缘；移动端 → 端侧轻量。
• 边缘与云端不是二选一，常见的是"边缘先挡一层、云端兜底"的分层部署，把最常用的判断留本地、把最重的库查交给云端。
• 上线前务必在目标硬件上测真实帧率与内存，再决定要不要换轻量主干、量化压缩，别等落地才发现跑不动——把"模型能不能塞进这台盒子"提前到项目早期验证。

一句话直觉：硬件选型是在"算力、延迟、隐私、成本"四个秤砣上找平衡，没有通吃，只有适配。别把云端架构原样搬到边缘，算力骤降后检测识别都会跑不动，必须先做最小可行验证再放大。

算一个真实的部署成本算例

空谈平衡，不如动手算一笔账。假设你有一套门禁，日均 5 万次核身：如果全走云端，每帧约传 100KB 图像、来回延迟按网络波动 100ms 估算，光带宽和 GPU/CPU 时长就是持续的硬支出，且随流量线性涨——流量峰值还要另计扩容费用。如果改成边缘优先，把"检测＋轻识别"放本机，只有存疑帧才上云，本地 CPU/盒子的采购是一次性的，日常带宽成本骤降到原来的零头。两种方案的差别，恰恰印证"算力 vs 离现场近"这四个秤砣的博弈：没有绝对更省钱，只有和你的流量、隐私、延迟要求匹配的一笔账。上线前把这笔账按"日均、峰值、年化"三档都算一遍，你才敢拍板。

端侧推理的量化与裁剪，是硬件选型的另一半

硬件选型不能只选盒子，还得选"能不能塞得进盒子"。同一个模型，全精度 FP32 跑在边缘盒子上可能帧率远不达标，但量化到 FP16 或 INT8、裁剪掉冗余通道后，帧率和内存立刻可用了。所以判断"这台硬件够不够"，要看：同样的模型在你的目标盒子上能否量化后跑到目标帧率、内存能否装下模型＋特征缓存。手里没有量化和裁剪的手段，再强的盒子也白搭。把"模型压缩"和"硬件选型"放在一起决策，是先验真章再选型的关键。

一个常见的误区：笔记本上跑得动，不等于盒子上跑得动

开发常在带大 GPU 的机器上测，模型跑得飞快，就想当然以为部署没问题。现实是边缘盒子算力只有开发机的一个零头，又没有 CUDA 那种加速，同一个模型可能是几十倍的帧率差距。所以千万别用开发机的表现推算目标硬件的表现——要么直接在目标盒子/手机上真机测，要么用官方提供的基准转换系数做估算。这条一旦忽视，等上线才发现跑不动，返工成本远高于早期花一天在真实硬件上跑一遍快速验证。

功耗与散热，别被纸面参数骗了

边缘盒子、手机这类设备还有个容易被忽略的约束：功耗与散热。纸面 TOPS 再高，若是持续满负荷推理导致降频、过热重启，实际帧率会大打折扣；手机端长期满负荷推理更是直接烫手、掉电快，影响用户对产品的信心。选购和设计时，把"持续推理是否降频、散热是否够、整机功耗预算允许多少"这三问纳入考量，别只盯峰值算力这一个数——峰值光鲜、持续平庸，是端侧硬件最典型的坑。

一张硬件选型自查表

把前面的取舍汇成一张可勾选的自查表，落地时逐项打钩：一是"单次核身延迟预算"是多少毫秒，端上本地判还是可上云往返；二是"数据能不能出境"，不能出的就得上边缘或端侧；三是"峰值流量有多大"，按日均流量的几倍来配算力与索引；四是"模型在目标硬件量化后能否跑到达标帧率、内存能不能装下"，这两项必须先真机验证；五是"全流程成本（采购、带宽、运维、功耗）"是否在预算内。若五项都答得清楚，选型就基本不会走偏。把这张表当作项目的起点文档之一，它比反复纠结某个模型名称更能帮你站稳。

关键的一课：先做最小可行，再谈放大

无论你资源多充足，落地硬件选型几乎都该走"先最小可行、再放大"这条路：先在一台目标盒子/一部真机上跑通"检测＋对齐＋识别＋比对的闭环"，把真实帧率、内存、耗电测出来，确认可行后才谈采购规模与扩容。很多项目失败在"从一开始就按理想中的大库、大流量去规划硬件"——结果一上线发现单机根本跑不动，前期豪掷的资源都打了水漂。先小后大，既验证了技术，也控制了风险，是硬件这类重资产的稳妥姿势。

平台定了，下一步把这套台面上要拼装的"软件积木"摆出来——框架、工具链怎么搭。