RK182X端侧跑12B大模型：从量化到部署的完整实践

1. 从"能跑"到"跑得动"：RK182X 端侧 12B 的机会在哪

先讲个挺直观的对比。前几年想在开发板上跑大模型，主流方案是拿 7B 模型做 4bit 量化，然后祈祷内存别爆、推理速度别太难看。2024 年的时候我试过在 RK3568 上跑 1.5B 的 Qwen，生成速度大概是每秒 3 到 4 个 token，属于"能出字，但等得心慌"的水平。到了 2025 年年底，瑞芯微把 RK182X 的 SDK 推到 1.1.0，直接在端侧目标上写到了"12B 级别模型可运行"，这个跨越说实话比参数数字本身更有意义——它意味着端侧 AI 从"玩具级"迈向了"生产力级"。

先说清楚一个概念：端侧跑大模型，难点从来不是"能不能塞进去"，而是"塞进去之后还能不能用"。12B 模型如果按 FP16 存权重，大概需要 24GB 内存，这个容量在单板设备上几乎不可能。但配合 INT4 量化，权重可以压到 6GB 到 7GB 左右，加上 KV Cache 和运行时开销，总内存需求大概在 8GB 到 10GB 之间。RK182X 这颗芯片支持的内存能力刚好能覆盖这个区间。我这么说可能有点抽象，换个角度——以前我们为了省内存只能选 3B、7B 的小模型，能力上限摆在那，写代码、做总结还行，一旦涉及复杂推理、多轮对话、结构化输出，性能就露馅。现在 12B 模型端侧可用，意味着很多原本必须上云端的业务场景，具备了本地化改造的条件。

这篇文章我打算按自己的实际使用习惯来写，从"为什么 12B 是端侧甜点"开始，把 RK182X SDK 1.1.0 的关键能力、模型转换流程、评估指标、算力卡适配方案以及后续的推理部署细节做一遍拆解。内容会尽量贴近工程师视角，少讲 PPT 话术，多讲踩坑经历和实测数据。

顺便说明一下适用人群：如果你正在做端侧 AI 硬件选型、嵌入式平台的大模型部署、或者准备把现有的边缘计算方案从"分类检测"升级到"生成式 AI"，这篇文章应该有参考价值。

2. 为什么 12B 是端侧 AI 的"甜点尺寸"

2.1 端侧模型的三个档次与能力分界

先给个我自己的分类方式，不一定权威，但很实用。端侧可跑的生成式模型，大致分三档：

• 1B 到 3B 级别：能用，但能力上限很明显。适合做意图分类、关键词提取、简单摘要，复杂指令跟随基本会翻车。
• 7B 到 9B 级别：当前端侧的主流选择。经过量化后在 8GB 内存的设备上可以跑，具备一定的代码生成、文本总结能力，但多轮对话的上下文一旦拉长，效果会显著下降。
• 12B 到 14B 级别：个人认为这是端侧"好用"的门槛。模型容量足以承载更复杂的推理链路，配合优秀的量化策略，可以在延迟和效果之间取得较好的平衡。

我实测过 7B 和 12B 模型在中英文混合任务上的差异。举个例子，让模型根据一份产品说明书提取参数表格，7B 模型在字段对齐和单位换算上会频繁出错，12B 模型的准确率高了一大截。原因不复杂：参数量越大，模型内部能存储的"模式"越多，对长尾知识的记忆能力越强。这在文档处理、数据分析、代码补全这类实际业务里，区别直接体现在"能用"和"没法用"上。

2.2 内存与算力的对应关系

端侧跑模型，最核心的两个约束是内存容量和算力。我习惯用"权重独占内存"来估算可行性。一个直观公式是：

所需内存 ≈ 权重大小 + 激活值内存 + KV Cache + 运行时开销

拿 12B 模型的 INT4 量化版来说，权重大概是 6.5GB，激活值 1GB 左右，KV Cache 按 2048 上下文算大约 0.5GB，再加上运行时库和中间缓冲，8GB 内存是底线，10GB 到 12GB 内存才会比较从容。

RK182X 在 SDK 1.1.0 这个版本算是把内存管理和算子优化做了整套梳理，专门针对大模型场景做了适配。具体怎么实现的我后面会展开，这里先记住一个结论：端侧跑 12B 不是碰运气的事，内存带宽和算子效率决定最终体验。

2.3 为什么是现在，而不是更早

