2024年开始AI 算力圈一个很明显的风向转变是大家不再只讨论“又要训练多大规模的模型”而是开始研究“每天几千万次推理请求到底该跑在哪”。算力的需求重心正在从集中训练向广泛推理迁移训练像盖楼是阶段性、集中性的投入推理像楼里每天亮着的灯是长期、弥散性的消耗。端脑科技在这条路上做的就是把云端训练集群、边缘推理网关和端侧设备算力捏合成一套云边端协同体系。这篇文章会拆解这套体系的设计思路、核心细节和落地时遇到的实际问题无论你手里是正在做 AI 落地的团队方案还是刚开始规划个人算力的开发者都能在其中找到可以直接参考的部分。1. 算力需求重心迁移为什么训练是“集中”的推理却必须“广泛”1.1 训练与推理的需求画像完全不同先明确一个底层事实训练和推理对算力的诉求根本上是两种不同的生物。训练走的是反向传播每一轮迭代都要前向算一遍、反向更新一遍权重batch 动辄几千上万整个集群要保持高带宽、低延迟的同步通信对 InfiniBand 或 RoCE 这类高速互联极其敏感。训练阶段还伴随着日志、checkpoint 落盘、实验调参算力被密集地“灌”在一个或者少数几个数据中心里。推理则是前向计算资源消耗比重大多了。它要响应真实用户的实际请求延迟是硬指标吞吐是硬指标。单个请求只需跑一次网络但请求量来自世界各地7×24 小时不中断。更麻烦的是推理负载往往不能用大 batch 一味堆吞吐在线场景下一个小 batch 甚至 batch1 的请求很常见这时候计算卡的利用率很难拉满瓶颈往往不在算力峰值而在内存带宽、算子调度和显存容量上。用生活化一点的说法训练像一次新药研发集中一批实验室和设备攻关推理像药品上市后的日常生产必须在遍布全国的生产线上稳定产出。你不可能把所有生产都塞回实验室去完成物理空间不允许物流也不允许。AI 算力同样如此应用越贴近现实推理算力就越要靠近“产生需求的地方”。1.2 广泛推理成为瓶颈的三个现实原因第一模型越来越大单次推理成本水涨船高。大模型动辄几百亿参数一次生成就可能消耗几十亿次浮点运算。加上长上下文场景KV Cache 会把显存占满吞吐量直接被卡住。以前跑一个小模型单卡能扛几千 QPS现在跑一个大模型单卡能稳定支撑的并发可能只有几十路。这就是为什么很多公司把模型从云端迁到边缘之后才发现边缘设备根本不是简单“瘦身版”的问题而是要用压缩、量化、剪枝整套工程手段把模型压到能跑得动的水平。第二设备数量和应用场景呈数量级增长。你训练出来的模型终端用户不只是从网页访问还会从手机 App、摄像头、智能音箱、工业网关、车载盒子、AI 短剧渲染节点等各种渠道发起请求。终端和边缘设备数以百万计每个设备哪怕只产生很小的工作负载汇聚起来也是云服务器承受不起的规模。第三实时性和隐私要求边缘端必须“动手”。很多场景不允许一个请求打到千里之外的云端再返回来比如工厂质检抓拍、商场人脸核验、工厂控制闭环要求毫秒级响应。还有一些场景数据本身敏感不能上传云端推理必须就近完成。这些硬性约束决定了“广泛推理”不是一个可选趋势而是 AI 落地过程中绕不开的现实。1.3 业务判断你缺的到底是训练算力还是推理算力很多人一开始做资源规划张口就是“我要多少张 A100”但这个问题其实很难直接回答。你可以先问自己三个问题判断自己的算力短板到底在哪一侧。你的模型多久迭代一次如果一个月才训练一轮那训练算力就是低频投入不需要长期固定大量 GPU如果你天天都想更新模型权重那才算训练密集型。你的在线请求峰值是多少请求是均匀分布还是集中在白天晚上峰值决定推理集群的规模均匀度决定你能不能错峰复用资源。你的数据能在本地处理吗数据必须离开本地还是可以本地推理只回传脱敏结果这决定推理节点应该放到多边缘的物理层级。这张判断表在端脑科技的项目里经常用到简单说就是模型更新频次低但调用量高的优先投推理算力模型迭代快、评测需求多的优先保训练资源数据敏感度高的哪怕调用量不高也必须把算力下沉到边缘或终端。没有一种方案能同时满足所有场景算力规划本质上是先做取舍再谈协同。2. 端脑科技云边端协同算力体系的设计逻辑2.1 云端负责“重活”边缘和端侧负责“快活”在端脑科技的体系里云、边、端三者不是把模型复制三份就完事而是各有明确分工像一家公司的总部、区域中心和一线的柜台。云端算力池承担训练任务、大模型基座服务、复杂 Agent 编排和全局调度。模型在这边不断做增量训练产生新的版本云端还要处理那些对算力要求极高、对延迟相对宽松的“重活”比如大规模语义检索、跨域的全局数据分析。云端的价值在于“能力上限”什么都能干但响应路径长。边缘层通常部署在各区域的机房或者大型现场的本地服务器里承担的是“高并发、亚秒级响应”的推理任务。比如一个园区企业部署了质量检测系统训练在云端统一做但检测推理放在边缘网关通过摄像头信号直接识别减少回传压力离线也能稳定运行。边缘需要有一定算力冗余因为本地业务峰值可能是突发的。端侧则是离用户最近的一层手机、工业设备、智能家居、车载盒子里的 NPU 都算。端侧模型通常是被压缩过的轻量模型承担最频繁、最低时延、离线可用的轻量任务比如关键词唤醒、图像预处理、基础质检分类。端侧算力不是免费的但它的单位成本最低而且当你把绝大多数简单请求消化在端上云端和边缘的压力会显著下降。三者的关系是云端产生能力边缘放大能力终端兑现能力。端脑科技这套体系的关键不在于某一边有多强而在于负载被精确路由到最合适的那一层。层级典型设备主要任务时延目标典型精度云GPU 服务器集群训练、微调、复杂推理、全局调度秒级以内FP16 / BF16边边缘网关、推理服务器区域推理、实时反馈、模型缓存亚秒级FP16 / INT8端手机 SoC、工控机、IoT 芯片常驻轻量推理、离线响应毫秒级INT8 / INT42.2 精度分层FP64/FP32/FP16/BF16/INT8 各管一段算力协同这件事很多人只关注硬件型号和数量却忽略了一个关键变量数据精度。同样一张卡跑 FP64 和跑 FP16 / INT8 的算力差距可能是十到几十倍。端脑科技在做算力体系时把精度策略当成一个独立的规划维度来看这点我觉得才是真正拉开差距的地方。FP64 和 FP32 主要用在科学计算、数值模拟和某些物理仿真这类领域对 AI 训练感兴趣的人不一定需要关心。AI 训练的主流精度是 FP16 和 BF16FP16 的优势是精度够用、显存占用减半但训练不稳定时容易溢出BF16 的指数范围跟 FP32 一样大大模型训练时更稳所以今天的预训练集群几乎都围着 BF16 打转。推理阶段的精度选择更灵活。云端推理可以用 BF16 或 FP16边缘和端侧为了在同样功耗下跑更多路并发通常会把权重量化到 INT8 甚至 INT4。量化并不是直接把数位砍掉而是通过校准把浮点数值映射到一个低比特整数空间配合张量核心的定点运算计算吞吐大幅提升。我自己测试下来一个视觉模型从 FP16 转 INT8在边缘设备上的推理速度通常能提升 1.5 到 3 倍显存占用降一半以上。代价是精度会有少量掉点但很多场景里从 98.2% 掉到 97.8% 是完全可以接受的。要是掉点太多就需要做量化感知训练或者混合量化——把对精度敏感的几个层保留 FP16其余压到 INT8。精度位宽训练/推理典型场景算力特性FP6464 bit训练科学计算数值模拟、高精度科学计算算力利用率低精度最高FP3232 bit训练传统深度学习基线兼容性好性能一般FP1616 bit训练/推理混合精度训练、云端推理吞吐翻倍需防溢出BF1616 bit训练大规模预训练范围大、稳常用于大模型INT88 bit推理边缘端侧推理吞吐高需校准和量化INT44 bit推理超轻量端侧、移动端极限压缩精度损失最大精度分层的意义在于同一套体系里云侧用高精度保能力上限边缘端侧用低精度保性能下限通过模型转换工具做无损对接。只要精度策略铺对了你不需要在边缘堆天价硬件也能扛住实时流量。2.3 模型分发、数据回流与增量学习闭环云边端协同算力体系里最难的不是物理硬件怎么连而是数据和模型在三层之间怎么流动。端脑科技的做法可以概括为“模型下发从云端走数据回流只回必要部分增量学习在云端完成之后再次下发”。具体来说云端训练好一个新版本模型之后先做压缩、量化和端侧适配然后通过 OTA 或者内网分发机制下发到边缘节点和终端设备。边缘节点可以按业务优先级缓存多个版本模型当业务请求到达时根据当前模型版本路由到对应的推理服务。终端设备则定期检查更新在低峰时段下载增量模型包。这个更新机制要设计失败回退一旦新模型在边缘表现异常可以快速切回上一稳定版本。数据回流环节要克制。边缘和终端每天会产生大量业务数据如果全量传回云端带宽成本会直接压垮项目。更合理的做法是明文数据不出本地只回传经过脱敏的统计指标、困难样本和模型置信度分布。端脑科技在工厂质检场景里就是只把系统判定为“低置信度”的图片样本传回云端做人工复审和增量训练而正常样本直接丢弃。这样既控制了带宽又保障了数据安全还保证了模型迭代有真实数据支撑。增量学习和联邦训练是闭环的关键。云端拿到各边缘节点回传的样本之后进行小步长微调更新后的模型再流向边端形成一轮一轮的迭代。这个机制在 Agent 场景里特别实用比如面向不同行业的 AI Agent云端保持一个通用基座边缘侧用各自行业的少量标注数据做局部适配既不用数据集中又让模型越来越贴合业务。3. 云边端协同落地算力评估到部署交付全过程3.1 算力需求盘点先把账算明白任何算力体系都不建议先买硬件再想用途。我见过太多团队先把服务器采购单交了最后发现训练集群空转、推理节点不够又去补单加机器。更好的落点是把负载类型、时延要求、数据敏感度通通列成一张表再决定每个场景落到哪层。端脑科技做盘点的模板大致是这样负载名称比如“客户语音实时转写”“厂区安防行为识别”“智能客服问答”。调用量预估日请求量、峰值 QPS、每路请求的平均处理长度。时延要求可接受 P95 延迟是 100ms 还是 3s。数据敏感度数据能否出域是否需要本地化存储。模型体量参数量、输入尺寸、上下文长度。把上面这张表填完之后你会发现很多负载其实并不需要云端参与。比如“厂区安防行为识别”要求毫秒级响应且数据敏感那显然应该放边缘而“智能客服问答”可以由云端统一推理因为它的模型需要不断更新统一部署成本更低。这一步做完算力分区逻辑就基本清晰了。3.2 算力评估建模训练 FLOPs 与推理吞吐的估算方法在“算力约束下提升大语言模型能力的资源配置建模”这类讨论里大家都在找一个能算得清、测得出的估算框架。我自己常用的是一个非常粗但足够立项使用的公式训练阶段的总计算量约等于 6 × 模型参数量 × 训练 token 数。这是业界广泛采用的 FLOPs 近似算法推导逻辑来自前向和反向的计算组合。比如一个 70B 参数的模型训练 2T tokens总计算量就是 6 × 70 × 10^9 × 2 × 10^12大约是 8.4 × 10^23 FLOPs。然后你用单卡算力乘上利用率来计算集群规模def estimate_training_cluster(params_b, tokens_t, single_card_flops, mfu, days): # params_b: 模型参数量Btokens_t: 训练数据量T # single_card_flops: 单卡峰值算力如 A100 BF16 为 312e12 # mfu: 模型的浮点利用率常见范围 0.35~0.55 total_flops 6 * params_b * 1e9 * tokens_t * 1e12 hourly_flops total_flops / (days * 24) / mfu card_count hourly_flops / (single_card_flops * 3600) return card_count # 70B 模型训练 2T tokens用 400 张 A100MFU 取 0.45 total 6 * 70 * 1e9 * 2 * 1e12 print(f总计算量: {total:.2e} FLOPs) # 单集群 400 卡需要多长时间 a100 312e12 mfu 0.45 seconds total / (400 * a100 * mfu) print(f约需: {seconds / 86400:.1f} 天)算出来你会发现一个 70B 模型要达到合理的训练周期数百张高性能卡是跑不掉的这也是为什么训练算力必须集中在一个数据中心里分散到各地根本组不成高效集群。推理侧的算力需求估算则要反过来看吞吐量而不是 FLOPs 总和。推理算力模型可以用“单卡能支撑多少并发、多快生成一个 token”来衡量。一个常见做法是先做压测得出单卡在目标精度的实际吞吐然后用“峰值 QPS × 平均输出 token 数”去除得到所需实例数。注意一定要给峰值留缓冲不然流量一冲延迟就崩。def estimate_inference_instances(peak_qps, avg_output_tokens, gpu_tokens_per_sec): total_tokens peak_qps * avg_output_tokens instances total_tokens / gpu_tokens_per_sec return instances # 峰值 100 QPS平均每次生成 200 token单卡 8K tokens/s 吞吐 estimate estimate_inference_instances(100, 200, 8000) print(f需要约: {estimate:.1f} 张推理卡)这个公式只能说是起步估计真实场景还要考虑 batch 动态、显存容量、请求长度分布等细节但已经足够让你在做预算时做到心中有数。3.3 硬件选型与资源池建设硬件选型最怕掉进参数攀比的坑。端脑科技在资源池建设中反复强调一个原则能满足任务要求的最普通的硬件往往才是最优的。训练集群需要高性能卡和高速互联这个没有捷径但边缘和端侧的选型就要务实很多。云端训练池优先看重算力峰值、HBM 带宽和卡间互联能力。H100/A100 级别的卡适合大模型训练如果做的是中小模型微调消费级显卡搭起来也不是不行关键是网络带宽和存储要跟上。边缘推理池选择范围很广有 NVIDIA Jetson 系列、Intel 边缘显卡、国产推理卡等。选型重点看三件事一是推理引擎的生态成熟度有没有 TensorRT、OpenVINO 这类工具帮你做加速二是功耗和散热能不能适应现场环境三是接口是否匹配你的摄像头、PLC 等现场设备。很多项目失败在推理性能没问题但设备在高温车间频繁宕机。端侧计算单元手机端的 NPU、工控主板上的集成 NPU、轻量 SoC 都可以。端侧 CPU 跑深度学习并不是不行但功耗和延迟通常不理想所以现在大多数端侧方案都依赖 NPU 或者 DSP 做专用加速。尺寸、功耗和成本约束比性能更硬算力只要能吃掉目标模型即可。资源池建设上要留一个“过度区”。端脑科技在边缘侧经常会放 20% 左右的闲置算力用来接突发任务和临时扩容。别小看这部分冗余负载高峰的时候它就是救命稻草。相比之下云端训练池反而可以做得更紧凑训练任务可以排队调度弹性空间比实时推理大得多。3.4 训练-压缩-部署流水线实操模型从训练到端侧部署完整流水线大概是预训练/微调 - 模型压缩 - 格式转换 - 端侧适配 - 灰度发布。第一步训练阶段就要考虑后续部署。很多团队训练时只用 FP32最后要部署到边缘才发现模型体积太大。最好在训练初期就加入量化感知训练让模型在低比特下也能保持精度。混合精度训练现在几乎是标配不需要刻意追求 FP32。第二步模型压缩常见手段是剪枝、蒸馏和量化。结构化剪枝把不重要的通道去掉蒸馏则让一个“小老师模型”模仿“大模型老师”的输出。DeepSeek 公开的 Agent 训练方法里就有值得参考的思路让大模型先产出高推理质量的思考链数据再蒸馏到小模型上小模型也能具备不错的规划能力。对端侧算力来说这一步的意义远大于堆硬件。第三步格式转换和推理引擎适配。PyTorch 模型通常要导出为 ONNX然后在 TensorRT、OpenVINO、NCNN、MNN 这些引擎里做图优化和算子替换。一个很常见的坑是模型里用了某些自定义算子转 ONNX 时直接卡住解决办法只有两个要么改模型结构支持标准算子要么为这个算子手写插件前者几乎总是更划算。# 以 PyTorch 模型导出 ONNX 为例 python -m torch.onnx.export \ --model ./model.pt \ --output model.onnx \ --dynamic-batch \ --opset 12 # 边缘端用 TensorRT 转换 INT8需要准备校准集 trtexec --onnxmodel.onnx \ --saveEnginemodel.trt \ --int8 \ --calibcalib.bin第四步端侧适配是最后一道坎。端侧内存小、算子有限模型跑起来往往要动态分配显存。这里建议大家先确认目标设备能不能完整加载模型再看单帧推理时间最后测多路并发时的稳定性。灰度发布时先放到 10% 的设备上观察一周确认无异常再全量推送。3.5 监控、调度与弹性伸缩算力体系建起来之后最忌“一锤子买卖”。你需要一套完整的可观测面板至少包含三类指标集群资源指标GPU 使用率、显存、功耗、服务性能指标QPS、P95 延迟、错误率、业务质量指标推理准确率、置信度分布。边端现场人员可能不关心 GPU 利用率但他们一定会关心“这个月模型误报了多少次”。调度策略要区分冷热。云端训练任务可以在低峰期排队边缘推理则按动态优先级调度。端脑科技在边缘侧的调度里会把实时质检这类固定优先级业务放在第一队列把离线分析和夜间批量任务放到低优先级队列高峰时段优先保障实时业务。边缘断网是常事。调度系统必须支持断网续传和本地缓存边缘节点收到模型更新包后先落盘重启后能自动恢复边缘产生的推理结果在上传失败时先存本地网络恢复后再批量上传。这套策略听起来简单做不好就是事故——数据丢一次模型迭代就失去了一次真实性。4. 现场实战常见问题与排查技巧4.1 边缘推理速度始终上不去这是边缘部署里问得最多的问题。明明模型不大设备也不差但推理时间就是超预期。排查思路不要上来就怀疑设备不行先按三步走第一步看算子是跑在 CPU 还是加速器上。有些推理引擎默认部分算子回退到 CPUCPU 和加速器之间的频繁拷贝才是延迟真凶。打印一次推理的算子耗时分布就能看出来哪个算子拖后腿。第二步看数据预处理和前后处理的时间。很多人只测模型推理本身没把图像解码、resize、归一化算进去。实测下来边缘设备上 JPG 解码可能比模型推理还慢这时候要换硬件解码方案或者缓存预处理结果。第三步看 batch 配置。边缘场景默认 batch 常常是 1吞吐上不去很正常。如果业务允许可以尝试把多个请求攒成一个小 batch或者启用推理引擎的动态 batch。端侧则要看 NPU 驱动是否真的接管了算子我曾经遇到某型号平台推理慢原因不过是 SDK 没有配置 NPU 模式所有算子都跑在 ARM 核上。4.2 模型量化后精度掉点严重量化掉点的原因通常不在量化本身而在校准过程。很多人随手拿几十张图片做校准集结果分布没有代表性量化参数完全偏离真实数据分布。解决办法很简单校准集要从真实业务场景里抽采样要覆盖低光照、遮挡、模糊各类情况量级至少要几百到上千张。如果校准集没问题还掉点就做层敏感性分析把对量化最敏感的几个层挑出来比如注意力层的 QKV 投影和最后的分类头将这些层保持 FP16其余压到 INT8。再不行就上量化感知训练整个模型在 QAT 过程中会主动适应量化噪声。这个流程跟调试程序一样先找准病灶再对症下药不要一上来就全模型回退到 FP16。4.3 端侧模型更新与断网续传端侧更新模型常见两个坑一是模型写了一半断电设备变砖二是新旧版本接口不兼容推理直接崩溃。端脑科技的处理办法是双分区启动设备上保持当前版模型和新版模型两份镜像下载完成后先写备用分区再由启动器统一切换。这样就算写坏了设备还能自动回滚到上一版。另外模型更新的灰度策略一定要做。大部分端侧问题都是在设备碎片化环境下暴露的——同样的模型在 A 型号的手机上正常在 B 型号的盒子上就崩。所以先放 5% 的设备观察 24 小时确认崩溃率、激活量都没问题后再全量。别嫌慢端侧的“全量发布事故”修复成本比这高多了。4.4 节点规模扩大后调度变得混乱边缘节点从十几个扩展到几百个之后原来的手工配置方式会彻底失效。你会遇到节点离线、重复上报、负载不均、模型版本不一致等各种问题。调度的底层逻辑必须从“手动指定”转向“全局状态管理”所有节点统一注册定期上报状态和资源负载中心调度器按照节点承载能力、当前负载和网络状况自动分配任务。这里有一个容易被忽视的坑节点漂移。边缘设备 IP 会变如果调度系统用 IP 做唯一标识断网重连之后会出现任务重复分配。更稳妥的做法是用设备 ID 或者证书体系做标识IP 只当作动态网络地址来用。同时模型版本必须纳入调度约束任务只能路由到已加载目标版本的节点否则同一业务不同节点模型不一致结果就开始打架。4.5 成本超预算的反思算力项目翻车最普遍的不是技术是预算。端脑科技一个早期项目曾经把云、边、端三套资源都翻了两倍采购结果大部分资源在闲置。复盘时发现问题出在只按峰值资源需求做规划没有考虑负载的时间分布。现在做算力计划我习惯先做一个“利用率底线测试”给每个节点加载目标负载跑一周记录实际利用率再按 P95 而不是峰值去规划资源。因为峰值可能只持续几小时为了这几小时配一倍硬件不如配合抢占式调度和低峰期任务错峰。云端训练也可以按 Spot 实例去拿廉价算力训练任务容错性高重启补跑一下就行没必要守着全价资源。5. 一点个人经验5.1 先小范围验证再全量铺开我见过太多项目死在“一套方案想覆盖所有场景”上。云边端协同听起来宏大但落地一定要从小切口开始。比如你先挑一个工厂质检场景把训练放在云端已有集群上边缘放一台网关端侧接一两路摄像头摄像头跑通之后再横向复制。小范围验证可以让你用最小的代价暴露问题模型压缩是否到位边缘断网是否自愈端侧更新是否稳定。这一步走顺了后续铺开只是数量问题而不是重新设计架构。5.2 别只盯着平均延迟要看 P95 和功耗平均延迟这件事欺骗性很强系统平时都很快但高峰一冲长尾请求就掉到不可接受的水平。监控里一定要有 P95/P99 延迟这是用户真实体感的关键。边缘部署还要特别关注功耗和温度有些设备在无风扇环境下跑 INT8 推理是够用的但连续跑 24 小时之后会热降频推理速度直接掉一半。选型的时候与其选“峰值算力最大”的不如选“持续运行不降频”的。5.3 边端版本管理请当核心系统来做云边端协同体系最薄弱的一环往往是模型版本管理。传统互联网服务可以快速回滚但边缘终端分散在各地回滚一次要很久。我自己的做法是只用一个“模型仓库”来管所有版本每次变更必须有变更说明、验证记录和回滚计划边缘节点碰到异常版本时自动降级到本地缓存模型而不是白屏报错。版本问题是慢性的前期不在乎后面一定会以最难看的方式爆发出来。从集中训练到广泛推理算力体系的形态正在从“一个中心点”变成“一张分布式网”。端脑科技的云边端协同体系只是其中一个工程样本真正值得借鉴的是它背后的思路先搞清楚需求在哪个层级发生再配置对应层级的算力让算力靠近需求而不是让需求追着算力跑。这套方法论放到任何区域的 AI 落地项目中都够用。