端侧大模型部署工程师：从模型量化到NPU适配的硬核实战

1. 端侧大模型部署工程师到底是个什么岗位

第一次听到“端侧大模型部署工程师”这个title，很多人脑子里冒出来的第一反应是：这不就是把模型塞到手机或者开发板上跑起来吗，能有多难？我刚开始也这么想，直到自己真正把一个7B模型往一块算力只有几TOPS的NPU上搬的时候，才发现这里面的水比想象中深得多。端侧大模型部署工程师，说白了就是负责把训练好的大模型经过一系列压缩、转换、适配、调优之后，让它能在手机、PC、车机、IoT设备这些终端上稳定高效推理的人。这个岗位卡在算法和底层硬件之间，往上要懂模型结构、量化原理，往下要懂NPU指令集、内存带宽、算子融合，中间还得跟推理框架和工具链打交道。

为什么这个岗位突然变得抢手？核心原因就一个：云端推理的成本和延迟已经撑不住大规模AI应用的落地了。你想想，一个日活千万的App，每次对话都往云端发请求，光是GPU推理成本和网络延迟就够喝一壶的。而端侧推理的好处是实打实的——数据不出本地，隐私有保障；不需要网络往返，响应快；不占用云端算力，边际成本趋近于零。但问题在于，端侧的算力、内存、功耗都是硬约束，一个在A100上跑得好好的模型，直接搬到手机上可能连加载都加载不起来。这中间的鸿沟，就是端侧部署工程师要填的。

这个岗位适合谁来？我观察下来，目前主要有三类人往这个方向转：一是原来做移动端AI的工程师，比如搞TFLite、NCNN、MNN的那批人，他们对端侧推理框架很熟，但大模型时代的量化技术和算子适配需要补课；二是做模型压缩和量化的算法工程师，他们对量化原理门清，但对底层硬件和推理引擎的调度逻辑不够了解；三是做嵌入式或者驱动开发的工程师，他们对NPU硬件很熟，但大模型的transformer结构、KV Cache、注意力机制这些需要从头学。三类人各有短板，但只要能补齐交叉领域的知识，就是市场上最抢手的那种。

这个岗位目前最大的特点是：没有标准答案。每家的NPU架构不一样，每家的推理框架不一样，每个模型的算子集也不一样，你很难找到一篇“照着做就行”的教程。真正值钱的能力，是面对一个全新的芯片和模型时，能快速定位瓶颈并给出优化方案。

2. 核心硬功夫拆解：从模型量化到NPU适配

2.1 模型量化：不是简单地把FP32砍成INT8

模型量化是端侧部署的第一道关，也是最能体现功力的地方。很多人以为量化就是把权重从FP32转成INT8，精度掉一点就掉一点，没什么大不了的。但实际操作中，量化的策略选择直接影响模型能不能跑、跑得多快、效果掉多少。

先说最基本的两种量化方式：训练后量化（PTQ）和量化感知训练（QAT）。PTQ就是拿训练好的模型直接做量化，不需要重新训练，速度快、成本低，适合快速验证。QAT是在训练过程中模拟量化误差，让模型提前适应低精度表示，精度保持更好，但需要重新训练，成本高。端侧部署工程师大部分时候先用PTQ跑一遍看看效果，如果精度掉得太多再考虑QAT。

PTQ里面又分动态量化和静态量化。动态量化只量化权重，激活值在推理时动态计算量化参数，实现简单但加速有限。静态量化需要校准数据集来提前统计激活值的分布范围，推理时直接用固定的量化参数，速度更快但需要额外的校准步骤。校准数据集的选择很关键，一般从训练集里随机抽几百条就够了，但分布要覆盖实际推理场景。我踩过的坑是：用了一个领域的校准数据去量化另一个领域的模型，结果精度直接崩了。

量化粒度的选择也很讲究。per-tensor量化是整个张量共用一个scale和zero-point，实现简单但精度损失大。per-channel量化是每个通道有自己的量化参数，精度好很多，但需要硬件支持。现在主流的NPU基本都支持per-channel量化，所以优先选这个。还有更细的per-group量化，比如group size设为128，在精度和开销之间取平衡，LLM领域用得比较多。