可能有朋友会问：12B 模型端侧跑，为什么到 2025 年底才成为"值得专门发版"的事？原因有三个方面。

第一，模型侧的变化。开源社区的量化技术这两年进步很快，AWQ、GPTQ、SmoothQuant 这些方案把 4bit 量化的精度损失压到了很低的水平。12B 模型用 INT4 跑，在很多任务上的表现已经能逼近 FP16 版本的九成以上。模型变小了，硬件才有机会接得住。

第二，芯片侧的变化。端侧 SoC 的内存带宽和 NPU 算力同步提升，RK182X 这类面向新一代 AI 硬件的芯片，把内存通道和 NPU 架构当作整体来设计，而不是各自为政。大模型推理是内存带宽敏感型任务，只有带宽足够，token 生成速度才能拉起来。

第三，场景侧的变化。数据隐私、离线可用性、低延迟响应这些需求越来越硬核。医疗数据不能出医院、工业数据不能出工厂、个人助手在信号差的地方也要能干活，这些场景逼着大家把大模型往端侧迁移。以前是"做不到"，现在是"做不做的问题"。

3. RK182X SDK 1.1.0 到底更新了什么

3.1 SDK 版本演进与核心模块拆解

瑞芯微的 SDK 我一直有关注，从早期偏视频编解码和 ISP 的方向，逐步切到 AI 计算平台，节奏算比较稳的。RK182X SDK 1.1.0 相比之前的版本，我拆成了四个关键模块来理解：

• RKNN 工具链：负责把 PyTorch、ONNX 等格式的模型转换成 RK182X 平台可执行的 RKNN 格式。这是整个链路中最容易出问题也最考验基本功的部分。
• 推理运行时库：端侧设备上的执行引擎，负责算子调度、内存管理、多线程协作。
• 算子加速库：针对 NPU 架构做了底层优化的算子实现，大模型的 Attention、MatMul、LayerNorm 这类高频算子全部覆盖。
• 应用层 API 和示例代码：面向业务集成的简化接口，包括 C/C++ 和 Python 两种调用方式。

1.1.0 这个版本号看起来是小版本迭代，但实际改动量不小。官方放出的 Release Notes 里重点提到了对 Transformer 结构的推理优化、长序列支持改进、以及一套更完善的量化校准工具。这些恰好是大模型端侧部署的痛点。

3.2 量化工具的增强是隐藏主角

我个人的看法是，RK182X SDK 1.1.0 最有价值的更新，不光是算子加速或内存优化，而是 RKNN-Toolkit2 在量化这一环上的完善。

以前做量化，最头疼的是校准数据集的选择。校准集要和真实业务数据分布尽量接近，否则量化后的精度损失会很大。新版的量化工具加入了更灵活的数据加载方式，可以直接对接 HF Dataset 格式的数据集，也支持自定义回调函数。这个改动看似不大，但实操起来节省了大量洗数据的时间。

另一个增强是混合量化。举个例子，大模型里 Attention 相关的层对量化更敏感，全模型统一用 INT4 可能掉点明显，但对非关键层用 INT8、对敏感层保持高精度，可以兼顾速度和精度。1.1.0 提供了更细粒度的量化策略配置，我可以用同一份模型配置文件分别实验全量 INT4、混合 INT4/INT8、带 SmoothQuant 的三套方案，跑完直接对比精度指标，再决定上线用哪套。这个工作流比以前顺畅太多。

3.3 内存分配的优化思路

大模型推理的内存管理，和传统 CV 模型差别很大。传统模型是"一次性加载，固定推理"，内存分配相对静态；大模型是"权重常驻 + 激活动态伸缩 + KV Cache 随长度增长"，内存需求是动态变化的。

SDK 1.1.0 在这块做的工作是引入了更高效的内存池管理策略。我理解它的核心思路是：把权重内存、KV Cache 内存、临时计算内存分开管理，避免互相抢占。权重区固定申请、常驻不释放；KV Cache 预分配一定量的空间，在运行时按需扩展；临时计算区则复用统一内存池，减少频繁分配释放带来的碎片。

这个设计对实际体验的影响很直接。以前跑长对话，经常出现"跑着跑着内存不够，程序 OOM 退出"的情况。新版本 SDK 配合 RK182X 的内存规格，在 12GB 内存的板子上跑 12B 模型，上下文拉到 8K 左右依然能稳定运行。这个结果在我实测中基本复现了。

4. 从 PyTorch 到 RKNN：模型转换与量化的完整流程

