企业官网建设流程全解析

1. 缘起：为什么要在MTK平台上折腾大模型

1.1 一个真实的项目需求

去年底接到一个需求，客户希望在基于MTK平台的边缘设备上跑一个本地化的大语言模型，用来做离线场景下的智能问答和文本摘要。设备端的算力有限，内存也不宽裕，但客户明确要求不能依赖云端推理，所有数据必须留在本地。这个需求其实挺典型的——现在越来越多的行业场景对数据隐私和响应延迟有硬性要求，云端方案虽然省事，但网络抖动、数据合规、调用成本这三座大山压下来，本地部署就成了绕不开的选择。

选型阶段我对比了几个主流的小尺寸模型，最终锁定Qwen2.5系列。原因很直接：Qwen2.5在中文理解和生成上的表现确实扎实，而且官方放出了多个参数规模的版本，从0.5B到72B都有，给边缘设备留足了选择空间。MTK平台这边，我手上用的是天玑系列的一款中高端芯片，CPU和APU的算力在移动端算是第一梯队，但要把一个几亿参数的大模型塞进去跑起来，中间要过的坎比想象中多得多。

这篇文章就是把这几个月踩过的坑、试过的方案、最终跑通的流程完整记录下来。如果你也在做类似的事情——不管是MTK平台还是其他嵌入式平台，不管跑的是Qwen2.5还是别的模型——这里面的思路和操作细节应该都能直接参考。

1.2 整体流程概览

先给一个全局视角，整个部署链路可以拆成四个阶段：

• 模型获取与格式转换：拿到原始权重，转成MTK平台能吃的格式
• 量化与图优化：压缩模型体积，适配端侧算力
• 推理引擎集成：把模型塞进MTK的推理框架里
• 端到端调优：跑通之后调性能、调精度、调内存

这四个阶段不是线性的，实际做的时候经常要来回跳。比如量化之后精度掉得厉害，就得回头调整转换参数；推理引擎报错，可能要重新检查图优化的步骤。下面我按这个脉络展开，每个环节都会说清楚为什么这么做、怎么做、以及我实际遇到的情况。

2. 模型转换：从原始权重到MTK可识别格式

2.1 原始模型的获取与检查

Qwen2.5的权重从官方渠道下载下来之后，第一件事不是急着转换，而是先做一次完整的体检。我见过太多人跳过这一步，结果转换到一半报错，回头查半天发现是权重文件本身有问题。

检查清单如下：

• 文件完整性：确认所有分片文件都在，model.safetensors.index.json里的映射关系能对上
• 配置一致性：config.json里的num_hidden_layers、hidden_size、num_attention_heads这些关键参数要和权重文件的实际shape匹配
• 分词器可用性：tokenizer.json和vocab.json能正常加载，随便拿一段中文测一下编解码是否正常

我习惯用一段Python脚本快速过一遍：

from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_path = "./Qwen2.5-1.5B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained(model_path, torch_dtype=torch.float16, trust_remote_code=True) # 快速推理测试 inputs = tokenizer("你好，请介绍一下你自己。", return_tensors="pt") outputs = model.generate(**inputs, max_new_tokens=50) print(tokenizer.decode(outputs[0], skip_special_tokens=True))

这一步能跑通，说明原始权重没问题，可以进入转换环节。如果这一步就报错，先解决环境依赖和权重完整性的问题，别往下走。

2.2 转换工具链的选择与配置

MTK平台有自己的模型转换工具链，核心是把PyTorch或ONNX格式的模型转成MTK推理引擎能加载的格式。这里有个关键决策点：走ONNX中转还是直接用MTK的原生转换器。

我两种都试过，说下实际感受。走ONNX中转的好处是通用性强，ONNX生态成熟，调试工具多，中间出了问题容易定位。缺点是转换链路长，PyTorch到ONNX、ONNX再到MTK格式，每一步都可能引入精度损失或算子不兼容。直接用MTK原生转换器链路短，但工具链的文档和社区支持相对薄弱，遇到问题排查起来费劲。

