1. 从集中训练到广泛推理先看清算力盘子发生了什么变化做AI基础设施这几年我最大的感受是算力的需求重心正在发生一次明显的迁移。过去大家提到AI算力脑子里浮现的是成排的GPU服务器在数据中心里跑大规模训练一张卡动辄几万块集群一搭就是几百卡上千卡。但从去年底开始越来越多的团队和客户问我的不是“怎么训更大的模型”而是“模型训完了之后怎么让更多人用起来还不卡、还不贵”。这个问题背后就是标题里说的“从集中训练到广泛推理”。为什么会出现这种变化原因不复杂。训练是一个阶段性的任务模型还在实验室里迭代期间集中砸算力没问题。但推理是持续的、分布式的、面向所有终端用户的服务。同一个模型训练可能只需要几十天上线之后却要被调用好几年。算力需求一旦上了服务条款就不再是“一次性采购”的逻辑而是每天都要面对的容量规划和成本控制问题。据我了解目前相当一部分大模型应用团队的推理成本已经超过训练成本而且这个差距还在拉大。推理放上了云端但并不是所有推理都适合放在云端很多场景卡在延迟、带宽和隐私上于是“云边端协同”就从一个技术概念变成了必须落地的现实方案。端脑科技在这个方向上做了一些比较系统的尝试。我们不是要做一套PPT上的架构图而是真正把训练集群、边缘节点和终端设备串起来让一个模型既能在云端做重活也能在边缘和端侧跑轻量推理。这篇文章就围绕这套体系的方方面面展开包括算力需求变化的原因、训练和推理的本质差异、云边端每一层的定位与选型以及我们在实操中踩过的坑和解决方法。如果你是做AI平台、模型部署或者边缘计算相关工作的这篇文章应该能给你一些可以落到项目里的参考。2. 训练和推理为什么不能共用一套算力方案很多人第一次听到“云边端协同”时会觉得既然云计算能提供足够强的算力那我把所有推理都放在云上不就行了为什么要搞边缘和端侧要回答这个问题必须先把训练和推理的底层差异讲清楚。这两类任务对算力的要求完全不一样用一套方案硬套要么浪费资源要么性能不达标。2.1 精度需求FP64、FP32、FP16、FP8、INT8到底差在哪精度是训练和推理最根本的差异点之一。训练过程涉及大量权重更新和梯度回传对数值误差非常敏感所以主流训练任务从FP32起步涉及科学计算或者传统HPC场景甚至要用到FP64。FP64的位宽是64位表示范围大、精度高但代价是运算单元占据芯片面积大、功耗高、算力相对低。到了深度学习训练阶段FP32成为主流因为神经网络的数值范围相对可控FP32已经能保证收敛稳定性。后来大家发现大模型训练时显存和带宽非常紧张于是BF16和FP16这种16位半精度格式被广泛使用。BF16保留了和FP32一样的指数位只是砍掉了尾数位在混合精度训练中几乎不会造成精度损失所以H100、A100这些训练卡都把BF16算力放在性能指标的核心位置。到了推理阶段需求又变了。推理不需要反向传播数值敏感性进一步下降FP8、INT8甚至更低比特的量化格式都可行。用INT8做推理时算力吞吐常常是FP16的两倍以上模型体积直接缩到四分之一对于边缘设备是质的提升。我曾经在内部做过一次对比同样的一个视觉模型FP16权重跑在A100上延迟大约12毫秒换成INT8量化后同样的模型在边缘设备上能跑到8毫秒左右。这中间省下的不只是算力还有带宽和功耗。对于实时性要求高的场景比如安防摄像头、门禁闸机INT8几乎是必选项。所以你看训练时我们盯FP32、BF16推理时我们想尽办法往INT8、FP8靠这个精度的取舍就是两类任务的分水岭。2.2 显存、带宽与算力消耗的具体差异训练和推理对硬件资源的需求结构也很不一样。训练时最吃紧的资源除了算力还有显存和片间带宽。举个例子训练一个7B参数规模的模型如果序列长度是2048batch size是16仅激活值缓存就可能占掉几十GB显存。参数本身加上优化器状态又需要额外存储。所以训练场景里哪怕你有8张80GB的卡显存规划稍有疏忽也会爆。这也是为什么分布式训练框架动不动就要求你用张量并行、流水线并行本质就是在多个卡之间分摊显存和计算。推理则是一种截然不同的模式。推理时模型参数是固定的不需要保存梯度显存消耗主要体现在权重、KV cache和中间激活。KV cache随着并发请求和序列长度线性增长批量推理时尤其明显。于是推理引擎做了大量优化比如vLLM的PagedAttention把KV cache按页管理减少显存碎片让并发请求尽可能塞进同一张卡里。算力消耗上也存在差异。训练任务的计算密度很高矩阵乘法的规模动辄上千维很容易把GPU的算力打满。推理任务则不一定小batch请求时GPU常常处于“吃不饱”的状态受制于算子调度和访存延迟算力利用率不高。这也是为什么我们做推理时会关注吞吐量而不是单纯的单请求延迟因为一张卡上能塞多少并发请求直接决定了你的单位推理成本。越早理解这个差异你在规划算力体系时就越不容易走弯路。3. “云边端协同”具体拆开是怎么分层的云边端协同不是一个模糊的口号它要对三类不同的物理位置分别做算力部署和任务调度。我把这套体系拆成云端、边缘、端侧三层来讲每一层承担的角色、使用到的硬件和典型场景都梳理清楚你就知道该在哪个层面投入资源了。3.1 云端集中式训练和基础推理的中心云端是算力体系的算力核心。这里要承担几类任务大模型的全量预训练和微调、海量数据的批处理、以及对延迟不敏感的通用推理。训练任务基本只能放在云端因为只有数据中心级别的集群才有足够的算力规模和高速互联条件。我们用到的典型硬件包括NVIDIA的A100、H100这类高算力训练卡还有刚兴起的FP8训练加速方案。端脑科技的云端集群采用了分层架构训练集群内部用高速互联组成高带宽域推理服务集群则部署在靠近边缘的机房方便和边缘节点进行低延迟通信。云端推理服务的部署方式也有讲究。一个成熟的做法是用vLLM这类推理框架把模型加载进显存后对外提供OpenAI兼容的API接口。vLLM的连续批处理和PagedAttention特性能让一张80GB的显卡同时处理几十路并发请求吞吐量远高于朴素部署。同时云端还会承担模型的量化、蒸馏、微调等生产流程把最终优化好的模型再下发到边缘和端侧。云端就是一个大后方既做训练也做推理兜底保证系统在高并发尖峰时有足够的伸缩能力。3.2 边缘低延迟、高并发的中间层边缘节点是云和端之间的缓冲地带。边缘的定位不是代替云端做重训练而是在靠近用户的位置提供低延迟推理服务同时把不需要上传云端的数据留在本地处理。经典场景包括园区安防、工业质检、智慧零售之类的多路视频流分析。这类任务的共同点是数据量大、实时性要求高如果全部传回云端带宽和延迟都受不了。边缘层的硬件方案非常多从NVIDIA Jetson系列、边缘GPU服务器到专用的AI推理加速卡和NPU芯片都有。我实际用过的方案里基于ARM架构的AI开发板比如K210这类带KPU的板子很适合轻量级视觉推理算力有限但功耗极低部署成本很友好。如果任务稍微重一些比如同时处理几十路视频流做目标检测那就需要上带独立GPU的边缘服务器用TensorRT或者ONNX Runtime做引擎优化。边缘节点最好能独立完成模型推理和结果上报把分析结果压缩成结构化数据再传给云端这样云端压力会小很多。3.3 端侧贴身运行的轻量化智能端侧是离用户最近的设备手机、摄像头、智能音箱、会议终端都算。端侧能跑的是极轻量化的模型比如用INT8量化后的二值化网络或者蒸馏出的小模型。端侧的优势是零延迟、离线可用、隐私不出设备适合人脸识别解锁、语音唤醒这一类对响应速度极其敏感的功能。从算力角度看手机里的NPU、DSP现在都能提供不错的端侧推理能力一套人脸检测模型在手机端能做到十几毫秒完成。端脑科技在端侧做的主要工作是模型瘦身。一个27B的大模型不可能整个塞进手机里但可以用蒸馏和量化从大模型提取一个几亿参数的小模型专门负责意图识别、语音指令处理等有限子任务。端侧处理不了的高难度请求再通过协议走上边缘或云端。这三个层的配合就像公司里的人员分工端侧是前台接待能处理的当场解决边缘是部门经理处理更复杂的问题云端是后台专家团队负责最重的活。任务在不同层之间流转自然就把算力用到了刀刃上。3.4 调度与路由谁来决定任务去哪一层云边端三层部署完之后最关键的问题来了一个推理请求进来之后到底应该由哪一层来处理这就是调度与路由层要做的事情。我们的方案是在客户端SDK和边缘网关里内置规则引擎根据延迟要求、数据敏感度、当前负载三个维度做路由选择。比如一个请求要求在100毫秒内响应模型又是轻量的视觉模型那就直接放端侧执行如果涉及复杂的多轮对话或长文本生成再考虑走边缘或者云端。调度层还需要感知各节点的健康状态和负载情况。边缘节点偶尔会宕机或者网络抖动这时候路由规则要能自动摘除故障节点把流量切换到邻接的正常节点。云端侧的负载均衡器则根据请求量和GPU显存利用率做动态伸缩高峰期临时拉起推理Pod低峰期释放资源降成本。这套调度体系本质上是在做资源的最优配置是“协同”二字的真正体现。4. 从训练到部署的关键实操工具选型与落地记录概念讲再多不如把工具链和实操流程理一遍。训练、微调、推理、部署这几个环节每一个都有对应的主流工具和注意要点。我把我们实际操作过的工作流整理出来供你参考。4.1 训练侧的常用工作流视觉模型训练现在基本已经被YOLO系列和Transformer架构的检测分割模型占满。YOLOv8、YOLOv10系列常被用来做自定义数据集的目标检测它们的核心操作是准备好标注数据后修改配置文件里的类别数、输入尺寸和训练参数。这里有一个容易踩的坑不同YOLO版本的推理输出格式差异很大比如YOLOv11保存推理结果时可以输出标签文件、裁剪框图和标注图但如果你在后续写自动化脚本时把格式假定错了整个流程会中断。所以训练之前一定要先确认推理导出的字段定义。实例分割和旋转目标检测的场景则常用Mask2Former和MMRotate。MMRotate需要配置DOTA数据集格式这在遥感影像检测里很常见。用MMRotate训练DOTA数据集时最需要注意的是数据预处理阶段因为DOTA数据集里的标注是四点坐标表示的旋转框和常规水平框的训练方式不同数据增强策略也要调整。另外这类框架版本迭代频繁依赖库之间容易冲突建议用官方提供的Docker镜像作为基础环境不要在自己本机装太多自定义依赖。大语言模型的微调则主要走LoRA这类参数高效微调方案。LoRA只训练权重矩阵的低秩分解部分显存开销大幅降低一张24GB显存的消费级显卡就能微调7B级别的模型。实操上LoRA的rank和alpha设置直接影响微调效果rank取8到64之间比较常见太小则表达能力不足太大会过拟合和增加显存压力。我们通常的做法是先跑一个小规模的实验集对比不同rank下的验证loss再确定正式训练的参数组合。4.2 推理引擎的选择vLLM、nano-vLLM、MLX推理引擎是整个推理链路的加速关键。vLLM在大模型推理场景最流行核心优势是PagedAttention和连续批处理。连续批处理的意思是系统不需要等一批请求全部结束时才换下一批而是每个请求生成完一个token后动态决定是否插入新请求这样GPU的空闲时间被大幅压缩。我实测过同一个7B模型用朴素的FastAPI部署单卡并发4路就已经开始掉速度而换成vLLM后并发16路依然稳定吞吐量提高了很多。如果你想把推理部署在Apple Silicon的Mac电脑上那MLX是绕不开的框架。MLX是一个针对Apple Silicon优化的机器学习框架支持4-bit、8-bit量化推理。用MLX跑Qwen3的8B模型在M系列芯片上可以达到不错的生成速度内存占用也控制得很好。但要注意的是MLX的算子覆盖面没有CUDA生态那么全面某些模型结构转换时需要做少量适配工作。对于想深入理解推理引擎底层的人我特别推荐去读nano-vLLM的源码。nan-vLLM是一个精简版的vLLM实现代码量比原版少很多但保留了PagedAttention、continuous batching、prefix caching等关键模块的设计思路。如果你能完整走一遍nano-vLLM中请求调度和显存管理的主流程再回去看vLLM会清晰得多。4.3 量化与精度校准的实操细节量化推理是边缘和端侧部署的必经之路。目前比较通用的做法是先对整个模型做校准收集一组有代表性的输入数据统计每一层的激活值范围然后选择int8、fp8或4bit量化格式。这里容易忽略的一点是激活值的分布和权重值的分布差异很大权重往往集中在零附近激活值则可能出现极端差异量化时如果不做逐层校准精度掉得会很厉害。我的建议是量化后用至少1000条贴近真实场景的数据做精度验证对比量化前后的准确率和输出相似度。如果掉点明显可以考虑混合精度方案对敏感层保留FP16只对非敏感层做INT8量化。以我们部署过的一个视觉检测模型为例全INT8量化后mAP掉了2.1%混合精度量化后只掉0.4%但推理速度依然比FP16提升了接近一倍。量化不是一刀切而是要找到精度和速度的平衡点。5. 常见问题与排查经验实录实操过程中遇到问题在所难免。这里我把几个高频率的问题和排查思路写下来都是我们实际踩过的坑你可以直接拿来对照。5.1 显存不够还是带宽不够先定位资源瓶颈部署模型时GPU显存爆掉是最常见的故障。但如果只看显存很容易忽略一个更隐蔽的问题——访存带宽。举个实际例子我们在边缘服务器上部署一个RTX 3090跑28B参数级别的量化模型。单纯的显存占用并不高但生成速度却很慢排除了模型结构问题后最后才发现瓶颈在显存带宽。RTX 3090的显存带宽约为936GB/s对于大模型的逐token生成权重参数量乘以生成速度就是带宽需求模型每生成一个token都要把全部参数过一遍。所以当模型参数超过带宽能支撑的范围就会出现“显存够用但生成像蜗牛”的现象。排查方法很简单先用nvidia-smi确认显存占用再用性能分析工具统计GPU利用率。如果GPU利用率持续50%以下而显存占用不低大概率是访存瓶颈而非算力瓶颈。这时候该想的是换用更高带宽的显卡、减小模型参数蒸馏或量化而不是继续堆算力。5.2 Qwen3 27B在边缘上推理很慢怎么解决Qwen3 27B是比较重的大模型直接部署到边缘设备上很多人第一反应是慢到没法用。我见过最典型的情况是在32GB内存的边缘设备上用纯CPU推理生成一个token要几秒完全没法做交互式应用。解决思路有几条按优先级排序第一量化。用4-bit量化可以把27B模型压到15GB左右内存在边缘设备上勉强放得下。第二换推理框架。如果在Apple Silicon上用MLX的4-bit推理比常用的ONNX Runtime快很多。我曾经在M系列芯片上跑Qwen3 27B的4-bit量化版本速度能稳定在每秒几十个token基本满足文档总结这类场景的使用需求。第三如果还是扛不住就退一步用8B版本通过知识蒸馏让8B模型逼近27B的效果在边缘侧只部署小型化版本。这里要特别提醒4-bit量化不是“无损”的。量化前后的输出质量和多轮对话连贯性要逐项对比尤其涉及长文档总结或者逻辑推理时掉点可能比纯对话场景更明显。上线前最好准备一个自动化的质量回归测试集每次做量化调整都跑一遍。5.3 分布式算力的通信瓶颈分布式算力听起来很美多卡并在一起就是超级计算机。实际做起来通信瓶颈才是最让人头疼的。分布式训练时张量并行需要在每步计算后同步梯度模型越大同步数据量越大如果节点之间用普通千兆网络性能会拖垮得很难看。这也是深度学习集群坚持用高速互联比如NVLink、InfiniBand的原因。推理场景的分布式问题则不一样更多是负载均衡和服务状态同步问题。多个推理节点组成服务集群后调度器需要知道每个节点的实时负载、车辆数和显存余量。如果这些状态信息同步不及时就可能出现某个节点负载已经打满调度器还在往它转发请求的情况。我们的解决办法是让每个节点定时上报心跳和负载数据调度器使用“最少连接数加权延迟感知”策略做路由节点响应变慢时自动降权。5.4 算力成本优化怎么把单位推理成本打下来如果说上面的问题都是技术层面的那成本就是老板层面的一票否决项。算力成本优化主要从三个维度出发模型越小成本越省、并发越高成本越摊薄、硬件匹配越精确成本越合理。模型层面能做蒸馏就不直接用27B并发层面用推理引擎的批处理能力尽量塞满每一张卡硬件匹配层面不要什么任务都上A100简单的OCR识别用边缘盒子的NPU就够了何必让一万块的GPU闲着跑一个小模型。我做过一个粗略的测算同一个OCR识别模型部署在云GPU上单次推理成本约为0.012元部署到边缘NPU设备后加上硬件折旧和电费单次成本大约只有前者的五分之一。对于每天百万级调用量的业务这个差距就是百万级的资金投入差别。这也是为什么云边端协同在商业上站得住脚——它不只是技术理想更是成本现实的倒逼。6. 经验收尾关于云边端协同我还想多说两句文章写到这里主体内容基本讲完了但我还是想用经验的方式再多说几句。端脑科技的云边端协同算力体系从设计到落地最复杂的不是搭建集群、不是训练模型而是想明白哪些计算应该放在哪一层。这个决策会直接影响你的成本、延迟、用户体验和数据合规性。我的一个强烈建议是做任何AI产品前先画一张“模型能力-硬件约束”对照表。把每个功能点需要的模型规模、延迟预算、数据敏感程度列出来再对照手上可用的终端算力、边缘节点和云端资源你会发现很多需求根本不需要云端大模型出场。能做端侧就用端侧能走边缘就不上云这种从上到下的“算力下沉”才是云边端协同的核心价值。最后分享一个小技巧也是我们在大量部署中总结出来的云端、边缘、端侧不同层级的模型版本要保持统一的版本管理机制每次模型更新后要同时下发配置文件和推理引擎版本否则很容易出现三层模型行为不一致的混乱。算力协同不只是硬件协同更是模型生命周期和软件栈的协同。这套体系我们还在持续迭代后续有更多边缘和端侧的实际案例之后再继续和同行们交流。