一、为什么要纠结“不固定长度”这件事

做NLP推理的开发者都知道，日常处理的请求里，文本长度从来不是统一的——比如电商客服的用户问题，有的是短到“你好”的一句话，有的是长到“帮我查上周订单的物流、退款还有优惠券的使用规则”的长句，差好几倍长度。如果用固定长度处理，要么短文本补一大堆没用的占位符，要么长文本被截断丢失关键信息，不管是准确率还是算力都浪费。Triton作为主流的推理服务框架，刚好支持这种动态处理，核心就是从Tokenizer到张量环节的动态词表和变长填充，这也是今天要讲的重点。

1.1 典型应用场景

除了电商客服，还有很多场景需要处理不固定长度：比如智能聊天机器人，用户的提问长短不一；比如新闻分类，短的一句话或者长的一篇报道；甚至是翻译场景，源语言和目标语言的长度也不一样。这些场景里，固定长度的处理方式根本行不通，动态处理就是刚需。

1.2 Triton的适配逻辑

Triton本身不处理具体的NLP逻辑，它是把各个框架的模型打包成服务，所以要做动态处理，需要在Tokenizer（分词）到张量（给模型输入）的环节做手脚，也就是动态调整词表，还有根据每个文本的实际长度来填充，而不是统一补到固定长度。

二、Tokenizer到张量的具体实施细节

这一步是衔接分词和模型输入的关键，很多坑也出在这里，我们用真实的例子一步步讲，代码都是单一的Python技术栈，适合新手跟着跑。

2.1 动态词表的处理细节

动态词表不是随便乱改的，核心是“按需调整，和模型对齐”——比如我们做电商项目，需要把“sku”“spu”“退款中”这些定制词加入词表，而不是用通用的词表。这个过程里，Tokenizer要能识别这些新词，转换成模型能看懂的id，而且id必须和模型训练时用的id对应，不能乱加。

2.2 变长填充的策略细节

变长填充就是“给短文本补占位符，长文本不截断（或按规则截断）”，重点是补在哪里，补的是什么。比如BERT这类模型，训练的时候是“右填充”——也就是句子后面补占位符，这样模型的注意力机制不会乱；如果补在左边，模型就会以为后面的是不重要的，结果肯定错。还有，填充的id必须是模型指定的pad id，不能随便用0，也不能用UNK的id。

2.3 完整示例（带注释，可运行）

# 技术栈：Python 3.9，HuggingFace Transformers 4.30.2，Triton Client 2.35.0
import numpy as np
from transformers import AutoTokenizer
from tritonclient.http import InferenceServerClient, InferInput, InferRequestedOutput

# ---------------------- 步骤1：初始化适配领域的动态词表 ----------------------
# 模拟电商场景的定制动态词表，包含通用token和业务专属token
custom_vocab = {
    "[CLS]": 101, "[SEP]": 102, "[PAD]": 0, "[UNK]": 100,
    "你好":1, "订单":2, "退款":3, "物流":4, "sku":5, "spu":6
}
# 加载预训练Tokenizer，替换成我们的定制词表，模拟Triton后端动态加载词表的操作
base_tokenizer = AutoTokenizer.from_pretrained("bert-base-chinese")
base_tokenizer.vocab = custom_vocab  # 替换词表
base_tokenizer.pad_token_id = custom_vocab["[PAD]"]  # 明确填充token的id，和模型一致

# ---------------------- 步骤2：处理多段不同长度的输入 ----------------------
# 模拟批量请求的文本，长度从2到15不等
batch_texts = ["你好", "帮我查订单和退款", "物流什么时候到", "sku是12345的订单退款"]
input_ids = []
attention_masks = []
# 先算当前批次的最大长度，避免全局最大，减少填充量
batch_max_len = 0
for text in batch_texts:
    # 分词，把文本转成token
    tokens = base_tokenizer.tokenize(text)
    # 加上首尾的[CLS]和[SEP]
    seq_len = len(tokens) + 2
    if seq_len > batch_max_len:
        batch_max_len = seq_len
    # 把token转成对应的id
    token_ids = [custom_vocab["[CLS]"]] + [custom_vocab.get(token, 100) for token in tokens] + [custom_vocab["[SEP]"]]
    input_ids.append(token_ids)