最终我选了ONNX中转方案，原因是Qwen2.5的模型结构里有几个算子MTK原生转换器支持得不够好，走ONNX可以手动干预这些算子的映射关系。

转换到ONNX的具体操作：

python -m transformers.onnx \ --model=./Qwen2.5-1.5B-Instruct \ --feature=causal-lm \ --opset=14 \ ./onnx_output/

这里有几个参数需要特别注意：

• opset版本：选14而不是最新的，因为MTK的ONNX解析器对14的支持最稳定，更高的版本反而容易出兼容性问题
• feature类型：必须是causal-lm，这是Qwen2.5的架构决定的
• 输出目录：确保有足够的磁盘空间，1.5B的模型转成ONNX大概要占3-4GB

转换完成后，用ONNX Runtime做一次推理验证：

import onnxruntime as ort import numpy as np session = ort.InferenceSession("./onnx_output/model.onnx") input_ids = np.array([[1, 2, 3, 4, 5]], dtype=np.int64) outputs = session.run(None, {"input_ids": input_ids}) print(outputs[0].shape)

这一步的输出shape应该和原始PyTorch模型一致，如果对不上，说明转换过程中有算子被错误处理了。

2.3 算子兼容性处理

Qwen2.5用到了RoPE旋转位置编码、SwiGLU激活函数、RMSNorm归一化这几个比较新的结构。ONNX标准算子集里没有直接对应的实现，需要做算子替换或自定义。

RoPE的处理是最麻烦的。ONNX没有原生的旋转位置编码算子，常见的做法是用一系列基础算子拼出来。我在转换脚本里加了一段自定义映射：

class RoPEModule(torch.nn.Module): def forward(self, x, cos, sin): # 手动实现旋转位置编码 x1, x2 = x[..., :x.shape[-1]//2], x[..., x.shape[-1]//2:] return torch.cat([x1 * cos - x2 * sin, x1 * sin + x2 * cos], dim=-1)

然后在导出ONNX时把这个模块注册进去。实测下来，这种手动展开的方式虽然增加了图的大小，但推理结果的精度和原始模型几乎一致，误差在1e-5以内。

SwiGLU和RMSNorm相对好处理，ONNX有对应的基础算子可以组合出来。关键是转换后要用onnxruntime的GraphOptimizationLevel开到最高，让运行时自动做算子融合。

注意：算子替换之后一定要做数值对比。我一般会跑100条测试样本，逐token对比原始模型和ONNX模型的输出logits，确保最大绝对误差不超过1e-4。超过这个阈值，后面量化之后精度会崩得更厉害。

3. 量化压缩：让模型在端侧跑得动

3.1 量化方案选型

1.5B的模型用FP16存储大概要3GB内存，MTK设备上根本放不下。量化是必须的，问题是选哪种量化方案。

我对比了三种主流方案：

最终选了INT8静态量化。理由是：INT4虽然体积最小，但Qwen2.5的注意力层对权重的数值范围比较敏感，INT4量化后生成质量下降明显，尤其是长文本生成时容易出现重复和逻辑断裂。INT8静态量化在精度和体积之间取得了比较好的平衡，而且MTK的APU对INT8算子的硬件加速支持最完善。

3.2 校准数据集的准备

静态量化的关键是校准数据集。校准集的质量直接决定了量化参数的合理性。我的做法是从实际业务场景里抽500-1000条文本，覆盖不同的长度和主题分布。

校准集的构建原则：

• 长度分布：短文本（10-50 token）占30%，中等长度（50-200 token）占50%，长文本（200-512 token）占20%
• 主题覆盖：如果业务场景是客服问答，校准集里就要有足够多的问答对；如果是文档摘要，就要有长文档样本
• 语言分布：中英文混合的场景，校准集里两种语言都要有