# 以PyTorch的量化工具为例，展示静态量化的基本流程 import torch from torch.quantization import get_default_qconfig, prepare, convert # 选择量化配置，x86平台用fbgemm，ARM平台用qnnpack qconfig = get_default_qconfig('qnnpack') # 准备模型，插入观察节点 model.eval() model.qconfig = qconfig model_prepared = prepare(model) # 用校准数据跑一遍，收集激活值分布 with torch.no_grad(): for data in calibration_loader: model_prepared(data) # 转换为量化模型 model_quantized = convert(model_prepared)

这段代码看起来简单，但实际跑的时候你会发现很多算子不支持量化，需要手动替换或者用自定义算子。而且PyTorch的量化工具链对transformer结构的支持一直不太完善，很多时候需要转到ONNX再用其他工具处理。

量化最容易被忽视的一点是：精度评估不能只看 perplexity。Perplexity掉了0.1可能在实际对话中完全感知不到，但某些关键任务的准确率可能掉10个点。一定要针对你的实际应用场景做端到端的评估。

2.2 推理框架选型：没有银弹，只有取舍

端侧推理框架的选择，直接决定了你后面所有工作的难度和工作量。目前主流的几个框架各有优劣，我按实际使用体验来说。

ONNX Runtime是通用性最好的选择，支持多种硬件后端，从CPU到GPU到NPU都有对应的Execution Provider。它的优势是生态成熟、文档齐全、社区活跃，模型转换的坑相对少。但缺点是针对特定NPU的优化不够深入，性能往往不是最优的。而且ONNX Runtime的移动端包体积偏大，对资源紧张的设备不太友好。

MNN是阿里开源的轻量级推理引擎，在移动端表现很好，包体积小、启动快、内存占用低。它对ARM CPU的优化很到位，也支持部分NPU后端。但MNN对大模型的支持相对较新，一些最新的量化技术和算子融合策略可能没有及时跟进。

NCNN是腾讯开源的，在手机端部署小模型非常成熟，性能稳定。但NCNN的设计初衷是CNN，对transformer结构的支持是后来加的，一些注意力相关的算子优化不如专门做大模型的框架。

TFLite在Android生态里集成度最好，Google的NPU委托支持也在不断完善。但TFLite的量化工具链和PyTorch的配合有时候不太顺畅，模型转换过程中容易出问题。

厂商自研框架，比如高通的QNN、联发科的NeuroPilot、华为的CANN，这些框架对自家NPU的优化是最深的，性能通常最好。但缺点是绑定特定硬件，换一个平台就要重新适配，而且文档和社区支持参差不齐。

我的建议是：如果目标是快速验证和跨平台部署，优先选ONNX Runtime；如果追求极致性能和包体积，选MNN或NCNN；如果绑定特定芯片平台，直接用厂商框架。实际项目中经常是组合使用，比如用ONNX Runtime做原型验证，最终部署时转到厂商框架。

2.3 NPU适配：最容易被低估的硬骨头

NPU适配是端侧部署里最考验底层功力的环节。很多人以为NPU就是一个更快的CPU，把模型丢进去就能跑。实际上，NPU的架构和CPU/GPU差异巨大，它的优势在于矩阵乘法和卷积的并行计算，但弱点也很明显：算子支持有限、内存管理严格、调试手段匮乏。

先说算子支持。NPU通常只支持有限的一组算子，而且每个算子还有特定的输入输出格式要求。比如很多NPU要求卷积的输入是NHWC格式，而PyTorch默认是NCHW，转换的时候需要额外处理。再比如transformer里的LayerNorm、GELU、Softmax这些算子，有些NPU不支持或者只支持特定变体，需要手动拆解或者用近似实现替代。

内存管理是另一个大坑。NPU的片上内存（SRAM）通常很小，可能只有几MB，而大模型的权重动辄几个GB。这就需要在推理过程中不断在DRAM和SRAM之间搬运数据，搬运的开销往往成为瓶颈。优化策略包括算子融合（把多个小算子合并成一个大算子，减少中间结果的搬运）、权重重排（把权重按NPU友好的顺序排列，提高访问效率）、分块计算（把大矩阵乘法拆成小块，适配SRAM容量）。

调试手段匮乏是NPU开发最让人头疼的地方。CPU上你可以打断点、看变量、单步执行，NPU上这些都没有。你只能通过性能计数器看一些宏观指标，比如MAC利用率、内存带宽占用、各算子的耗时。出了问题只能靠经验和二分法排查。我遇到过最诡异的一个bug是：模型在模拟器上跑得好好的，上真机就输出全零，查了两天才发现是某个算子的输入地址没有对齐到NPU要求的边界。

