模型部署这件事真正踩过坑的人都知道训练只是上半场推理落地才是下半场。我最近在做一个英译中的离线翻译功能模型是从 HuggingFace 上拉的一个预训练英译中模型原本用 PyTorch 直接推理也能跑但一旦要集成到端侧或者嵌入式设备上PyTorch 那套运行时依赖就显得太重了。于是我把目光转向了 ONNX把 HuggingFace 的英译中模型迁移到 ONNX 格式再用 ONNX Runtime 做推理。整个过程踩了不少坑从模型导出、算子兼容、动态轴设置到量化压缩、推理验证每一步都有细节值得说。这篇文章就把我完整的迁移过程拆开来讲适合正在做模型部署、端侧推理、或者想把 Transformer 类模型从 PyTorch 迁到 ONNX 的同行参考。不管你是刚接触 ONNX 的新手还是已经用过 ONNX Runtime 的老手应该都能从里面找到一些能直接抄作业的东西。1. 为什么要做这次迁移从 PyTorch 到 ONNX 的动机拆解1.1 英译中模型的部署困境先说说我面对的实际场景。这个英译中模型是基于 Transformer 架构的序列到序列模型编码器负责理解英文输入解码器负责逐 token 生成中文翻译。在 HuggingFace 上用transformers库加载几行代码就能跑起来推理开发阶段确实舒服。但问题出在部署环节。PyTorch 的运行时体积大一个完整的 PyTorch 环境动辄几个 GB如果只是为了一次翻译推理这个开销实在不划算。而且 PyTorch 在不同硬件平台上的适配成本高尤其是要往移动端或者边缘设备上放的时候依赖链会变得非常复杂。另外PyTorch 默认的推理模式没有做图优化算子融合、内存复用这些都没有充分做推理延迟和内存占用都有优化空间。ONNX 的出现正好解决了这几个痛点。ONNX 是一种开放的模型交换格式它把模型的计算图用一种与框架无关的方式描述出来。导出成 ONNX 之后模型可以用 ONNX Runtime 来推理而 ONNX Runtime 是一个专门为推理优化的运行时体积小、启动快、跨平台支持好。更关键的是ONNX Runtime 支持多种执行提供者Execution Provider比如 CPU、CUDA、TensorRT 等切换硬件后端只需要换个配置不用改模型代码。1.2 ONNX 迁移的核心价值把 HuggingFace 的英译中模型迁到 ONNX核心价值体现在三个层面。第一是部署轻量化。ONNX Runtime 的 CPU 版本安装包只有几十 MB相比 PyTorch 的 GB 级别差距是数量级的。这对于端侧部署、容器镜像瘦身、冷启动优化都有直接帮助。第二是推理性能提升。ONNX Runtime 内置了图层面的优化包括算子融合、常量折叠、内存规划等。实测下来同一个英译中模型ONNX Runtime 的 CPU 推理速度比 PyTorch 默认模式快 1.5 到 2 倍如果开启量化还能进一步压缩模型体积和加速。第三是跨平台一致性。ONNX 作为中间表示可以在 Windows、Linux、macOS、Android、iOS 等多个平台上用同一份模型文件推理行为一致不需要为每个平台单独适配。这对于需要多端部署的项目来说省了大量的重复工作。1.3 迁移前需要想清楚的问题不过迁移不是无脑导出就完事。动手之前有几个问题必须先想清楚。模型结构是否支持导出。Transformer 类模型整体是支持 ONNX 导出的但要注意一些自定义算子或者动态控制流可能会出问题。HuggingFace 的transformers库提供了torch.onnx.export的封装大部分标准模型都能直接导出但英译中这种 seq2seq 模型涉及编码器和解码器两部分导出策略需要仔细设计。动态轴怎么设置。翻译任务的输入长度是可变的batch size 也可能变化所以导出时必须把序列长度和 batch 维度设为动态轴否则模型只能处理固定长度的输入实用性大打折扣。解码策略怎么处理。seq2seq 模型的推理涉及自回归解码每一步生成一个 token然后拼接到输入里继续生成。这个循环逻辑是在 ONNX 图外面用 Python 写的还是想办法塞进图里需要权衡。通常的做法是导出编码器和单步解码器循环逻辑放在外面用 ONNX Runtime 的 session 调用来驱动。量化要不要做。ONNX 支持 INT8 量化可以显著压缩模型体积、加速推理但量化会带来精度损失。对于翻译任务精度损失可能表现为译文质量下降需要做量化前后的对比评估。这些问题想清楚了迁移的路线图也就清晰了。2. 环境准备与模型导出前的关键检查2.1 依赖安装与版本选择环境准备这一步看似简单但版本兼容性是后面很多问题的根源。我踩过的坑里至少有一半跟版本有关。下面是我实测下来比较稳的一套版本组合。pip install torch2.1.0 pip install transformers4.35.0 pip install onnx1.15.0 pip install onnxruntime1.16.0 pip install sentencepiece这里有几个点要说明。torch的版本和transformers的版本要匹配transformers4.35 对 torch 2.1 的支持是经过验证的。onnx和onnxruntime的版本也要注意onnxruntime1.16 支持 ONNX opset 17这个 opset 版本对 Transformer 类模型的算子覆盖比较完整。sentencepiece这个依赖容易被忽略。很多英译中模型用的是 SentencePiece 分词器如果没装这个库加载 tokenizer 的时候会报错。即使模型用的是 BERT 类的 WordPiece 分词器装上也无妨不会冲突。提示如果你在国内环境安装pip 源建议换成国内镜像否则下载 torch 这种大包会非常慢。但具体用哪个源根据你所在网络环境选择即可。2.2 模型加载与结构确认导出之前先把模型加载起来确认一下结构。这一步的目的是搞清楚模型的输入输出签名后面导出的时候要用到。from transformers import AutoTokenizer, AutoModelForSeq2SeqLM model_name your-en-zh-model tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSeq2SeqLM.from_pretrained(model_name) print(model.config) print(model)加载完之后重点看几个东西。model.config里的vocab_size、d_model、encoder_layers、decoder_layers这些参数决定了模型的规模。print(model)会打印出完整的层结构确认一下编码器和解码器的类型。对于英译中模型常见的架构是 MarianMT 或者 mBART、mT5 这类。MarianMT 是专门为翻译任务设计的结构相对简单导出比较友好。mBART 和 mT5 是通用的多语言模型参数量大导出时要注意内存占用。我这次用的是 MarianMT 架构的英译中模型编码器和解码器都是标准的 Transformer 层没有自定义算子导出难度较低。2.3 导出前的推理验证在导出之前先用 PyTorch 跑一遍推理把输入输出记下来后面 ONNX 推理的时候要对比结果确认导出没有引入误差。text The quick brown fox jumps over the lazy dog. inputs tokenizer(text, return_tensorspt) with torch.no_grad(): generated_ids model.generate( **inputs, max_length128, num_beams4, early_stoppingTrue ) pytorch_result tokenizer.decode(generated_ids[0], skip_special_tokensTrue) print(PyTorch result:, pytorch_result)这一步的输出要保存好后面 ONNX 推理出来的结果要跟这个对比。如果两者差异很大说明导出过程有问题需要排查。注意model.generate里面包含了 beam search 等解码策略这些策略在导出成 ONNX 的时候通常不会包含在图里。所以 ONNX 推理的时候解码逻辑要自己实现或者用贪心解码简化。这一点后面会详细讲。3. 核心导出流程编码器与解码器的分离导出3.1 为什么要把编码器和解码器分开导出这是整个迁移过程中最关键的一个设计决策。seq2seq 模型的推理分两个阶段编码阶段和解码阶段。编码阶段把英文输入编码成一组隐藏状态解码阶段根据这些隐藏状态自回归地生成中文 token。如果想把整个推理流程塞进一个 ONNX 图里就需要把自回归循环也表达成图的一部分。这在技术上可行但会带来几个问题。一是图会变得非常复杂包含循环控制流导出和优化都更困难。二是每次生成一个 token 都要重新跑一遍整个图效率低。三是 beam search 这类解码策略很难用静态图表达。所以更常见的做法是把编码器导出成一个 ONNX 模型把解码器的单步推理导出成另一个 ONNX 模型。推理的时候先用编码器模型跑一次得到编码器输出然后在 Python 里写循环每一步调用解码器模型生成一个 token直到遇到结束符或者达到最大长度。这种分离导出的方式灵活性高解码策略可以自由控制而且每个模型都相对简单导出成功率高。3.2 编码器导出实操先导出编码器。编码器的输入是 token ids 和 attention mask输出是最后一层的隐藏状态。import torch from transformers import AutoTokenizer, AutoModelForSeq2SeqLM model_name your-en-zh-model tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSeq2SeqLM.from_pretrained(model_name) model.eval() # 构造示例输入 dummy_text The quick brown fox jumps over the lazy dog. dummy_inputs tokenizer(dummy_text, return_tensorspt) input_ids dummy_inputs[input_ids] attention_mask dummy_inputs[attention_mask] # 导出编码器 encoder model.get_encoder() torch.onnx.export( encoder, (input_ids, attention_mask), encoder.onnx, input_names[input_ids, attention_mask], output_names[encoder_hidden_states], dynamic_axes{ input_ids: {0: batch_size, 1: sequence_length}, attention_mask: {0: batch_size, 1: sequence_length}, encoder_hidden_states: {0: batch_size, 1: sequence_length} }, opset_version17, do_constant_foldingTrue )这里有几个关键点要解释。model.get_encoder()拿到的是编码器子模块它的 forward 接受input_ids和attention_mask返回last_hidden_state。这个接口是 HuggingFace 定义好的直接拿来用就行。dynamic_axes的设置是重点。input_ids的第 0 维是 batch size第 1 维是序列长度这两个都要设成动态的。attention_mask同理。encoder_hidden_states的输出维度也要设动态因为它的序列长度跟输入相关。opset_version17是我实测下来对 Transformer 支持最好的版本。opset 太低可能不支持某些算子太高可能 ONNX Runtime 还没跟上。do_constant_foldingTrue开启常量折叠优化可以把一些在导出时就能确定的计算提前算好减小图的大小。3.3 解码器导出实操解码器的导出稍微复杂一点。解码器的输入包括当前已生成的 token ids、编码器的输出、编码器的 attention mask。输出是下一个 token 的 logits。# 构造解码器的示例输入 decoder_input_ids torch.tensor([[model.config.decoder_start_token_id]]) encoder_hidden_states encoder(input_ids, attention_mask)[0] torch.onnx.export( model.get_decoder(), (decoder_input_ids, encoder_hidden_states, attention_mask), decoder.onnx, input_names[decoder_input_ids, encoder_hidden_states, encoder_attention_mask], output_names[logits], dynamic_axes{ decoder_input_ids: {0: batch_size, 1: decoder_sequence_length}, encoder_hidden_states: {0: batch_size, 1: encoder_sequence_length}, encoder_attention_mask: {0: batch_size, 1: encoder_sequence_length}, logits: {0: batch_size, 1: decoder_sequence_length} }, opset_version17, do_constant_foldingTrue )这里有个容易踩的坑model.get_decoder()返回的解码器它的 forward 签名跟编码器不一样。它需要input_ids、encoder_hidden_states、encoder_attention_mask三个输入。而且不同版本的 transformers解码器的 forward 参数名可能略有差异导出前最好看一下源码或者用inspect.signature确认一下。还有一个坑是decoder_start_token_id。这个值在model.config里不同模型可能不一样。MarianMT 通常是pad_token_idmBART 是特定的起始 token。导出的时候用这个值构造示例输入推理的时候也要用同样的值作为解码的起始。3.4 导出后的模型检查导出完成后用onnx库检查一下模型结构确认没有异常。import onnx encoder_model onnx.load(encoder.onnx) onnx.checker.check_model(encoder_model) print(Encoder ONNX model is valid.) decoder_model onnx.load(decoder.onnx) onnx.checker.check_model(decoder_model) print(Decoder ONNX model is valid.)onnx.checker.check_model会检查模型的合法性包括算子是否支持、图的连接是否正确等。如果这一步报错说明导出有问题需要根据错误信息排查。还可以用onnx.shape_inference.infer_shapes做形状推断确认动态轴设置是否正确。from onnx import shape_inference inferred shape_inference.infer_shapes(encoder_model) for output in inferred.graph.output: print(output.name, output.type)4. ONNX Runtime 推理实现与解码循环4.1 推理环境搭建模型导出好了接下来用 ONNX Runtime 做推理。先创建 InferenceSession。import onnxruntime as ort import numpy as np encoder_session ort.InferenceSession(encoder.onnx, providers[CPUExecutionProvider]) decoder_session ort.InferenceSession(decoder.onnx, providers[CPUExecutionProvider])providers参数指定执行提供者。CPU 推理用CPUExecutionProvider如果有 GPU 可以换成CUDAExecutionProvider。切换后端只需要改这个参数模型文件不用动这就是 ONNX 的好处。4.2 编码阶段实现编码阶段的逻辑很直接把 token ids 和 attention mask 喂给编码器 session拿到编码器输出。def encode(text): inputs tokenizer(text, return_tensorsnp) input_ids inputs[input_ids].astype(np.int64) attention_mask inputs[attention_mask].astype(np.int64) encoder_outputs encoder_session.run( [encoder_hidden_states], { input_ids: input_ids, attention_mask: attention_mask } ) return encoder_outputs[0], attention_mask注意这里用的是return_tensorsnp直接返回 numpy 数组省去从 torch tensor 转换的步骤。ONNX Runtime 的输入要求是 numpy 数组dtype 要跟导出时一致通常是 int64。4.3 解码循环实现解码循环是整个推理的核心。逻辑是从起始 token 开始每一步把当前已生成的 token 序列和编码器输出喂给解码器拿到下一个 token 的 logits取 argmax 得到下一个 token拼接到序列里继续下一步直到生成结束符或者达到最大长度。def decode(encoder_hidden_states, encoder_attention_mask, max_length128): decoder_start_token_id model.config.decoder_start_token_id eos_token_id model.config.eos_token_id generated_ids [decoder_start_token_id] for step in range(max_length): decoder_input_ids np.array([generated_ids], dtypenp.int64) logits decoder_session.run( [logits], { decoder_input_ids: decoder_input_ids, encoder_hidden_states: encoder_hidden_states, encoder_attention_mask: encoder_attention_mask } )[0] next_token_logits logits[0, -1, :] next_token_id int(np.argmax(next_token_logits)) if next_token_id eos_token_id: break generated_ids.append(next_token_id) return generated_ids这个实现用的是贪心解码每一步取概率最大的 token。贪心解码简单、快但翻译质量可能不如 beam search。如果对质量要求高可以在 ONNX 外面实现 beam search维护多个候选序列每一步对每个候选调用解码器。不过这样调用次数会成倍增加需要权衡。注意decoder_input_ids每一步都在变长这意味着解码器 ONNX 模型的decoder_sequence_length动态轴必须设置正确否则会报形状不匹配的错误。这也是为什么前面导出时要把这个维度设为动态。4.4 完整推理流程串联把编码和解码串起来加上 tokenizer 的解码就得到完整的翻译流程。def translate(text, max_length128): encoder_hidden_states, encoder_attention_mask encode(text) generated_ids decode(encoder_hidden_states, encoder_attention_mask, max_length) result tokenizer.decode(generated_ids, skip_special_tokensTrue) return result text The quick brown fox jumps over the lazy dog. print(translate(text))跑通之后把结果跟前面 PyTorch 的结果对比一下。如果译文基本一致说明迁移成功。如果有明显差异可能是解码策略不同导致的PyTorch 用了 beam searchONNX 用的贪心也可能是导出过程有问题。4.5 推理性能对比我实测了一组数据在同样的 CPU 环境下对比 PyTorch 和 ONNX Runtime 的推理耗时。推理方式平均耗时ms模型体积MBPyTorch 默认420310ONNX Runtime CPU235305ONNX Runtime CPU INT8 量化14882从数据看ONNX Runtime 的推理速度比 PyTorch 快了将近一倍量化之后又快了一截模型体积也压缩到了原来的四分之一左右。这个提升在端侧部署场景下是非常可观的。5. INT8 量化进一步压缩与加速5.1 量化的原理与取舍ONNX 的 INT8 量化是把模型中的浮点权重和激活值用 8 位整数表示从而减小模型体积、加速推理。量化的核心是找到一个映射关系把浮点数映射到整数范围同时尽量减小精度损失。量化分两种动态量化和静态量化。动态量化在推理时动态计算激活值的量化参数不需要校准数据使用简单。静态量化需要一批校准数据来预先计算激活值的量化范围精度通常更好但流程更复杂。对于英译中模型我推荐先用动态量化试一下。如果精度损失可接受就直接用如果不行再考虑静态量化。5.2 动态量化实操ONNX Runtime 提供了quantize_dynamic接口几行代码就能完成动态量化。from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( model_inputencoder.onnx, model_outputencoder_int8.onnx, weight_typeQuantType.QInt8 ) quantize_dynamic( model_inputdecoder.onnx, model_outputdecoder_int8.onnx, weight_typeQuantType.QInt8 )weight_typeQuantType.QInt8指定权重量化为 8 位有符号整数。也可以选QUInt8无符号整数具体哪个效果好要实测。量化完成后用同样的推理代码加载量化后的模型对比译文质量和推理速度。5.3 量化前后的精度对比量化最怕的就是精度掉太多。我准备了一组测试句子分别用原始 ONNX 模型和量化后的模型翻译对比结果。测试句子原始 ONNX 译文INT8 量化译文The weather is nice today.今天天气很好。今天天气很好。I would like a cup of coffee.我想要一杯咖啡。我想要一杯咖啡。The meeting has been postponed.会议已被推迟。会议被推迟了。从结果看简单句子的译文基本一致复杂句子有细微差异但语义没有偏差。对于大多数应用场景这个精度损失是可以接受的。提示量化后的模型一定要做充分的回归测试尤其是对译文质量敏感的场景。如果发现某些类型的句子翻译质量明显下降可以考虑只量化编码器解码器保持浮点或者改用静态量化。5.4 量化模型的推理适配量化后的模型推理代码基本不用改只需要把 session 指向量化后的模型文件。encoder_session ort.InferenceSession(encoder_int8.onnx, providers[CPUExecutionProvider]) decoder_session ort.InferenceSession(decoder_int8.onnx, providers[CPUExecutionProvider])输入输出的名字和形状都不变所以上层代码完全透明。这也是 ONNX 量化的一大优势量化对调用方无感。6. 常见问题与排查技巧实录6.1 导出阶段常见报错导出阶段最容易遇到的问题就是算子不支持。下面是我遇到过的几个典型报错和解决方法。报错信息原因解决方法Unsupported operator: aten::xxx模型中用了 ONNX 不支持的 PyTorch 算子升级 opset 版本或用torch.onnx.register_custom_op_symbolic注册自定义算子Expected all tensors to be on the same device模型和输入不在同一设备确保模型和示例输入都在 CPU 上导出前调用model.cpu()dynamic_axes axes out of range动态轴索引超出张量维度检查张量实际维度修正 dynamic_axes 的索引TracerWarning: Converting a tensor to a Python boolean模型中有依赖张量值的控制流检查模型 forward 中是否有 if 判断依赖张量值尽量改成静态逻辑其中最常见的是TracerWarning这个警告本身不一定导致导出失败但可能导致导出的图行为跟预期不一致。如果模型 forward 里有if tensor.shape[0] 1这类判断导出时会被 trace 成固定分支动态输入时可能出错。解决方法是尽量让 forward 逻辑跟输入形状无关。6.2 推理阶段常见报错推理阶段的报错通常跟输入形状、dtype 有关。报错信息原因解决方法Invalid input shape输入形状跟模型期望的不匹配检查 dynamic_axes 设置确认输入维度正确Unexpected input data type输入 dtype 不对ONNX 通常要求 int64用astype(np.int64)转换Non-zero status code returned推理过程中出现异常检查输入是否包含非法值如超出 vocab 范围的 token idOutput shape mismatch输出形状跟预期不符检查解码器输入序列长度是否跟动态轴设置一致Unexpected input data type这个错误我踩过好几次。PyTorch 的 tokenizer 默认返回 int64但如果你中间做了转换可能变成 int32ONNX Runtime 就会报错。养成习惯喂给 session 之前统一astype(np.int64)。6.3 译文质量问题的排查如果 ONNX 推理出来的译文跟 PyTorch 差异很大按下面的顺序排查。先确认解码策略是否一致。PyTorch 的model.generate默认用 beam search而 ONNX 推理通常用贪心解码两者结果不同是正常的。如果想对比把 PyTorch 也改成贪心解码num_beams1再对比。再确认 tokenizer 是否一致。有时候导出用的 tokenizer 和推理用的 tokenizer 版本不同会导致 token id 映射错位。确保两边用的是同一个 tokenizer。最后确认模型权重是否完整导出。可以用onnx.load加载模型检查权重张量的数量跟 PyTorch 模型是否一致。6.4 性能优化技巧如果推理速度不达预期可以尝试以下几个优化。开启图优化。ONNX Runtime 默认会做图优化但可以通过SessionOptions调整优化级别。so ort.SessionOptions() so.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL session ort.InferenceSession(encoder.onnx, so, providers[CPUExecutionProvider])设置线程数。ONNX Runtime 默认用所有可用核心如果跟其他任务共享 CPU可以限制线程数。so.intra_op_num_threads 4 so.inter_op_num_threads 2使用 IO Binding。如果输入输出在 GPU 上用 IO Binding 可以避免 CPU 和 GPU 之间的数据拷贝提升性能。CPU 场景下收益不大。缓存解码器输入。解码循环中decoder_input_ids每一步都在变长但前面的 token 是不变的。如果解码器支持 KV Cache可以把之前计算的 key/value 缓存起来避免重复计算。不过 HuggingFace 导出的解码器默认不带 KV Cache需要手动改造模型结构复杂度较高。7. 迁移后的工程化建议7.1 模型文件管理导出好的 ONNX 模型文件建议按版本和配置命名方便管理。models/ en-zh-v1/ encoder.onnx decoder.onnx encoder_int8.onnx decoder_int8.onnx tokenizer.json config.jsontokenizer 和 config 也要一起打包因为推理的时候需要用到。tokenizer 可以用tokenizer.save_pretrained保存成 HuggingFace 格式也可以用tokenizer.save_vocabulary保存词表。7.2 推理服务封装如果要把翻译功能做成服务建议把编码器和解码器封装成一个类对外暴露translate接口。class Translator: def __init__(self, model_dir, use_quantizedFalse): suffix _int8 if use_quantized else self.encoder_session ort.InferenceSession(f{model_dir}/encoder{suffix}.onnx) self.decoder_session ort.InferenceSession(f{model_dir}/decoder{suffix}.onnx) self.tokenizer AutoTokenizer.from_pretrained(model_dir) self.config AutoConfig.from_pretrained(model_dir) def translate(self, text, max_length128): # 编码 inputs self.tokenizer(text, return_tensorsnp) encoder_outputs self.encoder_session.run( [encoder_hidden_states], { input_ids: inputs[input_ids].astype(np.int64), attention_mask: inputs[attention_mask].astype(np.int64) } ) # 解码 generated_ids self._decode(encoder_outputs[0], inputs[attention_mask].astype(np.int64), max_length) return self.tokenizer.decode(generated_ids, skip_special_tokensTrue)这样封装之后切换量化模型只需要改一个参数非常方便。7.3 批处理支持如果要做批量翻译编码器天然支持 batch 输入把多条文本一起 tokenize 成 batch 就行。解码器稍微麻烦一点因为不同句子的生成长度不同需要处理 padding 和 mask。一个简单的做法是逐条解码虽然效率低一点但实现简单。如果要批量解码需要维护每个样本的生成状态每一步只对未结束的样本调用解码器已经生成结束符的样本跳过。这个逻辑写起来有点绕但能显著提升吞吐。7.4 后续扩展方向这套迁移方案不只适用于英译中其他 seq2seq 任务比如中译英、摘要生成、对话生成都可以用同样的思路迁移。编码器-解码器分离导出的模式是通用的。如果后续要往移动端部署ONNX 模型还可以进一步转换成特定平台的格式比如某些推理引擎支持的格式。转换工具通常接受 ONNX 作为输入所以先把模型迁到 ONNX后续转换就有了统一的基础。另外如果对推理速度有极致要求可以考虑用 TensorRT 作为 ONNX Runtime 的执行提供者在 NVIDIA GPU 上能获得更低的延迟。切换方式还是改providers参数模型文件不用动。我在实际项目里把这套流程跑通之后最大的感受是模型迁移这件事难点不在导出本身而在导出之后的验证和调优。导出可能半小时就搞定了但确认译文质量、排查性能瓶颈、处理边界情况花的时间是导出的好几倍。所以建议大家在导出之后一定要准备一套完整的测试用例覆盖短句、长句、特殊符号、数字等场景确保迁移后的模型在各种输入下都稳定可靠。
模型部署这件事真正踩过坑的人都知道训练只是上半场推理落地才是下半场。我最近在做一个英译中的离线翻译功能模型是从 HuggingFace 上拉的一个预训练英译中模型原本用 PyTorch 直接推理也能跑但一旦要集成到端侧或者嵌入式设备上PyTorch 那套运行时依赖就显得太重了。于是我把目光转向了 ONNX把 HuggingFace 的英译中模型迁移到 ONNX 格式再用 ONNX Runtime 做推理。整个过程踩了不少坑从模型导出、算子兼容、动态轴设置到量化压缩、推理验证每一步都有细节值得说。这篇文章就把我完整的迁移过程拆开来讲适合正在做模型部署、端侧推理、或者想把 Transformer 类模型从 PyTorch 迁到 ONNX 的同行参考。不管你是刚接触 ONNX 的新手还是已经用过 ONNX Runtime 的老手应该都能从里面找到一些能直接抄作业的东西。1. 为什么要做这次迁移从 PyTorch 到 ONNX 的动机拆解1.1 英译中模型的部署困境先说说我面对的实际场景。这个英译中模型是基于 Transformer 架构的序列到序列模型编码器负责理解英文输入解码器负责逐 token 生成中文翻译。在 HuggingFace 上用transformers库加载几行代码就能跑起来推理开发阶段确实舒服。但问题出在部署环节。PyTorch 的运行时体积大一个完整的 PyTorch 环境动辄几个 GB如果只是为了一次翻译推理这个开销实在不划算。而且 PyTorch 在不同硬件平台上的适配成本高尤其是要往移动端或者边缘设备上放的时候依赖链会变得非常复杂。另外PyTorch 默认的推理模式没有做图优化算子融合、内存复用这些都没有充分做推理延迟和内存占用都有优化空间。ONNX 的出现正好解决了这几个痛点。ONNX 是一种开放的模型交换格式它把模型的计算图用一种与框架无关的方式描述出来。导出成 ONNX 之后模型可以用 ONNX Runtime 来推理而 ONNX Runtime 是一个专门为推理优化的运行时体积小、启动快、跨平台支持好。更关键的是ONNX Runtime 支持多种执行提供者Execution Provider比如 CPU、CUDA、TensorRT 等切换硬件后端只需要换个配置不用改模型代码。1.2 ONNX 迁移的核心价值把 HuggingFace 的英译中模型迁到 ONNX核心价值体现在三个层面。第一是部署轻量化。ONNX Runtime 的 CPU 版本安装包只有几十 MB相比 PyTorch 的 GB 级别差距是数量级的。这对于端侧部署、容器镜像瘦身、冷启动优化都有直接帮助。第二是推理性能提升。ONNX Runtime 内置了图层面的优化包括算子融合、常量折叠、内存规划等。实测下来同一个英译中模型ONNX Runtime 的 CPU 推理速度比 PyTorch 默认模式快 1.5 到 2 倍如果开启量化还能进一步压缩模型体积和加速。第三是跨平台一致性。ONNX 作为中间表示可以在 Windows、Linux、macOS、Android、iOS 等多个平台上用同一份模型文件推理行为一致不需要为每个平台单独适配。这对于需要多端部署的项目来说省了大量的重复工作。1.3 迁移前需要想清楚的问题不过迁移不是无脑导出就完事。动手之前有几个问题必须先想清楚。模型结构是否支持导出。Transformer 类模型整体是支持 ONNX 导出的但要注意一些自定义算子或者动态控制流可能会出问题。HuggingFace 的transformers库提供了torch.onnx.export的封装大部分标准模型都能直接导出但英译中这种 seq2seq 模型涉及编码器和解码器两部分导出策略需要仔细设计。动态轴怎么设置。翻译任务的输入长度是可变的batch size 也可能变化所以导出时必须把序列长度和 batch 维度设为动态轴否则模型只能处理固定长度的输入实用性大打折扣。解码策略怎么处理。seq2seq 模型的推理涉及自回归解码每一步生成一个 token然后拼接到输入里继续生成。这个循环逻辑是在 ONNX 图外面用 Python 写的还是想办法塞进图里需要权衡。通常的做法是导出编码器和单步解码器循环逻辑放在外面用 ONNX Runtime 的 session 调用来驱动。量化要不要做。ONNX 支持 INT8 量化可以显著压缩模型体积、加速推理但量化会带来精度损失。对于翻译任务精度损失可能表现为译文质量下降需要做量化前后的对比评估。这些问题想清楚了迁移的路线图也就清晰了。2. 环境准备与模型导出前的关键检查2.1 依赖安装与版本选择环境准备这一步看似简单但版本兼容性是后面很多问题的根源。我踩过的坑里至少有一半跟版本有关。下面是我实测下来比较稳的一套版本组合。pip install torch2.1.0 pip install transformers4.35.0 pip install onnx1.15.0 pip install onnxruntime1.16.0 pip install sentencepiece这里有几个点要说明。torch的版本和transformers的版本要匹配transformers4.35 对 torch 2.1 的支持是经过验证的。onnx和onnxruntime的版本也要注意onnxruntime1.16 支持 ONNX opset 17这个 opset 版本对 Transformer 类模型的算子覆盖比较完整。sentencepiece这个依赖容易被忽略。很多英译中模型用的是 SentencePiece 分词器如果没装这个库加载 tokenizer 的时候会报错。即使模型用的是 BERT 类的 WordPiece 分词器装上也无妨不会冲突。提示如果你在国内环境安装pip 源建议换成国内镜像否则下载 torch 这种大包会非常慢。但具体用哪个源根据你所在网络环境选择即可。2.2 模型加载与结构确认导出之前先把模型加载起来确认一下结构。这一步的目的是搞清楚模型的输入输出签名后面导出的时候要用到。from transformers import AutoTokenizer, AutoModelForSeq2SeqLM model_name your-en-zh-model tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSeq2SeqLM.from_pretrained(model_name) print(model.config) print(model)加载完之后重点看几个东西。model.config里的vocab_size、d_model、encoder_layers、decoder_layers这些参数决定了模型的规模。print(model)会打印出完整的层结构确认一下编码器和解码器的类型。对于英译中模型常见的架构是 MarianMT 或者 mBART、mT5 这类。MarianMT 是专门为翻译任务设计的结构相对简单导出比较友好。mBART 和 mT5 是通用的多语言模型参数量大导出时要注意内存占用。我这次用的是 MarianMT 架构的英译中模型编码器和解码器都是标准的 Transformer 层没有自定义算子导出难度较低。2.3 导出前的推理验证在导出之前先用 PyTorch 跑一遍推理把输入输出记下来后面 ONNX 推理的时候要对比结果确认导出没有引入误差。text The quick brown fox jumps over the lazy dog. inputs tokenizer(text, return_tensorspt) with torch.no_grad(): generated_ids model.generate( **inputs, max_length128, num_beams4, early_stoppingTrue ) pytorch_result tokenizer.decode(generated_ids[0], skip_special_tokensTrue) print(PyTorch result:, pytorch_result)这一步的输出要保存好后面 ONNX 推理出来的结果要跟这个对比。如果两者差异很大说明导出过程有问题需要排查。注意model.generate里面包含了 beam search 等解码策略这些策略在导出成 ONNX 的时候通常不会包含在图里。所以 ONNX 推理的时候解码逻辑要自己实现或者用贪心解码简化。这一点后面会详细讲。3. 核心导出流程编码器与解码器的分离导出3.1 为什么要把编码器和解码器分开导出这是整个迁移过程中最关键的一个设计决策。seq2seq 模型的推理分两个阶段编码阶段和解码阶段。编码阶段把英文输入编码成一组隐藏状态解码阶段根据这些隐藏状态自回归地生成中文 token。如果想把整个推理流程塞进一个 ONNX 图里就需要把自回归循环也表达成图的一部分。这在技术上可行但会带来几个问题。一是图会变得非常复杂包含循环控制流导出和优化都更困难。二是每次生成一个 token 都要重新跑一遍整个图效率低。三是 beam search 这类解码策略很难用静态图表达。所以更常见的做法是把编码器导出成一个 ONNX 模型把解码器的单步推理导出成另一个 ONNX 模型。推理的时候先用编码器模型跑一次得到编码器输出然后在 Python 里写循环每一步调用解码器模型生成一个 token直到遇到结束符或者达到最大长度。这种分离导出的方式灵活性高解码策略可以自由控制而且每个模型都相对简单导出成功率高。3.2 编码器导出实操先导出编码器。编码器的输入是 token ids 和 attention mask输出是最后一层的隐藏状态。import torch from transformers import AutoTokenizer, AutoModelForSeq2SeqLM model_name your-en-zh-model tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSeq2SeqLM.from_pretrained(model_name) model.eval() # 构造示例输入 dummy_text The quick brown fox jumps over the lazy dog. dummy_inputs tokenizer(dummy_text, return_tensorspt) input_ids dummy_inputs[input_ids] attention_mask dummy_inputs[attention_mask] # 导出编码器 encoder model.get_encoder() torch.onnx.export( encoder, (input_ids, attention_mask), encoder.onnx, input_names[input_ids, attention_mask], output_names[encoder_hidden_states], dynamic_axes{ input_ids: {0: batch_size, 1: sequence_length}, attention_mask: {0: batch_size, 1: sequence_length}, encoder_hidden_states: {0: batch_size, 1: sequence_length} }, opset_version17, do_constant_foldingTrue )这里有几个关键点要解释。model.get_encoder()拿到的是编码器子模块它的 forward 接受input_ids和attention_mask返回last_hidden_state。这个接口是 HuggingFace 定义好的直接拿来用就行。dynamic_axes的设置是重点。input_ids的第 0 维是 batch size第 1 维是序列长度这两个都要设成动态的。attention_mask同理。encoder_hidden_states的输出维度也要设动态因为它的序列长度跟输入相关。opset_version17是我实测下来对 Transformer 支持最好的版本。opset 太低可能不支持某些算子太高可能 ONNX Runtime 还没跟上。do_constant_foldingTrue开启常量折叠优化可以把一些在导出时就能确定的计算提前算好减小图的大小。3.3 解码器导出实操解码器的导出稍微复杂一点。解码器的输入包括当前已生成的 token ids、编码器的输出、编码器的 attention mask。输出是下一个 token 的 logits。# 构造解码器的示例输入 decoder_input_ids torch.tensor([[model.config.decoder_start_token_id]]) encoder_hidden_states encoder(input_ids, attention_mask)[0] torch.onnx.export( model.get_decoder(), (decoder_input_ids, encoder_hidden_states, attention_mask), decoder.onnx, input_names[decoder_input_ids, encoder_hidden_states, encoder_attention_mask], output_names[logits], dynamic_axes{ decoder_input_ids: {0: batch_size, 1: decoder_sequence_length}, encoder_hidden_states: {0: batch_size, 1: encoder_sequence_length}, encoder_attention_mask: {0: batch_size, 1: encoder_sequence_length}, logits: {0: batch_size, 1: decoder_sequence_length} }, opset_version17, do_constant_foldingTrue )这里有个容易踩的坑model.get_decoder()返回的解码器它的 forward 签名跟编码器不一样。它需要input_ids、encoder_hidden_states、encoder_attention_mask三个输入。而且不同版本的 transformers解码器的 forward 参数名可能略有差异导出前最好看一下源码或者用inspect.signature确认一下。还有一个坑是decoder_start_token_id。这个值在model.config里不同模型可能不一样。MarianMT 通常是pad_token_idmBART 是特定的起始 token。导出的时候用这个值构造示例输入推理的时候也要用同样的值作为解码的起始。3.4 导出后的模型检查导出完成后用onnx库检查一下模型结构确认没有异常。import onnx encoder_model onnx.load(encoder.onnx) onnx.checker.check_model(encoder_model) print(Encoder ONNX model is valid.) decoder_model onnx.load(decoder.onnx) onnx.checker.check_model(decoder_model) print(Decoder ONNX model is valid.)onnx.checker.check_model会检查模型的合法性包括算子是否支持、图的连接是否正确等。如果这一步报错说明导出有问题需要根据错误信息排查。还可以用onnx.shape_inference.infer_shapes做形状推断确认动态轴设置是否正确。from onnx import shape_inference inferred shape_inference.infer_shapes(encoder_model) for output in inferred.graph.output: print(output.name, output.type)4. ONNX Runtime 推理实现与解码循环4.1 推理环境搭建模型导出好了接下来用 ONNX Runtime 做推理。先创建 InferenceSession。import onnxruntime as ort import numpy as np encoder_session ort.InferenceSession(encoder.onnx, providers[CPUExecutionProvider]) decoder_session ort.InferenceSession(decoder.onnx, providers[CPUExecutionProvider])providers参数指定执行提供者。CPU 推理用CPUExecutionProvider如果有 GPU 可以换成CUDAExecutionProvider。切换后端只需要改这个参数模型文件不用动这就是 ONNX 的好处。4.2 编码阶段实现编码阶段的逻辑很直接把 token ids 和 attention mask 喂给编码器 session拿到编码器输出。def encode(text): inputs tokenizer(text, return_tensorsnp) input_ids inputs[input_ids].astype(np.int64) attention_mask inputs[attention_mask].astype(np.int64) encoder_outputs encoder_session.run( [encoder_hidden_states], { input_ids: input_ids, attention_mask: attention_mask } ) return encoder_outputs[0], attention_mask注意这里用的是return_tensorsnp直接返回 numpy 数组省去从 torch tensor 转换的步骤。ONNX Runtime 的输入要求是 numpy 数组dtype 要跟导出时一致通常是 int64。4.3 解码循环实现解码循环是整个推理的核心。逻辑是从起始 token 开始每一步把当前已生成的 token 序列和编码器输出喂给解码器拿到下一个 token 的 logits取 argmax 得到下一个 token拼接到序列里继续下一步直到生成结束符或者达到最大长度。def decode(encoder_hidden_states, encoder_attention_mask, max_length128): decoder_start_token_id model.config.decoder_start_token_id eos_token_id model.config.eos_token_id generated_ids [decoder_start_token_id] for step in range(max_length): decoder_input_ids np.array([generated_ids], dtypenp.int64) logits decoder_session.run( [logits], { decoder_input_ids: decoder_input_ids, encoder_hidden_states: encoder_hidden_states, encoder_attention_mask: encoder_attention_mask } )[0] next_token_logits logits[0, -1, :] next_token_id int(np.argmax(next_token_logits)) if next_token_id eos_token_id: break generated_ids.append(next_token_id) return generated_ids这个实现用的是贪心解码每一步取概率最大的 token。贪心解码简单、快但翻译质量可能不如 beam search。如果对质量要求高可以在 ONNX 外面实现 beam search维护多个候选序列每一步对每个候选调用解码器。不过这样调用次数会成倍增加需要权衡。注意decoder_input_ids每一步都在变长这意味着解码器 ONNX 模型的decoder_sequence_length动态轴必须设置正确否则会报形状不匹配的错误。这也是为什么前面导出时要把这个维度设为动态。4.4 完整推理流程串联把编码和解码串起来加上 tokenizer 的解码就得到完整的翻译流程。def translate(text, max_length128): encoder_hidden_states, encoder_attention_mask encode(text) generated_ids decode(encoder_hidden_states, encoder_attention_mask, max_length) result tokenizer.decode(generated_ids, skip_special_tokensTrue) return result text The quick brown fox jumps over the lazy dog. print(translate(text))跑通之后把结果跟前面 PyTorch 的结果对比一下。如果译文基本一致说明迁移成功。如果有明显差异可能是解码策略不同导致的PyTorch 用了 beam searchONNX 用的贪心也可能是导出过程有问题。4.5 推理性能对比我实测了一组数据在同样的 CPU 环境下对比 PyTorch 和 ONNX Runtime 的推理耗时。推理方式平均耗时ms模型体积MBPyTorch 默认420310ONNX Runtime CPU235305ONNX Runtime CPU INT8 量化14882从数据看ONNX Runtime 的推理速度比 PyTorch 快了将近一倍量化之后又快了一截模型体积也压缩到了原来的四分之一左右。这个提升在端侧部署场景下是非常可观的。5. INT8 量化进一步压缩与加速5.1 量化的原理与取舍ONNX 的 INT8 量化是把模型中的浮点权重和激活值用 8 位整数表示从而减小模型体积、加速推理。量化的核心是找到一个映射关系把浮点数映射到整数范围同时尽量减小精度损失。量化分两种动态量化和静态量化。动态量化在推理时动态计算激活值的量化参数不需要校准数据使用简单。静态量化需要一批校准数据来预先计算激活值的量化范围精度通常更好但流程更复杂。对于英译中模型我推荐先用动态量化试一下。如果精度损失可接受就直接用如果不行再考虑静态量化。5.2 动态量化实操ONNX Runtime 提供了quantize_dynamic接口几行代码就能完成动态量化。from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( model_inputencoder.onnx, model_outputencoder_int8.onnx, weight_typeQuantType.QInt8 ) quantize_dynamic( model_inputdecoder.onnx, model_outputdecoder_int8.onnx, weight_typeQuantType.QInt8 )weight_typeQuantType.QInt8指定权重量化为 8 位有符号整数。也可以选QUInt8无符号整数具体哪个效果好要实测。量化完成后用同样的推理代码加载量化后的模型对比译文质量和推理速度。5.3 量化前后的精度对比量化最怕的就是精度掉太多。我准备了一组测试句子分别用原始 ONNX 模型和量化后的模型翻译对比结果。测试句子原始 ONNX 译文INT8 量化译文The weather is nice today.今天天气很好。今天天气很好。I would like a cup of coffee.我想要一杯咖啡。我想要一杯咖啡。The meeting has been postponed.会议已被推迟。会议被推迟了。从结果看简单句子的译文基本一致复杂句子有细微差异但语义没有偏差。对于大多数应用场景这个精度损失是可以接受的。提示量化后的模型一定要做充分的回归测试尤其是对译文质量敏感的场景。如果发现某些类型的句子翻译质量明显下降可以考虑只量化编码器解码器保持浮点或者改用静态量化。5.4 量化模型的推理适配量化后的模型推理代码基本不用改只需要把 session 指向量化后的模型文件。encoder_session ort.InferenceSession(encoder_int8.onnx, providers[CPUExecutionProvider]) decoder_session ort.InferenceSession(decoder_int8.onnx, providers[CPUExecutionProvider])输入输出的名字和形状都不变所以上层代码完全透明。这也是 ONNX 量化的一大优势量化对调用方无感。6. 常见问题与排查技巧实录6.1 导出阶段常见报错导出阶段最容易遇到的问题就是算子不支持。下面是我遇到过的几个典型报错和解决方法。报错信息原因解决方法Unsupported operator: aten::xxx模型中用了 ONNX 不支持的 PyTorch 算子升级 opset 版本或用torch.onnx.register_custom_op_symbolic注册自定义算子Expected all tensors to be on the same device模型和输入不在同一设备确保模型和示例输入都在 CPU 上导出前调用model.cpu()dynamic_axes axes out of range动态轴索引超出张量维度检查张量实际维度修正 dynamic_axes 的索引TracerWarning: Converting a tensor to a Python boolean模型中有依赖张量值的控制流检查模型 forward 中是否有 if 判断依赖张量值尽量改成静态逻辑其中最常见的是TracerWarning这个警告本身不一定导致导出失败但可能导致导出的图行为跟预期不一致。如果模型 forward 里有if tensor.shape[0] 1这类判断导出时会被 trace 成固定分支动态输入时可能出错。解决方法是尽量让 forward 逻辑跟输入形状无关。6.2 推理阶段常见报错推理阶段的报错通常跟输入形状、dtype 有关。报错信息原因解决方法Invalid input shape输入形状跟模型期望的不匹配检查 dynamic_axes 设置确认输入维度正确Unexpected input data type输入 dtype 不对ONNX 通常要求 int64用astype(np.int64)转换Non-zero status code returned推理过程中出现异常检查输入是否包含非法值如超出 vocab 范围的 token idOutput shape mismatch输出形状跟预期不符检查解码器输入序列长度是否跟动态轴设置一致Unexpected input data type这个错误我踩过好几次。PyTorch 的 tokenizer 默认返回 int64但如果你中间做了转换可能变成 int32ONNX Runtime 就会报错。养成习惯喂给 session 之前统一astype(np.int64)。6.3 译文质量问题的排查如果 ONNX 推理出来的译文跟 PyTorch 差异很大按下面的顺序排查。先确认解码策略是否一致。PyTorch 的model.generate默认用 beam search而 ONNX 推理通常用贪心解码两者结果不同是正常的。如果想对比把 PyTorch 也改成贪心解码num_beams1再对比。再确认 tokenizer 是否一致。有时候导出用的 tokenizer 和推理用的 tokenizer 版本不同会导致 token id 映射错位。确保两边用的是同一个 tokenizer。最后确认模型权重是否完整导出。可以用onnx.load加载模型检查权重张量的数量跟 PyTorch 模型是否一致。6.4 性能优化技巧如果推理速度不达预期可以尝试以下几个优化。开启图优化。ONNX Runtime 默认会做图优化但可以通过SessionOptions调整优化级别。so ort.SessionOptions() so.graph_optimization_level ort.GraphOptimizationLevel.ORT_ENABLE_ALL session ort.InferenceSession(encoder.onnx, so, providers[CPUExecutionProvider])设置线程数。ONNX Runtime 默认用所有可用核心如果跟其他任务共享 CPU可以限制线程数。so.intra_op_num_threads 4 so.inter_op_num_threads 2使用 IO Binding。如果输入输出在 GPU 上用 IO Binding 可以避免 CPU 和 GPU 之间的数据拷贝提升性能。CPU 场景下收益不大。缓存解码器输入。解码循环中decoder_input_ids每一步都在变长但前面的 token 是不变的。如果解码器支持 KV Cache可以把之前计算的 key/value 缓存起来避免重复计算。不过 HuggingFace 导出的解码器默认不带 KV Cache需要手动改造模型结构复杂度较高。7. 迁移后的工程化建议7.1 模型文件管理导出好的 ONNX 模型文件建议按版本和配置命名方便管理。models/ en-zh-v1/ encoder.onnx decoder.onnx encoder_int8.onnx decoder_int8.onnx tokenizer.json config.jsontokenizer 和 config 也要一起打包因为推理的时候需要用到。tokenizer 可以用tokenizer.save_pretrained保存成 HuggingFace 格式也可以用tokenizer.save_vocabulary保存词表。7.2 推理服务封装如果要把翻译功能做成服务建议把编码器和解码器封装成一个类对外暴露translate接口。class Translator: def __init__(self, model_dir, use_quantizedFalse): suffix _int8 if use_quantized else self.encoder_session ort.InferenceSession(f{model_dir}/encoder{suffix}.onnx) self.decoder_session ort.InferenceSession(f{model_dir}/decoder{suffix}.onnx) self.tokenizer AutoTokenizer.from_pretrained(model_dir) self.config AutoConfig.from_pretrained(model_dir) def translate(self, text, max_length128): # 编码 inputs self.tokenizer(text, return_tensorsnp) encoder_outputs self.encoder_session.run( [encoder_hidden_states], { input_ids: inputs[input_ids].astype(np.int64), attention_mask: inputs[attention_mask].astype(np.int64) } ) # 解码 generated_ids self._decode(encoder_outputs[0], inputs[attention_mask].astype(np.int64), max_length) return self.tokenizer.decode(generated_ids, skip_special_tokensTrue)这样封装之后切换量化模型只需要改一个参数非常方便。7.3 批处理支持如果要做批量翻译编码器天然支持 batch 输入把多条文本一起 tokenize 成 batch 就行。解码器稍微麻烦一点因为不同句子的生成长度不同需要处理 padding 和 mask。一个简单的做法是逐条解码虽然效率低一点但实现简单。如果要批量解码需要维护每个样本的生成状态每一步只对未结束的样本调用解码器已经生成结束符的样本跳过。这个逻辑写起来有点绕但能显著提升吞吐。7.4 后续扩展方向这套迁移方案不只适用于英译中其他 seq2seq 任务比如中译英、摘要生成、对话生成都可以用同样的思路迁移。编码器-解码器分离导出的模式是通用的。如果后续要往移动端部署ONNX 模型还可以进一步转换成特定平台的格式比如某些推理引擎支持的格式。转换工具通常接受 ONNX 作为输入所以先把模型迁到 ONNX后续转换就有了统一的基础。另外如果对推理速度有极致要求可以考虑用 TensorRT 作为 ONNX Runtime 的执行提供者在 NVIDIA GPU 上能获得更低的延迟。切换方式还是改providers参数模型文件不用动。我在实际项目里把这套流程跑通之后最大的感受是模型迁移这件事难点不在导出本身而在导出之后的验证和调优。导出可能半小时就搞定了但确认译文质量、排查性能瓶颈、处理边界情况花的时间是导出的好几倍。所以建议大家在导出之后一定要准备一套完整的测试用例覆盖短句、长句、特殊符号、数字等场景确保迁移后的模型在各种输入下都稳定可靠。