from neural_compressor import quantization from neural_compressor.config import PostTrainingQuantConfig calib_data = load_calibration_data("./calib_dataset.json", tokenizer, max_length=512) quant_config = PostTrainingQuantConfig( approach="static", calibration_sampling_size=500, op_type_dict={ ".*": {"weight": {"dtype": ["int8"]}, "activation": {"dtype": ["int8"]}}, ".*attention.*": {"weight": {"dtype": ["int8"]}, "activation": {"dtype": ["fp32"]}} } ) quantized_model = quantization.fit( model=onnx_model, quant_config=quant_config, calib_dataloader=calib_data )

注意上面配置里对attention层的特殊处理：注意力层的激活值保持FP32，只量化权重。这是因为注意力分数经过softmax之后数值范围很小，INT8的表示精度不够，强行量化会导致注意力分布偏移。

3.3 量化后的精度验证

量化完成之后，必须做严格的精度验证。我设计了一套评估流程：

1. 困惑度对比：在验证集上分别计算原始模型和量化模型的困惑度，差距控制在5%以内算合格
2. 生成质量人工评估：随机抽50条prompt，人工对比生成结果，看是否有明显的质量下降
3. 任务指标验证：如果模型用于特定任务（如分类、抽取），要在任务测试集上跑一遍指标

实测数据：Qwen2.5-1.5B在INT8静态量化后，困惑度从8.32上升到8.71，涨幅4.7%，在可接受范围内。生成质量方面，短文本生成几乎无差异，长文本生成偶尔会出现轻微的重复，但整体可用。

实操心得：量化后的模型一定要在实际设备上跑一遍再下结论。我在PC上验证精度合格，但部署到MTK设备后发现某些层的量化参数在APU上执行时会有额外的精度损失。后来在转换脚本里加了逐层的数值dump对比，才发现是APU对某些INT8算子的累加精度和PC端不一致。解决办法是把这些层的累加器位宽从INT32提到INT64，代价是推理速度慢了约8%，但精度回来了。

4. 推理引擎集成：把模型塞进MTK框架

4.1 MTK推理框架的架构理解

MTK平台的推理框架是分层设计的，从上到下大致是：

• 应用层：你的业务代码，调用推理API
• 框架层：模型加载、内存管理、任务调度
• 算子层：具体的计算算子实现
• 硬件层：CPU、APU、GPU的驱动和指令集

模型部署的核心工作是把量化后的模型映射到算子层，并确保框架层能正确调度。MTK的推理框架支持动态加载模型，但要求模型的图结构符合它的规范。

4.2 模型图的重写与适配

ONNX转过来的图不能直接喂给MTK框架，需要做几项重写：

第一，算子替换。MTK框架对某些ONNX算子的支持不完整，需要用它的原生算子重新表达。比如ONNX的LayerNormalization在MTK框架里要拆成ReduceMean、Sub、Pow、ReduceMean、Add、Sqrt、Div、Mul、Add这一串基础算子。

第二，内存布局调整。MTK的APU对NHWC布局的卷积有硬件加速，但ONNX默认是NCHW。虽然Qwen2.5主要是矩阵运算不涉及卷积，但注意力层的reshape操作会受布局影响。我在图重写阶段统一把张量布局转成APU友好的格式。

第三，常量折叠。把推理过程中不变的子图提前算出来，减少运行时的计算量。比如RoPE的cos/sin表，可以在加载阶段就预计算好。

import mtk_inference as mtk # 加载ONNX模型 graph = mtk.Graph() graph.load_onnx("./quantized_model.onnx") # 算子替换 graph.replace_op("LayerNormalization", "MTK_LayerNorm") graph.replace_op("Gelu", "MTK_Gelu") # 布局转换 graph.convert_layout("NCHW", "NHWC") # 常量折叠 graph.constant_folding() # 保存适配后的模型 graph.save("./mtk_model.bin")