# 以某厂商NPU工具链为例，展示模型转换和性能分析的基本命令 # 转换ONNX模型到NPU格式 npu_converter --input model.onnx --output model.npu \ --quantize int8 --calibration_data calib/ \ --target_platform npu_v3 # 查看模型在各层的耗时分布 npu_profiler --model model.npu --input test_input.bin \ --output profile.json --iterations 100 # 分析性能瓶颈 npu_analyzer --profile profile.json --report bottleneck

这些命令看起来简单，但每个参数背后都有讲究。比如量化校准数据的选择、目标平台的版本匹配、profiler的采样频率设置，都会影响最终结果。

NPU适配的一个核心原则是：尽量让NPU做它擅长的事，不擅长的交给CPU。比如一些控制逻辑、动态shape处理、后处理逻辑，放在CPU上反而更快。不要试图把所有计算都塞给NPU。

3. 实操全流程：把一个LLM部署到端侧NPU上

3.1 环境准备与工具链搭建

假设我们现在要把一个7B参数的LLM部署到一块支持INT8量化的端侧NPU上。整个流程大致分为：模型导出、量化校准、格式转换、NPU编译、真机部署、性能调优六个阶段。

环境准备阶段，你需要的东西包括：训练框架（PyTorch为主）、模型转换工具（ONNX导出）、量化工具（厂商提供的或者开源的）、NPU编译工具链、真机调试环境。这里最容易出问题的是版本匹配。PyTorch的版本、ONNX的opset版本、量化工具的版本、NPU工具链的版本，这四个版本之间往往有严格的对应关系，错一个就可能导致转换失败。

我一般会先建一个干净的conda环境，把版本锁死。比如PyTorch 2.1 + ONNX opset 17 + 厂商工具链v3.2，这个组合是我验证过比较稳定的。然后写一个导出脚本，把模型转成ONNX格式。

# 导出LLM到ONNX，注意处理KV Cache的动态维度 import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name = "your-llm-model" model = AutoModelForCausalLM.from_pretrained(model_name, torch_dtype=torch.float32) tokenizer = AutoTokenizer.from_pretrained(model_name) # 构造示例输入 dummy_input = tokenizer("Hello", return_tensors="pt") input_ids = dummy_input["input_ids"] attention_mask = dummy_input["attention_mask"] # 导出ONNX，注意设置动态轴 torch.onnx.export( model, (input_ids, attention_mask), "model.onnx", opset_version=17, input_names=["input_ids", "attention_mask"], output_names=["logits"], dynamic_axes={ "input_ids": {0: "batch", 1: "sequence"}, "attention_mask": {0: "batch", 1: "sequence"}, "logits": {0: "batch", 1: "sequence"} } )

导出的时候有几个坑要注意。第一，LLM的KV Cache在ONNX里通常用past_key_values来表示，但不同版本的transformers导出方式不一样，需要确认你的工具链支持哪种格式。第二，动态轴的设置要跟NPU工具链的要求匹配，有些工具链不支持某些维度的动态shape。第三，导出后的ONNX模型要用onnxsim做一下简化，去掉冗余算子，否则NPU编译器可能处理不了。

3.2 量化校准与精度验证

模型导出成ONNX之后，下一步是量化校准。这一步的目标是收集激活值的分布范围，为每个张量计算合适的scale和zero-point。校准数据集的选择直接决定量化精度，我一般会从实际业务数据里抽500到1000条，覆盖各种输入长度和内容类型。

# 使用ONNX Runtime的量化工具做静态量化 from onnxruntime.quantization import quantize_static, CalibrationDataReader import numpy as np class LLMCalibrationReader(CalibrationDataReader): def __init__(self, calibration_texts, tokenizer, max_length=512): self.data = [] for text in calibration_texts: inputs = tokenizer(text, return_tensors="np", max_length=max_length, truncation=True) self.data.append({ "input_ids": inputs["input_ids"].astype(np.int64), "attention_mask": inputs["attention_mask"].astype(np.int64) }) self.index = 0 def get_next(self): if self.index >= len(self.data): return None data = self.data[self.index] self.index += 1 return data # 执行量化 calibration_reader = LLMCalibrationReader(calib_texts, tokenizer) quantize_static( model_input="model.onnx", model_output="model_quantized.onnx", calibration_data_reader=calibration_reader, quant_format=QuantFormat.QDQ, # 或QOperator per_channel=True, weight_type=QuantType.QInt8, activation_type=QuantType.QInt8 )