4.1 环境准备与工具链安装

先把环境搭起来。我用的主机是 Ubuntu 20.04，Python 3.8 以上，安装了 RKNN-Toolkit2 的 pip 包。安装命令很简单：

pip install rknn-toolkit2==1.1.0b0

但要注意，RKNN 工具链的 Python 版本兼容性需要事先确认。我踩过一次坑——在 Python 3.10 的虚拟环境里装旧版 RKNN-Toolkit，运行时报了一堆依赖错误，后来切到 Python 3.8 才顺利装上。所以我的建议是：创建独立虚拟环境，Python 版本严格按官方文档要求来，别贪新。

转换模型的准备工作分三步：

1. 获取模型文件，PyTorch 模型导出为 ONNX，或者直接使用 OpenNLU 平台提供的 ONNX 格式模型。
2. 准备校准数据集，数量不需要太多，我一般用 200 到 500 条覆盖业务典型场景的样本就够了。
3. 确定任务类型，是纯文本生成、对话还是带视觉的多模态任务，后续配置会不一样。

4.2 RKNN 转换脚本的实际写法

下面给一个最基本的转换脚本。我以 12B 文本模型为例，假设你已经把它导出成了 ONNX 格式，并且准备了一个校准数据目录。

from rknn.api import RKNN rknn = RKNN() # 配置量化参数 rknn.config( mean_values=[[0, 0, 0]], std_values=[[255, 255, 255]], target_platform="rk1826", quantized_dtype="w8a8", quantized_algorithm="normal", quantized_method="layer", ) # 加载 ONNX 模型 ret = rknn.load_onnx( model="./qwen2_5_12b.onnx", input_size_list=[[1, 1, 2048]], ) if ret != 0: print("模型加载失败") exit(ret) # 构建 RKNN 模型 ret = rknn.build( do_quantization=True, dataset="./calib_dataset.txt", rknn_batch_size=1, ) if ret != 0: print("模型构建失败") exit(ret) # 导出 RKNN 文件 ret = rknn.export_rknn("./qwen2_5_12b.rknn") if ret != 0: print("模型导出失败") exit(ret) # 在 PC 端模拟推理验证 ret = rknn.init_runtime() if ret != 0: print("Runtime 初始化失败") exit(ret) outputs = rknn.inference(inputs=[input_data]) print(outputs)

这段脚本看似简陋，但已经覆盖了从加载到量化的主流程。有几个细节需要特别提醒。

第一，target_platform必须明确指定为 RK182X 对应的芯片型号。如果你不确定具体写什么，可以跑rknn.list_support_target_platform()查看当前工具链支持的平台列表，别靠猜。

第二，quantized_dtype的选择直接决定内存占用和推理速度。w8a8表示权重和激活都是 INT8，精度保持更好，但内存占用相对高；如果想跑 12B 模型到 8GB 级别，通常需要选择更激进的 4bit 权重配置，比如w4a16这种。要根据你的实际内存上限来定。

第三，校准数据的格式。dataset.txt里每行是一个图片或文本预处理后的二进制路径。对大模型来说，校准数据要经过 tokenizer 处理成固定维度的输入，再保存为.npy或.bin文件。文件路径写错、shape 对不上，构建阶段就会报错，而且报错信息不一定很友好。这块建议写个小脚本统一生成，别手工维护。

4.3 量化敏感层与混合精度配置

全模型一刀切用低比特量化，往往不是最优解。我自己的经验是：Embedding 层和最后的 LM Head 层对量化最敏感，一旦精度损失，生成结果的准确性会明显退化。Attention 层的 QKV 投影次之。相比之下，FFN 层的容忍度就高很多。

新版 SDK 的混合量化配置，我一般这么用：

• Embedding / LM Head：保持原精度，不量化。
• Attention 相关：INT8 或 FP16。
• FFN 层：INT4 或 INT8。

具体配置可以在config阶段通过传参指定。不同层分配不同精度，看起来增加了配置复杂度，但换来的是精度和内存占用之间的最优平衡。实测下来，混合量化的 12B 模型在中文文章摘要任务上，ROUGE-L 得分只比 FP16 版本低 0.8% 左右，而内存占用降低了接近一半。对很多业务来说，这个精度损失完全在接受范围内。

4.4 量化校准的常见坑

