尧图网页设计 
1. Qwen2 输出乱码到底长什么样从 GGGGGG 到问号方块的排查起点Qwen2 系列开源之后很多人第一次在本地跑起来输入一句中文结果模型回了一串GGGGGG或者满屏、锟斤拷又或者中英文夹杂着莫名其妙的符号。这类现象统称为乱码输出但它背后的原因完全不是同一个。有人以为是模型权重坏了有人怀疑显卡驱动还有人直接重装环境折腾半天问题依旧。实际上Qwen2 乱码绝大多数情况下出在三个环节tokenizer 配置、prompt 编码、推理采样参数。把这三处对齐九成以上的乱码都能定位并修掉。先说清楚 Qwen2 是什么、能做什么、适合谁。Qwen2 是阿里通义千问团队开源的大语言模型系列覆盖 0.5B、1.5B、7B、57B-A14B、72B 五个尺寸支持中文、英文以及另外 27 种语言上下文最长可到 128K tokens代码和数学能力相比 Qwen1.5 有明显提升。它适合想在本地或私有环境部署 LLM 的开发者、做 RAG 和 Agent 的工程同学以及需要中文能力强的开源模型的团队。你可以用 Hugging Face Transformers 加载也可以用 Ollama、vLLM、llama.cpp 等推理框架跑起来还可以通过统一 API 通道调用。乱码的典型表现可以分成几类先对号入座能省很多时间。第一类是重复单字符比如GGGGGGGG或。。。。。。这通常和 tokenizer 的 special token 配置、生成时的eos_token_id有关。第二类是编码错乱出现锟斤拷、、“这种基本是 UTF-8 和 GBK 之间来回转换导致的。第三类是语言漂移你问中文它回英文或者中英混杂这往往和 prompt 模板、system prompt 缺失有关。第四类是 token 边界错位输出一些看似正常但语义断裂的片段常见于 tokenizer 版本和模型权重不匹配。我试过在同一个 Qwen2-7B-Instruct 权重上用不同版本的 transformers 加载输出质量差异非常明显。老版本 tokenizer 缺少 Qwen2 新增的 special token 定义模型会把本应被识别为控制符的 token 当成普通文本生成于是就开始刷G。所以排查乱码的第一步不是改参数而是确认你的 tokenizer 和模型是不是同一套、版本是不是对得上。这一节先建立判断框架乱码不是单一 bug而是 tokenizer、编码、采样三条链路中某一环断了。接下来会先讲怎么用 TaoToken 统一 Key 快速搭一个可复现的调用环境再逐个拆解这三条链路给出可复制的配置片段和验证请求最后对照真实报错做排查。你跟着走一遍基本能自己判断乱码来源。2. TaoToken 统一 Key 前置准备一个 Key 打通 Qwen2 多通道调用排查乱码最怕的是环境变量太多一会儿本地 transformers一会儿 Ollama一会儿又换个 API变量一多就说不清是模型问题还是通道问题。所以我习惯先用一个统一的 API 通道把 Qwen2 跑通拿到一份“干净”的基线输出再去对比本地环境的输出。TaoToken 在这里的作用就是提供统一的 Key 和 API 入口让你用同一套请求格式去调不同模型减少环境差异带来的干扰。TaoToken 的官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 注意 API 地址后面不加 UTM 参数。你需要先在控制台创建一个 API Key控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。创建好之后把 Key 存到环境变量里不要硬编码进代码。export TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你只是想先验证模型输出是否正常可以直接用模型对话页面手动发一条中文请求看看返回是否连贯。模型对话入口是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。这一步的意义是如果网页端输出正常说明模型本身没问题乱码大概率出在你本地环境的 tokenizer 或编码环节如果网页端也乱码那就要看请求参数和模型 ID 是否匹配。对于要长期做编码或 Agent 的场景可以了解 Coding Plan入口是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面会说明 Base URL、Key、Model ID 三件套怎么填。这里要强调一个原则无论你用哪种客户端只要涉及接入就必须同时确认 Base URL、API Key、Model ID 三项缺一项或者写错一项都会报错而不是乱码。乱码通常发生在请求已经成功、模型开始生成之后。用 TaoToken 做基线的另一个好处是它的请求格式和 OpenAI 兼容接口一致你可以用同一段 Python 代码切换模型只改model字段。这样在排查 Qwen2 乱码时你可以先用 API 通道确认 Qwen2 的正常输出长什么样再回到本地对比。下面这段代码就是最基础的调用骨架先跑通它再往下看 tokenizer 和参数细节。import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) resp client.chat.completions.create( modelQwen2-7B-Instruct, messages[ {role: system, content: 你是一个中文助手请始终用简体中文回答。}, {role: user, content: 用一句话解释什么是 tokenizer。}, ], temperature0.7, top_p0.8, max_tokens256, ) print(resp.choices[0].message.content)这段代码跑通后你会得到一份正常的中文输出。把它保存下来作为后续对比的参照。如果这段代码返回的是GGGGGG或者乱码那问题在请求参数或模型 ID不在本地 tokenizer。如果这段正常、本地 transformers 乱码那基本可以锁定本地环境。下一节开始进入可复制配置重点讲 tokenizer 和推理参数怎么写。3. 可复制配置tokenizer、prompt 编码与推理参数三件套这一节是整篇的核心给出可以直接复制到项目里的配置片段。乱码排查的关键是把 tokenizer 配置、prompt 编码、推理采样参数三处都写对任何一处偷懒都可能复现乱码。先讲 tokenizer。Qwen2 的 tokenizer 必须和模型权重版本匹配。用 transformers 加载时推荐直接用AutoTokenizer.from_pretrained指向模型目录并且显式设置trust_remote_codeTrue因为 Qwen2 的部分实现依赖远程代码。同时要确认pad_token、eos_token、bos_token都有定义缺失会导致生成时行为异常。from transformers import AutoTokenizer, AutoModelForCausalLM import torch model_dir Qwen/Qwen2-7B-Instruct tokenizer AutoTokenizer.from_pretrained( model_dir, trust_remote_codeTrue, use_fastFalse, ) model AutoModelForCausalLM.from_pretrained( model_dir, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue, ) print(pad_token:, tokenizer.pad_token) print(eos_token:, tokenizer.eos_token) print(bos_token:, tokenizer.bos_token) print(vocab_size:, tokenizer.vocab_size)如果pad_token是None生成时 batch 推理会出问题单条推理也可能因为 padding 逻辑异常导致输出错乱。可以手动补上if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token接下来是 prompt 编码。Qwen2-Instruct 系列有固定的 chat 模板必须用apply_chat_template来构造输入不要自己手拼字符串。手拼很容易漏掉 special token模型会把角色标记当成普通文本输出就会漂移甚至乱码。messages [ {role: system, content: 你是一个严谨的中文助手。}, {role: user, content: 请用三句话介绍 Qwen2 的特点。}, ] text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue, ) inputs tokenizer(text, return_tensorspt).to(model.device)注意add_generation_promptTrue它会在末尾加上 assistant 的起始标记少了这个模型不知道轮到自己说话可能继续补全用户内容或者输出奇怪符号。编码环节还要注意文件读写统一用 UTF-8Python 里打开文件时显式写encodingutf-8避免系统默认编码把中文读成乱码再喂给模型。然后是推理采样参数。乱码和采样参数的关系经常被忽略。temperature过高、top_p过宽、repetition_penalty设置不当都会让模型进入退化状态开始重复单字符。Qwen2 官方推荐的中文对话参数大致是temperature0.7、top_p0.8、top_k20、repetition_penalty1.05。如果你把temperature拉到 1.5 以上很容易看到GGGGGG。generated model.generate( **inputs, max_new_tokens256, do_sampleTrue, temperature0.7, top_p0.8, top_k20, repetition_penalty1.05, eos_token_idtokenizer.eos_token_id, pad_token_idtokenizer.pad_token_id, ) output tokenizer.decode( generated[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue, ) print(output)这里eos_token_id和pad_token_id一定要显式传。如果不传transformers 会用默认值而 Qwen2 的 token id 和默认值不一致生成可能不会正常停止或者把 padding token 解码成可见字符看起来就是乱码。skip_special_tokensTrue也要开否则 special token 会被解码成文本混进输出。如果你用 API 通道调用参数写法对应如下注意 JSON 字段名和本地略有不同{ model: Qwen2-7B-Instruct, messages: [ {role: system, content: 你是一个中文助手。}, {role: user, content: 解释一下 GQA 是什么。} ], temperature: 0.7, top_p: 0.8, max_tokens: 512, frequency_penalty: 0.0, presence_penalty: 0.0 }把这三件套写对之后乱码出现的概率会大幅下降。下一节用实际请求验证对比乱码前后输出确认修复是否生效。4. 验证请求与成功结果对比乱码前后输出确认修复配置写完不能只看代码要实际发请求看输出。这一节给出完整的验证流程包括一个会触发乱码的错误配置和一个修复后的正确配置你可以在自己环境里复现对比。验证的核心思路是控制变量同一段 prompt、同一个模型只改一个参数看输出变化。先构造错误配置。把temperature设成 1.8top_p设成 1.0不传eos_token_id并且手拼 prompt 不用 chat 模板。bad_text 用户请介绍一下 Qwen2。助手 bad_inputs tokenizer(bad_text, return_tensorspt).to(model.device) bad_generated model.generate( **bad_inputs, max_new_tokens128, do_sampleTrue, temperature1.8, top_p1.0, ) bad_output tokenizer.decode( bad_generated[0][bad_inputs[input_ids].shape[1]:], skip_special_tokensFalse, ) print(错误配置输出, bad_output)实测下来这种配置很容易输出GGGGGGGG或者大量重复标点。原因有三手拼 prompt 缺少 assistant 起始标记模型不知道角色边界temperature1.8让分布过于平坦模型进入退化循环skip_special_tokensFalse把控制符解码成可见字符。三个问题叠加乱码几乎必然出现。再跑正确配置用上一节的 chat 模板和推荐参数good_text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue, ) good_inputs tokenizer(good_text, return_tensorspt).to(model.device) good_generated model.generate( **good_inputs, max_new_tokens256, do_sampleTrue, temperature0.7, top_p0.8, top_k20, repetition_penalty1.05, eos_token_idtokenizer.eos_token_id, pad_token_idtokenizer.pad_token_id, ) good_output tokenizer.decode( good_generated[0][good_inputs[input_ids].shape[1]:], skip_special_tokensTrue, ) print(正确配置输出, good_output)正确配置下输出应该是连贯的简体中文没有重复单字符没有问号方块。如果正确配置仍然乱码那就要检查 tokenizer 版本和模型权重是否匹配以及文件编码是不是 UTF-8。再用 API 通道做一次交叉验证。用第 2 节的 Python 代码把model换成Qwen2-7B-Instruct发同样的中文问题。如果 API 返回正常、本地返回乱码说明问题在本地 tokenizer 或参数如果两边都乱码说明请求参数或模型 ID 有问题。这种交叉验证能快速缩小范围。验证时还要看一个细节输出的 token 数量。如果max_new_tokens设得很大但输出很快就停了可能是eos_token_id不对导致提前停止如果输出一直不停、刷满max_new_tokens可能是eos_token_id没生效。这两种情况都会伴随乱码或重复。你可以打印generated.shape和实际解码长度来确认。成功结果的标准很简单中文语义连贯、无重复单字符、无编码错乱符号、能在合理长度内自然结束。达到这四条说明 tokenizer、编码、采样三处都对齐了。下一节列出排查过程中最常见的报错和对应处理。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 对照排查乱码时除了输出异常还会遇到各种报错。这些报错和乱码不是一回事但经常混在一起出现导致判断困难。这一节把常见报错和对应原因列清楚你对照着看。401 Unauthorized 是最常见的接入报错。原因通常是 API Key 没传、传错、或者环境变量没生效。检查TAOTOKEN_API_KEY是否设置正确请求头里Authorization: Bearer sk-xxx格式是否完整。如果你用的是某个客户端确认它读取的是正确的环境变量名。401 不会导致乱码它直接拒绝请求所以看到 401 先解决鉴权别去改 tokenizer。local proxy failed 通常出现在客户端配置了本地代理但代理没启动或者代理地址写错。这个报错和网络通道有关处理方式是检查客户端的代理配置确认 Base URL 是否被错误地指向了本地地址。注意不要把 Base URL 写成带路径的完整接口地址TaoToken 的 Base URL 是https://taotoken.net/api客户端会自动拼接/v1/chat/completions这类路径。写错 Base URL 会导致请求发不出去报连接失败。reading choices 这类报错一般出现在解析响应时代码期望choices字段但响应结构不对。常见原因是请求根本没成功返回的是错误 JSON而代码直接去读choices[0]于是报 KeyError 或 reading choices 失败。排查方法是先把原始响应打印出来看response.status_code和response.text确认返回结构再解析。如果你用 OpenAI SDK异常信息里通常会带状态码先看状态码。OAuth 相关报错多出现在某些客户端的登录流程里比如 Claude Code 或类似工具要求先完成授权。这类报错和 API Key 调用是两条路径如果你用的是 Key 方式就不应该触发 OAuth 流程。检查客户端是否被配置成了 OAuth 模式改回 API Key 模式即可。涉及 Claude Code 接入时Base URL、Key、Model ID 三件套要写全缺一项就会在启动时报错。还有一类报错是模型 ID 不存在返回 404 或 model not found。Qwen2 的模型 ID 在不同通道可能写法不同比如Qwen2-7B-Instruct和qwen2-7b-instruct大小写敏感。确认你用的模型 ID 和通道文档一致。模型 ID 写错不会乱码但会导致请求失败。最后提醒一个容易混淆的点乱码和报错要分开处理。报错是请求没成功乱码是请求成功但输出异常。先确保请求成功再排查乱码。如果你在报错状态下改 tokenizer 参数是白费功夫。把报错清掉拿到正常响应再按第 3、4 节的方法对齐 tokenizer 和采样参数。6. 语义一致 CTA把 Qwen2 乱码排查固化成可复用流程乱码排查做完一次最好把流程固化下来下次换模型或换环境能直接复用。我的做法是准备一个最小验证脚本固定三件事用 chat 模板构造输入、用推荐采样参数生成、打印 tokenizer 的关键 token 信息。这样每次环境变动先跑这个脚本输出正常再继续开发输出异常就先排查。如果你要长期做编码或 Agent 开发可以把 Qwen2 接入到统一通道里用同一套 Key 管理多个模型。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面说明了 Base URL、Key、Model ID 的填写方式。需要管理多个 Key 时API Keys 页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。想快速验证模型输出用模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 手动发一条中文请求即可。长期编码场景可以看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。回到 Qwen2 乱码本身记住三条链路tokenizer 要和权重版本匹配、prompt 要用 chat 模板编码、采样参数要传全eos_token_id和pad_token_id。这三处对齐乱码基本不会出现。遇到乱码先别重装环境按第 4 节的方法做一次错误配置和正确配置的对比看输出差异再定位是哪条链路断了。这个对比动作比盲目改参数有效得多。 Qwen2 输出乱码排查指南：从 tokenizer 到推理参数，TaoToken 统一 Key 实测
1. Qwen2 输出乱码到底长什么样从 GGGGGG 到问号方块的排查起点Qwen2 系列开源之后很多人第一次在本地跑起来输入一句中文结果模型回了一串GGGGGG或者满屏、锟斤拷又或者中英文夹杂着莫名其妙的符号。这类现象统称为乱码输出但它背后的原因完全不是同一个。有人以为是模型权重坏了有人怀疑显卡驱动还有人直接重装环境折腾半天问题依旧。实际上Qwen2 乱码绝大多数情况下出在三个环节tokenizer 配置、prompt 编码、推理采样参数。把这三处对齐九成以上的乱码都能定位并修掉。先说清楚 Qwen2 是什么、能做什么、适合谁。Qwen2 是阿里通义千问团队开源的大语言模型系列覆盖 0.5B、1.5B、7B、57B-A14B、72B 五个尺寸支持中文、英文以及另外 27 种语言上下文最长可到 128K tokens代码和数学能力相比 Qwen1.5 有明显提升。它适合想在本地或私有环境部署 LLM 的开发者、做 RAG 和 Agent 的工程同学以及需要中文能力强的开源模型的团队。你可以用 Hugging Face Transformers 加载也可以用 Ollama、vLLM、llama.cpp 等推理框架跑起来还可以通过统一 API 通道调用。乱码的典型表现可以分成几类先对号入座能省很多时间。第一类是重复单字符比如GGGGGGGG或。。。。。。这通常和 tokenizer 的 special token 配置、生成时的eos_token_id有关。第二类是编码错乱出现锟斤拷、、“这种基本是 UTF-8 和 GBK 之间来回转换导致的。第三类是语言漂移你问中文它回英文或者中英混杂这往往和 prompt 模板、system prompt 缺失有关。第四类是 token 边界错位输出一些看似正常但语义断裂的片段常见于 tokenizer 版本和模型权重不匹配。我试过在同一个 Qwen2-7B-Instruct 权重上用不同版本的 transformers 加载输出质量差异非常明显。老版本 tokenizer 缺少 Qwen2 新增的 special token 定义模型会把本应被识别为控制符的 token 当成普通文本生成于是就开始刷G。所以排查乱码的第一步不是改参数而是确认你的 tokenizer 和模型是不是同一套、版本是不是对得上。这一节先建立判断框架乱码不是单一 bug而是 tokenizer、编码、采样三条链路中某一环断了。接下来会先讲怎么用 TaoToken 统一 Key 快速搭一个可复现的调用环境再逐个拆解这三条链路给出可复制的配置片段和验证请求最后对照真实报错做排查。你跟着走一遍基本能自己判断乱码来源。2. TaoToken 统一 Key 前置准备一个 Key 打通 Qwen2 多通道调用排查乱码最怕的是环境变量太多一会儿本地 transformers一会儿 Ollama一会儿又换个 API变量一多就说不清是模型问题还是通道问题。所以我习惯先用一个统一的 API 通道把 Qwen2 跑通拿到一份“干净”的基线输出再去对比本地环境的输出。TaoToken 在这里的作用就是提供统一的 Key 和 API 入口让你用同一套请求格式去调不同模型减少环境差异带来的干扰。TaoToken 的官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 注意 API 地址后面不加 UTM 参数。你需要先在控制台创建一个 API Key控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。创建好之后把 Key 存到环境变量里不要硬编码进代码。export TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你只是想先验证模型输出是否正常可以直接用模型对话页面手动发一条中文请求看看返回是否连贯。模型对话入口是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。这一步的意义是如果网页端输出正常说明模型本身没问题乱码大概率出在你本地环境的 tokenizer 或编码环节如果网页端也乱码那就要看请求参数和模型 ID 是否匹配。对于要长期做编码或 Agent 的场景可以了解 Coding Plan入口是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面会说明 Base URL、Key、Model ID 三件套怎么填。这里要强调一个原则无论你用哪种客户端只要涉及接入就必须同时确认 Base URL、API Key、Model ID 三项缺一项或者写错一项都会报错而不是乱码。乱码通常发生在请求已经成功、模型开始生成之后。用 TaoToken 做基线的另一个好处是它的请求格式和 OpenAI 兼容接口一致你可以用同一段 Python 代码切换模型只改model字段。这样在排查 Qwen2 乱码时你可以先用 API 通道确认 Qwen2 的正常输出长什么样再回到本地对比。下面这段代码就是最基础的调用骨架先跑通它再往下看 tokenizer 和参数细节。import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) resp client.chat.completions.create( modelQwen2-7B-Instruct, messages[ {role: system, content: 你是一个中文助手请始终用简体中文回答。}, {role: user, content: 用一句话解释什么是 tokenizer。}, ], temperature0.7, top_p0.8, max_tokens256, ) print(resp.choices[0].message.content)这段代码跑通后你会得到一份正常的中文输出。把它保存下来作为后续对比的参照。如果这段代码返回的是GGGGGG或者乱码那问题在请求参数或模型 ID不在本地 tokenizer。如果这段正常、本地 transformers 乱码那基本可以锁定本地环境。下一节开始进入可复制配置重点讲 tokenizer 和推理参数怎么写。3. 可复制配置tokenizer、prompt 编码与推理参数三件套这一节是整篇的核心给出可以直接复制到项目里的配置片段。乱码排查的关键是把 tokenizer 配置、prompt 编码、推理采样参数三处都写对任何一处偷懒都可能复现乱码。先讲 tokenizer。Qwen2 的 tokenizer 必须和模型权重版本匹配。用 transformers 加载时推荐直接用AutoTokenizer.from_pretrained指向模型目录并且显式设置trust_remote_codeTrue因为 Qwen2 的部分实现依赖远程代码。同时要确认pad_token、eos_token、bos_token都有定义缺失会导致生成时行为异常。from transformers import AutoTokenizer, AutoModelForCausalLM import torch model_dir Qwen/Qwen2-7B-Instruct tokenizer AutoTokenizer.from_pretrained( model_dir, trust_remote_codeTrue, use_fastFalse, ) model AutoModelForCausalLM.from_pretrained( model_dir, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue, ) print(pad_token:, tokenizer.pad_token) print(eos_token:, tokenizer.eos_token) print(bos_token:, tokenizer.bos_token) print(vocab_size:, tokenizer.vocab_size)如果pad_token是None生成时 batch 推理会出问题单条推理也可能因为 padding 逻辑异常导致输出错乱。可以手动补上if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token接下来是 prompt 编码。Qwen2-Instruct 系列有固定的 chat 模板必须用apply_chat_template来构造输入不要自己手拼字符串。手拼很容易漏掉 special token模型会把角色标记当成普通文本输出就会漂移甚至乱码。messages [ {role: system, content: 你是一个严谨的中文助手。}, {role: user, content: 请用三句话介绍 Qwen2 的特点。}, ] text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue, ) inputs tokenizer(text, return_tensorspt).to(model.device)注意add_generation_promptTrue它会在末尾加上 assistant 的起始标记少了这个模型不知道轮到自己说话可能继续补全用户内容或者输出奇怪符号。编码环节还要注意文件读写统一用 UTF-8Python 里打开文件时显式写encodingutf-8避免系统默认编码把中文读成乱码再喂给模型。然后是推理采样参数。乱码和采样参数的关系经常被忽略。temperature过高、top_p过宽、repetition_penalty设置不当都会让模型进入退化状态开始重复单字符。Qwen2 官方推荐的中文对话参数大致是temperature0.7、top_p0.8、top_k20、repetition_penalty1.05。如果你把temperature拉到 1.5 以上很容易看到GGGGGG。generated model.generate( **inputs, max_new_tokens256, do_sampleTrue, temperature0.7, top_p0.8, top_k20, repetition_penalty1.05, eos_token_idtokenizer.eos_token_id, pad_token_idtokenizer.pad_token_id, ) output tokenizer.decode( generated[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue, ) print(output)这里eos_token_id和pad_token_id一定要显式传。如果不传transformers 会用默认值而 Qwen2 的 token id 和默认值不一致生成可能不会正常停止或者把 padding token 解码成可见字符看起来就是乱码。skip_special_tokensTrue也要开否则 special token 会被解码成文本混进输出。如果你用 API 通道调用参数写法对应如下注意 JSON 字段名和本地略有不同{ model: Qwen2-7B-Instruct, messages: [ {role: system, content: 你是一个中文助手。}, {role: user, content: 解释一下 GQA 是什么。} ], temperature: 0.7, top_p: 0.8, max_tokens: 512, frequency_penalty: 0.0, presence_penalty: 0.0 }把这三件套写对之后乱码出现的概率会大幅下降。下一节用实际请求验证对比乱码前后输出确认修复是否生效。4. 验证请求与成功结果对比乱码前后输出确认修复配置写完不能只看代码要实际发请求看输出。这一节给出完整的验证流程包括一个会触发乱码的错误配置和一个修复后的正确配置你可以在自己环境里复现对比。验证的核心思路是控制变量同一段 prompt、同一个模型只改一个参数看输出变化。先构造错误配置。把temperature设成 1.8top_p设成 1.0不传eos_token_id并且手拼 prompt 不用 chat 模板。bad_text 用户请介绍一下 Qwen2。助手 bad_inputs tokenizer(bad_text, return_tensorspt).to(model.device) bad_generated model.generate( **bad_inputs, max_new_tokens128, do_sampleTrue, temperature1.8, top_p1.0, ) bad_output tokenizer.decode( bad_generated[0][bad_inputs[input_ids].shape[1]:], skip_special_tokensFalse, ) print(错误配置输出, bad_output)实测下来这种配置很容易输出GGGGGGGG或者大量重复标点。原因有三手拼 prompt 缺少 assistant 起始标记模型不知道角色边界temperature1.8让分布过于平坦模型进入退化循环skip_special_tokensFalse把控制符解码成可见字符。三个问题叠加乱码几乎必然出现。再跑正确配置用上一节的 chat 模板和推荐参数good_text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue, ) good_inputs tokenizer(good_text, return_tensorspt).to(model.device) good_generated model.generate( **good_inputs, max_new_tokens256, do_sampleTrue, temperature0.7, top_p0.8, top_k20, repetition_penalty1.05, eos_token_idtokenizer.eos_token_id, pad_token_idtokenizer.pad_token_id, ) good_output tokenizer.decode( good_generated[0][good_inputs[input_ids].shape[1]:], skip_special_tokensTrue, ) print(正确配置输出, good_output)正确配置下输出应该是连贯的简体中文没有重复单字符没有问号方块。如果正确配置仍然乱码那就要检查 tokenizer 版本和模型权重是否匹配以及文件编码是不是 UTF-8。再用 API 通道做一次交叉验证。用第 2 节的 Python 代码把model换成Qwen2-7B-Instruct发同样的中文问题。如果 API 返回正常、本地返回乱码说明问题在本地 tokenizer 或参数如果两边都乱码说明请求参数或模型 ID 有问题。这种交叉验证能快速缩小范围。验证时还要看一个细节输出的 token 数量。如果max_new_tokens设得很大但输出很快就停了可能是eos_token_id不对导致提前停止如果输出一直不停、刷满max_new_tokens可能是eos_token_id没生效。这两种情况都会伴随乱码或重复。你可以打印generated.shape和实际解码长度来确认。成功结果的标准很简单中文语义连贯、无重复单字符、无编码错乱符号、能在合理长度内自然结束。达到这四条说明 tokenizer、编码、采样三处都对齐了。下一节列出排查过程中最常见的报错和对应处理。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 对照排查乱码时除了输出异常还会遇到各种报错。这些报错和乱码不是一回事但经常混在一起出现导致判断困难。这一节把常见报错和对应原因列清楚你对照着看。401 Unauthorized 是最常见的接入报错。原因通常是 API Key 没传、传错、或者环境变量没生效。检查TAOTOKEN_API_KEY是否设置正确请求头里Authorization: Bearer sk-xxx格式是否完整。如果你用的是某个客户端确认它读取的是正确的环境变量名。401 不会导致乱码它直接拒绝请求所以看到 401 先解决鉴权别去改 tokenizer。local proxy failed 通常出现在客户端配置了本地代理但代理没启动或者代理地址写错。这个报错和网络通道有关处理方式是检查客户端的代理配置确认 Base URL 是否被错误地指向了本地地址。注意不要把 Base URL 写成带路径的完整接口地址TaoToken 的 Base URL 是https://taotoken.net/api客户端会自动拼接/v1/chat/completions这类路径。写错 Base URL 会导致请求发不出去报连接失败。reading choices 这类报错一般出现在解析响应时代码期望choices字段但响应结构不对。常见原因是请求根本没成功返回的是错误 JSON而代码直接去读choices[0]于是报 KeyError 或 reading choices 失败。排查方法是先把原始响应打印出来看response.status_code和response.text确认返回结构再解析。如果你用 OpenAI SDK异常信息里通常会带状态码先看状态码。OAuth 相关报错多出现在某些客户端的登录流程里比如 Claude Code 或类似工具要求先完成授权。这类报错和 API Key 调用是两条路径如果你用的是 Key 方式就不应该触发 OAuth 流程。检查客户端是否被配置成了 OAuth 模式改回 API Key 模式即可。涉及 Claude Code 接入时Base URL、Key、Model ID 三件套要写全缺一项就会在启动时报错。还有一类报错是模型 ID 不存在返回 404 或 model not found。Qwen2 的模型 ID 在不同通道可能写法不同比如Qwen2-7B-Instruct和qwen2-7b-instruct大小写敏感。确认你用的模型 ID 和通道文档一致。模型 ID 写错不会乱码但会导致请求失败。最后提醒一个容易混淆的点乱码和报错要分开处理。报错是请求没成功乱码是请求成功但输出异常。先确保请求成功再排查乱码。如果你在报错状态下改 tokenizer 参数是白费功夫。把报错清掉拿到正常响应再按第 3、4 节的方法对齐 tokenizer 和采样参数。6. 语义一致 CTA把 Qwen2 乱码排查固化成可复用流程乱码排查做完一次最好把流程固化下来下次换模型或换环境能直接复用。我的做法是准备一个最小验证脚本固定三件事用 chat 模板构造输入、用推荐采样参数生成、打印 tokenizer 的关键 token 信息。这样每次环境变动先跑这个脚本输出正常再继续开发输出异常就先排查。如果你要长期做编码或 Agent 开发可以把 Qwen2 接入到统一通道里用同一套 Key 管理多个模型。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面说明了 Base URL、Key、Model ID 的填写方式。需要管理多个 Key 时API Keys 页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。想快速验证模型输出用模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 手动发一条中文请求即可。长期编码场景可以看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。回到 Qwen2 乱码本身记住三条链路tokenizer 要和权重版本匹配、prompt 要用 chat 模板编码、采样参数要传全eos_token_id和pad_token_id。这三处对齐乱码基本不会出现。遇到乱码先别重装环境按第 4 节的方法做一次错误配置和正确配置的对比看输出差异再定位是哪条链路断了。这个对比动作比盲目改参数有效得多。