同一段 1200 字的客服话术，把英文逗号句号换成全角后，接口返回的 prompt_tokens 从 980 涨到 1380，做成本预估时按字符数折算完全对不上。
一开始怀疑是「不同模型的词表对全角符号覆盖不同」，查了一圈，方向不对。
真正麻烦的地方在于，几个原因的现象几乎一样。全角标点在词表里常被拆成多字节。另一种情况是中英混排时标点前后的空格影响切分。
不容易想到的是，估算脚本只数字符不数 token。
上来先用目标模型的 tokenizer 实测两版
python -c "from transformers import AutoTokenizer;t=AutoTokenizer.from_pretrained('Qwen/Qwen2.5-7B-Instruct');print(len(t('你好，世界').input_ids),len(t('你好,世界').input_ids))"批量统计全角标点占比
python count_punct.py --file faq.txt --fullwidth做一次 NFKC 归一后再估算
python -c "import unicodedata;print(unicodedata.normalize('NFKC','你好，世界'))"等前面都确认过，再用接口 usage 校准换算系数
python -c "print(round(1380/1200,3))"改完先别撤，确认这几项。估算值与接口 usage 的偏差压到 5% 以内，归一后文本语义不变，行数与原来一致。
容易忽略的是，NFKC 会把全角括号和百分号一起改写，展示给用户的文案不要直接归一，只在送模型前做。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。