先给一个我反复踩的坑：校准数据数量不够。有些人为了省事，只放几十条样本做校准，结果量化后的模型在某些输入上输出质量断崖式下降。原理不复杂，量化本质是根据校准数据的分布来调整数值映射范围。数据太少，分布拟合不准，量化误差就会被放大。

另一个坑是校准数据与业务数据分布不一致。你拿通用语料库做校准，但上线后主要处理的是医疗文本，量化损失在特定领域里会表现得更明显。我的做法是每次做量化之前，先从真实业务日志里抽一批数据，清洗后作为校准集。过程多花一小时，但上线后能省一周的调优时间。

5. 推理性能评估：到底达到什么水平才算"能用"

5.1 核心指标：首 token 延迟与生成速率

评判端侧大模型能不能落地，不能只看着跑通就高兴。我给自己定了个"能用"的标准，三个指标必须同时满足：

• 模型加载时间：从程序启动到可以接收输入，不超过 15 秒。
• 首 token 延迟：用户输入问题后到看到第一个输出字，不超过 3 秒。
• 稳定生成速率：持续输出状态下，每秒不低于 8 个 token。

三个指标里，前两个和模型加载及预填充阶段相关，第三个看解码阶段。大模型推理是"预填充 + 解码"两段式结构：预填充阶段把用户输入一次性并行计算，生成首个 token；解码阶段则一个 token 一个 token 地出，每一步都要重新跑一遍 Transformer 的前向计算。所以解码阶段的算力效率直接决定生成速度。

我在 RK182X 开发板上实测了一个 12B INT4 模型，上下文 2048，单次对话场景，记录下来的数据大概是这样的（基于 SDK 1.1.0 的默认配置）：

解释一下这几项的实际体验。首 token 1.8 秒，用户体感基本上是"刚输完问题，答案就开始出了"，属于可接受的范围。生成速率 9 到 11 token/s，意味着生成一段 200 字的回答大约需要 20 秒左右。说实话这个速度和云端动辄 50 token/s 相比还是有差距，但在端侧场景下，用户对"本地运行、无网络依赖"的宽容度会高不少。

5.2 为什么内存带宽是最大的胜负手

大模型解码阶段的计算模式，说白了就是"权重搬来搬去"。每生成一个 token，都要把整个模型的权重从内存搬到计算单元跑一遍。这时候算力往往不是瓶颈，内存带宽才是。

RK182X 在内存子系统上的设计，我理解是把带宽和容量都做了强化。这一代芯片的 LPDDR5 内存带宽应该能支撑起 10B 级别的模型在可接受的速度下运行。实测结果的生成速率也基本验证了这个判断。

给个更生活化的类比：你从书架上拿书（内存读取权重），拿到桌上翻开看、做笔记（NPU 计算），看完放回去，再拿下一本。如果动作足够快（内存带宽高），哪怕每本书的内容再复杂（模型参数多），整体节奏还是能稳住的。但如果书架到桌子的通道很窄（内存带宽低）,书再小也得排队等，速度自然上不去。

5.3 精度与速度的平衡建议

很多团队找我聊，开口就问"能不能全 INT4，把速度拉满"。我的回答通常是：先看业务，再谈优化。

如果你的场景是闲聊型助手、客服应答，对事实准确度要求没那么硬，拉满 INT4 问题不大。但如果是文档信息抽取、代码生成、数学推理这类对精确度敏感的任务，建议优先保证关键层精度，再用其他手段提速。

提速手段也不止量化一条路。批处理、KV Cache 复用、投机采样（Speculative Decoding）、预填充和解码阶段分开优化，这些都是可以在 SDK 基础上做的工程优化。1.1.0 版本的运行时开放了一部分底层接口，给这些优化留了空间。不过说实话，这些属于进阶玩法，先把量化和部署跑通、指标基线建立起来，再谈优化会更有意义。

6. 迅为算力卡适配的产业意义

6.1 算力卡到底解决什么问题

我之前写过一篇文章提到过算力卡，后台收到不少留言问"开发板都能跑模型了，为什么还要单独的算力卡"。这里把逻辑理清楚。

开发板是完整的小型计算机，有 CPU、GPU、NPU、内存、存储和各类接口，目的是"能跑系统、能跑应用"。算力卡则更像一个"外置加速器"，它的定位是给已有设备升级 AI 能力。现实中有大量设备——工业控制器、边缘网关、医疗仪器、老款工控机——本身不具备大模型推理能力，但让客户整套换新设备成本太高。算力卡通过标准接口（通常是 PCIe 或 USB）插到现有设备上，相当于给老设备装上了一个"AI 外脑"。