量化完成之后，一定要做精度验证。我一般会跑三个指标：perplexity（衡量语言建模能力）、任务准确率（比如问答、分类的准确率）、生成质量（人工评估或者用GPT-4打分）。如果精度掉得太多，可以考虑混合精度量化——对敏感层保持FP16，其他层用INT8。敏感层的识别可以通过分析每层量化后的误差贡献来做。

校准数据的一个常见误区是：只用短文本校准。LLM在实际使用中经常处理长文本，如果校准数据全是短句，长序列上的激活值分布可能完全不一样，导致量化精度在长文本上崩掉。建议校准数据里至少包含20%的长文本。

3.3 NPU编译与真机部署

量化后的ONNX模型需要经过NPU编译器转换成NPU能执行的格式。这个过程通常包括：图优化（算子融合、常量折叠、死代码消除）、算子映射（把ONNX算子映射到NPU算子）、内存分配（为每个张量分配片上或片外内存）、指令生成（生成NPU能执行的指令序列）。

# NPU编译流程示例 # 第一步：图优化和算子映射 npu_compiler --input model_quantized.onnx \ --output model_optimized.npu \ --config npu_config.json \ --verbose # 第二步：内存分配和指令生成 npu_linker --input model_optimized.npu \ --output model_final.npu \ --memory_plan auto \ --target_device npu_v3 # 第三步：真机部署和验证 npu_deploy --model model_final.npu \ --device /dev/npu0 \ --input test_input.bin \ --output test_output.bin

编译过程中最常见的错误是算子不支持。NPU编译器会告诉你哪些算子无法映射，你需要手动替换或者用CPU fallback。另一个常见问题是内存超限，NPU的片上内存不够放下整个模型，需要做分块或者用片外内存。片外内存的访问延迟高很多，会严重影响性能，所以尽量把频繁访问的数据放在片上。

真机部署的时候，我习惯先用一个小输入跑通流程，确认输出正确之后再上完整测试。验证输出正确性的时候，不要只看最终结果，要逐层对比NPU输出和CPU参考实现的差异。如果某一层误差突然变大，说明那个算子的量化或者映射有问题。

3.4 性能调优与瓶颈定位

模型跑通只是第一步，性能调优才是真正拉开差距的地方。端侧LLM的性能瓶颈通常不在计算，而在内存带宽。因为LLM是自回归生成，每生成一个token都要把整个模型的权重读一遍，权重读取的带宽需求远大于计算需求。

优化策略主要有几个方向。权重量化是最直接的，INT8量化能把权重体积压缩到FP32的四分之一，带宽需求也相应降低。权重重排是把权重按NPU友好的顺序排列，提高缓存命中率。算子融合是把多个连续的小算子合并成一个大算子，减少中间结果的读写。KV Cache优化是LLM特有的，把KV Cache量化或者用更紧凑的格式存储，减少内存占用和带宽消耗。

# KV Cache量化的简化示例 class QuantizedKVCache: def __init__(self, max_batch, max_seq, num_heads, head_dim): self.max_batch = max_batch self.max_seq = max_seq self.num_heads = num_heads self.head_dim = head_dim # 用INT8存储KV Cache self.k_cache = np.zeros((max_batch, num_heads, max_seq, head_dim), dtype=np.int8) self.v_cache = np.zeros((max_batch, num_heads, max_seq, head_dim), dtype=np.int8) # 每个头有自己的scale self.k_scale = np.ones((num_heads,), dtype=np.float32) self.v_scale = np.ones((num_heads,), dtype=np.float32) def update(self, new_k, new_v, position): # 量化后存入 quantized_k = np.clip(new_k / self.k_scale[:, None, None], -128, 127).astype(np.int8) quantized_v = np.clip(new_v / self.v_scale[:, None, None], -128, 127).astype(np.int8) self.k_cache[:, :, position:position+1, :] = quantized_k self.v_cache[:, :, position:position+1, :] = quantized_v def get(self, start, end): # 反量化后返回 k = self.k_cache[:, :, start:end, :].astype(np.float32) * \ self.k_scale[:, None, None] v = self.v_cache[:, :, start:end, :].astype(np.float32) * \ self.v_scale[:, None, None] return k, v

