1. 2026 年 AI 的算力重心凭什么一定要往设备端挪过去两三年大家习惯了这样一种分工大模型住在云端手机和电脑只负责上传请求、渲染结果。打开一个智能助手语音要先传上去等一串文字传回来拍一张照片也要先传上去再等一段描述传回来。这套模式在 2023 年还让人觉得很有“未来感”但放到 2026 年适用范围已经肉眼可见地在缩小。原因不复杂真正高频的 AI 交互已经等不了网络往返了。这个转向背后有一个非常硬的技术支点端侧推理运行时必须成熟到可以流畅执行大语言模型。Google 的 LiteRT-LM 就是这条赛道上目前最值得拿出来拆解的候选方案它专门为手机、平板、车载设备、嵌入式设备上的模型推理而生。与此同时GPT-5 的传闻几乎每隔几周就会冒出新版本真真假假的消息满天飞。这两件事一个发生在设备端一个发生在云端看起来是两条线实际上是同一次大模型范式转折的两端。我在本篇里想聊清楚三件事LiteRT-LM 到底解决了什么底层问题GPT-5 这类云端大模型的进化又会如何反哺端侧的小模型以及站在 2026 年做实际项目时云边端三层应该怎样分工才不落伍。如果你正在做端侧 AI 方案选型或者只听说过大模型、想搞清楚“端侧到底能干什么”这篇内容应该能省下你不少查资料的工夫。1.1 云端模型不是太慢是端侧场景等不起先说一个反直觉的观察云端大模型本身并不慢真正的瓶颈是网络和排队。一个几千亿参数的模型在数据中心里生成一个 token 的时间可能只需要几十毫秒但音频要上传、请求要排队、结果要下传整个过程叠加下来首字延迟经常冲到 800 毫秒到 2 秒。如果是轮询式的语音对话用户勉强能接受一旦涉及驾驶、工业控制、医疗急救这类无法容忍延迟的场景云端方案从架构上就不成立。我拿自动驾驶舱内交互举例驾驶员说“帮我找一条避开拥堵的路”这句话如果拆解成语音识别、意图理解、路线生成三个环节任何一个环节丢去云端都会增加不可控的往返时间。车载端如果有一个 2B 参数左右的本地模型可以在 100 毫秒内完成意图理解再只把地址解析这类必要操作抛给云端整体体验就会从“卡顿”变成“跟手”。更极端的例子是工业视觉质检。高速流水线上一个零件从摄像头前经过的时间只有 200 毫秒左右云端推理就算性能再强也不可能覆盖这个节奏。把模型压缩到可以在设备端完成检测是唯一说得通的做法。这个逻辑同样适用于监控摄像头、智能门锁、可穿戴健康设备。所以“边缘计算”在 2026 年不再是概念上的补充而是很多产品能不能落地的先决条件。它不需要在综合能力上超过云端大模型只需要在特定任务上足够快、足够稳、成本足够低。这正是 LiteRT-LM 这类运行时被推向前台的根本原因。1.2 隐私、带宽和账单三顶帽子往本地扣除了延迟还有三个现实问题把算力往本地推。第一是隐私。健康数据、车内语音、企业内部文档这些信息很多在合规层面根本不允许直接传到云端。即便技术上可以加密传输审计和授权流程也会拖慢产品迭代。在本地处理完敏感数据只把脱敏后的结果上传这是技术选择更是合规刚需。第二是带宽。视频流、传感器流、多路音频如果全部上传云端每个月产生的流量费用相当可观。一个园区部署几十个摄像头如果每一路视频都靠云端做大模型分析带宽账单会比芯片成本还吓人。在端侧先把视频压缩成“正常”和“异常”两个事件描述再决定要不要传云端带宽消耗可以降一个数量级。第三是成本。云端 token 计费模型适合低频、高价值的请求不适合高频、低价值的日常交互。一个手机助手如果每个操作都消耗云端 token厂商的运维成本会迅速失控。端侧模型虽然能力弱一些但边际成本几乎为零——只要模型已经装进设备跑多少次都不再按 token 计费。2. LiteRT-LM 的“硬核”之处一个专门伺候大语言模型的端侧运行时很多开发者其实没有区分清楚两个概念LiteRT 和 LiteRT-LM。LiteRT 的定位是通用端侧推理运行时它继承了此前 TFLite 时代的扩展包生态能跑图像分类、目标检测、语音识别这类中小模型。而 LiteRT-LM 是专门为语言模型设计的运行时面向的是几亿到几十亿参数的模型目标平台是手机、平板、智能座舱、嵌入式设备。它不是简单地把一个大模型塞进手机里而是把语言模型推理过程中最折磨人的那些底层问题全部接管过去。为什么这件事重要因为在 LiteRT-LM 出现之前想在移动端跑一个像样的 LLM开发体验非常痛苦。主流方式要么是拿 C 手写推理内核要么是套一个不支持动态形状的推理框架一旦输入长度变化就得重新构图、重新编译。这种工程量根本不是普通应用团队能负担的。LiteRT-LM 的意义在于它把“在端侧跑 LLM”从研究院课题变成了应用开发者的普通依赖。2.1 从 LiteRT 到 LiteRT-LM不只是改了个名字简单回顾一下这条线。Google 在移动端推理领域做了很多年迭代最初的 TensorFlow Lite 奠定了算子库、模型转换、移动端加速器接入的基础后来更名为 LiteRT形成了更统一的跨平台运行时。再往后语言模型成为主流需求官方把 LLM 推理单独拆出来做了一层面向大语言模型的运行时这就是 LiteRT-LM。它和通用 LiteRT 共享底层算子、内存管理、硬件抽象但针对 Transformer 架构做了大量定制。这个拆分非常重要。通用推理框架的目标是“包罗万象”图像、音频、文本什么都能跑语言模型推理则需要处理截然不同的访问模式自回归生成、KV Cache、动态序列长度、连续批量调度。把它塞进通用框架里会让框架设计变得极其臃肿。单独建一层就能把注意力机制、缓存管理、采样策略这些事做深做透。LiteRT-LM 在架构上还沿用了一个理念模型不是“一个文件”而是一个目录里面包含权重、分词器、配置项和可选的草稿模型。这种 bundle 结构比单个模型文件更接近真实部署需求。因为端侧模型的迭代频率很高今天换一个分词器明天换一套量化方案如果用单一文件每次都要全量替换非常麻烦。目录化之后升级权重、替换 tokenizer、调整 sampling 参数可以互不干扰。2.2 动态形状、KV Cache、投机采样三件套解决了什么我不打算把这部分写成 API 文档只讲三个决定端侧 LLM 能不能用的硬骨头。第一个是动态形状。语言模型的序列长度每生成一个 token 都在变这是天然动态的。服务端推理框架通常可以把请求 pad 到固定长度牺牲一点显存换调度简单端侧内存本来就紧张不可能给你 pad 到满。LiteRT-LM 的做法是在运行时动态规划内存根据当前序列长度调整激活值缓冲区和算子执行计划避免为最坏情况预留资源。第二个是 KV Cache。自回归模型每生成一个 token都要保留之前所有 token 的 Key 和 Value 向量。上下文越长缓存越大。很多简单移植的推理引擎会按照最大上下文长度一次性预留整块缓存比如配置 4096 就预留 4096结果是模型参数才占 2GBKV Cache 反而把内存吃光了。LiteRT-LM 借鉴了服务端框架的做法把缓存按页管理用多少、分配多少。上下文从 128 增长到 1024缓存只是多申请几页而不是从一开始就吃满峰值。第三个是投机采样。这个方法这两年很火本质上是拿一个小模型当“草稿员”先快速猜出接下来三五个 token再让大模型一次性验证。猜中的 token 直接通过猜不中的部分重新来。端侧 LLM 最痛的点是生成太慢投机采样能把生成速度提升 1.5 到 3 倍。有人以为它减少了计算量其实不是它只是把串行的 token 生成变成了并行的批量验证用更多的有效计算换更低的延迟。这对端侧尤其合适因为端侧算力有富余但无法像服务端那样靠 GPU 批处理来解决单请求延迟。这三件事以前都要开发者自己造轮子现在被收进运行时直接面对业务逻辑就行。这也是我认为 LiteRT-LM 真正“硬核”的地方。3. 大模型进化的两条暗线压缩变小以及云端“主脑”与端侧“副脑”的分工把视野从设备端拉回大模型本身。2026 年的大模型竞争已经和两三年前的“参数军备竞赛”完全不是一回事。行业内更关心的不是谁能堆出更大的参数量而是谁能把同一个智能水平用更小的规模、更低的推理成本表达出来。这背后有两条清晰的演进路线第一条是压缩把一个大而全的云端模型蒸馏、量化成一个适合端侧部署的小模型第二条是分工让云端模型当“主脑”负责复杂推理让端侧模型当“副脑”负责高频、实时、私密的简单任务。LiteRT-LM 承接的是“副脑”的落地GPT-5 的传闻则让我们更清楚地看到“主脑”会往哪个方向演进。3.1 蒸馏、稀疏、低比特把云端大模型压缩成端侧可用规模的三大法器模型压缩发展到现在已经有一套成熟的组合拳。单独用任何一个都有极限组合起来效果最好。知识蒸馏是最常见的起点。流程是用一个几十亿甚至更大规模模型去标注海量数据然后训练一个几亿到十几亿参数的学生模型学习教师模型的输出分布。蒸馏和普通微调最大的区别在于它不用硬标签用教师模型输出的概率分布当“软标签”让学生模型不只是背答案而是学习教师模型的“犹豫方式”。所以现在手机上的模型已经能做文档摘要、代码解释、角色扮演靠的绝不是把大模型直接缩小而是背后有一整套蒸馏产线在持续生产数据。稀疏化处理的是模型里的冗余连接。大模型训练完之后大量参数贡献很小可以置零。部署时跳过这些连接理论上可以大幅降低计算量。但我对端侧用稀疏化一直持保留态度CPU 上需要专门的稀疏算子库NPU 上更依赖芯片是否支持收益不匹配复杂度。如果你不是对推理内核和硬件细节非常熟第一版部署不建议上稀疏化先老老实实用量化和蒸馏解决 80% 的问题。低比特量化是最能看到直观收益的一步。FP32 压到 INT8模型体积缩小四倍再压到 INT4体积缩小到原来的八分之一。端侧模型现在普遍走 INT4 路线配合 AWQ 或 GPTQ 这类量化算法以及校准阶段的逐层误差补偿精度损失其实没有想象中严重。让我给个具体体感一个 3B 参数模型FP16 格式约 6GBINT4 格式约 1.5GB内存占用差距达到 4 倍。后者才能在手机和车载设备上流畅运行。3.2 GPT-5 传闻里真正会传导到端侧的红利是什么关于 GPT-5我不想讨论它是多少参数、什么时间发布、名字到底是不是叫这个。这些只是新闻不是技术。真正值得关注的是它背后代表的“推理式模型”趋势。从目前已公开的行业讨论来看下一代云端模型的重心会从“更快地生成”转向“更准地推理”。模型在回答复杂问题之前会在内部产生更长的思维链先拆解问题、再分步骤验证、最后给出结论。这带来的第一个副产品是一批更高质量的“思维样本”。这些样本蒸馏到端侧小模型里之后端侧模型就不再只是“接话”而是也能模仿出有结构的推理过程。你会发现端侧模型虽然不能像云端模型一样思考一个晚上但面对日常问题时的条理性会明显好于上一代。另一个传导路径是端侧和云端的“师徒关系”。未来理想的形态是端侧模型负责快速响应和隐私保护遇到真正困难的问题可以把对话历史和中间状态打包交给云端“主脑”处理云端模型处理完毕再把提炼后的答案和推理过程传回端侧端侧模型以此继续后续对话。看起来像 API 调用实际上是在端侧和云端之间形成持续反馈的闭环。GPT-5 如果真如传闻所说在复杂推理和长上下文理解上有跨越式提升这个闭环的价值会被进一步放大。4. 一份可以直接参考的端侧 LLM 部署流程导出、量化到接入运行时理论讲了不少接下来上一段能直接照做的实操流程。目标很明确把一个 1B 到 3B 级别的开源小模型部署到端侧设备上实现流畅的本地对话。我用的是当前社区比较通用的工具链具体命令在不同版本里可能略有差异但整体流程在未来很长一段时间内都应该适用模型导出、量化校准、格式转换、运行时接入、压测验收。4.1 模型选型先避开两个误区选模型是第一步也是陷阱最多的一步。第一个误区是“能跑多大的就跑多大的”。7B 参数模型虽然也能在高端手机上跑但发热和耗电会让你付出代价。端侧项目的成功标准不是“跑起来”而是“持续用了 30 分钟还不烫”。以我的经验1B 左右适合文本摘要、指令跟随、简单的多轮问答3B 级别才适合带工具调用、复杂逻辑推理和更丰富的角色扮演。7B 以上留给平板、PC 或者智能座舱这类功耗预算更宽裕的设备手机端不建议强上。第二个误区是不看算子兼容性就选模型。同一个模型在不同设备后端上的表现差异可能极大有些算子 NPU 支持有些只支持 GPU有些只能 CPU 跑。选型之前先查一下目标硬件的支持矩阵比部署之后再换模型省时间得多。4.2 转换与量化命令、参数和校准集的正确用法下面给出一套可复现的流程以 Python 环境和转换工具链为例。第一步准备模型导出为 ONNX 格式。我在开源模型的基础上做过不少尝试最终的经验是导出时不要只导出主干结构要把 embedding、attention、mlp 各层完整导出。很多端侧推理崩溃都源于导出阶段图不完整运行时加载才发现缺算子。第二步做权重量化。量化命令通常长这样python -m llm_quantize \ --model ./exported_model/ \ --calibration ./data/calibration.jsonl \ --format int4 \ --output ./quantized_model/其中--calibration指向的校准数据集是整条流程里最容易被低估的部分。校准数据不要用通用语料随便填最好从你真实业务场景里抽 200 到 300 条。否则量化算法只会根据它见过的数据分布做误差补偿你的业务数据大概率落在补偿盲区上线后会出现大量莫名其妙的输出漂移。第三步转换成运行时目标格式。LiteRT-LM 的 bundle 目录里通常包含model ├── tokenizer.model ├── model.int4.bin ├── config.json └── system_prompt.txtconfig.json里要重点检查context_length、temperature、max_tokens三个参数。前两个决定模型行为第三个决定单次生成上限。很多项目部署后出现“回答到一半就断”多半是max_tokens填得太小。第四步在 Android 侧接入运行时。核心代码逻辑很简单val session LiteRtLmSession.Builder(context) .setModelBundle(modelPath) .setBackend(Backend.GPU) .build() session.generateAsync(prompt, callback)这里我最想提醒的一点是所有推理调用必须在子线程执行主线程只负责接收 token 回调并刷新 UI。否则一旦遇到长上下文生成应用立刻会掉帧严重时直接 ANR。4.3 集成、压测与验收一套 30 分钟能做完的验证方案很多人把模型跑起来就算完成这是最大的误区。至少要做三件事再上线。第一业务样本回归。拿 100 到 200 条真实业务问题在量化前后各跑一遍对比输出质量重点关注是否出现新增的重复、乱码、单字循环。第二双指标压测。首 token 延迟和平均生成速度要分开记录。首 token 延迟决定“聊不聊得起来”平均速度决定“聊得顺不顺”。第三长文本压力测试。连续生成长文本观察设备发热后性能是否下降。端侧设备在持续高负载下会发生频率限制生成速度可能从每秒 30 token 掉到每秒 15 token这个数字必须提前测出来才好设计产品提示词和交互节奏。5. 部署端侧模型时最容易踩的五个坑我帮你先踩一遍端侧部署的容错空间比服务端小得多。服务端出问题可以扩容、重启、加显存端侧出问题用户看到的只是应用变慢、闪退、或者模型突然开始说胡话。我在这里把这几个月见过最多的坑集中写一下都是真实会出现的问题不是纸面推演。5.1 校准数据不对量化后的模型开始“胡说”这是量化后最容易出现的现象。模型结构没变任务领域也没变就是某些输入会产生超出常规的输出漂移。排查到最后根因经常在量化校准数据集上。校准数据的分布和实际业务分布差异越大量化误差越会集中在业务数据区域。要解决首先是换校准数据。直接把你自己的业务数据按比例抽样组成几百条校准集重新量化一次大部分漂移都会消失。其次是混合采样如果担心业务数据量太小可以按业务数据 70%、通用数据 30% 的比例混合效果也不错。最后建议保留量化前的模型备份方便在出现漂移时做 A/B 对比确认问题出在量化还是出在别处。5.2 算子不支持导致“假 NPU 加速”有一类性能问题非常隐蔽你明明在代码里指定了 NPU 后端跑下来的速度却和 CPU 差不多甚至更慢。原因通常是一个不支持的算子触发了运行时回退整个图都回退到 CPU 执行。日志里可能只有一句不显眼的 warning不仔细看根本发现不了。建议在部署前做一次算子盘点把模型所有算子和目标硬件的支持列表做 diff。发现缺失就做两件事要么用等价算子替换掉不支持的部分要么直接放弃该硬件后端改用 GPU 或 CPU省得系统来回切换反而增加额外开销。宁可提前明确“我就用 CPU 跑”也不要假装“我在用 NPU”。5.3 上下文窗口数字虚高长文本一上来就崩模型卡上写着 context_length 4096实际 2048 就开始变慢或生成结果明显变差。这种情况在端侧特别常见因为内存带宽和峰值内存根本撑不起宣传里的“最大长度”。KV Cache 分页虽然能推迟内存耗尽但注意力计算在长序列下的耗时还是线性上升的。我的处理方法是在应用层主动限制对话历史长度。比如模型宣称 4K 上下文客户端就把历史 token 数控制在 1.5K 到 2K超出部分做摘要压缩后转成系统提示。用这种方式防护之后稳定性会好很多用户也感知不到模型能力的明显下降。5.4 分词器版本不一致模型像“失忆”一样很多小模型在训练时用的分词器和你部署时转换工具生成的分词器版本不一致。最典型的坑是特殊 token 的 ID 对不上同一段文字训练时是一种切法部署时是另一种切法模型生成出来的概率分布全乱。检查方法很简单打印出 tokenizer 的 vocabulary 长度和模型 config 里的vocab_size对一下。不一致就先解决不一致不要急着跑推理。否则后面每一步都是浪费时间。5.5 GPU 后端吃功耗CPU 后端也能救急端侧推理有时不必执着于用 GPU 或 NPU。某些任务对延迟不敏感但对功耗很敏感比如待机状态下的语音唤醒、低频率的通知摘要。这时候用 CPU 后端反而更稳没有 GPU 唤醒的额外功耗也不存在散热压力。LiteRT-LM 的好处是后端切换在运行时层面就能完成不需要重新编译模型。开发时多做几次后端切换测试把“最快”和“最省电”两个配置都跑一遍再决定不同场景怎么选。6. 云边端三层智能该怎样分工2026 年新范式的实操草图前面讲完了端侧模型的能力边界和部署细节这一节把视野拉回来看看完整的系统架构应该怎么搭。我的核心观点是2026 年做 AI 产品不要二选一不要“全端侧”也不要“全云端”要做云边端三层分工。6.1 本地兜底、云端兜智的路由策略具体落地上我会按一个简单的优先级来分流高频请求、实时性强、隐私等级高这类任务直接由端侧模型处理不联网不等待中等复杂任务端侧模型先给出一个“草稿答案”同时把关键信息传给云端模型校验低频但极度复杂的任务比如长文档分析、代码库理解、多步推理全部交给云端大模型。这个逻辑听起来像是后端路由实际上它应该是端侧 SDK 里内置的能力。端侧运行时持续上报任务特征和模型置信度路由规则根据置信度决定要不要上云。置信度高的本地直接回答置信度低的上云再把云端结果回传给本地用于后续对话上下文更新。这种设计的好处是用户对 AI 的响应速度始终很快因为大多数请求都被本地拦截了。云端只在真正需要的时候介入token 成本也控制得住。长期跑下来云端模型还会不断产生新的“教学样本”用来持续更新端侧模型形成一个越用越准的飞轮。6.2 语义缓存和长窗口让端侧模型“划算”的两个加速点最后讲两个能立刻提升端侧性价比的技术语义缓存和长窗口。语义缓存不是简单的“相同请求直接返回旧答案”。它把用户输入编码成向量计算和过去问题的相似度相似度超过阈值就直接复用上次结果。比如用户问“今天气温适合跑步吗”过两天又问“这天气能不能去跑步”语义上其实指向同一个答案缓存可以直接命中。这个方案对端侧模型很划算因为向量检索的内存开销远小于重新跑一次完整推理。长窗口则是端侧模型往更高价值方向爬升的关键。如果端侧模型能处理几万 token 的上下文很多办公场景比如会议纪要整理、聊天记录检索都能直接本地完成。目前的瓶颈主要在 KV Cache 的显存占用和注意力计算的耗时上分页缓存加流式重计算是行业内公认的两个解法。LiteRT-LM 这类运行时接下来最值得关注的进化方向就是看它对长窗口的支持能做到什么程度。因为对绝大多数用户来说“记得住”比“算得快”更容易被感知。7. 最后交代几句实在话端侧模型不是越强越好写到最后我不打算做大总结只分享两个在这条路上走出来的实际判断。第一不要迷信任何“最强端侧模型”的榜单。端侧模型的好坏永远是在容量、速度、功耗、精度四个维度上做权衡。同一个模型在同一款手机和另一款手机上表现可能完全不一样。真正适合你项目的不是综合分数最高的那个而是和你的设备算子支持程度、内存带宽、场景要求最匹配的那个。第二生态成熟度比模型单点能力更加重要。模型再强如果转换工具链不稳定、量化工具缺文档、网上搜不到真实报错案例项目也很容易中途夭折。选择技术栈时我会优先看开发者社区活跃度、官方文档完整度、以及模板项目能不能一键跑通。这些东西平时不起眼真到上线排障时才知道有多值钱。我自己的体感是从“模型能跑”到“服务稳定上线”中间隔着一条亲手用调试信息填过去的路。LiteRT-LM 和 GPT-5 代表的大模型进化一个是地基一个是灯塔。地基决定你现在能走多远灯塔决定你明年往哪个方向走。先把端侧模型这条链路跑通再盯着云端模型的新能力做蒸馏和迭代这是我目前在 2026 年最有信心的一条技术路径。