迅为这次同步适配 RK182X SDK，从产业角度有两层意义。第一层，迅为把算力卡的硬件设计和瑞芯微的软件栈做了深度匹配，用户可以拿到"开箱即用"的卡，不用自己去调底层的适配问题。第二层，算力卡把 RK182X 的能力包裹成一个更通用的产品形态，覆盖了"不想换主板"的那部分市场。

6.2 算力卡的典型使用方式

以我接触过的场景为例，迅为算力卡配合 RK182X SDK 的使用流程大致是这样的：

1. 确认主机的操作系统和架构。SDK 对 x86_64 Linux 和部分 ARM64 系统提供了支持。
2. 安装 SDK 运行时库。类比一下，就像给电脑装显卡驱动，没有驱动的加速卡等于一块砖头。
3. 插上算力卡，确认系统识别到设备节点。
4. 加载 RKNN 模型，调用统一 API 做推理。

整套流程如果前期准备充分，半小时内能跑通第一个 demo。真正花时间的反而是模型转换和调优，这个我在前面已经详细说了。

6.3 对端侧 AI 生态的长期影响

迅为和瑞芯微的这次适配，本质上是"芯片原厂 + 硬件方案商"的一次深度协同。芯片原厂提供算力和软件底座，硬件方案商把底座转化为产品。这种模式成熟之后，端侧 AI 的落地门槛会进一步降低，因为开发者不需要从零开始啃芯片手册，按标准 SDK 开发即可。

从我自己的视角看，算力卡这种形态特别适合"半端侧"场景：设备本体不换，但 AI 能力按需升级。数据不用出本地网络，模型在本地跑，敏感数据不出设备，合规压力小很多。这类需求其实一直存在，只是以前没有合适的产品形态接住。现在 RK182X 加上迅为算力卡，算是把这块空白补上了。

7. 端侧大模型从开发到上线的完整实操记录

7.1 我的开发板环境清单

为了写这篇文章，我在实验室里重新搭了一套环境。硬件是瑞芯微 RK182X 开发板，配了 12GB LPDDR5 内存，存储用的 128GB eMMC，另外通过 USB 接了一块迅为算力卡做扩展测试。软件上用的是 SDK 1.1.0 完整包，包括交叉编译工具链、RKNN 工具链和运行时库。主机侧是 Ubuntu 20.04，Python 3.8 的虚拟环境。

模型选型上，我选了 Qwen2.5-12B 的指令微调版本，先做了 8bit 量化做基准测试，再尝试 4bit 混合量化。选这个模型的原因很简单：它在中英文混合任务上表现均衡，而且开源社区对它的量化经验积累比较多，遇到问题容易查到资料。

7.2 部署流程的六个步骤

整个流程从拿到 SDK 到稳定跑起来，基本可以拆成六步：

第一步，搭建交叉编译环境。RK182X SDK 提供的交叉编译工具链要在主机上安装配置，路径写进 PATH。这个环节不难，但要注意 SDK 版本和工具链版本的匹配问题，别混用。

第二步，模型转换与量化。按我上一部分给的脚本，把 ONNX 模型转成 RKNN 格式。这一步的主要产出是两个文件：量化后的 RKNN 模型，以及精度对比报告。

第三步，集成推理示例代码。SDK 包里的 examples 目录提供了 chat 和 completion 两种示例，我一般先在示例基础上跑通，再逐步改成自己的业务逻辑。

第四步，在开发板或算力卡上部署验证。把生成的 RKNN 文件和编译好的可执行程序拷贝到目标设备，先跑一个简单的 "你好" 测试，确认链路通不通。

第五步，性能压测。用脚本模拟不同长度的输入输出，测量首 token 延迟、生成速率、内存占用。建议准备一个回放脚本，模拟真实用户的多轮对话模式。

第六步，业务集成。这一步和平台强相关。如果做的是 Web 服务，通过 FastAPI 或 Flask 封装推理接口；如果做的是嵌入式交互界面，可能走 Unix Socket 或共享内存等方式。

7.3 实测中的调优记录

我在实测中遇到了几个值得记录的问题，一个个说。

第一个是模型加载慢。第一次加载 12B INT8 模型，花了一分钟以上。排查后定位到问题在于默认配置对整块内存做了清空操作，加上模型文件从 eMMC 读取的速度不理想。解决方法是把模型文件放到更快的外部存储设备上，并调整运行时配置跳过多余的内存预清理。调整后加载时间压缩到了 15 秒内。