性能调优的时候，一定要用profiler工具看数据，不要凭感觉猜。我见过太多人花大量时间优化计算部分，结果发现瓶颈根本不在计算，而在内存搬运。NPU的profiler通常能给出每个算子的耗时、内存带宽占用、MAC利用率等指标，根据这些指标定位瓶颈才靠谱。

4. 常见问题与排查技巧实录

4.1 模型转换失败：从报错信息定位根因

模型转换失败是端侧部署最高频的问题，没有之一。报错信息往往很模糊，比如“unsupported operator”或者“shape mismatch”，但具体是哪个算子、哪个维度，需要你自己去查。

我整理了一个常见转换错误和排查思路的对照表：

排查转换问题的时候，我习惯用二分法：先把模型截断到一半，看能不能转换成功，如果能，说明问题在后半部分，再继续二分。这个方法虽然笨，但很有效。另一个技巧是用ONNX Runtime先跑一遍量化后的模型，确认ONNX层面没问题，再把问题范围缩小到NPU编译器。

一个容易被忽视的点是：ONNX的opset版本和NPU工具链支持的opset版本可能不一致。比如你用opset 17导出的模型，NPU工具链只支持到opset 15，那就会有很多算子无法识别。导出的时候一定要确认目标opset版本。

4.2 精度掉点：量化不是越激进越好

量化后精度掉点是另一个高频问题。很多人为了追求速度，把能量化的都量化了，结果模型效果惨不忍睹。我的经验是：权重可以大胆量化，激活值要谨慎。权重的分布相对稳定，INT8量化通常没问题；激活值的分布受输入影响很大，量化误差更容易累积。

如果精度掉得太多，可以尝试以下策略。第一，混合精度量化：对敏感层保持FP16，其他层INT8。敏感层的识别可以通过逐层量化、观察精度变化来做。第二，更细的量化粒度：从per-tensor改成per-channel，或者用group-wise量化。第三，更好的校准方法：用KL散度或者MSE来优化scale和zero-point，而不是简单的min-max。第四，QAT微调：如果PTQ怎么调都不行，只能用QAT重新训练了。

# 逐层敏感度分析的简化示例 def layer_sensitivity_analysis(model, calibration_data, eval_fn): """逐层量化，观察精度变化，识别敏感层""" baseline_score = eval_fn(model, calibration_data) sensitivity = {} for name, module in model.named_modules(): if not isinstance(module, (nn.Linear, nn.Conv2d)): continue # 只量化当前层 original_weight = module.weight.data.clone() module.weight.data = quantize_tensor(original_weight) score = eval_fn(model, calibration_data) sensitivity[name] = baseline_score - score # 恢复 module.weight.data = original_weight # 按敏感度排序 sorted_layers = sorted(sensitivity.items(), key=lambda x: x[1], reverse=True) return sorted_layers

这个分析跑起来比较慢，但能帮你精准定位哪些层不能量化。实际项目中，我一般会把敏感度最高的10%的层保持FP16，其余层INT8，这样精度和速度的平衡最好。

4.3 性能不达预期：瓶颈可能在你想不到的地方

模型跑起来了，精度也还行，但速度就是上不去，这是最让人抓狂的情况。性能问题通常有以下几个来源，按出现频率排序：

内存带宽瓶颈是最常见的。LLM的权重读取量巨大，如果NPU的内存带宽不够，计算单元再快也没用。判断方法很简单：看profiler里内存带宽的利用率，如果接近100%，那就是带宽瓶颈。解决办法包括权重量化、权重重排、算子融合。

算子调度开销是第二常见的。每个算子的启动都有固定开销，如果模型里有很多小算子，调度开销可能超过计算本身。解决办法是算子融合，把多个小算子合并成一个大算子。NPU编译器通常会自动做算子融合，但有些情况下需要手动指定融合策略。

CPU-NPU数据搬运是第三常见的。如果模型的一部分在NPU上跑，一部分在CPU上跑，两者之间的数据搬运会成为瓶颈。解决办法是尽量减少CPU fallback的算子数量，或者把CPU部分的计算也放到NPU上。

动态shape处理是LLM特有的问题。LLM的输入长度是动态的，NPU通常对动态shape支持不好，每次shape变化都要重新编译或者重新分配内存。解决办法是固定shape，把输入padding到固定长度，或者用多个固定shape的模型覆盖不同的长度范围。

