过去半年我一直在折腾一件事在内网的国产化边缘算力终端上把7B到30B量级的LLM/VLM推理跑顺。起因是一个客户的数据不能出园区预算只够买几台边缘盒子又非要跑私有化大模型做知识库问答和智能体。一开始我也以为这活儿很简单——找一台算力高点的国产盒子装个推理框架把模型塞进去就完事。结果从显存估算、量化选型到多卡互联每一步都有坑最离谱的是有些盒子标称几十TOPS实测跑7B模型的速度连手机都不如。这篇内容不是论文也不是厂商彩页。我把这一段时间做过的选型对比、实测数据和踩坑记录整理出来核心围绕三件事不同量级的模型在国产化边缘终端上到底能跑多快、显存究竟要多少、怎么从业务需求反推硬件配置。适合正在做私有化部署、边缘AI落地的工程师和项目负责人参考。当然涉及具体设备和固件的性能因批次差异很大我给的是我在真实项目里反复验证过的典型区间。1. 国产化边缘终端到底能跑到哪一步7B-30B的算力天花板1.1 一张表看懂不同量级模型的端侧表现区间决定边缘终端能否承载某个模型不需要看一堆复杂benchmark先看两个硬指标端到端生成速度token/s和首token延迟。我把近半年接触到的几类设备数据整理成了一个粗粒度表格适用于带NPU/GPU的国产边缘终端比如带昇腾、寒武纪、算能芯片的盒子或者飞腾/兆芯CPU配NPU卡的一体机也包括部分异构算力设备。模型量级典型量化单卡实测速度双卡实测速度适合场景7BINT415-30 token/s25-45 token/s轻量问答、RAG、意图识别13BINT46-15 token/s12-20 token/s工具调用、复杂指令、代码补全30BINT42-5 token/s8-15 token/s长文档摘要、复杂Agent、高理解力场景30BINT81-3 token/s5-10 token/s离线批量处理这里的数据是能稳定跑满的持续性能不是厂商宣传的峰值。很多设备一开始跑得飞快两分钟后触发功耗墙或温度墙速度直接腰斩后面我会专门讲这个坑。直观结论是7B-13B是边缘终端真正可用的甜点区间30B属于能跑但要忍受等待的范畴必须在模型能力和延迟之间做取舍。1.2 为什么厂商标的TOPS很高实际token/s却上不去这是选型时最容易踩的第一个认知误区。国产边缘终端都喜欢标INT8/INT4峰值算力数字看着很吓人动辄几十甚至上百TOPS但LLM推理的真实吞吐并不完全由算力决定。LLM解码过程是典型的memory-bound任务。生成每个token时模型要从显存里把全部权重读一遍权重读取速度往往远小于计算速度。用一个生活化类比算力是后厨炒菜的速度显存带宽是传菜员端盘子的速度LLM推理的瓶颈通常是传菜员端不过来而不是厨师炒不过来。所以你会发现同样是7B模型显存带宽高一点的设备哪怕TOPS低一半生成速度反而更快。还有一个隐性瓶颈是prefill阶段。用户输入的一段长文本要在一次前向中并行处理这个阶段是compute-bound对算力的需求骤然上升。表现为首token延迟很高7B模型生成一个token只要30ms但用户发来一段800字的问题盒子可能要卡2-5秒才开始返回。这也是为什么选型不能只盯生成速度还要实测长prompt下的首token延迟。另外一个现实问题是算子生态。GQA分组查询注意力、FlashAttention、RoPE这些优化在NVIDIA生态里已经非常成熟但在部分国产芯片的SDK里适配滞后或者效果打折。我遇到过同一台设备官方适配的模型能跑出不错的速度换成我从HuggingFace直接导出的量化模型速度直接掉一半有时甚至编译失败。因此判断一个边缘终端能不能用不能只看芯片规格要看它配套的推理框架支持哪些模型、哪些量化格式、哪些新算子。2. 显存占用算清楚30B模型不是30GB显存那么简单2.1 显存构成的四个大头很多人选边缘终端只看模型多大比如听到30B就以为需要30GB显存这个理解差了十万八千里。模型部署后的显存占用由四部分组成第一是权重参数总量乘以每个参数占用的字节数。7B模型FP16约14GBINT4量化后约3.5-4GB13B的INT4约7-8GB30B的INT4约16-18GB。这是最大的一块但也只是起点。第二是KV Cache随着上下文长度线性增长。每生成一个token模型都要缓存当前所有层的Key和Value后续token计算时复用。一个经验公式是每个token的KV占用约等于2 × 层数 × 每层KV头数 × 头维度 × 字节数。具体参数要看模型config但你可以用更粗的估算7B模型在8K上下文下KV Cache大约0.5-1.5GB13B约1.5-3GB30B约4-8GB。一份8K的对话历史KV Cache就有这么多。第三是激活值也就是前向计算中中间层的临时输出。边缘终端通常batch1激活值占比不大但在长序列或多batch并发时膨胀得很快不能完全忽略。第四是运行时缓冲包括算子临时缓冲区、上下文context、框架自身占用等一般要预留2-4GB。这部分最容易被低估尤其是一些国产SDK的运行时比较臃肿启动后什么都不干就吃掉1GB多。所以一块16GB显存的设备跑7B INT4很舒服跑13B INT4就比较勉强跑30B INT420GB以下的显存基本不用考虑勉强塞进去也会因为KV Cache扩展而迅速OOM。2.2 量化位宽和上下文长度如何叠加影响最终显存选量化位宽时很多人只盯着权重省了多少忽略了量化对KV Cache和激活值精度的影响。如果你的推理框架支持KV Cache也做INT8/INT4量化长上下文场景能省下很多显存如果框架只量化权重、KV Cache仍然保持FP16那么4K上下文和8K上下文的显存差距会被明显放大。我习惯在部署前做一张清单按最终负担来估算模型权重格式权重占用KV Cache4KKV Cache8K运行缓冲推荐显存Qwen2.5-7BINT4~4GB~0.5GB~1GB2GB8-12GBQwen2.5-14BINT4~8GB~1.5GB~3GB3GB16-24GB30B量级INT4~17GB~4GB~8GB4GB32-48GB30B量级INT8~31GB同上同上4GB48-64GB这张表很现实地说明了为什么边缘终端跑30B这么难即使做了INT4量化只要你想保留一定的上下文窗口显存需求就会冲到32GB以上。而市面上边缘终端的显存配置通常集中在8GB、16GB、32GB三档32GB以上的设备价格和算力往往不成正比。所以我的建议是边缘终端的主力阵容锁定7B-13B30B除非是高端双卡设备否则不要轻易挑战。3. 7B-13B实测体验问答、RAG与工具调用场景下的真实硬指标3.1 7B量化模型的端侧可用度我在一台32TOPS级别的国产边缘盒子上跑过7B INT4量化的Qwen2.5系列数据是验收阶段反复测出来的单卡流式输出稳定在18-24 token/s首token延迟在prompt较短时约300-600msprompt超过1000字时首token延迟拉到3秒左右。这个速度什么概念呢做流式问答完全够用文字像正常打字速度一样往外蹦用户不会觉得卡但如果是代码生成或长文本续写预期的等待感会明显增强毕竟代码单行输出通常超过20个token相当于每写一行都要等1秒。真实部署中还要注意解码参数的影响。采样温度、top_p、repetition_penalty这些参数不只是影响质量也会影响速度。我实测发现repetition_penalty开得过高时部分国产推理框架会多出额外的后处理步骤整体速度下降5%-10%。在边缘算力有限的情况下建议把重复惩罚控制在1.0-1.05之间不要照搬NVIDIA服务器上的那套激进参数。另外一个经常被忽略的指标是并发能力。单用户对话时7B速度不错但如果是三个用户同时提问单卡边缘终端的显存和算力会被分摊每个人拿到的速度会掉到原来的1/3左右而且频繁抢占会导致部分请求排队延迟波动很厉害。如果业务要求多人并发答案很简单要么上一台更高端的设备要么做多节点负载均衡不要指望一块板卡扛下所有。3.2 工具调用、智能体与VLM场景下的性能真相最近大家热衷于把模型做成智能体让LLM自主决定调用什么工具、以什么参数调用。这个场景在边缘终端上有两重压力。第一重压力来自于格式约束。工具调用通常要求模型输出严格遵循JSON Schema常见的做法是在采样阶段做约束解码。NVIDIA生态的vLLM、LMDeploy等框架原生支持guided decoding直接在解码时屏蔽不合法的token但部分国产边缘设备只适配到llama.cpp或Ollama这个层面这俩工具对约束解码的支持比较弱更多是靠系统提示词把模型哄到正确格式上。我做过对比同一台设备上用支持约束解码的框架跑工具调用一小时内的格式失败率能控制在2%以内用纯提示词方案失败率有时会到10%以上而且模型越小人越容易顶不住复杂指令。第二重压力来自于上下文累积。智能体一轮问答往往要经历用户问题—模型思考—调用工具—返回结果—模型总结这么个链路多轮跑下来之后前面的工具结果和对话历史全部塞进KV Cache。我做RAGAgent测试时经常跑到第8-10轮就OOM。解决办法很粗暴但有效设置历史轮数上限超了就把最早的历史摘要后截断或者干脆用短期记忆机制每隔几轮把关键信息压缩成固定长度的摘要。至于VLM视觉模型的显存和延迟压力比同尺寸纯文本模型更大。一张图被视觉编码器切成几百个visual token这些token会全部进入LLM的prefill阶段首token延迟比纯文本输入高一个数量级。7B的VLM实际负载通常比同尺寸文本模型多占1.5-2GB显存算上视觉token的KV Cache16GB设备跑起来会非常紧张。我的建议是如果业务确实需要VLM优先保证显存余量不要为了省预算选刚好卡线的设备。4. 20B-30B的实战边界多卡互联、VLM额外成本与决策拐点4.1 三条路把30B塞进边缘终端如果业务强需求逼着你必须在边缘终端跑30B现实中有三条路可以走。第一条路是单卡大显存。找一块64GB甚至更大显存的板卡一次把INT4权重和KV Cache全放进去。这条路最稳部署简单、不用考虑跨卡通信但在边缘终端市场里这种卡的数量少、价格高而且单卡的算力通常不足以让30B跑得流畅。我实测的大多数单卡场景下30B INT4的速度勉强到3-5 token/s只适合对延迟不敏感的后台处理。第二条路是双卡Tensor Parallel。用llama.cpp或LMDeploy的并行模式把模型按层拆分到两张卡上推导速度能比单卡提升2-3倍。命令形式大概是这样的以llama.cpp为例llama-server -m /models/Qwen2.5-30B-Instruct-Q4_K_M.gguf \ -c 8192 \ --n-gpu-layers 99 \ --split-mode layer \ --main-gpu 0 \ --tensor-split 1,1 \ --host 0.0.0.0 --port 8080要注意Tensor Parallel不是说加一张卡就线性翻倍。每生成一个token各卡之间都要同步梯度级的数据通信延迟是硬开销。两张PCIe卡互联时速度提升通常只有1.5-2.5倍达不到2倍更别提3倍。如果两张卡的互联带宽只有PCIe 3.0 x8甚至更低并行通信开销可能占掉整体时间的30%以上这时加卡的意义就大打折扣。第三条路是CPUNPU异构/内存复用。把权重驻留在系统大内存里推理时按层搬到计算单元或者干脆用高主频CPU跑纯CPU推理。这条路在边缘终端上一般不推荐作为主力方案因为CPU推理30B INT4的速度常年在1-3 token/s徘徊比等待还痛苦。它真正的价值在于验证阶段如果你手头只有一台大内存的测试机可以先用CPU把30B的模型能力和业务效果验证清楚再决定要不要采购高端边缘终端。4.2 双卡互联的算力收益与通信损耗我踩过最深的一个坑就是以为两张卡一定能跑出111.5的效果。实际项目中某国产盒子配备两张通过PCIe互联的算力卡跑30B INT4时单卡速度约4 token/s双卡并行理论上限是8 token/s实测只有6.5 token/s。损失主要出在每步的权重同步上30B模型每层权重量很大每生成一个token都要把中间结果跨卡传一遍。优化手段是有的。一是尽量让两个卡通过同一PCIe控制器下的高带宽通道互联避免跨CPU的PCIe拓扑二是加载模型时把整层权重分片不要让一张卡持有多份冗余三是把KV Cache也跟着分片让每张卡的显存压力更均匀。这几条做下来双卡的效率能从1.5倍拉到接近1.9倍但也就到此为止了拓扑结构决定了上限。所以20B-30B在边缘终端的决策拐点其实取决于你愿不愿意接受7B的流畅度换来30B的理解力。我在多个业务场景里做过主观测试当30B只有3-5 token/s而7B能跑出20 token/s时绝大多数非技术用户反而觉得7B更好用因为响应快、交互感强只有当任务本身就是长文档分析、复杂规则推理、工具调用可靠性这些硬核场景30B的能力优势才能覆盖延迟带来的体验损失。这里的建议很明确先跑通7B-13B验证业务闭环如果算法效果确实不够再上双卡30B一上来就追求最大的模型大概率会得到一个能跑但没法用的系统。5. 选型决策表与防坑清单从需求反推边缘终端配置5.1 四个典型业务场景的选型速查很多团队采购时从硬件出发先买设备再想跑什么这是本末倒置。正确逻辑是从业务场景反推模型量级再反推显存和算力需求。我整理了一个速查表基本覆盖边缘侧最常见的四类需求场景推荐模型量级显存底线算力参考持续性能关键选型指标内网知识库RAG问答7B INT48GB建议16GB8K上下文稳定20 token/s框架对RAG长上下文的KV Cache优化工具调用/智能体13B INT416GB建议24GB支持约束解码的框架生态成熟多轮上下文稳定性、工具格式成功率长文档分析/VLM13B-30B24GB起建议双卡视觉编码器额外显存预留首token延迟、视觉token的内存开销高并发线上服务7B-13B多节点每节点16GB每卡并发会话数≥4负载均衡、显存预分配策略RAG场景里大部分团队的问题是没做好chunk分块。把单次上下文控制在4K-8K以内7B模型可以在16GB设备上跑得游刃有余。如果文档很长就做检索分段不要一次性把全文塞进上下文否则KV Cache翻倍、首token延迟爆炸最后谁都跑不快。工具调用场景多花点时间考察框架的约束解码能力比单纯加大显存更值。我在实际项目中对比过支持guided decoding的框架下13B模型的工具调用成功率已经能逼近30B模型在提示词方案下的表现。也就是说在边缘端你完全可以用更小的模型获得接近更大模型的Agent能力前提是框架生态选对了。VLM场景则要单独算账因为视觉编码器的显存开销和视觉token对prefill的冲击不能简单套用同尺寸文本模型的经验。我建议至少留出20%-30%的显存余量同时把图像预处理尺寸控制在模型推荐范围不要随意放大分辨率否则每张图多出来的视觉token会让首token延迟翻倍。5.2 我在真实项目里踩过的坑与规避方法最后分享几个反复踩过、价值很高的坑希望能帮你省下至少两个星期的调试时间。第一个坑是只看峰值算力不看持续性能。某款设备标称64TOPS INT8实际满负载跑模型三分钟后触发功耗墙速度掉到峰值的60%左右。原因是边缘终端的散热设计跟不上芯片上限。采购前一定要问清楚持续性能而不是峰值最好让厂商提供实际跑7B/13B模型一小时的速度曲线。我后来每一次选型都把持续性能测试写进验收标准。第二个坑是框架算子适配不全。部分国产NPU的SDK对llama.cpp的适配停留在特定版本新模型的GQA、RoPE、FlashAttention优化没跟上同一个模型在软件更新前后的速度差能到一倍以上。规避方法是先确认该设备官方支持列表里有没有你想要的模型架构然后锁死框架版本不要在项目中途随意升级。第三个坑是上下文长度带来的显存雪崩。我见过有人把8G显存的设备硬跑7B模型小窗口测试一切正常一上生产环境就OOM。原因很简单8G设备在模型权重之外只剩不到4GB给KV Cache用户多聊几轮就爆。规避方法是在部署前按峰值上下文长度和最大并发数做压力测试不能只跑一个几百字的demo就上线。第四个坑是VLM的隐性开销。视觉模型除了权重比同尺寸文本模型大之外图像转成的视觉token会长期占据KV Cache。一张图几百个token十张图就是几千个token显存消耗远超预期。规避方法是在应用层限制单次对话的图片数量并主动清理历史视觉token。第五个坑是多卡互联带宽不足导致并行效率低。这不是靠软件能解决的硬件拓扑决定了上限。采购多卡设备时务必确认卡间互联走的是高带宽专用通道还是PCIe如果只是PCIe 3.0 x8那双卡跑大模型的意义真的不大。我后来在采购清单里加了一条必须在现场实测双卡并行跑30B的吞吐达不到预期可退货。第六个坑是跨框架数值偏差。同样一个模型在NVIDIA卡上跑FP16和国产卡上跑FP16个别层的结果会有细微差异。大多数任务无所谓但像JSON输出、代码生成这种对格式敏感的任务可能在国产卡上出现莫名其妙的丢标点或括号不闭合。我在交付前会做一轮针对性的回归测试用固定prompt集跑三遍确保输出格式和关键内容一致再放心交给业务方。这些坑看起来琐碎但每一个都真实地耗掉过我大量时间。边缘终端不是服务器它更像是一个精打细算的容器任何一点资源浪费都会被放大。现在回头想想国产化边缘算力终端跑大模型这件事最大的门槛从来不是芯片够不够强而是你能不能把模型量级、显存规划、框架生态和业务场景对齐。我目前的默认方案是7B打底做轻量服务13B做Agent和工具调用30B只在长文档高理解力场景且预算充足时启用双卡方案。这套组合帮我在多个项目里实现了平衡也希望这篇经验能让你少走些弯路。