这阵子大家都在聊大模型聊着聊着风向越来越明显了很多应用不再死磕云端调用而是开始问一句“我的手机、我的本地电脑到底能不能直接跑”。我自己做端侧推理优化也有几年亲眼看着 7B 模型从只能躺在数据中心、到能压在手机里、再到现在 AI PC 上流畅对话这个时间节点确实很有意思。端侧 AI 芯片的窗口期并不是哪一家厂商喊出来的而是算力需求结构变了推理这件事正在从集中式云端往分布式终端迁。这篇文章我想从迁移逻辑、芯片架构需求、实际部署方法和行业竞争几个层面把这事掰开揉碎讲清楚。对大模型不再是“云端专属”这个话题感兴趣的朋友无论是算法工程师、嵌入式开发者、芯片行业观察者还是单纯想在本地跑通一个大模型的好奇玩家这篇文章应该都能帮你补上几块拼图。1. 窗口期从哪里来算力需求的迁移逻辑1.1 云端推理的四个硬伤先聊最根本的问题云端为什么不是万能解药。很多产品把业务逻辑全丢给云端 API体验好坏完全看网络脸色。第一个痛点是延迟尤其对话场景你发一句话token 生成是流式的如果每个 token 都要走一次云端往返用户能明显感觉到“卡”问完一个问题要等一两秒才开始真正吐字吐两句又停一下。单看单次 API 调用延迟可能只有几百毫秒叠加网络抖动、服务排队之后真实体感一下就崩了。第二个痛点是成本。大模型推理是 token 计费越智能的模型单价越高。To C 产品如果日活上了十万、百万云端推理费用直接吃掉毛利。我见过一个工具类产品为了让对话不冷场每天光 token 成本就超过五位数这还没算 GPU 实例的租用费。用户只是问几个问题模型却在云端烧 GPU长期看谁都吃不消。第三个痛点是隐私。现在是个人数据意识非常强的时代聊天记录、文档摘要、医疗影像初筛这些场景用户对自己的数据“出不出设备”极其敏感。把数据上传云端做推理就算合同里写了不保存心理门槛依然在那。端侧推理让数据到模型都在本机天然规避这个问题而且是拿到台面上就能讲清楚的合规故事。第四个痛点是没有网络或者弱网。坐高铁、出国漫游、在偏远现场调试设备遇到断网丢包云端服务再强也没办法。端侧模型一旦部署好就是离线可用这对工业巡检、车载语音、户外助手这类场景是刚需。这四个痛点叠加起来就不是“想让模型下终端”而是“必须让模型下终端”。1.2 什么样的应用真正需要端侧大模型但这里要说句实在话并不是所有模型都应该端侧跑也不是所有用户都能接受端侧体验降级。真正适合端侧的场景要满足三个特征交互实时、数据敏感、模型规模可控。交互最典型的例子是语音助手。我试过在手机上用云方案做语音识别加问答链路长、服务不稳定经常莫名断流。接入端侧五亿参数不到的语音模型后唤醒到响应几乎零感知延迟。数据敏感的代表是文档处理和企业知识库合同、病历、会议纪要这种东西本地摘要、本地问答是硬需求。模型规模可控意思是应用侧本来只需要完成单一能力通常经过蒸馏、量化和裁剪之后几百兆到两三 GB 的模型文件就能承载。还有一个容易被忽略的场景是边缘设备的“语义理解前置”摄像头端侧先做语义过滤再把真正可疑的片段上报到中心云端只需要处理更少的数据。这种场景不是跟云端抢活而是帮云端减负。做端侧大模型最优解往往不是把模型训得越大越好而是在给定芯片算力、内存带宽和功耗约束下把特定任务的效果做到“用户不再抱怨”。1.3 “能跑”和“跑得好”之间的差距聊到端侧部署很多人第一个问题是“这个模型能在我电脑上跑吗”。装个 Ollama拉个 7B 量化模型敲两行命令能聊天了——这是“能跑”。但“跑得好”完全是另一回事。能跑意味着模型推理逻辑没有报错每秒能出一两个 tokenCPU 风扇已经起飞。跑得好考虑的是延迟可控、吞吐稳定、功耗不爆炸、内存占用可控、冷启动时间短、并发请求不互相拉扯。就拿生成速度来说用户跟模型对话每秒两三 token 其实也能忍但做批量文档摘要时每秒出五个 token 和出二十个 token效率差距是肉眼可见的。更隐蔽的差距是“内存墙”。大模型本质上是重访密集型计算一个 token 的生成要把模型所有参数都扫一遍。7B 模型即使量化到 4bit权重存储也接近 3.5GB再加上 KV Cache 和激活值内存占用可能冲到五到六 GB。算力再强内存带宽跟不上就会眼睁睁看着计算单元空转等数据。这也是我们在端侧选择芯片时必须同时看算力 TOPS 和内存带宽的原因。另一个差距在生态支持。能跑可能只是 CPU 硬撑着跑跑得好需要 NPU、GPU 配合推理框架做张量切分、算子融合、内存复用。这些都不是在命令行敲个ollama run就能自动搞定的事需要根据具体芯片、具体框架、具体模型做大量适配。所以判断窗口期是否真的到来不能只看有没有模型跑起来更要看端侧芯片的软件栈是否已经能把模型调度得漂亮。2. 端侧 AI 芯片到底在“卷”什么2.1 CPU、GPU、TPU、NPU 在端侧推理中各自负责什么很多人一看到“AI 芯片”就以为是一块新东西其实手机、PC 里面早就堆了不少处理单元。CPU 大家都熟擅长复杂控制和串行逻辑单核性能强但做大规模并行矩阵乘法效率不高。GPU 本来是图形渲染专家后来因为并行计算能力突出被推到通用计算前线无论是云端的 NVIDIA A100/H100 还是 PC 里的核显都能做通用矩阵运算。TPU 是谷歌提出的专用张量处理器面向 TensorFlow 和自家负载优化在云端做了很多定制化设计。NPU 则是更贴近端侧的神经网络处理单元本质上是一个乘加运算加速器把矩阵乘法、卷积、激活函数这些 AI 高频操作固化成硬件电路用极低的功耗做大量并行计算。在端侧推理工作流里CPU 通常负责调度、内存拷贝和部分不支持算子的兜底GPU 和 NPU 负责吃掉大头——Transformer 结构里大量矩阵乘法和注意力计算如果模型里有图像解码、语音信号处理的非 AI 部分还会用到 ISP、DSP 等专用模块。把这些单元组合起来协同工作是当前端侧芯片设计的关键单看某一个单元的峰值算力没有任何意义。2.2 一块合格的端侧 NPU要从 MAC 阵列和带宽看起NPU 再怎么宣传“AI 算力几十 TOPS”拆开来看最核心的是一堆乘加单元也叫 MAC 阵列。以 4bit INT 精度为例一次矩阵乘法需要对两个向量做乘法和加法这个操作在传统 AI 芯片里是最基本运算单元。峰值算力单位 TOPS 代表每秒能执行多少万亿次整数运算但实际能达到多少受制于阵列利用率、数据搬运效率、算子融合程度。业内现在争论的焦点之一是精度制式。云端主流是 FP16/BF16/FP8而端侧为了省内存、省功耗普遍走 INT8、INT4 路线。量化是大模型落地的关键手段却也考验芯片对低比特数据的支持。早期 NPU 主要服务 CV 模型对 8bit 卷积优化得很透但大模型是 Transformer 结构里面除了普通矩阵乘还有非线性激活、LayerNorm、Softmax、KV Cache 存储这些环节如果 NPU 内置的计算流不支持这些操作就只能频繁跟 CPU 交互性能照样不行。MAC 阵列之外更麻烦的是 NPU 的“memory wall”。我看到很多芯片评测只写“多少 TOPS”不写“多少 GB/s”结果用户实际跑模型时发现NPU 利用率不到三分之一瓶颈在参数和中间结果搬进搬出太慢。真正适合端侧大模型的 NPU需要做到计算阵列端和缓存端之间的数据吞吐足够高且支持多级流水线并行让权重预取、计算、结果写回同时发生。这样模型加载和 token 推理的每一拍都没闲着。2.3 内存带宽才是端侧大模型的第一瓶颈这是很多芯片厂商不太愿意在 PPT 上放大讲的问题。大模型单次推理可以简单理解成每个 token 生成都需要把模型全部参数读一遍。一个大语言模型可能十几 GB 权重假设内存带宽只有 50GB/s那么每秒最多读取 50GB 权重生成一个 token 理论上就算计算完全免费也要 20GB 除以 50GB/s 等于零点几秒实际延迟会更差。我算过一笔账用一张内存带宽约 100GB/s 的普通 PC 平台跑量化后的 7B 模型模型约占 4GB 权重理论上每秒能扫 25 遍参数意味着生成速度极限大约是 25 token/s。如果平台内存带宽只有 30GB/s生成速度就只剩个位数哪怕 NPU 宣称算力再高也救不了。这就是为什么最近端侧推理方案都在卷内存苹果 M 系列统一内存带宽做到了上百 GB/s 甚至两百 GB/s高通骁龙旗舰平台的 LPDDR5X 带宽也拉到 50GB/s 以上桌面级平台更不用说DDR5 双通道已经接近 90GB/s这对 7B、13B 模型来说是还算舒适的区域。说一个更扎心的事实很多手机端侧跑大模型跑不动核心并不是 NPU 不够强而是内存带宽和容量限制住了。这个瓶颈不是靠堆算力就能突破的必须从芯片存储架构入手用大容量 SRAM 做缓存层级、压缩数据搬运量甚至研究模型权重剪枝和激活稀疏性来绕过带宽墙。3. 端侧部署大模型的实操路径3.1 模型选型与量化从 FP16 到 INT4 意味着什么讲完芯片聊点实际能上手的。在端侧部署大模型第一步从来不是选框架而是选模型。7B、13B 这类参数规模是目前端侧的甜点位再大的 70B 级模型即使 4bit 量化后仍有 35GB 以上PC 顶配都吃紧更别谈手机。所以先明确任务复杂度简单对话、信息抽取、意图分类7B 级别足够复杂推理、长文写作、代码生成尽量选同系列的更大参数版本比如 13B、14B或者用推理能力更强的蒸馏版。选定模型后第二件事就是量化。FP16 每个参数占 16bit7B 模型就要 14GBINT8 压到 7GBINT4 压到 3.5GB内存占用差距非常明显。但量化不是一个免费的传送门。INT4 虽然大幅降低存储和带宽需求也会带来模型精度下降尤其在复杂推理、多轮对话、非英语语料场景下模型“变笨”的程度会放大。我自己的经验是能用 INT8 就尽量不用 INT4除非内存实在挤不出空间。对于手机端通常只能 INT4那就必须额外做混合量化——敏感层比如注意力层的 QKV 投影保持更高精度FFN 层用 INT4这样精度损失能压得更低。3.2 推理框架选型Ollama、llama.cpp、AirLLM 各管哪一块框架是端侧落地的另一半。现在最主流的开源推理框架包括三大类Ollama 定位“用户友好”帮你把模型下载、量化格式转换、服务启动全封装好适合快速验证和日常使用llama.cpp 是“硬核工具链”基于 GGUF 格式做了大量 CPU/GPU 混合推理优化适合嵌入式二次开发和深度调优AirLLM 这类方案则主打“在单卡/内存受限设备上也能跑”通过层间换入换出策略实现小内存运行大模型代价是速度慢只适合应急和演示。实际项目中我建议的使用逻辑是这样的最简单的个人体验场景直接 Ollama要在多端统一部署、准备做工具链定制考虑 llama.cpp需要在 8GB 甚至 4GB 内存设备上把 13B、30B 跑起来的极端场景才上 AirLLM 这种 offload 方案如果在云端做高吞吐并发则选 vLLM 这类面向服务化的引擎。这里不做“谁取代谁”的结论因为它们在架构上解决的是不同问题。有人拿 Ollama 和 vLLM 对比其实是错位的Ollama 更适合桌面和本地、快速开箱vLLM 为云端高并发推理而设计擅长 PagedAttention 来管理显存。选型要看场景而不是看谁名气大。3.3 一个 AI PC 本地跑 7B/13B 模型的完整流程拿一台普通配置的 Windows 或 Linux PC 举例CPU 十二代 i5 以上、内存 32GB、没有独立显卡也没关系用核显加 CPU 跑量化后的 7B 模型是可以接受的。整个流程可以拆成五步第一步安装 Ollama。官方支持 macOS、Linux、Windows装好后在终端验证一下ollama --version。然后拉取一个量化模型比如 7B 规模命令行里写ollama run qwen2.5:7b或者模型库中任选它会自动下载模型和标签。第二步确认模型运行状态。简单问一个问题观察首 token 延迟和每秒生成 token 数。这里我强烈建议用ollama ps检查模型是否常驻内存再用ollama serve开启服务用接口性能工具去测并发响应时长别只用聊天窗口的“体感速度”判断。第三步做针对性调优。很多人在默认参数下跑忽略了上下文长度和批处理的影响。大上下文虽然让模型记忆更丰富但 KV Cache 会快速吃内存batch size 加大能显著提升吞吐却会让单请求响应变慢。这个阶段可以根据实际应用在 API 参数里调整num_ctx和num_predict我要提醒的是有些人把num_ctx调到 32K 之后内存占用直接从 4GB 飙到 20GB机器直接卡顿这不叫部署成功叫资源爆炸。第四步接入上层应用。Ollama 默认启动一个本地 HTTP 服务端口 11434。用任何语言写个请求传 JSON 格式的 prompt 就能拿到流式回复。很多 IDE 插件也支持填本地接口地址让编码助手也走本地方案不回传代码到外部云端对代码保密性有需求的团队格外友好。第五步把模型和应用打包成更完整的服务比如加一层鉴权、日志、监控做成团队内可共享的“私人 AI 服务”。如果只是自己验证这层可以先省略。整个流程没有跳到任何外部配置完全本地闭环。跑下来你会对延迟、并发和内存占用有直观感受这时候再回看芯片参数的宣传会踏实很多。3.4 NPU 异构调度的基本玩法在 AI PC 和手机上吃透 NPU是“把模型跑好”的关键一步。异构推理的基本思路把模型里那些计算密集的算子用 NPU 或 GPU 执行把控制密集和少量不支持的算子丢给 CPU框架负责层间调度和数据搬运。以 llama.cpp 为例它支持 OpenCL/Vulkan 等后端能让部分层在 GPU 或 NPU 上执行。实操中把模型层切成几段前几层上 NPU中间层上 GPU最后几层或采样部分留在 CPU。切分比例不是一拍脑门定的要看 NPU 对算子支持度、内存访问时延和带宽然后一遍遍跑 bench 测试微调。有些公司的优化工具能自动做算子级切分效果比自己盲切好很多。真要在手机上做 NPU 低比特推理还需要芯片厂商的 SDK。高通有 QNN联发科有 NeuroPilot苹果有 Core ML / ANE各家能力不一。第一课永远是“先看算子支持表”很多 Transformer 算子没被完全加速强行部署会回退到 CPU 跑最后反而比纯 CPU 慢。对普通开发者来说先用厂商现成示例工程跑通官方支持列表里的模型再替换成自己的微调模型是最稳的路。4. 这波芯片竞争谁在抢谁的窗口4.1 手机 SoC 的集体转向从消费者能感知的层面看今年新发布的旗舰手机 SoC几乎都把“端侧生成式 AI”写进了主推功能。以前芯片厂商宣传像素、刷新率、充电速度现在发布会大段时间给 AI能本地跑几 B 参数的模型、能实现端侧多模态理解、能控制隐私数据不出设备。我最关注的是各家对内存带宽的态度。旗舰 SoC 开始支持 LPDDR5X 高频内存带宽从去年 50GB/s 提到 70GB/s 以上这是让 7B 级量化模型在手机上真正能用的基础。另一个变化是 NPU 架构从“专用于固定 CV 模型”向“可编程性强、支持大算子集合”演进增加对 Transformer 中注意力机制、Softmax、RMSNorm 等算子的原生支持。只有硬件算子和软件库配套了第三方开发者才不愁算子不支持。4.2 PC 端和车载场景的落地节奏如果说手机是端侧 AI 的天然战场PC 则是生产力场景的承接地。AI PC 的概念这两年已经铺开嵌入 NPU 的 CPU 平台越来越多配合大内存、独立显卡或者核显本地跑 13B 模型已经不再是程序员的天方夜谭。AI PC 的意义不只是把模型挪到本地而是跟办公流深度结合本地会议纪要摘要、本地文档问答、本地代码生成规则检查这些在隐私敏感的企业环境里尤其有价值。车载是另一个被低估的场景。车机里的语音助手如果还要联网进隧道、下地库、高速跨区信号切换时体验非常差。把语音识别、意图理解、对话生成全部端侧化离线能用在线也能用这才是“智能座舱”该有的水平。车载芯片环境比手机严苛要过 AEC-Q 可靠性测试、考虑散热和寿命所以整体节奏比手机慢半拍但一旦量产上车需求量是很大的。4.3 窗口期判断哪些卡点还没解决既然说是窗口期就必须知道卡点在哪。当前端侧大模型赛道最明显的问题是——模型规模和场景需求之间的错配。云端模型动辄几百 B 参数能力很强但端侧撑不起端侧能跑的小参数模型智力水平又容易被用户嫌弃。中间的 7B、14B 模型是当前甜点但离“端侧完整体验超过云端”还有距离必须靠模型压缩、蒸馏、注意力机制改良等技术继续拉近。另一大卡点是软件生态碎片化。手机端每个厂商都有自己的 NPU SDKPC 端 Vulkan 支持分布不均AI 框架和芯片之间的“最后一公里”远没有趟平。开发者想做一个跨手机、PC、车载的端侧 AI 应用工作量很大。没有统一、成熟的工具链端侧模型的“可用”离“好用”就有很大距离。算力之外还有功耗和散热问题。手机里跑 7B 模型如果连续对话几分钟机身明显发热NPU 频率一降速度就是雪崩式下跌。芯片设计要做的是在同样功耗下榨出更多有效算力而不是一味堆峰值数字。这个问题不解决端侧 AI 就没有真正“随时随地在用”的体验。5. 常见问题与排查实录5.1 为什么我的本地模型越跑越慢这个问题我遇到很多次几乎每两个端侧部署的开发者就有一个会踩。刚加载完模型时速度不错聊了几句之后明显变慢到后面甚至一个字要等十秒。第一大原因是上下文窗口里累积的 token 太多KV Cache 越占越大每一步生成时都要重新计算与全部历史 token 的注意力计算量随对话长度平方级增长。第二大原因是系统内存不足开始换页交换把模型权重或者其他进程写进 swap速度直接断崖式下降。解决办法很直接限制上下文长度控制在 4096 或 8192 以内运行模型前关闭后台大内存应用通过ollama ps等命令确认模型是常驻显存还是被迫换出动态监控内存占用如果某次对话超过设限长度要么截断历史要么直接重新开始一轮。想要更长上下文还能保持速度就只能换更大内存设备或者更强带宽平台。5.2 内存或显存不足怎么办这里先纠正一个常见误区很多人以为“内存越大越好不够就加虚拟内存”。虚拟内存能保证不崩但大模型推理是极度重量访问的负载内存一旦换页就是灾难级卡顿相当于把“带宽从 50GB/s 降到几百 MB/s”。所以虚拟内存只适合兜底启动不适合日常部署。真正可行的方向有三个。第一是选择更激进的量化比如从 Q8 换到 Q4模型占用大幅缩水代价是精度损失需要在可接受范围内做评测。第二是做部分层 offload主力模型驻留在内存中前几层或中间几层按需加载牺牲少量速度换容量。第三是选择更小的模型如果业务场景本身不需要 13B降到 7B 或者 1.5B 级别内存压力瞬间消失。有个取巧的办法是使用量化感知的模型剪枝和蒸馏后的模型例如只保留特定任务能力的版本参数体积能进一步压缩到 3B、4B对端侧友好很多。5.3 端侧还是云端我的五点判断清单每次同行问我“项目到底该端侧还是云端”我都让 TA先过一遍这个决策清单基本能滤掉大半伪需求判断维度倾向于端侧倾向于云端交互延迟强实时要求剪不断网可接受网络往返无强实时数据隐私内容敏感禁止出设备数据脱敏后可共享成本模型终端算力已支付边际成本低按 token 付费量大成本高网络条件弱网、离线场景常见网络稳定模型规模需求任务单一7B/14B 够用需要百B级复杂推理或长上下文但这个清单不是永远固定。比较典型的组合拳是端侧跑轻量语音助手快速响应用户识别意图后发现请求需要深度推理就把脱敏请求升级到云端大模型。这叫端云协同未来很长一段时间这都会是主流产品架构而不是非此即彼。5.4 端侧新品体验前的三个体检项目拿到一块新的端侧芯片或者新的开发板我建议先做三个测试别急着看跑分软件。第一实测一款量化大模型每秒生成 token 速度。别看理论 TOPS直接跑 Llama 3.2 或 Qwen 系列 7B Q4 模型记录 prefill 速度和 decode 速度这两个值分开记不要只记“生成速度”。第二测多轮长对话稳定性。让模型连续做 30 轮对话上下文累计到一定长度后看推理速度、发热、掉电情况。有些设备前几分钟正常热起来就不行这个测试很能反映真实水平。第三测 NPU 算子覆盖度。拿几个不同结构的模型比如带视觉编码器的多模态模型、纯文本模型、带工具调用的模型分别跑一下看哪些算子在 NPU 上顺利执行、哪些回退 CPU。如果回退比例高说明这个芯片对大模型场景的适配还不到位窗口期对它来说尚未来临。我自己实测过几款不同的终端芯片最直观的感受是真正拉开体验差距的不是“能跑多大的模型”而是“能不能长时间稳定输出、热降频曲线是否平缓、算子支持度是否齐全”。这些指标比发布会那张峰值算力表格诚实得多。这项工作中最让我感慨的一点就是端侧 AI 芯片从来不只是芯片本身的事它背后是存储技术、编译器优化、模型压缩、算子演进一起在往前赶。窗口期的“窗”可能只开两年三年谁能在软硬协同上先跑通闭环谁就能在这些新终端上站稳位置。从投入产出的角度我觉得现在正是动手实测一代端侧硬件、在自己业务场景里找到确定性价值的最好时机。踩过几次坑之后你会发现真正值钱的并不是那个纸面最高的 TOPS而是能把模型流畅、稳定、可控地跑在用户手里的整套能力。