4.3 内存管理与分配策略

MTK设备的内存是稀缺资源，推理过程中的内存分配策略直接影响能不能跑起来。

我的做法是：

• 权重内存：量化后的权重约1.5GB，用mmap方式加载，避免一次性拷贝到堆内存
• 激活内存：预分配一块固定大小的内存池，推理时复用，避免频繁malloc/free
• KV Cache：Qwen2.5是自回归生成，KV Cache会随生成长度增长。我设置了最大生成长度512，预分配对应的KV Cache空间

# 内存池配置 memory_pool = mtk.MemoryPool( weight_size=1.5 * 1024**3, # 1.5GB activation_size=256 * 1024**2, # 256MB kv_cache_size=128 * 1024**2, # 128MB max_seq_length=512 ) # 模型加载时绑定内存池 model = mtk.load_model("./mtk_model.bin", memory_pool=memory_pool)

注意：KV Cache的大小要按最坏情况预估。Qwen2.5-1.5B有28层，每层KV Cache的维度是[batch, num_heads, seq_len, head_dim]。按batch=1、num_heads=12、head_dim=128、seq_len=512算，单层KV Cache是1.5MB，28层就是42MB。我预留128MB是留了余量，防止多轮对话时缓存溢出。

4.4 推理接口的封装

模型加载好之后，需要封装一个干净的推理接口给上层业务调用。我设计的接口长这样：

class QwenInference: def __init__(self, model_path, tokenizer_path): self.model = mtk.load_model(model_path) self.tokenizer = AutoTokenizer.from_pretrained(tokenizer_path) self.max_new_tokens = 512 self.temperature = 0.7 self.top_p = 0.9 def generate(self, prompt, max_new_tokens=None): input_ids = self.tokenizer.encode(prompt, return_tensors="np") output_ids = self.model.generate( input_ids, max_new_tokens=max_new_tokens or self.max_new_tokens, temperature=self.temperature, top_p=self.top_p ) return self.tokenizer.decode(output_ids[0], skip_special_tokens=True) def stream_generate(self, prompt): # 流式生成，逐token返回 input_ids = self.tokenizer.encode(prompt, return_tensors="np") for token_id in self.model.stream_generate(input_ids): yield self.tokenizer.decode([token_id], skip_special_tokens=True)

流式生成在端侧场景里特别重要。用户等一个完整回答可能要好几秒，但流式输出可以让首token延迟降到几百毫秒，体验上差别很大。

5. 性能调优与问题排查实录

5.1 首token延迟优化

首token延迟是端侧大模型最关键的体验指标。我实测下来，Qwen2.5-1.5B在MTK设备上的首token延迟从最初的2.3秒优化到了680毫秒，主要做了这几件事：

预填充优化。prompt的prefill阶段是计算密集型的，MTK的APU对矩阵乘有硬件加速，但需要把输入padding到对齐的长度。我把padding策略从动态改为固定长度（256），虽然浪费了一点计算，但避免了动态shape带来的调度开销。

算子融合。把连续的MatMul + Add + Gelu融合成一个算子，减少kernel launch次数。MTK框架支持自定义算子融合规则，我在图优化阶段加了一条规则：

graph.fuse_pattern( pattern=["MatMul", "Add", "Gelu"], fused_name="MTK_FusedMLP" )

权重预加载。第一次推理时权重从存储加载到内存有IO开销，我在应用启动时就触发一次预热推理，把权重全部加载到内存。

5.2 生成阶段的吞吐优化

生成阶段是逐token的，瓶颈在内存带宽而不是算力。优化手段：

• KV Cache量化：把KV Cache也量化到INT8，内存占用减半，带宽压力降低
• 投机采样：用一个更小的草稿模型（比如Qwen2.5-0.5B）先生成几个候选token，再用主模型验证。实测能提升1.8倍的生成速度
• 批处理：如果业务场景支持，把多个请求拼成一个batch，提高APU利用率

