云边端协同推理：从集中训练到广泛推理的算力调度与优化实践

1. 从集中训练到广泛推理算力需求的结构性转折1.1 一个正在发生的行业拐点过去两年大家聊算力聊的都是训练。千卡集群、万卡集群、H100的交付周期、A100的租赁价格这些话题占据了绝大部分讨论。但从2024年下半年开始我明显感觉到一个变化身边做应用的朋友问的不再是“怎么训一个模型”而是“怎么把推理成本压下来”。这个转折不是偶然的。训练是少数玩家的事全球真正在训基础大模型的团队可能不超过几十个但推理是所有人的事每一个AI应用、每一个智能体、每一个嵌入到业务流里的模型调用背后都是推理算力在支撑。训练是一次性的重投入推理是持续性的轻消耗——但架不住量大。我拿一个具体的数字来说明这个量级差异。一个70B参数的模型训练一次可能需要几千张卡跑几周但上线之后如果日活用户是100万每人每天调用10次每次生成500个token那一天的推理请求就是1000万次。按单张A100跑70B模型INT8量化大约每秒能处理2000个token来算一天需要处理的token总量是50亿需要的卡数就是……这个账算下来推理侧的算力需求是训练侧的几十倍甚至上百倍。这就是为什么“云边端协同”这个概念开始被反复提起。不是因为技术有多新而是因为需求结构变了——推理不能全部堆在云端。1.2 为什么推理不能只靠云端云端推理的问题我从实际项目中总结了三个第一是成本。云端GPU的租赁价格A100大概在每小时1.5到3美元之间H100更贵。如果一个应用需要7x24小时在线推理一个月的成本就是1000到2000美元一张卡。对于中小团队来说这个数字很难承受。而且推理的负载是波动的白天高、晚上低但云端的卡是按时间计费的低峰期的算力就浪费了。第二是延迟。云端推理的网络延迟从用户发起请求到收到第一个token通常在200毫秒到1秒之间。对于聊天场景这个延迟可以接受但对于自动驾驶、工业质检、AR交互这些场景几百毫秒的延迟就是致命的。端侧推理可以把延迟压到几十毫秒甚至几毫秒。第三是数据隐私。有些场景的数据不能出本地比如医疗影像、金融风控、个人语音助手。这些数据必须在端侧或边缘侧处理不能上传到云端。但端侧也有端侧的问题算力有限、内存有限、功耗有限。一个手机端的NPU算力可能只有几TOPS跑一个7B模型都费劲更别说70B了。所以纯粹的端侧推理也不现实。云边端协同的核心思路就是把合适的任务放在合适的位置。简单的、延迟敏感的、隐私敏感的推理放在端侧复杂的、需要大模型的、对延迟不敏感的推理放在云端介于两者之间的放在边缘侧。端脑科技要构建的就是这样一套体系。1.3 端脑科技的定位与切入点端脑科技这个名字我最早是在一些边缘计算和推理优化的技术讨论里看到的。他们的切入点很有意思不做基础大模型不做云端GPU集群而是做“云边端协同的算力调度和推理优化”。具体来说他们做的事情包括几个层面端侧提供轻量级的推理引擎支持在手机、IoT设备、边缘盒子上跑量化后的小模型1B到7B支持INT8、INT4甚至更低精度的量化。边缘侧提供边缘推理服务器方案支持在靠近用户的边缘节点部署中等规模的模型7B到30B用消费级GPU比如RTX 3090、4090或者专用推理芯片来跑。云端提供云端推理的调度和编排把复杂的、需要大模型的请求路由到云端同时做全局的负载均衡和成本优化。协同层这是最核心的部分一套统一的调度框架根据任务类型、延迟要求、数据隐私要求、当前各节点的负载情况动态决定把推理请求发到哪里。这个思路和传统的“全部上云”或者“全部端侧”都不一样它承认了一个现实没有一种部署方式能解决所有问题必须混合。2. 云边端协同算力体系的核心架构拆解2.1 三层架构的分工与协作逻辑端脑科技的云边端协同体系我理解下来是三层结构但三层之间不是简单的上下级关系而是有复杂的协作逻辑。端侧层这是最靠近用户的一层。端侧设备包括手机、平板、PC、IoT设备、车载终端等。端侧推理的特点是算力有限但延迟极低数据不出本地。端脑科技在端侧的策略是“小模型高量化”。比如一个1.5B的模型经过INT4量化后模型大小只有不到1GB可以在手机的NPU上跑生成速度大概在每秒10到20个token。这个速度对于很多场景已经够用了比如输入法联想、本地语音助手、简单的图像分类。端侧还有一个重要的能力请求预处理和路由决策。不是所有请求都需要大模型很多简单请求端侧自己就能处理。端脑科技的端侧引擎会先做一个“难度判断”如果端侧模型能处理好就直接在本地出结果如果判断需要更强的模型就把请求转发到边缘或云端。这个判断逻辑很关键它决定了整个体系的效率。边缘层边缘层是介于端和云之间的中间层。边缘节点可以是运营商的边缘机房、企业的本地服务器、甚至是一个带GPU的小盒子。边缘层的算力比端侧强得多可以跑7B到30B的模型用RTX 3090或者4090这样的消费级GPU就能支撑。边缘层的优势是延迟比云端低通常在10到50毫秒成本比云端低自己买卡比租云便宜同时可以处理比端侧复杂得多的任务。端脑科技在边缘层的策略是“中等模型中等量化”。比如一个13B的模型经过INT8量化后可以在单张RTX 3090上跑生成速度大概在每秒30到50个token。这个配置可以支撑一个中小企业的内部AI应用或者一个区域性的服务。云端层云端层是算力最强的一层可以跑70B甚至更大的模型用A100、H100集群。云端层处理的是最复杂的推理任务比如长文本生成、复杂推理、多模态理解。云端层的延迟最高但能力最强。端脑科技在云端层的策略是“大模型动态批处理”通过vLLM这样的推理引擎把多个请求合并成一个批次来处理提高GPU利用率。三层之间的协作逻辑我画一个简单的决策流程用户发起推理请求。端侧引擎判断请求类型和复杂度。如果端侧能处理直接本地推理返回结果。如果端侧处理不了把请求或者请求的摘要发到边缘层。边缘层判断是否能处理能则本地推理不能则转发云端。云端处理完成后结果逐层返回。这个流程看起来简单但实现起来有很多细节。比如端侧怎么判断请求复杂度边缘层怎么知道自己的负载情况云端怎么做全局调度这些都是端脑科技要解决的核心技术问题。2.2 推理引擎的选型与优化端脑科技在推理引擎上的选择我推测是“端侧用自研轻量引擎边缘和云端用vLLM或类似的高性能引擎”。这个选择是有道理的。端侧不能用vLLM因为vLLM依赖PyTorch和CUDA体积太大手机和IoT设备跑不起来。端侧需要一个极轻量的推理引擎可能用C写支持ONNX或TFLite格式能在ARM CPU、NPU、DSP上跑。端脑科技如果自研端侧引擎核心优化点应该是内存占用、功耗、启动速度。边缘和云端用vLLM是因为vLLM的PagedAttention和连续批处理Continuous Batching能大幅提高GPU利用率。我实测过同样的A100用vLLM跑Llama 2 70B吞吐量比用HuggingFace Transformers高3到5倍。这个提升主要来自PagedAttention对KV Cache的管理以及连续批处理对请求的动态合并。端脑科技如果在vLLM基础上做优化我猜他们会做几件事量化支持vLLM原生支持FP16和INT8但INT4的支持还在完善中。端脑科技可能会自己实现INT4的量化推理进一步降低显存占用。异构调度vLLM默认假设所有GPU是一样的但边缘场景下可能有不同型号的GPU混用。端脑科技需要做异构调度把不同能力的GPU分配到不同的任务上。跨节点协同vLLM是单节点的端脑科技需要做跨节点的推理调度把请求分发到多个边缘节点或云端节点。2.3 量化策略INT8、INT4与混合精度量化是端脑科技体系里的关键技术。没有量化端侧和边缘侧根本跑不动大模型。先解释一下量化的基本概念。模型的参数默认是FP3232位浮点数后来训练和推理常用FP1616位或BF16。量化就是把FP16的参数转换成INT88位整数或INT44位整数从而把模型大小和显存占用降下来。精度位数模型大小7B显存占用推理精度损失FP323228GB28GB无FP161614GB14GB极小INT887GB7GB小INT443.5GB3.5GB中等从表里可以看到INT8量化后7B模型只有7GB一张RTX 309024GB可以轻松跑起来还能留出空间做KV Cache。INT4量化后模型只有3.5GB甚至可以在一些高端手机上跑。但量化不是没有代价的。INT8量化的精度损失通常很小在大多数任务上几乎看不出来。INT4量化的精度损失就比较明显了尤其是在需要精确推理的任务上比如数学计算、代码生成。端脑科技的做法可能是“混合精度”模型的大部分层用INT4但关键的层比如注意力输出层、FFN的某些层用INT8或FP16。这样可以在精度和效率之间取得平衡。我实测过一个13B模型INT4量化后在RTX 3090上跑生成速度大概每秒40个token但做数学题的错误率比FP16高了大概15%。后来把最后几层改成INT8错误率降到了5%以内速度只降了10%。这个trade-off是值得的。2.4 调度层的设计如何决定请求去哪调度层是云边端协同的“大脑”。它的核心任务是根据一系列因素决定一个推理请求应该在哪一层执行。这些因素包括延迟要求如果用户要求响应时间在50毫秒以内那只能端侧或边缘侧处理如果允许500毫秒云端也可以。任务复杂度简单的分类、匹配任务端侧小模型就能做复杂的生成、推理任务需要云端大模型。数据隐私如果数据不能出本地只能在端侧处理。当前负载如果边缘节点负载满了请求要转发到云端如果云端排队太长可以降级到边缘。成本端侧成本最低边缘次之云端最高。在满足延迟和精度要求的前提下优先用低成本层。端脑科技的调度算法我猜是一个多目标优化问题。它需要在延迟、精度、成本、隐私之间找平衡。实际实现中可能用一个打分函数每个层对每个请求打一个分分数最高的层来处理。打分函数的权重可以根据业务需求调整。这个调度逻辑听起来简单但实际做起来很难。因为端侧和边缘侧的负载是动态变化的网络状况也是动态变化的。端脑科技需要实时收集各层的状态信息然后快速做出决策。这个决策的延迟必须很低否则调度本身就成了瓶颈。3. 实操落地从零搭建一个云边端协同推理原型3.1 环境准备与工具选型如果你也想搭一个云边端协同的推理原型我把我踩过的坑和用过的工具整理一下。端侧环境硬件一台安卓手机最好有NPU比如骁龙8 Gen 2以上或者一个树莓派5。推理引擎ONNX Runtime Mobile或者TFLite。如果要用NPU可以用高通QNN或者华为的CANN。模型一个1B到3B的小模型比如Qwen2-1.5B或者Phi-2量化到INT4。边缘侧环境硬件一台带RTX 3090或4090的服务器。如果没有用云上的单卡实例也行。推理引擎vLLM。安装很简单pip install vllm就行。模型一个7B到13B的模型比如Llama 3 8B或者Qwen2-13B量化到INT8。云端环境硬件A100或H100集群。如果只是测试用云上的多卡实例。推理引擎vLLM或者TensorRT-LLM。模型70B级别的模型比如Llama 3 70B。协同层调度框架可以用Ray或者Kubernetes做编排自己写调度逻辑。通信gRPC或者HTTP/2端侧和边缘侧之间用MQTT也可以。监控Prometheus Grafana收集各层的延迟、吞吐、负载。3.2 端侧推理的部署与优化端侧部署的第一步是模型转换。以ONNX为例你需要把PyTorch模型导出成ONNX格式然后量化。import torch from transformers import AutoModelForCausalLM, AutoTokenizer # 加载模型 model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2-1.5B) tokenizer AutoTokenizer.from_pretrained(Qwen/Qwen2-1.5B) # 导出ONNX dummy_input tokenizer(Hello, return_tensorspt) torch.onnx.export( model, (dummy_input[input_ids], dummy_input[attention_mask]), qwen2-1.5b.onnx, input_names[input_ids, attention_mask], output_names[logits], dynamic_axes{ input_ids: {0: batch, 1: sequence}, attention_mask: {0: batch, 1: sequence}, logits: {0: batch, 1: sequence} }, opset_version14 )导出之后用ONNX Runtime的量化工具做INT4量化from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( qwen2-1.5b.onnx, qwen2-1.5b-int4.onnx, weight_typeQuantType.QInt4 )量化后的模型大概只有800MB可以在手机上跑。但要注意ONNX Runtime Mobile对INT4的支持还不完善可能需要用自定义算子。端侧推理的另一个关键是KV Cache管理。端侧内存有限KV Cache不能无限增长。我的做法是设置一个最大长度比如2048个token超过就截断或者滑动窗口。滑动窗口的实现是当KV Cache满了丢掉最旧的token的KV保留最近的。这样可以在有限内存下支持长对话。3.3 边缘侧vLLM的配置与调优边缘侧用vLLM配置相对简单但有几个参数需要调。python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2-13B-Instruct \ --quantization int8 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 16 \ --port 8000几个关键参数的解释--quantization int8启用INT8量化。vLLM会自动把模型量化到INT8显存占用减半。--max-model-len 4096最大序列长度。这个值越大KV Cache占用越多。4096对于大多数对话场景够用了。--gpu-memory-utilization 0.9GPU显存利用率。0.9表示用90%的显存留10%给系统。--max-num-seqs 16最大并发序列数。这个值决定了同时能处理多少个请求。太大显存不够太小吞吐上不去。16是一个比较平衡的值。我实测下来RTX 3090跑Qwen2-13B INT8max-num-seqs16时吞吐量大概每秒500个token延迟在100毫秒左右。如果调到32吞吐量能到800但延迟会增加到200毫秒。这个trade-off要根据业务需求来定。3.4 云端推理的批处理与调度云端用vLLM配置和边缘侧类似但模型更大需要多卡。python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-3-70B-Instruct \ --tensor-parallel-size 4 \ --quantization int8 \ --max-model-len 8192 \ --gpu-memory-utilization 0.95 \ --max-num-seqs 64 \ --port 8000--tensor-parallel-size 4表示用4张卡做张量并行。70B模型INT8量化后大概70GB4张A10040GB刚好够。云端的调度比边缘侧复杂因为要处理跨节点的请求分发。我的做法是用一个简单的负载均衡器根据每个节点的当前队列长度来分发请求。队列短的节点优先。import requests nodes [ http://node1:8000, http://node2:8000, http://node3:8000 ] def get_least_loaded_node(): min_queue float(inf) best_node None for node in nodes: try: resp requests.get(f{node}/metrics) queue_len resp.json()[queue_length] if queue_len min_queue: min_queue queue_len best_node node except: continue return best_node这个逻辑很简单但有效。实际生产中可能还需要考虑节点的GPU型号、网络延迟等因素。3.5 协同层的调度逻辑实现协同层的调度逻辑我用一个简单的Python函数来演示def route_request(request): # 判断延迟要求 if request.latency_requirement 50: # 只能端侧或边缘 if request.complexity 0.3: return edge else: return edge # 端侧处理不了复杂请求 elif request.latency_requirement 200: # 边缘或云端 if request.complexity 0.5: return edge else: return cloud else: # 都可以优先低成本 if request.complexity 0.3: return edge elif request.complexity 0.7: return edge else: return cloud这个逻辑很粗糙实际中需要更精细的复杂度评估和负载感知。但核心思想是一样的根据延迟要求、任务复杂度、当前负载选择最合适的层。4. 常见问题与排查技巧实录4.1 端侧推理的典型问题问题一模型转换后精度下降严重。我遇到过好几次PyTorch模型导出ONNX后输出完全不对。排查下来通常是两个原因一是算子不支持ONNX没有对应的算子导出时被替换成了近似算子二是动态轴设置不对导致batch或sequence维度被固定了。解决办法先用ONNX Runtime的onnxruntime.tools.check_model检查模型看有没有不支持的算子。如果有要么换算子要么用自定义算子。动态轴的问题仔细检查dynamic_axes参数确保所有需要动态的维度都设置了。问题二端侧推理速度慢。手机端跑1.5B模型如果不用NPU纯CPU跑速度可能只有每秒2到3个token根本没法用。解决办法一定要用NPU。高通的QNN、华为的CANN、苹果的Core ML都能把推理速度提升5到10倍。如果设备没有NPU那就只能降模型大小用0.5B的模型。问题三KV Cache内存溢出。端侧内存有限长对话时KV Cache会爆。解决办法设置最大长度超过就滑动窗口。或者用PagedAttention的思想把KV Cache分页管理但端侧实现比较复杂。4.2 边缘侧vLLM的常见坑坑一显存不够模型加载失败。vLLM加载模型时会先分配显存。如果gpu-memory-utilization设得太高比如0.95而系统还有其他进程占用显存就会OOM。解决办法设成0.85到0.9留一些余量。或者用--swap-space参数把一部分KV Cache放到CPU内存。坑二吞吐量上不去。vLLM的吞吐量取决于max-num-seqs和max-model-len。如果这两个值设得太小GPU利用率上不去。解决办法根据显存大小尽量调大这两个值。RTX 3090跑13B INT8max-num-seqs可以设到32max-model-len设到4096。坑三请求排队太长。如果并发请求太多vLLM会排队。排队时间太长用户体验就差。解决办法加节点做负载均衡。或者用优先级队列重要请求优先处理。4.3 协同调度的常见问题问题一调度决策延迟高。如果调度层每次都要查询所有节点的状态决策延迟可能达到几十毫秒。解决办法缓存节点状态每隔几秒更新一次。或者用近似的负载信息不要求完全准确。问题二跨层通信失败。端侧到边缘侧的网络可能不稳定请求丢失或超时。解决办法加重试机制设置合理的超时时间。如果边缘侧不可用降级到云端。问题三数据一致性。端侧和边缘侧的模型版本可能不一致导致同样的请求在不同层得到不同结果。解决办法统一模型版本管理每次更新模型时所有层同步更新。或者用版本号标记请求确保同一请求在同一版本上处理。4.4 常见问题速查表问题可能原因排查方法解决办法端侧模型精度下降算子不支持或动态轴错误用ONNX检查工具换算子或修正动态轴端侧推理慢没用NPU检查是否调用了NPU启用NPU加速KV Cache溢出序列太长监控内存占用滑动窗口或分页管理vLLM OOM显存利用率太高查看GPU显存降低gpu-memory-utilization吞吐量低max-num-seqs太小查看GPU利用率调大max-num-seqs调度延迟高状态查询太频繁测量调度耗时缓存节点状态跨层通信失败网络不稳定查看网络日志加重试和降级模型版本不一致更新不同步检查各层模型版本统一版本管理5. 这套体系适合谁以及我的一些实操心得5.1 适合的场景与团队云边端协同的算力体系不是所有团队都需要。我总结下来适合这几类第一类有延迟敏感场景的团队。比如做自动驾驶、工业质检、AR/VR的团队端侧和边缘侧推理是刚需。云端推理的几百毫秒延迟在这些场景下不可接受。第二类有数据隐私要求的团队。比如做医疗、金融、政务的团队数据不能出本地。端侧推理是唯一选择。第三类成本敏感的团队。如果全部用云端推理成本太高。把一部分推理放到边缘侧用自购的GPU长期来看能省不少钱。我算过一笔账一个中等规模的AI应用如果全部用云端A100一年成本大概50万如果用边缘侧RTX 4090加云端混合一年成本可以降到20万左右。第四类做AI Agent和多AI协作的团队。Agent的推理请求很分散有的简单有的复杂。云边端协同可以根据请求类型动态调度提高整体效率。5.2 我踩过的坑和总结的经验经验一不要追求一步到位。我一开始就想搭一个完整的云边端协同体系结果发现太复杂了光是调度逻辑就写了上千行bug一堆。后来我改成先做端侧再做边缘侧最后做协同。每一步都跑通了再往上加。这样稳得多。经验二量化不是万能的。INT4量化确实能把模型压得很小但精度损失在某些任务上很致命。我的做法是先试INT8如果显存够就用INT8如果不够再试INT4但一定要做精度评估。评估的方法很简单拿100条测试数据对比量化前后的输出看差异有多大。如果差异超过10%就要考虑混合精度。经验三调度逻辑要简单可靠。我见过一些团队调度逻辑写得非常复杂考虑了十几个因素结果经常出bug。我的建议是先做最简单的调度比如只根据延迟要求来路由。跑通了再慢慢加因素。每加一个因素都要做充分的测试。经验四监控比优化更重要。云边端协同体系各层的状态是动态变化的。如果没有监控你根本不知道问题出在哪。我的做法是每一层都部署Prometheus收集延迟、吞吐、错误率、显存占用等指标。然后用Grafana做统一展示。这样出问题时一眼就能看出是哪一层的问题。经验五端侧模型要定期更新。端侧模型一旦部署更新很麻烦。但如果不更新端侧的能力会越来越落后。我的做法是端侧模型每季度更新一次用OTA的方式推送。更新时要注意兼容性新模型要能处理旧模型的请求格式。5.3 后续可以扩展的方向这套体系搭起来之后还可以往几个方向扩展方向一联邦学习。端侧设备可以在本地训练小模型然后把梯度上传到云端聚合。这样既能利用端侧数据又能保护隐私。方向二动态模型切换。根据当前负载和任务类型动态切换端侧和边缘侧的模型。比如低峰期用大模型高峰期用小模型。方向三多模态推理。现在主要是文本推理后续可以扩展到图像、语音、视频。端侧做预处理边缘侧做特征提取云端做多模态融合。方向四自动扩缩容。根据请求量的变化自动增加或减少边缘节点。这需要和Kubernetes集成用HPAHorizontal Pod Autoscaler来做。我个人在实际操作中的体会是云边端协同不是一个纯技术问题更多的是一个工程问题。技术方案有很多但能不能落地取决于你对业务场景的理解对成本、延迟、精度的权衡以及团队的工程能力。端脑科技的这个方向是对的但具体能做到什么程度还要看他们的工程实现和生态建设。