6.3 交通出行与移动端

6.3 交通出行与移动端

本节摘要：高铁站上行色匆匆、闸机前一秒放行一人；手机上天天解锁数不清几次。交通与移动端把人脸识别推到"实时、高吞吐、轻量、省电"的极限。本节讲高铁/机场的身份核身吞吐、人脸闸机分流、手机解锁与 App 认证的端侧落地，说明这些场景为什么往往是"端云混合＋极致轻量"的样板间。

春运闸机的一秒与手机的一天

春运的高铁闸机，一秒要放行好些人，你没法让每个人都停下来等云端往返。手机的解锁，你一天要刷几十上百次，更不可能每次都把脸传回服务器、还要祈祷网络。交通与移动端对人脸识别的共同要求，就是把"快"和"轻"两个字写进架构：实时性不能断、吞吐量要够、算力功耗要省。它们给"端云混合＋轻量主干"加了最有力的脚注。

这两类场景还有一个共通的隐藏压力：极端峰值。春运、早晚高峰、节假日闸机，流量一下子飙到日常的几倍甚至十几倍——架构要是按平均负载设计，峰值一到就崩。

吞吐、实时、轻量

高铁/机场：身份核身的高吞吐

实名制与安检要求"人票证合一"，系统要做验证（1:1）＋防止冒乘倒票。硬约束在吞吐：高峰期闸机前排长队，一次核身必须毫秒级完成。所以通常在设备本地跑轻量检测＋轻识别，把"是不是本人"先判在本地；只有跨闸的比对、库变更新才少量上云。

"本地先判、拿不准再上云补一刀"的设计，把高峰期的请求压力大部分留在本机，只在存疑时才占云端带宽——这是吞吐类场景降本增效的关键一招。

人脸闸机与分流：实时并发

地铁、景区的人脸闸机靠 1:N 或预授权库做无卡通行，核心是"并发高、响应快"。它常配合端侧缓存＋云端索引，把"该在哪层查"的时序调准，高峰期才知道怎么扛住集中入闸的峰值。这背后还有一个分工窍门：热门常客的比对结果做本地缓存，冷门新客才上云查大库，能显著削掉峰值压力。

手机解锁与 App 认证：端侧轻量

手机解锁是移动端人脸的样板：活体、1:1 比对、特征几乎全在设备本地跑，数据不出机，还受功耗发热约束。工程上坚持把轻量主干（MobileFaceNet 一档）量化后塞进端侧神经引擎，靠"端上活体＋端侧比对"保证体验与隐私，只有注册更新才触网。

这类场景"验收"用的仍是老两样：FRR 管"解锁顺不顺"，FAR 管"别人开不开你手机"，再加一点防伪造（印有你照片的 A4 纸也打不开）——四者像一把锁的四道簧。

峰值与功耗两头防

• 吞吐类场景先按"峰值并发的计量"配设备，别等闸机瘫痪才醒悟要端云分层——把春运/高峰的峰值流量写进容量规划，是这类项目绕不开的功课。
• 移动端起测真实帧率与耗电，量化＋裁剪是标配，但精度让位要守一条底线，别压到不可用——为了省电把 FAR 做崩，得不偿失。
• 端上判"是否本人"，云上兜底"大库变更/复核"，端云混合是交通与移动的主流解；本地缓存常客、云端查冷门，是削峰的具体手段。

一句话直觉：交通与移动端是"把识别尽量留在离现场最近、风险最低的那一层"的践行者——本地快判，云上兜底，省带宽又保隐私。高并发不是"多买几台服务器就完事"，真正的瓶颈常在上链路、端上帧率与云端索引。

把"一秒放几人"落到量化：吞吐到底从哪来

都说高铁闸机要毫秒级、一秒放一人，可这个"一"从哪来？一次核身的完整链路是：图像采集→检测∓对齐→嵌入→比对→判决，每一段都有耗时，端上的推理耗时占大头。要提吞吐，别只盯着换更快的模型，还要并行化：把多路人流并排多台闸机、端上做流水线（采集与推理重叠）、把比对结果的缓存本地化命中，这些往往比单点抢那几十毫秒更能抬高一秒的放行量。真算一遍端上单次耗时 × 并行度，你才知道峰值要配多少台设备才不堵点。

弱网与离线：交通场景的降级开关

交通闸机最怕的是"网络一断全线瘫痪"。设计上必须提前想好降级：端上能独立完成的本地 1:1 先判，存疑才上云；一旦云端失联，要么干脆走"保守拒绝＋引导走人工通道"，要么放本地做一次更宽阈值但更谨慎的临时判定。把"断网怎么办"当作一等公民写进架构，而不是上线后遇上才补——春运这样的极端流量本就脆弱，多点一个"离线可走"的备胎，就是给通行高峰兜底。

手机端的天平：精度、耗电、耗存三选二

手机端人脸解锁，是在精度、耗电、内存三者之间挑平衡,往往是"三选二"：要精度高、又要体积小，就必须在耗电/推理速度上让步；要轻量省电，就得接受一定精度的让位。工程上常见的权衡路径：先量化到 INT8 让模型变小、推理快，看精度掉多少；再考虑剪枝或换更轻主干；最后按"帧率、耗电、精度"三个指标一起验收，而不是只报一个准确率。很多手机解锁项目做砸，不是模型不好，而是没在"精度-耗电-体积"三角里找到一个可上线的落点。

人脸闸机的误拦：排队环境的隐形压力

人脸闸机还有一个容易被忽略的隐性考验：误拦（FRR）不仅伤用户体验，还直接引发排队。闸机前一个人被误拦，就得转人工核验，后面人的节奏全断，高峰期甚至造成闸口排堵。所以闸机选型对 FRR 比对精度更敏感——你不能只追求 FAR 极低，还得保证 FRR 足够低，否则安全是做到了、通行效率崩了。针对闸机场景评分时，别只盯着"能拦多准"，更要看"别把人堵在门口"——这是吞吐类场景和纯高安全场景在指标权重上的本质差别。

闸机前的等待时间：体验不是玄学，是能算出来的

高铁闸机前旅客抱怨"慢"，有时不是模型本身慢，而是"采集-检测-对齐"这几帧要占时间。优化的思路可以往"提前采集"走：旅客走到闸机前一米，摄像头就开始检测帧，一旦检测到人脸合格就马上进入比对；这样走到闸机正前时，比对已经快做完，几乎秒开。把"计算时间藏在等待时间里"，是吞吐和体验双优的工程手艺。这种体验优化不需要换更贵的硬件，只需要把"采集与检测提前触发"写进时序设计，就能把平均等待时间砍一半，排队观感立刻变好。

移动端功耗的优化：推理时机的巧安排

移动端人脸解锁需要平衡"快"和"省电"，一个常见的优化是"把推理触发点放在亮屏那一帧，亮屏后立刻推理，推理出通过就立刻解锁"——而不是等你把脸对准再采集再推理。把整个流程时序往前挪，用户拿起手机亮屏，解锁结论已经出来，体验跟功耗都好了。再配合亮屏那一下的硬件加速，既能快得让你感知不到，又不会在后台无端耗电。移动端的好体验，常常在时序上做文章，不止是算法压缩这一件事。

三个行业看完了，我们看到了同一台断案台的千姿百态。可每个行业都藏着绕不开的天敌——下一章直面那些短板、对抗与伦理护栏。