投机采样的实现稍微复杂一点，核心逻辑：

def speculative_generate(draft_model, target_model, prompt, gamma=4): input_ids = tokenizer.encode(prompt) while len(input_ids) < max_length: # 草稿模型生成gamma个候选 draft_tokens = draft_model.generate(input_ids, max_new_tokens=gamma) # 主模型验证 target_logits = target_model.forward(input_ids + draft_tokens) # 接受或拒绝 accepted = verify_tokens(draft_tokens, target_logits) input_ids.extend(accepted) if len(accepted) < gamma: break return input_ids

5.3 常见问题速查表

5.4 几个踩过的坑

坑一：量化后的模型在PC上正常，在设备上输出乱码。排查了两天才发现是MTK的APU对INT8的饱和运算和PC端不一致。某些层的激活值在PC上刚好没溢出，在APU上因为累加顺序不同溢出了。解决办法是在量化配置里对这些层加clip，限制激活值的范围。

坑二：流式生成时首token之后卡顿。原因是KV Cache在第一次生成后没有正确复用，每次生成新token都重新计算了整个序列的KV。修复方法是确保KV Cache的索引正确递增。

坑三：模型在低电量模式下推理速度骤降。MTK的电源管理策略会在低电量时限制APU频率。如果业务场景对性能有硬性要求，需要在应用层申请性能模式，或者引导用户充电。

实操心得：端侧部署一定要在真实设备上做长时间稳定性测试。我遇到过连续推理2小时后内存泄漏的问题，原因是KV Cache的释放逻辑有bug，每次对话结束后没有完全释放。这种问题在短时间测试里根本发现不了。

6. 实际效果与后续扩展方向

6.1 最终的性能数据

经过完整优化后，Qwen2.5-1.5B在MTK设备上的表现：

• 模型体积：1.5GB（INT8量化后）
• 内存占用：峰值约2.1GB（含KV Cache和运行时开销）
• 首token延迟：680ms（prompt长度128）
• 生成速度：18 tokens/s
• 连续推理稳定性：8小时无崩溃、无内存泄漏

这个数据对于端侧场景来说已经可用了。离线问答、文本摘要、简单的对话交互都能撑住。

6.2 还能怎么优化

如果对性能有更高要求，还有几个方向可以挖：

模型蒸馏。用Qwen2.5-7B作为教师模型，蒸馏一个更小的学生模型，专门针对业务场景优化。蒸馏后的模型可能只有0.5B，但特定任务上的表现接近1.5B。

混合精度量化。对不同层用不同的量化精度，敏感的层用INT8，不敏感的层用INT4。这样能在精度和体积之间找到更优的平衡点。

硬件协同设计。如果设备是自研的，可以在芯片设计阶段就考虑大模型推理的需求，比如增加专用的矩阵乘单元、扩大片上缓存。

动态推理。根据输入复杂度动态选择模型大小，简单问题用0.5B，复杂问题用1.5B。这样平均延迟和功耗都能降下来。

6.3 一些个人体会

做端侧大模型部署这几个月，最大的感受是：端侧和云端的优化思路完全不同。云端可以堆算力、堆内存，优化重点是吞吐和成本；端侧资源受限，优化重点是延迟和内存，很多时候要在精度上做妥协。

另一个体会是工具链的成熟度决定效率。MTK的推理框架相比一些主流方案还有差距，文档不够全、调试工具不够好用，很多问题要靠自己摸索。但这也意味着先跑通的人有先发优势，踩过的坑都是壁垒。

最后说一个实际建议：如果你刚开始做端侧大模型部署，不要一上来就追求大模型。先从0.5B的小模型跑通全流程，把转换、量化、集成、调优的每个环节都摸一遍，再往上换大模型。这样遇到问题的时候，你能快速定位是模型本身的问题还是流程的问题。