4.5 端侧云侧部署

4.5 端侧云侧部署

本节摘要：训练好的模型要搬到云端、边缘或移动端"值班"。本节讲清三类部署形态的架构取舍（云端为主、边缘为主、端云混合）、以及大库检索在部署里怎么靠索引提速，最后给出一条从"模型导出→云端服务→边缘下沉"的落地路线，让你知道该把识别放在哪一"层"最值。

模型训好了，可它该在哪层值班

模型在手机里能跑，和塞进一个双核边缘盒子、再对接一座千万级的人脸库，是完全不同的问题。部署的痛点很直白：云端快但数据要飞回来、延迟不稳；边缘快又隐私但算力局促、库放不下；把两者混搭，又要处理"何时本地判、何时丢云端、结果怎么回流"。所谓部署，就是在"延迟、隐私、算力、可维护"四个约束里，把模型的每一段安顿在合适的那一层。

三种形态的取舍

云端为主

重识别与千万库检索放云端，通过统一接口对外服务。门槛低、好扩展、集中更新模型。缺点是每帧都走网络，延迟与带宽牵制明显，隐私要过合规。适合"数据可出区、能接受往返"的总行级核身、跨地域统一比对这样的场景。

云端部署的一个隐含工作量：你要自己处理并发、限流、容错、监控这几件事，模型本身的精度只是其中一环。上线"能跑"和上线"能扛住峰值且不崩"之间，隔着一个完整的服务工程。

边缘为主

检测（可加轻识别）放进设备本地，数据不出盒子，延迟低、离线可用。代价是算力轻模型、库放不下，基本只能做"本地判断是否本人"。适合门禁、闸机这类"实时、隐私敏感、可本地"的场景——它把最常用的判断压在本机，把最稳的交接留给运维。

端云混合：当下主流

把"轻量活体／检测/一次确认"放端上、把"大库检索开闸"放云端——这是当下最主流的分层架构。端上先挡一层噪声与基础核身，真正要查库时才把关键帧送云端，既省带宽又保精度。

大库检索：索引是提速舵

一旦库上百万，逐条比不现实。部署端普遍引入向量索引（倒排、乘积量化一类 ANN），先把"和全部比"换成"粗召回一批候选再精排"，把"找得多快"从线性磨到常量近似量级。索引的代价是近似误差与额外建库成本，需要拿准确率与耗时做折中——上线前务必用你自己的验证集量一下"索引引入了多少召回损失"，别只看它多快。

一张表：三种形态在哪层认人

从导出到下线的落地路线

• 模型导出阶段先试跑目标硬件的量化口（FP16/INT8）与运行时，把"能不能塞进边缘"提前验证，别到部署最后一刻才发现算力不够要返工。
• 端上先挡噪声与轻活体，云端负责大库检索与结算，边端混合兼顾实时、隐私与规模。
• 大库必配索引，把准确率损失控制在验收阈值内（用同阈值测召回），并保留无索引的暴力比对作为对照与兜底。
• 上线前对端上做"真实帧率/内存"压力测试，对云端做并发与限流演练——测试集上的模型成绩不能当生产表现，尤其要模拟弱网和峰值。
• 监控要盯"索引召回率漂移"和"端云失联时的降级行为"，这比盯单个准确率数字更能发现隐患。

一句话直觉：部署是给你的模型"安家"。安哪层，取决于延迟、隐私、算力、可维护四条绳索勒得多紧；端没想清楚就上生产，返工成本远高于一早点醒。

交付前的四问清单

在给模型"安家"之前，建议拿四问过一遍，能省掉大量返工。第一问：模型能在哪层跑——先试目标硬件的量化口（FP16/INT8）与运行时，确认能不能塞进端上；第二问：该在哪层判——端上能独立完成"活体＋1:1"吗，存疑才上云；第三问：大库怎么查——用向量索引把百万级检索压到合理时延，且索引的召回损失在验收阈值内；第四问：断了怎么办——端云失联时能否降级、不崩、可恢复。把四问落在某个具体案例上，你才能真正把"部署"从文档里的概念变成可落地、可排障的事实。

压测与降级：上线前的两道保险

部署最怕的不是模型精度，而是峰值来了扛不住、弱网断了没兜底。所以上线前做两件几乎必备的事：一是压测，用模拟峰值流量打模型与线程池，看吞吐和时延是否达标、会不会打爆内存；二是设计降级路径，端云失联或云端超时时，端上要么给一个保守的拒绝结果、要么提示用户改走人工通道，绝不能不明不白地放开或卡死。压测时着重观察索引的召回率，以及"大库越滚越大后索引更新会不会拖垮查询"这类长尾问题——很多系统死在数据涨到一定程度的那一天，而不是上线第一天。

灰度与回滚：部署不是三把火

真上线别一掌全量，用灰度更稳：先放小比例流量，观察 FRR/FAR 和调用成功率是否异常，再逐步放大；同时保留上一版模型与阈值的完整回滚配置，一旦发现指标异常能一键切回。时刻记住：线上模型的表现不等于测试集成绩——光照、遮挡、并发、索引状态都可能让线上悄悄偏离，灰度与回滚就是给这些"测不到的偏差"买保险。部署环节的责任，是让一次模型迭代像换插头一样可预期，而不是孤注一掷的脸盆倒水。

大库检索索引的代价：先量召回再上线

一引入向量索引，检索速度上去了，但要问一句"比暴力精确很多少召回"。不同索引（倒排、乘积量化）在不同召回率和体积下差异很大，上线前务必在你自己的库上测"索引后的召回率 vs 暴力比对的百分百召回"差多少，并把它锁进验收阈值。别只报"快了十倍"——如果这十倍是拿掉了一个百分点的准确率换来的，你得先想清楚这个损失能不能接受。索引和精确比对双轨保留、可对比可回退，是部署最稳妥的做派。

部署架构的演进线：从全云到端云混合

很多项目不是一开始就端云混合的，而是从"全部放云端"起步，被延迟和带宽成本逼着往端上挪。这条演进线往往是这样：云上全能 → 发现延迟和带宽不可接受 → 把检测和轻对齐拉下边缘 → 再把活体和轻识别也拉下边缘 → 端上只能判已知、存疑和未知才上云。每一步挪动都对应一个"这里放本地更划算"的决策点。理解这条演进线，能帮你判断自己当前项目在哪个阶段，以及下一步该往哪层挪——而不是照搬一个"别人说好"的架构，不知道它为什么好。对大多数项目来说，端云混合是终极形态，但不同阶段它"端"和"云"的边界可大可小，取决于你的算力、流量和隐私约束在挪动过程中如何变化。

到这里，从选型、框架、数据、训练到部署，一条落地链走到头了。可"好不好用"还得拿尺子量——第 5 章我们拨准那把评估的尺。