第一章:大模型运行本质与边缘部署核心逻辑
1.1 大模型运行的本质是什么?
大语言模型(LLM)的运行本质是一个自回归(Autoregressive)的下一个词预测过程。它接收人类语言,转化为数学矩阵,并通过庞大的神经网络不断计算概率,生成下一个最优结果。其运行过程严格分为两个核心阶段:
·Prefill(预填充/Prompt阶段):
模型一次性接收用户的全部输入(Prompt),并行计算所有输入 Token 的注意力(Attention)特征,生成首个输出词。这个阶段是典型的"计算密集型",对芯片的算力峰值要求极高。
·Decode(解码/生成阶段):
模型基于已有的输入和刚刚生成的词,逐个生成后续的词。每次只输入一个 Token(长度为 1),这个阶段是典型的"访存密集型",对内存带宽(Memory Bandwidth)的考验极大。
1.2 边缘侧部署:我们需要对模型做什么?
与云端拥有数百 GB 显存的集群不同,MTK 等移动端 SoC(边缘设备)面临着极其严苛的资源限制:内存有限、带宽受限、且必须控制功耗与发热。为了让庞大的 LLM 在边缘设备流畅运行,我们需要对它进行以下"改造":
·模型量化 (Quantization):
将模型原始的 FP16 浮点权重进行压缩。例如采用asym4W_sym16A(权重非对称 4-bit,激活值对称 16-bit)策略。这能把模型体积缩小约 75%,大幅降低内存占用,突破带宽瓶颈。
·图结构分离 (Split Prompt & Generative):
针对上文提到的 Prefill 和 Decode 特性,我们将模型切分为两套执行图。处理长上下文的编译为长图(如 128t),单次处理 1 个 token 的编译为单图(如 1t)。
·特定硬件后端映射:
将模型的算子通过专用编译器(如 Neuron SDK)翻译,使其完全适配底层硬件加速模块(如 MTK 的 MDLA 深度学习加速核心和 EDMA 内存搬运引擎)。
1.3 部署所需文件及其关系解构
在端侧跑起一个大模型,绝非一个文件就能搞定,它是一个软硬协同的系统工程。核心文件及其相互关系如下:
| 文件组件与模块 | 职能与关系解析 |
|---|---|
| 提词器文件 (Tokenizer) vocab.txt merges.txt added_tokens.yaml | 充当人机交流的桥梁: 文本输入时,靠它们切分成模型能理解的 ID 序列;生成完毕时,再将 ID 还原回文本。它是模型"认字"的根本。 |
| 动态编译库与入口 libmtk_llm.so main chat_loop.sh | 推理的中枢神经:chat_loop.sh 等入口脚本调用底层环境,libmtk_llm.so 负责整个大模型的前后处理流程与硬件调用协同。 |
| 运行配置文件 config_*.yaml | 控制塔: 定义了如 Temperature、Top-P 采样策略以及 BOS(开始符号)、EOS(结束符号)的特殊 Token 设置。 |
| 共享权重文件 shared_weight.bin | 减负优化: 因为 Prompt 图和 Generative 图仅是序列长度不同,层权重是相同的。将通用权重抽离成此文件可大幅节省物理内存。 |
| 嵌入层 (Embedding) embedding_int16.bin | 将 Token ID 映射成多维向量。为了节约 NPU 的高速显存,它通常被剥离并分配到 CPU 上执行。 |
| 底层执行图 (DLA) qwen_128t.dla qwen_1t.dla | 算力引擎的核心产物:128t.dla 负责首字推理的并发计算,1t.dla 负责逐字生成的序列计算。这些是 NPU 直接执行的机器指令封装。 |
第二章:MTK 边缘部署实战演练(以 Qwen2.5 为例)
2.1 模型量化准备与执行 (PTQ)
在获得了原始模型后,需对其进行后训练量化并固定模型形状(npu对内存的格式很严格,固定能够做到npu的内存消耗减少),示例如下:
bash
# 1. 提取校准数据集(保证量化后精度不会大幅下降)
bash 1_make_ptq_calibration_dataset.sh
# 2. 执行量化过程 (此处应用 asym4W_sym16A 策略)
bash 2_ptq.sh
# 3. 固定模型形状
bash 3_shape_fixer.sh
# 4. 可选:在 PC 上运行 TFLite 格式以验证模型正确性
bash 4_optional_inference_tflite.sh
2.2 适配目标芯片的硬件规格
MTK不同平台的APU硬件能力不一。这里我们需要针对特定芯片及配合其指定的Neuron_SDK进行编译脚本改造(我之前因为没有指定sdk出现过段错误):
打开编译脚本,找到 BACKEND 等参数并进行修改(修改这一步也特别重要,如果size和平台设置错误,后果也是很严重的):
bash
# 修改前 (例如适配高端多核平台):
BACKEND="mdla5.5"
L1_SIZE_KB="7168"
NUM_MDLA="4"
# 修改后 (适配当前平台芯片配置):
BACKEND="mdla5.3,edma3.6" # 指定具体的加速引擎版本
L1_SIZE_KB="256" # 调整 L1 缓存大小
NUM_MDLA="1" # 设置 MDLA 核心数
2.3 模型编译与权重抽离
硬件参数配置无误后,使用 Neuron SDK 将网络编译为底层指令 DLA,并将双流程复用的权重剥离出来以节约内存开销:
bash
# 5. 编译预填充模型 (Prompt, 示例路径 1t2048c)
bash compile_prompt_qwen2.5_0.5B_7B.sh ../post_training_quantize/tflite/
Qwen2.5-0.5B-Instruct_asym4W_..._1t2048c ~/work/MTK/neuron-8.0-release
# 6. 编译生成模型 (Generative)
bash compile_generative.sh ~/work/MTK/GAI-.../Qwen2.5-0.5B-Instruct_..._0.tflite
~/work/MTK/neuron-8.0-release
# 7. 编译权重提取 (extract-shared.sh)
# 将 128t (多Token) 与 1t (单Token) 模型中相同的权重提取至 shared_weight.bin
bash extract-shared.sh ~/work/MTK/neuron-8.0-release shared_weight.bin path/
to/..._128t2048c_0.dla path/to/..._1t2048c_0.dla
2.4 Tokenizer 提词器的准备
C++ 的推理引擎无法直接读取 Python 生态的 tokenizer.json。必须经过转化。目前社区主要有
两大流派,其处理方式如下:
对于 HuggingFace 体系(适用于 Qwen2.5): 需要借助提供的 Python 脚本,将 JSON 提取为底层的 txt 与 yaml。
python
python3 inference/scripts/prepare_huggingface_tokenizer.py ~/work/Qwen2.5-0.5B-
Instruct/tokenizer.json
# 生成附加特殊 Token 的 yaml
python3 inference/scripts/prepare_added_tokens.py ~/work/Qwen2.5-0.5B-Instruct/
tokenizer.json
对于 SentencePiece 体系(适用于 Phi 等): 需对 .model 文件处理以剥除生成的虚拟前缀。
python
python3 ./scripts/prepare_sentencepiece_tokenizer.py /path/to/tokenizer.model
2.5 终极部署:向设备进发
完成所有编译后,使用 Android 调试桥 (adb) 将产物统一推送到设备端。我们准备推送的文件分为两类:
核心模型库(业务数据)
包含:qwen_128t.dla qwen_1t.dla shared_weight.bin embedding_int16.bin
config_qwen2.5_0.5b_instruct.yaml 及由上一步生成的 Tokenizer 系列文件(vocab.txt、
merges.txt 等)。
动态链接库与可执行程序(驱动环境)
包含:基础依赖 libc++_shared.so libre2.so libyaml-cpp.so ;分词引擎 libhf-tokenizer.so libsentencepiece.so libtokenizer.so;
MTK 推理框架主核心
libmtk_llm.so libcommon.so libdrafter.so 以及执行程序入口 main
至此,只需在终端中执行 main,即可成功在联发科平台设备的边缘侧唤醒该大语言模
型,并开始流畅对话!