2024年下半年开始AI算力圈子里最明显的一个变化就是大家不再只盯着训练集群的利用率而是开始拼命追问推理服务的时延、并发和单位成本。我自己的团队过去半年处理的推理请求量已经比训练任务多了快两个数量级以前囤GPU是为了跑一次大训练任务现在GPU的日常消耗几乎全被线上推理吃掉了。这种从集中训练走向广泛推理的需求结构变化逼着我们把整个算力架构的思路重新梳理了一遍——不是把训练集群直接拿来跑推理就万事大吉而是要真正设计一套覆盖数据中心、边缘节点和终端设备的云边端协同算力体系。这篇内容就从端脑科技的设计思路出发聊聊我们为什么这么拆、怎么搭、踩过哪些坑以及推理引擎、精度量化、分布式调度这些实操环节里值得抄作业的细节。1. 算力拐点为什么推理正在取代训练成为真正的算力消耗大户1.1 训练和推理的需求本质完全不同很多人以为训练和推理都是“跑大模型”硬件通用就行实际上两者的资源画像差异非常大。训练任务的特点是大规模、长周期、数据密集一次7B模型的微调可能需要几十块GPU连续跑几天它对吞吐量的要求是“吃得越饱越好”但对单次请求的响应时间几乎没有硬性要求。推理任务则完全是另一回事用户的每个请求都希望几百毫秒内看到结果延迟长了用户立刻流失而且推理请求是持续不断、无法预知的中午可能是几千个并发凌晨又会掉到几十个。用一个生活类比来说训练像是一次电影拍摄要动用整个剧组、拍几个月追求的是作品质量推理更像是电影院每天排片放映关注的是每场能坐多少观众、散场多快、高峰期有没有爆场。如果拿拍电影的团队直接去运营电影院你很快会发现设备虽然都在但排片调度、分厅策略、人流疏导这些环节完全没有对应的能力。这也是为什么很多团队把训练集群改造成推理服务后发现GPU利用率上去了但用户实际体感非常差——因为推理集群的瓶颈从来不是显卡算力总量而是并发调度、KV Cache管理、批处理窗口这些工程细节。从算力需求的绝对值上看训练和推理也呈现出完全不同的增长曲线。训练需求是“脉冲式”的集中在模型版本迭代的几个时间点上推理需求是“长尾分布式”的每上线一个AI功能就有一批持续不断的推理流量涌进来。像端侧语音助手、智能客服、实时视觉检测这种场景推理请求随时随地都在产生你不可能把所有流量都导回一个几千公里外的数据中心——网络时延、带宽费用、数据合规、故障单点这些问题任何一个都足以让“全云端集中推理”的方案翻车。1.2 推理场景正在变得无处不在推理需求暴涨的背后是AI应用形态的转变。以前AI能力是“后台离线算”比如推荐系统每天跑一次批处理现在的AI能力变成了“前台实时用”用户直接在对话窗口、摄像头、手机App里反复调用模型。这种转变让算力必须向用户和数据发生的地方靠近。端脑科技在立项之前做过一次统计把我们接触的典型推理场景分成三类第一类是面向C端的交互式生成包括聊天机器人、AI写作、AI绘画特征是抖动大、对时延敏感第二类是面向行业的实时视觉分析比如工业质检、门店客流统计、安防巡检特征是在边缘侧就完成大部分计算只需要把结构化结论传回中心第三类是面向生产的复杂决策任务比如长文档理解、多步骤智能体任务特征是计算量大、上下文长必须依赖云端大模型能力。这三类场景混合在一起靠单一架构是撑不住的端侧管不了复杂任务云端又接不住高频低延迟需求所以云边端协同不是概念包装而是业务需求倒逼出来的必然结构。2. 端脑科技的三层架构云、边、端各自解决什么问题2.1 云端中心复杂推理和模型分发的中枢云端在整个体系里的定位是“复杂任务的最后兜底”和“模型的统一分发中心”。云端部署的模型通常是27B、72B甚至更大规模的稠密模型用多卡并行方式跑起来承担的是长上下文理解、多轮深度对话、Agent任务规划这类需要最强模型能力的请求。为什么不能让所有流量都走云端答案很简单算得动但传不起。一次云端推理请求百毫秒级别算完但跨地域网络往返可能就要几十毫秒甚至上百毫秒同时带宽成本随图片、音频、长文本飞速上涨。所以云端策略是“高价值集中、低价值下沉”。云端通过推理网关接收从边缘层上送的复杂请求配合消息队列削峰填谷把高峰期的突发流量缓存在队列里避免后端推理服务被打满。云端还会统一维护模型仓库每个模型版本打包后通过分发服务推送到边缘节点边缘节点只负责运行和上报状态模型训练、微调、量化、评测这些重活全在云端完成。这种设计让算法团队只需要维护云端一套模型管线的标准边缘侧就是“拉取-加载-运行”三个动作逻辑越简单线上故障越少。2.2 边缘节点吞吐与延迟的折中地带边缘节点是整张协同网络里最考验工程能力的部分。它本质上是在用户附近放置一台中等算力服务器通常是一张到四张专业显卡或边缘推理卡站在“云端大模型”和“端侧小模型”中间做承上启下。边缘节点承载的主要是7B到14B的量化模型形态上更偏向“任务分诊”角色简单直接的问题在边缘层直接回答不需要惊动云端只有识别到复杂意图、超长上下文、需要最新知识的请求才构建一个精简的请求包转发到云端。这样设计的原因很实在。首先是时延边缘节点和用户之间通常只有一跳网络时延可以控制在5到20毫秒而云端至少是百毫秒级别其次是成本把高频简单的推理任务压在边缘节点按单价算比云端至少便宜一半以上第三是隐私合规很多行业场景要求原始数据不能离开园区网络边缘节点可以直接消费本地数据只上送脱敏后的结果。端脑科技在落地连锁门店场景时的典型配置是每个区域节点放一台双卡推理服务器本地跑7B模型处理80%的常规咨询剩下的20%复杂请求走云端实测下来整体响应时间平均降低60%。边缘节点还有一个容易被忽视的工程细节它必须支持“热更新模型”。因为在真实业务中模型版本迭代很快如果每更新一次模型都要重启服务线上连接就会中断。我们采用的做法是边缘节点上同时保留两个模型版本新版本加载完成后流量逐步切过去切流过程中记录新旧版本的命中率、拒绝率、平均相似度确认无异常再回收老版本这套机制几乎可以做到用户无感。2.3 端侧设备把最后十米的算力用起来端侧是整个协同体系里最靠近用户、资源也最受限的一层。手机、PC、智能摄像头、车载设备这些终端芯片的算力远不能和大卡相比但优势在于“零网络延迟”——模型就在本地请求根本不用出设备。端侧适合跑的是一类极轻量的模型比如1.5B到3B的小模型量化版上下文限制在4K以内以及一些非生成式的任务模型比如唤醒词检测、语音转文字、简单的意图分类和图像预处理。端脑科技的协同策略叫“端侧先行、云端精修”。比如在PC端部署一个3B的对话助手用户的请求先由端侧小模型给出一个快速响应同时把输入文本压缩成关键的对话摘要当检测到当前请求超出小模型的能力边界比如需要引用最新知识、处理超长文档、进行多步推理时端侧会把摘要和必要上下文组成的紧凑请求包发送到边缘或云端由大模型接手。这个“先本地快速响应、后台模型精修”的模式既能保证用户的瞬时体验又能利用云端能力兜底实际使用中端到端延迟几乎感觉不到而不像纯云端方案那样每次交互都卡顿一下。端侧部署最麻烦的是功耗和散热。GPU算力再强放在手机里半分钟就过热降频体验反而比慢但稳定的CPU还差。我们的经验是端侧任务必须严格控制批处理窗口一次只处理一个推理请求连续运行一段时间就强制切换到低功耗模式另外要优先使用终端自带的NPU而不是通用CPU比如高通的Hexagon、苹果的ANeuralEngine它们的能效比是CPU推理的十倍以上对发热和耗电的控制立竿见影。3. 推理引擎选型与精度量化把每一张卡的潜力榨干3.1 vLLM与大模型推理引擎的关键设计云端推理主流的推理引擎是vLLM它解决了传统推理框架在高并发场景下显存浪费严重、批处理效率低的问题。vLLM最核心的两个设计一是PagedAttention二是Continuous Batching。PagedAttention的思路和操作系统里的虚拟内存分页非常像它把KV Cache切分成固定大小的块按需分配、动态存储而不是像传统框架那样给每个请求预分配一整块连续显存。这就能让显存碎片化大幅降低同样的卡可以同时跑的请求数量提高好几倍。Continuous Batching更好理解传统批处理是凑够一批再一起算就像公交车满员才发车等待时间长、发车间隔不稳定Continuous Batching则是来一个请求就插入到正在执行的批次里相当于随到随上的滚动发车让GPU始终处于满载状态。这两个机制叠加起来vLLM在实际部署中实现的中位延迟下降可以达到50%以上吞吐提升也可以达到数倍。我建议想彻底理解大模型推理内核的人去看看nano-vLLM这个项目它是vLLM的极简教学版本把推理过程拆成了请求调度器、KV Cache管理器、采样器三个核心模块代码量小很多但逻辑完整看完之后再回看vLLM的源码思路会清晰很多。配置vLLM时有几个参数值得反复调。--max-model-len设置模型最大输入长度实际业务如果大部分请求都在2K以内没必要按32K去预留显存--gpu-memory-utilization控制GPU显存利用率我会保守地设为0.9留一点余量给CUDA上下文和临时算子设到0.95遇到过偶发OOM--max-num-seqs决定并发序列数并不是越大越好过大会导致单个请求排队时间明显变长。我们线上7B模型在两块RTX 3090上的实践经验是max-num-seqs设为256单卡并发稳定在300到500 QPS尾延迟控制在2秒以内如果业务对延迟更敏感就把并发调到128换来更稳定的P99延迟。3.2 fp64/fp32/fp16/int8算力精度与性能的博弈推理部署绕不开精度选择很多新入行的同学对fp64、fp32、fp16、int8的区别只停留在“数字越大越准”的层面实际上每一步降精度背后都是算力、显存、带宽的综合权衡。下面这张表是我整理常用精度的速查参考精度每参数占用算力需求适用场景fp648字节极高主要用于科学计算AI训练推理几乎不用性价比极低fp324字节高传统深度学习训练基准小规模训练、调试基线fp16/bf162字节约是fp32的2倍吞吐大模型训练主流推理兜底精度int81字节约是fp16的2倍吞吐在线推理主流质量损失可控int40.5字节最高需特殊指令支持端侧和边缘推理常用训练阶段模型用fp16或bf16是主流选择原因是显存减半且算力吞吐翻倍bf16在动态范围上更稳不容易出现fp16低精度导致数值溢出。推理阶段则尽量往int8甚至int4压因为一次推理请求的瓶颈往往是显存带宽参数精度的字节数直接决定了每秒钟能读取的参数总量压低精度就能在线性提升推理吞吐。实际做量化时我的经验是优先选训练后量化PTQ原因是不需要重新训练模型流程短、见效快。工具上我常用的是GPTQ和AWQ两种方法对7B模型做int4量化业务指标几乎无损但显存占用从14GB直接降到4GB左右推理速度能提升1.5到2倍。需要提醒的是int4量化对模型的敏感层很挑剔实操里务必用校验集先跑一遍比较量化前后的困惑度PPL如果PPL上升超过10%就要考虑改用AWQ或者混合精度方案。另外fp16在上亿级参数模型中偶尔会出现数值精度不足导致的奇怪行为如果发现同一请求多次调用结果差异大优先排查是不是精度溢出。4. 分布式调度与共享算力从单卡到集群的资源编排实战4.1 显存规划一张卡到底能跑多大的模型做推理部署绕不开一个基本功算清显存。模型的权重显存有个粗略公式模型参数量乘以每个参数的字节数再乘一个1.2的安全系数。以7B模型为例fp16精度下权重显存大约是7×2×1.216.8GB一张24GB显存的RTX 3090可以勉强放下int8量化后大约8.4GB这就舒服多了显存大头可以留给KV Cache和并发请求。KV Cache的显存占用也很可观粗略估算公式是KV Cache字节数约等于Batch大小×序列长度×层数×隐藏层维度×2×2。第二个2来自K和V两个矩阵。以7B模型为例层数32、隐藏维度4096Batch16、序列长度2048时代KV Cache大约是16×2048×32×4096×2×2≈34GB这还没算权重整体显存压力非常大。这就是为什么线上通常要限制单请求的最大长度并且对超长请求做大模型分块或摘要压缩否则很快就会把显存打满。热词里提到的“K100单卡推理27B模型”这类场景我实测过类似配置Qwen2.5-27B用int8量化后权重显存约27GB一张A100 80G可以跑但并发做不高单卡推理速度约在5到10 token/s适合离线批处理任务如果换到4090这种24GB卡就得把量化降到int4或者用更激进的KV Cache量化才能塞进去。所以做单卡推理前一定要先做显存预算留出20%余量给临时算子否则服务上线后一阵流量波动就会OOM重启。4.2 共享算力与任务调度策略端脑科技在构建协同算力体系时还整合了一批分散的闲置算力资源包括个人电脑闲时共享、边缘小机房剩余算力等。这样做的好处是扩充了整体吞吐但调度复杂度也直线上升其中最核心的就是任务编排逻辑。一个稳定的共享算力池至少要有四个能力任务队列、优先级调度、超时回收、失败重投。我们的调度策略借鉴的是餐厅翻台逻辑任务队列相当于取号系统每个任务进来都有唯一的编号和预估执行时间边缘节点或共享设备空闲时调度器从队列里取出任务按照“优先级高者先执行、同级别短任务优先”的顺序分配如果某个节点的任务执行时间超过预估的两倍调度器会判定节点异常把任务转移到健康节点。这种设计在共享算力场景中非常重要因为个人电脑随时可能关机、游戏本随时可能跑起3A大作节点资源说没就没没有超时回收和失败重投机制任务堆积会把整个调度器拖垮。实际运行时我们还会对每个节点做实时画像记录最近一小时的平均延迟、成功率和可用显存节点画像越健康调度器越倾向于把高优任务派给它形成自然的分流和负载均衡。5. 实操中的五个坑我们踩过你绕开5.1 并发参数调大反而变慢很多新手配置vLLM时觉得并发数值越大越好把max-num-seqs调到1024结果吞吐反而下降了。原因在于并发请求增多后单个请求排队时间变长P99延迟飙升而且显存中同时驻留的KV Cache太多频繁触发换入换出。我们的建议是从256开始压测逐步调低到128或者更高以业务可接受的P99延迟为唯一标准不要单纯追求并发数值。5.2 边缘节点模型版本混乱当云端每次更新模型后自动推送到几十上百个边缘节点如果推送策略不做控制很容易出现“请求端新模型、边缘旧模型”的割裂局面。我们的解法是引入模型版本配置中心边缘节点启动时拉取指定版本清单之后每五分钟检查一次变更新版本不是到了就立即启用而是先加载到备用目录通过健康检查后再平滑切换流量切换期间如果错误率上升立即回滚到上一版本。这套流程保证了我们几十个边缘节点可以在十分钟内完成统一变更同时几乎不影响线上业务。5.3 端侧发热降频导致推理越来越慢端侧设备跑推理时发热降频是最大的敌人。我们的PC端助手在连续处理长文本总结时出现过CPU占用飙升、笔记本风扇狂转、速度越来越慢的情况。解决思路有两个方向一是限制批处理窗口端侧推理队列最多同时处理一个请求多余请求排队等待二是优先把任务调度到NPU或GPU而不是让CPU硬扛。实测下来同样一次推理NPU的功耗比CPU低一半多生成速度还更快所以端侧部署前一定要花时间适配目标硬件的加速接口。5.4 量化后模型“蹦字”int8/int4量化最常见的坑是模型输出逻辑混乱、出现胡言乱语这通常是校准集不够有代表性导致的。量化校准的本质是统计激活值的分布范围校准集如果只包含少量单一话题的文本统计出的分布就会偏量化后的模型在冷门话题上就会崩。我的经验是校准集至少要覆盖业务场景里高频的几十种意图每条数据长度也要多元化量化后先在测试集上跑一遍困惑度再抽样做人工问答评估双重验证没问题才允许上线。5.5 网络抖动导致边缘转云端任务重复边缘节点把请求转发到云端时如果网络发生抖动请求可能超时但实际云端已经处理完成边缘层重试后就会产生重复计算。这个问题在我们的长文档摘要场景中尤其明显一次摘要任务可能消耗云端几十秒算力重复一次成本很高。解决方式是给每个请求生成唯一的业务ID边缘层以这个ID作为幂等键重试云端检测到相同ID直接返回上一次结果。这个机制成本很低但在分布式调度中属于必须设计的保底逻辑。6. 常见问题排查速查表现象可能原因排查方法解决方案服务启动时OOM权重显存估算不足查看启动日志中的CUDA显存分配降低gpu-memory-utilization改用int8/int4量化或换更大显存卡QPS上不去但GPU利用率低并发或批处理配置太小压测观察吞吐与延迟曲线调高max-num-seqs开启Continuous Batching用户反馈输出乱码/逻辑混乱量化精度损失比较量化前后困惑度PPL换更强量化方法AWQ扩充校准集尾延迟忽高忽低显存碎片化或大请求占坑查看监控中KV Cache的使用曲线重启vLLM进程限制单请求最大长度边缘转云端请求大量超时网络抖动检查链路丢包率和重传率实现幂等重试增加熔断降级端侧设备异常卡顿发热降频查看系统CPU频率曲线改用NPU推理限制并发队列减少token长度模型更新后线上表现波动版本切换粗暴检查流量切换方式采用双版本灰度切换错误率过高自动回滚写在最后我在实际操作中最大的体会是云边端协同这个架构听起来像是一个宏大叙事但落地时最忌讳的恰恰是从“建一个大集群”开始。正确的打开方式是先找一个小而具体的场景比如一个门店的智能助手把“端侧唤醒、边缘处理、云端兜底”全链路跑通再把同一套模式复制到更多边缘节点。真正让你少走弯路的往往不是先进技术而是显存预算表、幂等重试、版本灰度这套看似不起眼的工程基本功。还有一个小技巧可以分享无论云端还是边缘部署完推理服务后第一件事不是测吞吐而是花半小时做一次低于并发极限10%的长稳压测很多偶发OOM和内存泄漏问题都会在这个阶段现出原形。
云边端协同算力架构：从推理引擎到量化部署的实战指南
2024年下半年开始AI算力圈子里最明显的一个变化就是大家不再只盯着训练集群的利用率而是开始拼命追问推理服务的时延、并发和单位成本。我自己的团队过去半年处理的推理请求量已经比训练任务多了快两个数量级以前囤GPU是为了跑一次大训练任务现在GPU的日常消耗几乎全被线上推理吃掉了。这种从集中训练走向广泛推理的需求结构变化逼着我们把整个算力架构的思路重新梳理了一遍——不是把训练集群直接拿来跑推理就万事大吉而是要真正设计一套覆盖数据中心、边缘节点和终端设备的云边端协同算力体系。这篇内容就从端脑科技的设计思路出发聊聊我们为什么这么拆、怎么搭、踩过哪些坑以及推理引擎、精度量化、分布式调度这些实操环节里值得抄作业的细节。1. 算力拐点为什么推理正在取代训练成为真正的算力消耗大户1.1 训练和推理的需求本质完全不同很多人以为训练和推理都是“跑大模型”硬件通用就行实际上两者的资源画像差异非常大。训练任务的特点是大规模、长周期、数据密集一次7B模型的微调可能需要几十块GPU连续跑几天它对吞吐量的要求是“吃得越饱越好”但对单次请求的响应时间几乎没有硬性要求。推理任务则完全是另一回事用户的每个请求都希望几百毫秒内看到结果延迟长了用户立刻流失而且推理请求是持续不断、无法预知的中午可能是几千个并发凌晨又会掉到几十个。用一个生活类比来说训练像是一次电影拍摄要动用整个剧组、拍几个月追求的是作品质量推理更像是电影院每天排片放映关注的是每场能坐多少观众、散场多快、高峰期有没有爆场。如果拿拍电影的团队直接去运营电影院你很快会发现设备虽然都在但排片调度、分厅策略、人流疏导这些环节完全没有对应的能力。这也是为什么很多团队把训练集群改造成推理服务后发现GPU利用率上去了但用户实际体感非常差——因为推理集群的瓶颈从来不是显卡算力总量而是并发调度、KV Cache管理、批处理窗口这些工程细节。从算力需求的绝对值上看训练和推理也呈现出完全不同的增长曲线。训练需求是“脉冲式”的集中在模型版本迭代的几个时间点上推理需求是“长尾分布式”的每上线一个AI功能就有一批持续不断的推理流量涌进来。像端侧语音助手、智能客服、实时视觉检测这种场景推理请求随时随地都在产生你不可能把所有流量都导回一个几千公里外的数据中心——网络时延、带宽费用、数据合规、故障单点这些问题任何一个都足以让“全云端集中推理”的方案翻车。1.2 推理场景正在变得无处不在推理需求暴涨的背后是AI应用形态的转变。以前AI能力是“后台离线算”比如推荐系统每天跑一次批处理现在的AI能力变成了“前台实时用”用户直接在对话窗口、摄像头、手机App里反复调用模型。这种转变让算力必须向用户和数据发生的地方靠近。端脑科技在立项之前做过一次统计把我们接触的典型推理场景分成三类第一类是面向C端的交互式生成包括聊天机器人、AI写作、AI绘画特征是抖动大、对时延敏感第二类是面向行业的实时视觉分析比如工业质检、门店客流统计、安防巡检特征是在边缘侧就完成大部分计算只需要把结构化结论传回中心第三类是面向生产的复杂决策任务比如长文档理解、多步骤智能体任务特征是计算量大、上下文长必须依赖云端大模型能力。这三类场景混合在一起靠单一架构是撑不住的端侧管不了复杂任务云端又接不住高频低延迟需求所以云边端协同不是概念包装而是业务需求倒逼出来的必然结构。2. 端脑科技的三层架构云、边、端各自解决什么问题2.1 云端中心复杂推理和模型分发的中枢云端在整个体系里的定位是“复杂任务的最后兜底”和“模型的统一分发中心”。云端部署的模型通常是27B、72B甚至更大规模的稠密模型用多卡并行方式跑起来承担的是长上下文理解、多轮深度对话、Agent任务规划这类需要最强模型能力的请求。为什么不能让所有流量都走云端答案很简单算得动但传不起。一次云端推理请求百毫秒级别算完但跨地域网络往返可能就要几十毫秒甚至上百毫秒同时带宽成本随图片、音频、长文本飞速上涨。所以云端策略是“高价值集中、低价值下沉”。云端通过推理网关接收从边缘层上送的复杂请求配合消息队列削峰填谷把高峰期的突发流量缓存在队列里避免后端推理服务被打满。云端还会统一维护模型仓库每个模型版本打包后通过分发服务推送到边缘节点边缘节点只负责运行和上报状态模型训练、微调、量化、评测这些重活全在云端完成。这种设计让算法团队只需要维护云端一套模型管线的标准边缘侧就是“拉取-加载-运行”三个动作逻辑越简单线上故障越少。2.2 边缘节点吞吐与延迟的折中地带边缘节点是整张协同网络里最考验工程能力的部分。它本质上是在用户附近放置一台中等算力服务器通常是一张到四张专业显卡或边缘推理卡站在“云端大模型”和“端侧小模型”中间做承上启下。边缘节点承载的主要是7B到14B的量化模型形态上更偏向“任务分诊”角色简单直接的问题在边缘层直接回答不需要惊动云端只有识别到复杂意图、超长上下文、需要最新知识的请求才构建一个精简的请求包转发到云端。这样设计的原因很实在。首先是时延边缘节点和用户之间通常只有一跳网络时延可以控制在5到20毫秒而云端至少是百毫秒级别其次是成本把高频简单的推理任务压在边缘节点按单价算比云端至少便宜一半以上第三是隐私合规很多行业场景要求原始数据不能离开园区网络边缘节点可以直接消费本地数据只上送脱敏后的结果。端脑科技在落地连锁门店场景时的典型配置是每个区域节点放一台双卡推理服务器本地跑7B模型处理80%的常规咨询剩下的20%复杂请求走云端实测下来整体响应时间平均降低60%。边缘节点还有一个容易被忽视的工程细节它必须支持“热更新模型”。因为在真实业务中模型版本迭代很快如果每更新一次模型都要重启服务线上连接就会中断。我们采用的做法是边缘节点上同时保留两个模型版本新版本加载完成后流量逐步切过去切流过程中记录新旧版本的命中率、拒绝率、平均相似度确认无异常再回收老版本这套机制几乎可以做到用户无感。2.3 端侧设备把最后十米的算力用起来端侧是整个协同体系里最靠近用户、资源也最受限的一层。手机、PC、智能摄像头、车载设备这些终端芯片的算力远不能和大卡相比但优势在于“零网络延迟”——模型就在本地请求根本不用出设备。端侧适合跑的是一类极轻量的模型比如1.5B到3B的小模型量化版上下文限制在4K以内以及一些非生成式的任务模型比如唤醒词检测、语音转文字、简单的意图分类和图像预处理。端脑科技的协同策略叫“端侧先行、云端精修”。比如在PC端部署一个3B的对话助手用户的请求先由端侧小模型给出一个快速响应同时把输入文本压缩成关键的对话摘要当检测到当前请求超出小模型的能力边界比如需要引用最新知识、处理超长文档、进行多步推理时端侧会把摘要和必要上下文组成的紧凑请求包发送到边缘或云端由大模型接手。这个“先本地快速响应、后台模型精修”的模式既能保证用户的瞬时体验又能利用云端能力兜底实际使用中端到端延迟几乎感觉不到而不像纯云端方案那样每次交互都卡顿一下。端侧部署最麻烦的是功耗和散热。GPU算力再强放在手机里半分钟就过热降频体验反而比慢但稳定的CPU还差。我们的经验是端侧任务必须严格控制批处理窗口一次只处理一个推理请求连续运行一段时间就强制切换到低功耗模式另外要优先使用终端自带的NPU而不是通用CPU比如高通的Hexagon、苹果的ANeuralEngine它们的能效比是CPU推理的十倍以上对发热和耗电的控制立竿见影。3. 推理引擎选型与精度量化把每一张卡的潜力榨干3.1 vLLM与大模型推理引擎的关键设计云端推理主流的推理引擎是vLLM它解决了传统推理框架在高并发场景下显存浪费严重、批处理效率低的问题。vLLM最核心的两个设计一是PagedAttention二是Continuous Batching。PagedAttention的思路和操作系统里的虚拟内存分页非常像它把KV Cache切分成固定大小的块按需分配、动态存储而不是像传统框架那样给每个请求预分配一整块连续显存。这就能让显存碎片化大幅降低同样的卡可以同时跑的请求数量提高好几倍。Continuous Batching更好理解传统批处理是凑够一批再一起算就像公交车满员才发车等待时间长、发车间隔不稳定Continuous Batching则是来一个请求就插入到正在执行的批次里相当于随到随上的滚动发车让GPU始终处于满载状态。这两个机制叠加起来vLLM在实际部署中实现的中位延迟下降可以达到50%以上吞吐提升也可以达到数倍。我建议想彻底理解大模型推理内核的人去看看nano-vLLM这个项目它是vLLM的极简教学版本把推理过程拆成了请求调度器、KV Cache管理器、采样器三个核心模块代码量小很多但逻辑完整看完之后再回看vLLM的源码思路会清晰很多。配置vLLM时有几个参数值得反复调。--max-model-len设置模型最大输入长度实际业务如果大部分请求都在2K以内没必要按32K去预留显存--gpu-memory-utilization控制GPU显存利用率我会保守地设为0.9留一点余量给CUDA上下文和临时算子设到0.95遇到过偶发OOM--max-num-seqs决定并发序列数并不是越大越好过大会导致单个请求排队时间明显变长。我们线上7B模型在两块RTX 3090上的实践经验是max-num-seqs设为256单卡并发稳定在300到500 QPS尾延迟控制在2秒以内如果业务对延迟更敏感就把并发调到128换来更稳定的P99延迟。3.2 fp64/fp32/fp16/int8算力精度与性能的博弈推理部署绕不开精度选择很多新入行的同学对fp64、fp32、fp16、int8的区别只停留在“数字越大越准”的层面实际上每一步降精度背后都是算力、显存、带宽的综合权衡。下面这张表是我整理常用精度的速查参考精度每参数占用算力需求适用场景fp648字节极高主要用于科学计算AI训练推理几乎不用性价比极低fp324字节高传统深度学习训练基准小规模训练、调试基线fp16/bf162字节约是fp32的2倍吞吐大模型训练主流推理兜底精度int81字节约是fp16的2倍吞吐在线推理主流质量损失可控int40.5字节最高需特殊指令支持端侧和边缘推理常用训练阶段模型用fp16或bf16是主流选择原因是显存减半且算力吞吐翻倍bf16在动态范围上更稳不容易出现fp16低精度导致数值溢出。推理阶段则尽量往int8甚至int4压因为一次推理请求的瓶颈往往是显存带宽参数精度的字节数直接决定了每秒钟能读取的参数总量压低精度就能在线性提升推理吞吐。实际做量化时我的经验是优先选训练后量化PTQ原因是不需要重新训练模型流程短、见效快。工具上我常用的是GPTQ和AWQ两种方法对7B模型做int4量化业务指标几乎无损但显存占用从14GB直接降到4GB左右推理速度能提升1.5到2倍。需要提醒的是int4量化对模型的敏感层很挑剔实操里务必用校验集先跑一遍比较量化前后的困惑度PPL如果PPL上升超过10%就要考虑改用AWQ或者混合精度方案。另外fp16在上亿级参数模型中偶尔会出现数值精度不足导致的奇怪行为如果发现同一请求多次调用结果差异大优先排查是不是精度溢出。4. 分布式调度与共享算力从单卡到集群的资源编排实战4.1 显存规划一张卡到底能跑多大的模型做推理部署绕不开一个基本功算清显存。模型的权重显存有个粗略公式模型参数量乘以每个参数的字节数再乘一个1.2的安全系数。以7B模型为例fp16精度下权重显存大约是7×2×1.216.8GB一张24GB显存的RTX 3090可以勉强放下int8量化后大约8.4GB这就舒服多了显存大头可以留给KV Cache和并发请求。KV Cache的显存占用也很可观粗略估算公式是KV Cache字节数约等于Batch大小×序列长度×层数×隐藏层维度×2×2。第二个2来自K和V两个矩阵。以7B模型为例层数32、隐藏维度4096Batch16、序列长度2048时代KV Cache大约是16×2048×32×4096×2×2≈34GB这还没算权重整体显存压力非常大。这就是为什么线上通常要限制单请求的最大长度并且对超长请求做大模型分块或摘要压缩否则很快就会把显存打满。热词里提到的“K100单卡推理27B模型”这类场景我实测过类似配置Qwen2.5-27B用int8量化后权重显存约27GB一张A100 80G可以跑但并发做不高单卡推理速度约在5到10 token/s适合离线批处理任务如果换到4090这种24GB卡就得把量化降到int4或者用更激进的KV Cache量化才能塞进去。所以做单卡推理前一定要先做显存预算留出20%余量给临时算子否则服务上线后一阵流量波动就会OOM重启。4.2 共享算力与任务调度策略端脑科技在构建协同算力体系时还整合了一批分散的闲置算力资源包括个人电脑闲时共享、边缘小机房剩余算力等。这样做的好处是扩充了整体吞吐但调度复杂度也直线上升其中最核心的就是任务编排逻辑。一个稳定的共享算力池至少要有四个能力任务队列、优先级调度、超时回收、失败重投。我们的调度策略借鉴的是餐厅翻台逻辑任务队列相当于取号系统每个任务进来都有唯一的编号和预估执行时间边缘节点或共享设备空闲时调度器从队列里取出任务按照“优先级高者先执行、同级别短任务优先”的顺序分配如果某个节点的任务执行时间超过预估的两倍调度器会判定节点异常把任务转移到健康节点。这种设计在共享算力场景中非常重要因为个人电脑随时可能关机、游戏本随时可能跑起3A大作节点资源说没就没没有超时回收和失败重投机制任务堆积会把整个调度器拖垮。实际运行时我们还会对每个节点做实时画像记录最近一小时的平均延迟、成功率和可用显存节点画像越健康调度器越倾向于把高优任务派给它形成自然的分流和负载均衡。5. 实操中的五个坑我们踩过你绕开5.1 并发参数调大反而变慢很多新手配置vLLM时觉得并发数值越大越好把max-num-seqs调到1024结果吞吐反而下降了。原因在于并发请求增多后单个请求排队时间变长P99延迟飙升而且显存中同时驻留的KV Cache太多频繁触发换入换出。我们的建议是从256开始压测逐步调低到128或者更高以业务可接受的P99延迟为唯一标准不要单纯追求并发数值。5.2 边缘节点模型版本混乱当云端每次更新模型后自动推送到几十上百个边缘节点如果推送策略不做控制很容易出现“请求端新模型、边缘旧模型”的割裂局面。我们的解法是引入模型版本配置中心边缘节点启动时拉取指定版本清单之后每五分钟检查一次变更新版本不是到了就立即启用而是先加载到备用目录通过健康检查后再平滑切换流量切换期间如果错误率上升立即回滚到上一版本。这套流程保证了我们几十个边缘节点可以在十分钟内完成统一变更同时几乎不影响线上业务。5.3 端侧发热降频导致推理越来越慢端侧设备跑推理时发热降频是最大的敌人。我们的PC端助手在连续处理长文本总结时出现过CPU占用飙升、笔记本风扇狂转、速度越来越慢的情况。解决思路有两个方向一是限制批处理窗口端侧推理队列最多同时处理一个请求多余请求排队等待二是优先把任务调度到NPU或GPU而不是让CPU硬扛。实测下来同样一次推理NPU的功耗比CPU低一半多生成速度还更快所以端侧部署前一定要花时间适配目标硬件的加速接口。5.4 量化后模型“蹦字”int8/int4量化最常见的坑是模型输出逻辑混乱、出现胡言乱语这通常是校准集不够有代表性导致的。量化校准的本质是统计激活值的分布范围校准集如果只包含少量单一话题的文本统计出的分布就会偏量化后的模型在冷门话题上就会崩。我的经验是校准集至少要覆盖业务场景里高频的几十种意图每条数据长度也要多元化量化后先在测试集上跑一遍困惑度再抽样做人工问答评估双重验证没问题才允许上线。5.5 网络抖动导致边缘转云端任务重复边缘节点把请求转发到云端时如果网络发生抖动请求可能超时但实际云端已经处理完成边缘层重试后就会产生重复计算。这个问题在我们的长文档摘要场景中尤其明显一次摘要任务可能消耗云端几十秒算力重复一次成本很高。解决方式是给每个请求生成唯一的业务ID边缘层以这个ID作为幂等键重试云端检测到相同ID直接返回上一次结果。这个机制成本很低但在分布式调度中属于必须设计的保底逻辑。6. 常见问题排查速查表现象可能原因排查方法解决方案服务启动时OOM权重显存估算不足查看启动日志中的CUDA显存分配降低gpu-memory-utilization改用int8/int4量化或换更大显存卡QPS上不去但GPU利用率低并发或批处理配置太小压测观察吞吐与延迟曲线调高max-num-seqs开启Continuous Batching用户反馈输出乱码/逻辑混乱量化精度损失比较量化前后困惑度PPL换更强量化方法AWQ扩充校准集尾延迟忽高忽低显存碎片化或大请求占坑查看监控中KV Cache的使用曲线重启vLLM进程限制单请求最大长度边缘转云端请求大量超时网络抖动检查链路丢包率和重传率实现幂等重试增加熔断降级端侧设备异常卡顿发热降频查看系统CPU频率曲线改用NPU推理限制并发队列减少token长度模型更新后线上表现波动版本切换粗暴检查流量切换方式采用双版本灰度切换错误率过高自动回滚写在最后我在实际操作中最大的体会是云边端协同这个架构听起来像是一个宏大叙事但落地时最忌讳的恰恰是从“建一个大集群”开始。正确的打开方式是先找一个小而具体的场景比如一个门店的智能助手把“端侧唤醒、边缘处理、云端兜底”全链路跑通再把同一套模式复制到更多边缘节点。真正让你少走弯路的往往不是先进技术而是显存预算表、幂等重试、版本灰度这套看似不起眼的工程基本功。还有一个小技巧可以分享无论云端还是边缘部署完推理服务后第一件事不是测吞吐而是花半小时做一次低于并发极限10%的长稳压测很多偶发OOM和内存泄漏问题都会在这个阶段现出原形。