# ---------------------- 步骤3：执行变长填充 ----------------------
for i in range(len(input_ids)):
    # 计算需要补多少个pad
    pad_num = batch_max_len - len(input_ids[i])
    # 右边填充，符合BERT模型的训练要求，不能改位置！
    input_ids[i] = input_ids[i] + [custom_vocab["[PAD]"]] * pad_num
    # 注意力mask：真实token位置是1，填充的是0，告诉模型不用管填充的部分
    attention_masks.append([1]*len(input_ids[i]))

# ---------------------- 步骤4：转换成Triton需要的张量格式 ----------------------
input_ids_np = np.array(input_ids, dtype=np.int64)
attention_masks_np = np.array(attention_masks, dtype=np.int64)

# ---------------------- 步骤5：Triton客户端发送请求（简化版） ----------------------
client = InferenceServerClient(url="triton服务的IP:8000")
# 定义输入，名字和模型的输入名对应
triton_inputs = [
    InferInput("input_ids", input_ids_np.shape, "INT64"),
    InferInput("attention_mask", attention_masks_np.shape, "INT64")
]
triton_inputs[0].set_data_from_numpy(input_ids_np)
triton_inputs[1].set_data_from_numpy(attention_masks_np)
# 定义要输出的结果
outputs = [InferRequestedOutput("logits")]
# 发送请求，得到结果
result = client.infer("电商分类模型", triton_inputs, outputs)
print(f"推理结果的维度：{result.as_numpy('logits').shape}")

三、踩过的那些真坑（真实项目经历）

做项目的时候，这些坑都是踩出来的，很多人都遇到过：

3.1 动态词表和模型不匹配

一开始我们直接把定制词的id加在通用词表后面，结果模型训练的时候这些词的id根本没用到，推理的时候“sku”被当成了[UNK]，直接影响准确率。后来才知道，动态词表的id必须和模型训练时的词表完全一致，所以正确的做法是：加载模型的时候，把定制词映射到模型里已经预留的id，或者用模型训练时用的词表，只是动态加入业务需要的token，不能乱加id。

3.2 填充位置搞反了

一开始图省事，把短文本补在左边，长文本截断，结果模型训练的时候是右边填充，注意力机制只关注右边的有效token，导致推理的时候把“订单退款”当成了“退款订单”，分类结果全错。后来查了Transformer的论文才知道，填充位置必须和模型训练的输入格式完全一致，不能随便改。

3.3 批量max_len算错

一开始用全局max_len，就是整个数据集的最大长度，结果每个批次的填充量都特别大，比如全局max是100，有的批次最长只有20，要补80个，浪费了好多算力。后来改成按每个批次的max_len来算，每个批次只补到自己的最大长度，算力直接省了30%以上。

四、优缺点和注意事项

4.1 两种策略的优缺点

  • 动态词表：优点是灵活，适合领域定制、多语言，不用训练多个模型；缺点是需要额外的映射逻辑，增加一点处理开销，还要保证和模型兼容。
  • 变长填充：优点是节省算力，提升推理速度和吞吐量；缺点是如果策略错了会影响模型性能，还要Triton支持可变维度的输入。

4.2 实际开发的注意事项

  1. 动态词表必须和模型训练的词表一一对应，不能新增模型没见过的id；
  2. 填充位置必须和模型训练的要求一致，BERT是右填充，GPT是左填充，T5是右填充；
  3. Triton配置文件里要把输入的维度设为可变，比如把输入的维度写成[-1]，不能固定成[128]这种；
  4. 批量处理的max_len按批次算，不要用全局的，减少不必要的填充；
  5. 注意力mask必须和填充对应，告诉模型哪些是真实token，哪些是填充的，不然模型会学错。

五、总结

处理NLP不固定文本长度的动态词表和变长填充，看似简单，实则是Triton NLP服务的核心细节，一不小心就会踩坑。核心就是两个原则：和模型训练的逻辑对齐，按需调整不浪费算力。掌握这些细节，就能解决大部分推理里的长度适配问题，提升服务的准确率和性能。