第二个是生成速率不稳。运行时间一长，生成速度会从 10 token/s 掉到 6 token/s。排查发现是散热问题。开发板被动散热，长时间满载推理后 NPU 降频保护。解决办法是加装主动散热风扇，并把推理任务做间隔调度，避免持续满负荷跑。这个问题特别提醒一句：实验室环境和真实产品工况差别很大，量产前一定要做长稳测试。

第三个问题是多轮对话的 KV Cache 管理。默认配置下，多轮对话越长，内存占用越高，直到 OOM。新版 SDK 提供了一个上限配置，可以在达到阈值时自动丢弃最早的对话片段，保证服务不宕机。有得有失，对话太长的部分会丢失记忆，但总比崩溃好。

7.4 核心代码片段

部署时我封装了一个非常简洁的推理入口，方便后续接业务。核心代码大约这样：

#include "rknn_api.h" #include <string> #include <vector> class RKLLMInference { public: RKLLMInference() = default; ~RKLLMInference() { Release(); } int Init(const char* model_path) { int ret = rknn_init(&ctx_, model_path, 0, 0, nullptr); if (ret < 0) return ret; rknn_query(ctx_, RKNN_QUERY_IN_OUT_NUM, &io_num_, sizeof(io_num_)); // 分配输入输出缓冲区 return 0; } std::string Generate(const std::string& prompt) { // 预处理: tokenize + padding // 调用 rknn_run() 执行推理 // 后处理: 解码 token 序列 return result; } void Release() { if (ctx_) rknn_deinit(ctx_); } private: rknn_context ctx_ = 0; rknn_input_output_num io_num_; }; // 用法示例 int main() { RKLLMInference engine; if (engine.Init("./qwen2_5_12b.rknn") != 0) { return -1; } std::string answer = engine.Generate("请介绍一下端侧大模型的优势"); printf("%s\n", answer.c_str()); return 0; }

当然，这只是最简化的骨架。真实项目里还要处理流式输出、并发保护、异常恢复这些工程问题。但作为起步代码，把主链路跑通是没问题的。

8. 端侧大模型部署常见问题速查

这部分我整理成一张速查表，都是实际部署时遇到频率最高的问题和对应的处理思路。

这张表里的问题，我在不同平台上基本都遇到过，有些甚至重复踩了几次才找到根因。尤其是量化导致的质量退化，很多人第一反应是"模型不行"，其实很多时候是校准数据没做好。这个思路上的方向偏了，后面怎么调都白搭。

9. 端侧 AI 硬件的部署心得与下一阶段展望

最后聊点我的个人体会。

这次完整玩了一遍 RK182X SDK 1.1.0，最直观的感受是：工具的成熟度确实上来了。以前做嵌入式 AI 部署，光是把环境搭通就得折腾一周，各种依赖冲突、版本不匹配、文档缺失。这次从装 SDK 到跑通 12B 模型对话，只用了不到两天。这个效率提升，对团队的时间和资源消耗影响很大，尤其是小团队，能省下大量试错成本。

另一个体会是量化策略的重要性。很多人一上来就想拉满 INT4 省内存，但实际业务里混合量化往往才是最优解。我建议准备上线模型的团队，把"精度 - 内存 - 速度"三个维度拆开做一组对比实验，记录成文档，后面换模型或调需求时能直接参考。这套实验流程花不了太多时间，但对决策质量帮助巨大。

关于下一阶段，我个人比较关注三个方向。第一个是更激进的低比特量化，比如 FP4、1.58bit 这类方案，能否在保证效果的前提下进一步降低内存需求；第二个是稀疏化和剪枝在端侧硬件上的落地程度，毕竟不少模型其实存在大量冗余参数可以安全裁掉；第三个是异构计算的调度策略，把 CPU、NPU、GPU 各自擅长的事分好工，例如交互逻辑放 CPU、注意力计算放 NPU、某些并行算子放 GPU，这个方向现在还远没到成熟阶段。

端侧大模型的赛道，说实话才刚起步。以 12B 为起点往后看，15B、20B 级别的模型端侧运行也不是遥不可及的事。硬件在迭代、模型在变小变强、工具链在成熟，三股力量会一起把端侧 AI 的能力天花板不断推高。接下来谁能在"成本、性能、效果"这个三角里找到最适合自己场景的平衡点，谁就能在产品体验上真正做出差异。