1. 先聊点实际的为什么你会在乎一台能跑大模型的边缘终端最近帮客户做边缘节点选型从7B小模型一路测到30B踩了不少坑。这片文章就想把国产化边缘算力终端的推理性能、显存占用和选型思路一次性说清楚免得后来人再走弯路。标题里提到的“7B-30B LLM/VLM”说白了就是现在边缘设备上最常跑的几档大模型7B上下的小模型适合端侧问答和文档摘要13B左右能兼顾效果和资源20B到30B则要开始跟显存、算力和框架生态较劲。先说个前提边缘算力终端不是什么新物种。以前大家叫它智能盒子、AI工控机、推理模组本质上都是把一块带NPU或GPU的板卡放进一个紧凑机箱在靠近数据源的地方做推理。但大模型时代把它逼上了另一个维度——过去跑个YOLO检测、语音识别只要几百个算子、几百MB模型就够了现在要跑LLM参数动辄几十亿KVCache要跟着序列长度线性增长输出是自回归的一个token一个token蹦出来的。这对整机的内存带宽、内存容量、NPU显存、算子覆盖度都提出了完全不同的要求。我见过很多项目在启动时会想当然“既然云端能用A100跑70B那我边缘盒子跑个7B总没问题吧”真跑起来就发现不是卡在速度就是卡在内存甚至卡在某个算子根本不支持。所以这篇文章不是写模型怎么训练的而是写怎么在一台国产边缘终端上把模型跑稳、跑快、跑不OOM以及到底应该怎么选一台合适的设备。适合的设备选型工程师、算法部署工程师、项目甲方以及所有想在本地端侧塞一个大模型的朋友。2. 推理性能纸面算力和真实吞吐之间的鸿沟2.1 先把度量衡统一tokens/s、TTFT和并发用户选型时第一个坑就是看厂商宣传的死算力。国产芯片的TOPS标得非常夸张但那些数字大多是在固定稀疏度、固定批量、极低精度下跑卷积网络测出来的。到了Transformer这种大模型场景标称算力根本没法直接换算生成速度。所以我一般只看三个指标首token延迟TTFT、生成速度tokens/s、以及并发吞吐。TTFT决定了用户感受到的“反应快不快”在边缘场景往往更重要。你问一个7B模型“今天天气怎么样”如果4秒才吐出第一个字哪怕后续每秒生成30个token体验也是灾难。TTFT主要受预填充阶段影响也就是把用户输入的prompt一次性灌给模型的过程。这个阶段是密集矩阵乘走的是算力和显存带宽而后续逐token生成阶段则极度依赖内存带宽因为每个token都要把整个模型参数再过一遍。所以边缘终端选型的核心往往不是“算力有多强”而是“内存带宽有多大”。生成速度tokens/s是最直观的指标但单路测速容易被误导。我实测过一个国产边缘盒子单用户跑Qwen2.5-7B量化模型能到18 tokens/s左右看着还行但一旦并发拉到8个用户有些底层实现没有做Continuous Batching显存直接按8份KVCache预分配速度掉到5 tokens/s以下甚至直接OOM。所以选型时一定要问清楚推理框架有没有做动态批处理而不是只看官网的“单路峰值”。2.2 精度和速度的兑换表FP16、INT8、INT4之间怎么选现在边缘端跑LLM量化已经不是可选项而是必需品。一个7B模型FP16权重就要14GB对大多数边缘终端来说实在太胖INT8可以压到7GB左右INT4GPTQ/AWQ等只需要3.5GB上下。但量化从来不是无代价的同一台设备上模型越小内存带宽压力越小生成速度通常越快代价是生成质量可能下降。尤其对代码、数学这类对数值敏感的任务4bit量化可能会让逻辑错误率上升一截。我自己的使用经验是如果任务是通用对话、摘要、分类INT4完全能接受如果任务涉及复杂推理、数学题、代码生成优先尝试INT8如果边缘终端内存足够大比如64GB就直接上FP16/BF16省得在效果排查时还要怀疑量化误差。不过量化带来的速度提升并没有想象中那么大——LLM单token生成很快但吞吐瓶颈往往是内存带宽和NPU利用率而不是参数尺寸。INT4更多是为了解决“放不放得下”的问题而不是“跑得快不快”的问题。不同芯片对量化格式的支持也不同。有些国产NPU对INT8做过深度优化速度接近甚至超过同尺寸FP16但有些对INT4支持极差虽然推理框架支持实际会先反量化回FP16再计算内存没省多少还慢了。所以不要机械地看“位宽越小越快”必须实测。选型阶段至少要准备一条INT8和一条INT4的实测结果否则后面部署很容易翻车。2.3 单路快不代表并发快边缘端并发的隐藏成本边缘终端的一个典型场景是“几十个人同时访问一个本地的知识库问答”这就注定了并发是绕不开的话题。云端GPU可以用vLLM、TensorRT-LLM这类框架做连续批处理把不同用户请求拼在一个batch里提高GPU利用率。但在国产边缘端很多厂商的推理引擎还是早期版本要么不支持动态批处理要么支持得比较粗糙。有一个细节容易忽略并发数越高KVCache占用越大。假设一个7B模型上下文长度设为4096单用户只需要给KVCache预留每层几十MB但10个用户同时在线KVCache可能要预留几个GB。如果把max_seq_len设成8192甚至32K分分钟把内存吃满。所以我选型时有个习惯先想好“最大并发用户数”和“最大单用户上下文长度”然后用这两个数字去反推需要多少内存这比看模型参数量还重要。后面章节我会专门写显存怎么算这里先记住一个结论——模型权重只是起步KVCache才是那个能把终端“吃破产”的后续开销。3. 显存占用比你想象中更容易爆3.1 模型参数占多少从7B到30B算一笔账很多朋友第一次跑大模型都会问“我买了个32GB内存的盒子总该能跑7B吧”结果一部署就OOM。原因就是只算了模型权重没算其他开销。我们先只算权重部分参数量的字节数取决于精度。FP16/BF16下每个参数占2字节INT8占1字节INT4严格说不是整数个字节通常按0.5字节估算。所以7B模型的权重占用大约是FP167B × 2B 14GBINT87B × 1B 7GBINT47B × 0.5B 3.5GB同理13B模型FP16约26GBINT8约13GBINT4约6.5GB30B模型FP16约60GBINT8约30GBINT4约15GB。但这只是“模型权重”离“能跑起来”还很远。边缘终端有系统内存往往还要跑容器、推理框架、持久化数据库、消息队列等其他服务这些都要从总内存里分一杯羹。所以我之前给客户做方案时会先按“额外预留20%~30%内存给系统”来打折。以一台标配32GB内存的终端为例如果跑7B模型INT4权重仅占3.5GB看起来很宽裕但再加上系统、推理框架、KVCache和输入图像缓存实际可支配空间可能只剩20GB出头。可如果你已经想跑30B INT4就危险了——权重15GB还没算上下文32GB内存已经捉襟见肘。这也是为什么很多号称能跑30B的盒子实际只敢配16GB上下文而且只能单用户跑。内存容量是不是足够永远是第一道门槛。3.2 KVCache才是压垮内存的那根稻草KVCache是Transformer推理时为了缓存历史token计算出来的Key和Value而开辟的空间。它不是固定不变的而是随着序列长度线性增长。模型越大、层数越多每增加一个token就要写入一次KVCache。我以前写过一个估算式子KVCache大小约等于“层数 × KV头数 × 注意力头维度 × 2K和V× 序列长度 × 字节数”。这个数算出来往往让人惊讶。举一个具体例子Qwen2.5-7B模型28层使用GQAKV头数为4每头维度128。那么每生成一个token每层KVCache占用为2K和V× 4KV头× 128维度× 2字节约2KB28层就是约56KB。听起来一个token才56KB但如果上下文长4096就是约224MB如果长32K就是1.75GB。这还只是7B模型。如果你用13B甚至30B模型层数更多KV头数也可能更多32K上下文下KVCache可能突破4GB甚至8GB。所以我现在看到有人想在边缘终端跑长文档分析第一反应就是问他有没有算过KVCache。更麻烦的是很多国产推理框架在分配KVCache时会按max_seq_len预分配全额内存而不是按实际使用量动态增长。也就是说哪怕你当前只处理一段200字的对话框架也已经按4096序列长度把几百MB内存圈走了。这种实现方式的好处是稳定、避免运行中申请内存失败坏处就是内存利用率极低。好在现在一些框架开始支持PagedAttention或类似机制按页分配KVCache能显著缓解浪费。但选型时你必须问清楚否则就会出现“32GB内存只敢设2048上下文”的窘境。3.3 激活值、视觉编码器和框架碎片才是真正的“隐藏开销”除了权重和KVCache还有三类占内存的东西容易被忽略。第一是激活值虽然推理阶段不像训练那样要存中间梯度但Transformer每一层的前向计算仍然会产生张量尤其是在预填充阶段处理长prompt时激活值可能达到几百MB甚至上GB。第二是推理框架自身的显存池很多框架为了减少重复分配会预申请一块大的内存池比如PyTorch的CUDA caching allocator在边缘NPU上也有类似机制这部分内存看起来是“空闲”实际已经被框架锁定了。第三是运行在CPU上的系统服务使用统一内存架构的芯片比如瑞芯微、部分算能芯片NPU和CPU共享内存系统一旦吃内存NPU能用的就更少。如果你是跑VLM视觉语言模型还要额外算视觉编码器的开销。VLM模型不仅仅是一个LLM它前面还挂着一个视觉塔ViT或类似结构。一张图片会被切成几十甚至上百个视觉patch每个patch都会变成若干个token再送入语言模型。以Qwen2-VL这类模型为例一张普通图片产生的视觉token数量可能在几百到上千高分辨率图片或者视频帧序列则会更多。这些视觉token同样占用序列长度和KVCache而且视觉编码器本身也要吃不少内存。所以在边缘终端跑VLM显存占用通常会比同参数量纯文本模型高出一截。选型时别只看“7B VLM”要问清楚支持输入几张图、能处理多长视频、最大分辨率是多少。4. 国产化芯片的现状与选型关键点4.1 市面主流方案到底能跑哪一档模型国产化边缘算力终端背后的芯片方案五花八门但按生态和算力能大致分几类。一类是深耕AI推理多年的老牌选手比如昇腾系列、寒武纪思元系列它们在中高端边缘设备上很常见通常有16GB、32GB甚至更大内存适配自家的推理引擎后7B到30B模型都有机会跑这类芯片的优势是算子覆盖相对完整、工具链成熟度高劣势是上手有学习曲线官方推荐配套的推理框架和你在网上看惯的PyTorch/Llama.cpp套路不完全一样。另一类是更偏端侧的SoC方案比如瑞芯微RK3588、算能的部分低功耗模组等主打低成本低功耗内存通常是8GB或16GB。这些平台跑YOLO、人脸识别很溜但跑7B LLM会比较吃力。RK3588这类平台即使量化到4bit勉强塞下7B模型生成速度也可能只有个位数tokens/s因为它的NPU设计并不是为大模型自回归生成的超大访存带宽服务的。如果你只是做概念验证可以这么玩要是真做面向用户的问答系统最好还是老实选中高端AI模组或者整机。但这里要特别说明国产芯片更新迭代非常快具体型号的算力、内存支持能力、框架适配情况可能你读这篇文章时和我测试时已经有差异。所以我不会给出“某某芯片一定能跑多少速”这种结论而是给一个可以复用的判断框架。关键不是记参数而是学会问对问题、做对测试。4.2 选型五步法先定模型再定内存然后看算子兼容我给客户做选型时一般按这五步走免得被厂商宣传带偏。第一步明确要跑什么模型档位。如果只要7B纯文本那么16GB内存的终端基本够用如果要13B且想跑较长上下文建议32GB起步如果要20B以上直接看64GB甚至更大的方案。模型选型是牛鼻子一定要先定。第二步反推显存需求。用我们上一章说的公式把权重、KVCache、视觉编码器、系统预留四部分都算一遍留出至少20%余量。这里的KVCache要按最大并发用户数和最大序列长度计算不要只看单用户。第三步确认关键算子是否支持。LLM的算子无非就是矩阵乘、Attention、RMSNorm、SwiGLU、RoPE这些。绝大多数芯片的成熟SDK都能支持90%以上但总有一两个特殊算子缺失比如某些激活函数的新变体、GQA优化、或者量化时的Group Size。如果模型里用了最新架构比如Mamba、混合专家模型就要格外谨慎。第四步看推理框架和生态。厂商有没有提供类似vLLM的连续批处理方案支不支持开源的GGUF格式能不能方便地从PyTorch模型转换如果只能跑一个定制好的静态模型那你的灵活度就大打折扣。第五步必须实测真实业务数据。不要用官网跑通的一个小测试demo当结论。我每次选型都要求供应商提供两个数据指定模型在指定并发下的生成速度以及连续压测4小时之后的内存曲线。这两个数据做过测试和没做过测试差别很大。4.3 生态兼容是最大的隐性成本很多项目在选型时只看硬件规格却忘了算“生态迁移成本”。你在云端用惯了各种开源推理工具链到了国产芯片上可能要换一套。有些厂商提供了很好的运行时兼容层能直接支持PyTorch导出的ONNX或TorchScript有些则必须用他们的模型转换工具重新转换。转换过程中最容易出的问题就是算子不支持这时要么改模型结构要么等厂商更新SDK时间完全不受你控制。另一个隐性成本是“容易被网上主流教程抛弃”。现在开源社区默认的推理方案都是基于NVIDIA CUDA生态的你拿着Llama.cpp在本地编译时默认不会去适配国产NPU。如果某个国产终端只能在官方闭源引擎下跑那你在部署、调优、排查问题时就非常依赖厂商技术支持。这本身没问题但要预留沟通和学习时间。所以我给所有项目团队的建议是不要把“能跑通”当成“能落地”。跑通一个静态导出的模型到能稳定对外提供服务中间隔着并发、动态输入、容错、监控、更新每一步都可能踩到生态坑。选型时把“技术团队多快能上手”也算进成本往往比单台设备便宜几千块更重要。5. 实操测试记录在一台国产边缘终端上跑7B/13B/20B模型5.1 环境准备和部署工具链为了写这篇文章我又专门在一台国产边缘终端上跑了一轮测试。设备是32GB统一内存的方案芯片不具体说了免得像带货大家可以类比同类产品。系统是常见Linux发行版部署工具链依赖厂商提供的推理引擎。我用的模型都是开源权重Qwen2.5-7B、Qwen2.5-13B的对话版以及一个20B左右的MoE模型外加一个7B级VLM做多模态验证。第一步是刷好系统、装好驱动然后用厂商提供的容器镜像。这里有一个经验尽量用官方给的深度学习运行时镜像不要自己到处装包。国产芯片的编译器、算子库、运行时通常和特定版本的Python、torch绑定很紧你心血来潮把环境升级一下很可能把已经调好的算子库搞挂。我吃过大亏所以现在固定做法是“先看官方支持矩阵再决定能不能动环境”。第二步是准备模型文件。大部分国产推理引擎支持从Hugging Face格式转换但转换脚本的入口参数各有坑尤其那套“trust_remote_code”逻辑模型结构里有些自定义类必须依赖官方代码加载。我建议先把模型跑在标准PyTorch环境下验证权重没问题再进转换流程否则会把模型转换的报错和推理引擎的报错混在一起非常难排查。5.2 7B模型实测唱主角的小钢炮先跑Qwen2.5-7B用INT8量化。权重约7GB预填充阶段设置最大序列长度4096KVCache按最大预留大概占用0.3GB到0.5GB再加上系统和框架池32GB内存在这个配置下非常从容。实测单用户生成速度大概在15到20 tokens/s之间具体看输入长度和系统负载。对于内部知识库问答、工单分类、文本摘要这类场景这个速度已经能满足日常使用。当然单用户测速不能当饭吃我又压了16个并发模拟“全员提问”场景。这里就看出框架支不支持动态批处理的分水岭了支持得好的框架虽然单个用户速度会降到10 tokens/s左右但总吞吐能到150 tokens/s以上支持得差的框架一个用户抢到全部资源其余用户排队总吞吐上不去而且KVCache内存还会预分配16份直接把内存干爆。所以如果你买这台设备就是为了团队用建议带着并发测试工具去验收。一个小技巧如果你只需要低延迟把batch size限制为1让推理引擎不要强行拼批。如果更看重吞吐允许批处理但调低最大上下文长度把省下的KVCache留给更多用户。这两个参数就像天平两端要按实际业务场景反复调。5.3 13B和20B模型显存吃紧时该牺牲什么接着我把Qwen2.5-13B INT8换上权重约13GB配上KVCache和系统开销32GB内存就开始有压力了。最大序列长度4096时KVCache占用比7B大不少因为层数更多、注意力计算规模更大实测单用户生成速度降到10 tokens/s出头。如果再把单用户上下文拉到8192内存占用明显上涨这时候就不得不把部分层offload到CPU速度会进一步下降。20B MoE模型更实在有趣。MoE模型虽然总参数量很大但推理时只激活部分专家所以实际算力和内存占用低于同规模的Dense模型。我用一个20B级MoE的4bit量化版本权重只有10GB左右跑起来速度比13B Dense模型还快效果也比13B好。这就引出一个选型思路在内存和算力有限的情况下优先考虑量化后的MoE模型往往比硬上大号Dense模型更划算。不过MoE模型的KVCache还是要按完整层数算如果上下文设得长内存优势会被抵消一部分。这个阶段我开始纠结“到底牺牲什么”。如果目标是跑20B以上模型32GB内存真的只是“勉强及格”。我通常建议要么把量化降到4bit要么把最大上下文砍到2048要么干脆换64GB内存终端。三者之间先保哪个我的排序是保模型效果优先其次保上下文长度最后才考虑并发数。因为对大多数业务来说模型回答质量差是硬伤长文档处理是刚需并发数可以通过负载均衡横向扩展来解决。5.4 一个VLM例子多模态模型的特殊显存需求最后我测了一个7B级VLM模型。把一张1080P截图丢进去模型先跑视觉编码器把图片转成一段视觉token序列再交给语言模型生成回答。这个过程中我发现显存占用比纯文本7B模型多了一大截。视觉编码器本身就是一个不小的模型加上图像token的KVCache整体内存峰值比同尺寸纯文本模型大概高出2GB以上。如果你要处理视频或者一次丢多张图这个开销还会成倍增加。所以给VLM选型时我建议把“最大图像数量”和“最大视频帧数”纳入需求清单。不要只说“我们有个多模态问答需求”而是要说“要能同时处理5张图每张图分辨率不超过1080P上下文长度8192”。这样选型人员才能准确估算内存。另外一个更隐形的坑是很多国产推理引擎对视觉编码器的优化程度不如语言模型同样的VLM在不同芯片上的速度差异非常大实测中必须单独测“图片输入到第一个文字输出”的时间而不是只测文字生成速度。6. 常见问题与排查技巧6.1 “明明内存够怎么还是OOM”的排查路径这是所有模型部署新手最常问的问题。先说结论绝大多数“离谱OOM”都是KVCache惹的祸。你可以用一段简单的测试先把max_seq_len调到最小比如256看模型能否跑通再逐步往上加同时用nvidia-smi或厂商提供的监控工具观察内存曲线。如果内存随着上下文长度增加而线性增长基本就是KVCache预分配导致的问题。这时优先考虑开启PagedAttention或者KVCache量化如果都不支持只能容忍较低的上下文上限。另一个常见原因是框架的内存池没释放。有些推理引擎在加载第二个模型或重新加载模型时不会即时释放上一次的内存池。如果你在同一台终端上反复切换模型做测试很容易出现“内存越跑越少最后重启才恢复”的现象。这种问题我不是通过调参解决的而是直接在部署脚本里加了模型加载前置自检每次切换模型前强制清理缓存并在监控里设置内存超限自动重启。6.2 模型转换成功但推理时报算子不支持的应对思路在国产芯片上部署最经典的就是“PyTorch模型在GPU上能跑转到NPU上报错”。报错信息往往模糊比如“unsupported op: XXX”。我的排查顺序是这样的第一看报错日志里是哪个算子然后用Python脚本单独构造一个小输入去调那个算子确认是算法问题还是SDK问题第二去官方文档或更新日志里查这个算子是否在最新版本中已支持如果支持就升级SDK第三实在不支持就考虑修改模型实现把这个算子替换成等价的算子组合。比如某些模型里的Rotary Position Embedding实现很复杂你可以先用大佬们写好的融合版算子往往能绕过去。最后的选择才是换模型毕竟换模型意味着重新评估效果。这里还有个体感很深的建议国产芯片的算子支持矩阵更新频繁你踩到一个算子不支持可能过三个月再看已经解决了。所以排查问题时养成记录“芯片型号 推理引擎版本 模型版本 报错信息”的习惯否则升级之后报错会变排查更难。有个客户项目就是靠这种记录从一个月搞定算子适配后来几天就升级完版本搞定。6.3 部署到生产前至少要做完这三项测试我见过太多项目在Demo阶段跑得飞快一到生产就翻车于是总结了一份“上线前三测”。第一是长稳测试用业务真实数据连续运行至少24小时观测内存和速度的衰退曲线。很多国产推理引擎在早期版本存在内存缓慢泄漏的bug短时间测不出来跑一天之后直接吃满内存。第二是并发压测用至少50个模拟用户同时访问观察吞吐和延迟的P99指标。第三是断电重启测试边缘终端往往会装在工控柜里偶尔断电是常态。确保断电后服务能自动拉起模型能正常加载不需要人工介入。这三项都过了我再敢把设备交到客户现场。实践下来能过这三测的终端和设备选型上基本不会跑偏。最后分享一个小经验别迷信“越大越好”。我在实际选型中见过不少项目一上来就想跑30B结果成本、功耗、散热全都要翻倍而业务效果和13B相比提升没那么明显。先把业务问题定义清楚把模型压到刚好能完成任务的最小规模你会发现边缘选型突然简单一大截。有时候一台跑7B模型跑得又快又稳的终端比一台硬撑着跑30B但经常超时、经常OOM的终端能为业务创造的价值高得多。