# 用profiler定位瓶颈的典型流程 # 1. 跑一遍完整推理，收集性能数据 npu_profiler --model model.npu --input input.bin --output profile.json # 2. 查看各算子的耗时分布 npu_analyzer --profile profile.json --report operator_time # 3. 查看内存带宽占用 npu_analyzer --profile profile.json --report memory_bandwidth # 4. 查看MAC利用率 npu_analyzer --profile profile.json --report mac_utilization

根据profiler的输出，你可以快速定位瓶颈在哪个环节。如果某个算子的耗时特别长，可能是那个算子的实现有问题；如果内存带宽利用率很高，说明是带宽瓶颈；如果MAC利用率很低，说明计算单元在等数据。

4.4 真机与模拟器不一致：最让人崩溃的坑

模拟器上跑得好好的，上真机就出问题，这是端侧部署最让人崩溃的情况。不一致的表现有很多种：输出全零、输出乱码、精度大幅下降、直接崩溃。

造成不一致的原因通常有这几个。内存对齐：模拟器可能不检查内存对齐，真机有严格要求。浮点精度：模拟器可能用FP32模拟，真机是FP16或者INT8，精度差异导致结果不同。算子实现差异：模拟器和真机的算子实现可能不一样，特别是边界情况。时序问题：真机上多个算子可能并行执行，如果存在数据依赖没处理好，会出现竞态条件。

排查这类问题，我一般用以下步骤。第一，用最小输入跑通，确认基本功能正常。第二，逐层对比模拟器和真机的输出，找到第一个出现差异的层。第三，针对那个层，检查输入输出格式、内存对齐、量化参数。第四，如果还找不到原因，把那个层单独拿出来做一个最小复现，逐步缩小范围。

真机调试的一个实用技巧是：在模型里插入“探针”算子，把中间结果输出到文件，然后跟模拟器的中间结果对比。虽然麻烦，但能精确定位问题层。

5. 这个岗位的未来与个人成长路径

端侧大模型部署工程师这个岗位，目前还处于非常早期的阶段。市场上的需求远大于供给，一个能独立完成端侧LLM部署的工程师，薪资水平已经对标甚至超过了很多算法岗。但这也意味着，这个岗位的知识体系还在快速变化，今天好用的工具和方法，明天可能就被新的替代了。

从技术趋势来看，几个方向值得关注。NPU的算力在快速提升，今年主流端侧NPU的算力大概是10到20 TOPS，明年可能翻倍，这意味着更大的模型可以在端侧跑。量化技术在不断进步，从INT8到INT4甚至INT2，精度损失越来越小。推理框架在快速迭代，各家都在针对LLM做专门优化，比如PagedAttention、Continuous Batching这些技术正在从云端下沉到端侧。工具链在逐步成熟，模型转换和调优的自动化程度越来越高。

对于想进入这个领域的人，我的建议是：不要只学一个框架或者一个芯片平台，要掌握底层原理。因为工具会变，但原理不会变。量化为什么会影响精度、NPU为什么对某些算子支持不好、内存带宽为什么是瓶颈，这些问题的答案在不同平台上都是相通的。掌握了原理，换一个平台你也能快速上手。

另外，动手能力比理论知识更重要。这个岗位的很多坑，只有自己踩过才知道。看再多的文档，不如自己把一个模型从PyTorch搬到NPU上跑一遍。过程中遇到的各种报错、精度问题、性能瓶颈，都是最好的学习材料。

我个人在实际操作中的体会是：端侧部署是一个需要耐心的活。一个模型从导出到最终上线，可能要经过几十次转换、量化、调优的迭代。每次迭代可能只提升几个百分点的性能，但积累起来就是巨大的差距。那些能沉下心来，一个算子一个算子地抠、一个参数一个参数地调的人，最终会成为这个领域最稀缺的人才。

最后分享一个小技巧：建立一个自己的“踩坑笔记”，把每次遇到的问题、排查过程、解决方法都记下来。端侧部署的问题往往有很强的相似性，今天在这个模型上遇到的问题，明天可能在另一个模型上重现。有一个积累的笔记，能帮你节省大量时间。我自己的笔记已经记了几百条，从算子不支持到内存对齐，从量化精度到性能瓶颈，每次翻看都能有新收获。