一台配有 24GB 运行内存的骁龙 8 Gen 5 旗舰手机，能在本地跑 INT4 量化的 32B 模型。刚启动，速度约为每秒 8 个 token。连续推理超过 10 分钟，机身温度升到 46°C，速度掉到每秒 3 个 token，还消耗了超过 20% 的电量。
这组真机记录来自《R1开源后，手机跑30B模型先撞上散热墙》。单次测试不能代表所有设备，却把端侧最难绕开的约束摆得很清楚：模型能点亮，不等于它适合长时间运行。
能点亮，不等于能常驻
32B 模型即使压到 INT4，依然要占用大量内存带宽，并把持续功耗变成热。手机没有服务器机房的散热条件，温度上来以后，芯片降频，推理速度随之下滑。
万亿参数模型没有过时，只是不适合被当作手机、智能家居设备和具身智能设备的默认常驻模型。端侧选型要看的，是持续吞吐、温度、电量和加载开销，而不只是参数规模与启动瞬间的跑分。
这也是“通专融合”在端侧受到关注的现实背景：不再让一个模型包办所有任务，而是把通用能力和专业能力分开部署。
先别把通专融合缩成“小模型 + LoRA”
概念边界需要先说清。“通专融合”并不等同于给 3B 模型外挂一个 LoRA。
百度百科相关条目将该概念归于上海人工智能实验室周伯文提出。2024 年 7 月 4 日，周伯文在 WAIC 2024 科学前沿主论坛作开场报告；相关规划还提出，2025 年完成三层技术体系全链路验证，重点突破世界模型建模中的因果推理瓶颈。到 2026 年出版的《数字化的力量》第 2 版，通专融合又被列为一种 AI 发展路径。
原概念覆盖的范围比“小模型 + 插件”更广。不过落到端侧工程，它最直观的形态确实是：让一个 3B 到 10B 的通用模型常驻设备，再按任务加载 LoRA、专有知识库或工具 Agent。
通用底座负责意图识别、普通对话和初步推理，专业组件负责票据解析、代码补全或离线健康助手等明确任务。这样做不是为了证明小模型比大模型更聪明，而是避免每个请求都搬动一套庞大的模型权重。
200 毫秒，先过内存这一关
《手机多模态推理压到200毫秒，先拆内存墙》把首字延迟目标写到了 200 毫秒。这个数字不宜被说成所有用户的统一容忍线，但它指出了工程重点：少搬权重，尽量提高 NPU 指令吞吐。
例如，用户拍下一张报销单据，要求手机完成识别和合规检查。系统可以先由常驻的 3B 底座判断任务类型，再加载几百兆大小的票据插件，而不是唤醒完整的 32B 模型。
在这套设计里，首字延迟可以把 150 毫秒以内设为目标。能不能做到，取决于权重搬运、插件加载、NPU 吞吐和内存调度，不是换上“通专融合”这个名字就会自动实现。
用户本地多模态输入
↓
常驻 3B 通用底座
意图识别 / 初步推理
↓ 动态路由
LoRA A：代码补全 LoRA B：离线健康助手
3B 能赢，但只能在窄任务里说
“3B 击败万亿参数”需要加上严格条件。它不是对通用能力的判断，而是对特定任务、特定设备和特定时延要求的比较。
云端大模型擅长开放式写作、复杂推理和跨领域问答。到了 Agentic Workflows，结果不再是一段文字，而是一次正确的本地 API 调用。此时，模型是否熟悉操作系统接口、页面结构和动作约束，往往比它拥有多少通用知识更重要。
经过高质量对齐数据蒸馏后，3B 模型可以专门处理本地文件检索、屏幕语义解析和单步行动规划。它不必经过多轮网络传输，也更容易围绕固定 API 做约束。在这些边界清楚的任务上，小模型可能获得更快的响应和更稳定的执行表现。
准确率是否超过云端模型，仍要看具体评测，不能在没有数据时写成“全面胜出”。所谓 3B 击败万亿，成立的前提从来不是参数奇迹，而是任务被切得足够窄，蒸馏数据也足够贴近实际调用。
对于受到算力租金影响的中小开发者，模型蒸馏的价值也正在这里：不是复制云端模型的全部能力，而是把业务真正需要的那部分压进本地小模型。
Agent 原生 OS，更像一个调度问题
AI地域归档在 2026 年 7 月 14 日收录了阶跃星辰发布“首个智能体原生 OS”的消息。值得注意的不是“首个”这个标签，而是模型在操作系统中的位置发生了变化：它不再只是一个聊天 App，而是开始参与任务分配和整机资源调度。
更准确地说，OS 仍然负责权限、资源和安全边界，各类轻量 Agent 负责处理具体任务。通用调度层判断用户想做什么，专业 Agent 再调用相应工具。这与端侧通专融合的分工很接近。
当然，能参与调度不等于模型已经成为真正的操作系统内核。插件隔离、权限控制和执行失败后的处理方式，仍然决定这套方案能不能长期使用。
240 微秒到 28 微秒，差距藏在算子里
模型结构只决定“运行什么”，编译器和芯片适配决定“跑得顺不顺”。模型迁到国产 NPU 或 Arm 处理器后，RMSNorm 等算子的融合、分块和访存方式都可能需要重新调整。
在《模型迁到国产芯片后，算子调优怎么交给 Auto-Kernel》引用的案例中，Auto-Kernel 自动处理算子融合、分块和访存优化，使昇腾芯片上的算子延迟从 240 微秒降到 28 微秒。
这组数字不能外推到所有芯片和算子，但足以说明：端侧推理的差距，经常不在模型排行榜里，而在编译器生成的代码和内存访问路径里。
同样，LoRA 插件的加载与卸载也不可能毫无成本。更快的算子和更好的编译工具可以减少内存抖动与切换卡顿，却不能把物理开销完全抹掉。
选型时，把参数量放到后面
开发者可以先做三件更实际的事：
- 先拆任务，再选模型。 日常对话、简单分类属于高频通用任务；特定格式文档解析、专业代码调试属于低频专业任务。两者没有必要塞进同一个模型。
- 端侧底座优先看 3B 到 7B。 除了剪枝和量化，还要确认它是否在高通、联发科、苹果 A/M 系列等实际硬件上完成加速适配。榜单分数不能替代真机持续测试。
- 让专业层保持独立。 使用高质量、小规模数据训练几百兆以内的 LoRA，再按输入动态路由。LangGraph 可以承担部分协同工作，但前提是任务边界和调用权限已经划清。
云端万亿参数模型仍适合处理开放问题和复杂推理，端侧小模型则更适合高频、本地、边界明确的任务。两者并不冲突。
判断一套端侧方案是否可用，不妨回到开头那台手机：连续运行 10 分钟后，它还能不能维持每秒 8 个 token，还是已经掉到 3 个 token？24GB 内存能装下模型，并没有回答这个问题。
通专融合的价值，是把通用路由、专业执行、云端能力和芯片适配放到各自合适的位置。对手机和边缘设备来说，这比把所有能力继续塞进一个更大的模型实际得多。
