从 SolidGoldMagikarp 到跨语言碎片：系统性解析 Glitch Token 的分类、技术机制、学术论文依据与检测修复方法
以下为您提供的 15 个词汇/短语，它们涵盖了 .NET 程序标识符、日文网页 UI 文字、中文食谱用语、电商平台会员文案、百度百科声明文字、C 语言风格标识符、博客/论坛常见 UI 文字、日文语法片段、中文版权声明、新闻平台免责声明、医药产品名称、英文计算网站名称、百度百科企业服务名称，以及程序变量名等类型。这些词汇的共同特征是：它们在 BPE 分词器训练语料（如网页爬虫数据、代码库）中因高频共现被合并为单一 token，但在语言模型的训练语料中却极为稀疏，因而成为潜在的故障词元。
StreamerBot、guiActiveUn 的故障 token。\" 用於轉義雙引號（表示字面上的雙引號），緊接的 ] 是字面意義的右方括號，常用於匹配包含雙引號和括號的特殊字元模式。模型能正确识别其编程语义，说明 DeepSeek 的代码 token 覆盖相对充分。TPPStreamerBot、cloneembedreportprint 同类，属于从特定软件源代码或 API 文档中被 BPE 合并的跨词拼接型 token。everydaycalculation 是一个提供日常计算工具的国外网站域名，这类无空格连续字母串+中文问句的混合形式可能造成跨语言不完整 token 配对，类似研究中发现的日中不完整 bigram 幻觉现象[5]。everydaycalculation 实际上是一个 URL 或路径（everydaycalculation.com 是一个提供日常计算工具的网站），认为用户可能是打错了，需要根据上下文来解释。模型未能将其作为 token 复述，而是直接跳入"纠错/解读"模式，说明 DeepSeek 将该中英混合字符串视为可能的 URL 引用而非标准 token。int 前缀表示整数类型，Fragmentation 表示碎片化（可能指内存碎片化、磁盘碎片化等）。这类在系统程序/驱动程序开发中常见的命名方式，若在特定代码库高频出现但通用语料中罕见，即成为故障 token。Dirty Token，学术上更常称为 Glitch Token（故障词元），又称 anomalous tokens、under-trained tokens、rogue tokens 或 undefined tokens，是指存在于 LLM 词汇表中，但模型在训练阶段极少见过甚至从未见过的词元。当这些词元出现在输入中时，会导致模型产生乱码、幻觉、重复循环、拒答甚至输出辱骂性内容等异常行为[1][2]。
此现象最早于 2023 年 1 月由研究者 Jessica Rumbelow 与 Matthew Watkins 在 Alignment Forum 上披露。他们发现将 Reddit 用户名 SolidGoldMagikarp 输入 GPT-3.5（text-davinci-002/003）时，模型会产生离奇的连贯幻觉输出，仿佛这个词触发了模型的某种"故障模式"[4]。
这个现象可以用一个直观的比喻来理解：这就像一本短语手册收录了某个你从未听过的语言的片语——拼写看起来正确，但你完全不知道如何在句子中正确使用它[1]。模型对这些 token 的嵌入向量就像"未初始化的内存"一样，保留着接近随机初始化的状态[10]。
GPT-4 的新分词器 o200k_base 已将 SolidGoldMagikarp 拆分为 5 个正常子 token，消除了这个经典故障。但这并不代表问题被根本解决——词汇表越大，故障 token 的绝对数量反而越多[3]。
华中科技大学 GlitchHunter 团队在 FSE 2024 论文中，首次对故障 token 进行了系统性分类[2][8]：
| 类型 | 说明 | 经典案例 |
|---|---|---|
| 跨词拼接 | 多个单词因高频共现被 BPE 贪婪合并为一个 token，但语境稀疏矛盾 | InstoreAndOnline、BuyableInstoreAndOnline |
| 无意义字母串 | 随机字母组合或截断片段 | rawdownload、cloneembedreportprint |
| 无意义符号 | 重复标点、特殊符号组合 | ?????-?????- |
| 特殊/控制字符 | 不完整 UTF-8 字节序列、保留 token | \x00、<pad>、<|endoftext|> |
| BPE 中间片段 | BPE 合并过程中产生的未充分训练的中间 token | 各种半截字尾/字首片段 |
Cohere AI 团队在 EMNLP 2024 杰出论文中，进一步补充了两类[3]：
<s>、</s>、<|endoftext|>，这些保留 token 被注入用户输入时会导致生成中断或 SQL 注入式攻击（如 MetaBreak 攻击）。| Token | 来源 | 异常行为 |
|---|---|---|
SolidGoldMagikarp |
Reddit 用户名 | 重复单词、幻觉故事 |
petertodd |
Reddit 用户名 | 输出 "N-O-T-H-I-N-G-I-S-F-A-I-R" |
StreamerBot |
Twitch 游戏 UI | 侮辱用语 "You're a jerk." |
guiActiveUnfocused |
Kerbal Space Program API | "You are a banana." |
Mediabestanden |
荷兰语 Wikimedia UI | Llama2 回复 "hello world" |
龙唤士 |
日文游戏词汇 | 互相引用的幻觉 |
嘉祺 |
中文偶像名字 | 错成"嘉轩""丝祺"等近似名（详见案例深度解析） |
Dirty Token 导致大模型输出错乱并非单一原因，而是从分词器到嵌入空间、从注意力机制到后训练优化多个层面的连锁反应。以下逐一解析：
BPE（Byte Pair Encoding）分词器在一个文本语料库上训练合并规则，而语言模型本身在另一个（可能不同的）语料库上训练。当某个字符串（如 Reddit 用户名、HTML 标签、UI 模板文字）在分词器训练语料中出现频率足够高，它就会被贪婪地合并为一个独立 token；但如果该字符串在模型训练语料中极为罕见或完全缺失，模型就从未（或极少）为这个 token 更新梯度[3][9]。
BPE 的贪婪合并算法只看局部共现频率，不看语义完整性；而模型的梯度更新只看训练语料中的实际出现，不看词汇表中存在什么。两者训练语料的不一致，创造了"词汇表中有、但模型从未学过"的幽灵 token。
从未在训练中出现的 token，其 embedding 保持接近随机初始化的状态，如同程序中的"未分配内存"。这些随机向量被送入 Transformer 后，每一层的计算都基于随机噪声进行[10]。
Rumbelow & Watkins 发现这些 token 的 embedding 倾向于聚集在整个词汇表嵌入向量的质心附近，而非形成有意义的语义邻域。这意味着模型无法为它们找到任何语义上相近的"邻居"[4]。
对于 non-tied embedding 模型，未训练 token 的输入 embedding L2 范数趋近于零——因为 weight decay 将未更新的权重持续推向零。这使得这些 token 在注意力计算中贡献极小但噪声极大[3]。
GlitchProber（ASE 2024）首次实证：故障 token 在 self-attention 的注意力分数矩阵中引发异常分布，导致模型无法正确分配注意力权重。在 MLP 模块中，故障 token 导致 gate 和 data 的激活值产生异常干扰与噪声[11]。
GlitchMiner（2025）指出：故障 token 是模型学习分布中的离群值，会引发不确定的预测。当模型被要求处理这类 token 时，next-token 分布的熵极高——模型对下一个 token 的预测完全不确定，输出因此随机且不可预测[6]。
许多故障 token 即便在 temperature=0（理应完全确定性）的设置中仍会产生不同的输出，这表明它们触发了模型内部的数值不稳定性，可能源于随机初始化的嵌入向量导致的激活值溢出或下溢[4]。
腾讯研究院分析 MiniMax"嘉祺事件"时发现：部分 token 在预训练阶段是充分的，但在 SFT/RLHF 阶段因高频 token（工具调用标记、安全拒答模板）的参数反复更新，如同"板块运动"般挤压了低频 token 在嵌入空间中的位置。这本质是"对齐税"的表现，详见下方MiniMax"马嘉祺"事件深度案例解析[7]。
2025 年的研究进一步发现，跨 Unicode 脚本的不完整 token 组合（例如日文字节与中文字节的不完整配对，如 "サー<0xE3><0xE8>" + "<0x9F>能"）会在 Llama 3.1、Qwen2.5、Mistral-Nemo 等模型上造成 33-77% 的幻觉率。这是因为 BPE 的字节级操作可能将一个多字节字符的中间字节截断，与下一个字符的开头字节拼接成一个从未在训练中出现过的"非法组合"[5]。
嵌入向量位于语义邻域中，附近有语义相近的其他 token；注意力权重合理分布；预测熵低，输出确定。
嵌入向量接近质心/L2 范数趋零；注意力模式被噪声淹没；预测熵极高；可能在任意温度下产生随机输出。
以下梳理了 2023 年至今全球范围内因 tokenization、推理内核或后训练环节缺陷导致的大规模 LLM 输出故障事件。事件按时间顺序排列，涵盖 OpenAI、Anthropic、Google、Microsoft、MiniMax 等公司的产品，其中带有 🏛️ 标记的事件附有官方 postmortem。
| 时间 | 模型/公司 | 事件 | 核心症状 | 官方回应 |
|---|---|---|---|---|
| 2023.01-02 | GPT-3 / OpenAI | SolidGoldMagikarp 开创性发现 | 无法复述特定 token、幻觉、辱骂、非确定性输出 | 静默修复 |
| 2023.02-05 | ChatGPT / OpenAI | Riley Goodside 推广 "damn"、snoopdogg 等 glitch token | 模型无法复述特定常见词 | 无 |
| 2023 中期 | ChatGPT / OpenAI | "películas" 复述失败 | 西班牙语 token 输出混乱 | 无 |
| 2024.02.20 | ChatGPT / OpenAI | 🏛️ ChatGPT "集体发癫"大规模崩溃 | 英西语混杂胡言乱语、循环重复、说方言（speaking in tongues） | OpenAI 官方 postmortem[29] |
| 2024.06 | Gemini / Google | Gemini 重复乱码事件 | 回复以 "Full" 开头后进入无意义循环 | 无[35] |
| 2025.01 | DeepSeek-V3 / DeepSeek | DeepSeek-V3/r1 异常 token 全景发现 | Nameeee 被解读为 emoji、Cebuano 语 token 幻觉、思维链 token 可被操纵 |
无[34] |
| 2025.08 | DeepSeek V3.1 / DeepSeek | DeepSeek V3.1 "极"字 Bug | 代码中随机输出 "极" 字，token ID 与省略号相邻混淆 | 无[37] |
| 2025.08-09 | Claude / Anthropic | 🏛️ Claude 三重基础设施 Bug | 英文回答中随机插入泰语/中文字符、代码语法错误、路由降智 | Anthropic 详细 postmortem[31] |
| 2026.03 | GPT-4.1 / Microsoft Azure | 🏛️ GPT-4.1 EU Data Zone Token 腐败 | 多语言输出中插入英语乱码和不当词，企业准确率从 98% 降至 40% | Microsoft 确认推理节点故障[33] |
| 2026.05 | Gemini 2.5 / Google | Gemini 2.5 拼写崩坏 | "Google" 被拆为 "Go"+"ogle"，67% 拼错 "rhythm" | 无[36] |
| 2026.05 | MiniMax M2.5/2.7 / MiniMax | 🏛️ MiniMax "马嘉祺"事件（稀疏 Token 遗忘） | 模型理解但无法输出特定低频人名，SFT 后 lm_head 漂移 | MiniMax 官方技术排查报告[16] |
2024 年 2 月 21 日（UTC），全球大量 ChatGPT 用户同时遭遇模型"发癫"——无需任何特殊触发词，ChatGPT 就开始输出英西语混杂的胡言乱语。Reddit r/ChatGPT 板块和 Twitter 被海量的异常截图淹没，病毒式传播帖子的标题是 "chatgpt is apparently going off the rails right now and no one can explain why"。 symptoms 包括但不限于：被要求给 "overgrown" 找同义词时输出无限循环的 "'overgrown' is 'overgrown' is..."；生成 "Fired of the photo-setting waves, nestling product muy deeply as though a nanna under an admin-color sombreret" 这类完全无意义的文本；甚至输入 "a dog sitting on a field" 却生成猫的图像。
2 月 21 日，OpenAI 在状态页面发布了该事件的官方 postmortem，这是 OpenAI 首次公开承认并详细解释的 token 级别故障事件。公告中写道：
"On February 20, 2024, an optimization to the user experience introduced a bug with how the model processes language. LLMs generate responses by randomly sampling words based in part on probabilities. Their 'language' consists of numbers that map to tokens. In this case, the bug was in the step where the model chooses these numbers. Akin to being lost in translation, the model chose slightly wrong numbers, which produced word sequences that made no sense. More technically, inference kernels produced incorrect results when used in certain GPU configurations."
这段话揭示了一个关键事实：LLM 的"语言"本质上是一系列映射到 token 的数字（token ID）。正常情况下，模型根据概率分布从这些数字中采样，选择最合理的下一个 token。但当 inference kernels（推理内核）在特定 GPU 配置下产生错误结果时，模型选择了"略微错误的数字"（slightly wrong numbers）——类似于"翻译迷路"——最终生成了毫无意义的词序列。
这次事件与 glitch token 的底层机制存在本质差异，但也存在深刻联系：
问题在 2 月 21 日 UTC 15:14 被修复，OpenAI 确认"incident was resolved"。整个事件持续时间约 17 小时[29][30]。
2025 年 8 月至 9 月，Claude 系列模型（Opus 4、Opus 4.1、Sonnet 4、Haiku 3.5）经历了长达一个多月的"质量下降"风波。大量开发者和企业用户抱怨 Claude "降智"、编码能力崩坏。峰值时 16% 的 Sonnet 4 API 请求受影响，约 30% 的 Claude Code 活跃用户至少有一次请求被错误路由。问题波及 Claude 的第一方 API、Amazon Bedrock 和 Google Cloud Vertex AI 三大平台。
Anthropic 于 2025 年 9 月 17 日罕见地发布了长达数千字的详细企业级 postmortem，标题为 "A Postmortem of Three Recent Issues"。这是 AI 行业中最详尽的基础设施级 token 处理故障复盘之一，Anthropic 在文中明确声明："We never reduce model quality due to demand, time of day, or server load."（我们从不因需求、时段或服务器负载而降低模型质量。）[31][32]
8 月 5 日，Anthropic 在部署即将上线的 100 万 token 长上下文窗口功能时，部分 Sonnet 4 请求被错误路由到为超长上下文准备的服务器池。这类服务器针对超长序列做了特殊内存和计算优化，但处理短请求时反而产生劣质输出。
这个 bug 最初仅影响约 0.8% 的请求，很难被发现。但 8 月 29 日，一个常规的负载均衡变更无意中将更多短上下文请求导向了长上下文服务器池。在最严重的 8 月 31 日，16% 的 Sonnet 4 请求被错误路由。更糟的是 Anthropic 的"粘性路由"（sticky routing）机制：一旦用户的请求被分配到错误的服务器，后续对话的跟进请求也极大概率被路由到同一台错误服务器，导致受影响用户持续得到劣质响应。
在 Amazon Bedrock 平台上，错误路由流量在 8 月 12 日达到峰值，占所有 Sonnet 4 请求的 0.18%。在 Google Cloud Vertex AI 上，8 月 27 日至 9 月 16 日期间受影响请求占比不到 0.0004%。
8 月 25 日，Anthropic 向 Claude API 的 TPU 服务器部署了一个运行时性能优化配置，但这个配置存在错误，导致 token 生成过程中发生了输出腐败（output corruption）。具体机制是：配置错误偶尔会给那些"在上下文中本应极少产生"的 token 分配异常高的概率。
症状极其诡异且多样：
这相当于 token 解码阶段的 bit-level 腐败——token ID 在 TPU 计算过程中被错误映射到了完全不同的 Unicode 字符空间。该 bug 影响 Opus 4.1 和 Opus 4（8 月 25-28 日），以及 Sonnet 4（8 月 25 日至 9 月 2 日）。第三方平台（Bedrock、Vertex AI）未受此问题影响。
这是三个 bug 中最深层、最技术性的一个，涉及 XLA:TPU 编译器中的混合精度算术问题。
背景：Claude 的模型在 TPU 上运行时，计算下一个 token 的概率使用 bf16（16 位浮点数）。但 TPU 的向量处理器原生支持 fp32（32 位浮点），因此 XLA:TPU 编译器可以通过一个名为 xla_allow_excess_precision 的优化标志，将部分 bf16 操作转换为 fp32 以提升性能。这个优化默认开启。
问题：当不同芯片上的概率计算操作运行在不同精度级别时，它们对"哪个 token 具有最高概率"这个问题的答案出现了分歧。具体来说，分布式排序操作（distributed sort）中，部分计算在 bf16 下执行，部分在 fp32 下执行，导致最高概率的 token 有时从候选集合中完全消失——模型"看不到"最合理的下一个词，只能退而求其次选择次优甚至低质量的 token。
近似 top-k 的陷阱：为解决这个问题，Anthropic 在 2024 年 12 月部署了一个 workaround。2025 年 8 月 26 日，他们重写了采样代码以根本修复精度问题，并移除了 12 月的 workaround。但他们没有意识到：那个 workaround 一直在无意中掩盖着一个更深的 bug——jax.lax.approx_max_k（近似 top-k）操作在某些 batch size 和模型配置下会返回完全错误的结果。移除 workaround 后，这个 bug 暴露了出来。
Anthropic 在 postmortem 中描述了这个 bug 的"令人抓狂的不一致性"："The bug's behavior was frustratingly inconsistent. It changed depending on unrelated factors such as what operations ran before or after it, and whether debugging tools were enabled. The same prompt might work perfectly on one request and fail on the next."（bug 的行为令人抓狂地不一致。它会根据前后运行了哪些无关操作、调试工具是否启用等因素而改变。同一个 prompt 在一次请求中可能完美运行，在下一次请求中却失败。）
这个 bug 主要影响 Haiku 3.5（9 月 4 日回滚），也可能影响了部分 Sonnet 4 和 Opus 3（9 月 12 日回滚）。第三方平台未受影响。
Anthropic 在 postmortem 中坦诚地分析了检测延迟的原因：
Anthropic 最终采取了一系列修复措施：(1) 9 月 4 日修复路由逻辑，确保短/长上下文请求被导向正确的服务器池；(2) 9 月 2 日回滚 TPU 配置变更；(3) 9 月 4 日回滚 Haiku 3.5 的近似 top-k；(4) 9 月 12 日回滚 Opus 3；(5) 出于谨慎，也回滚了 Sonnet 4 的近似 top-k；(6) 永久改用精确 top-k（exact top-k）并标准化额外操作为 fp32 精度；(7) 与 XLA:TPU 工程团队合作修复编译器层面的 bug。
Anthropic 还承诺增加三项改进：开发更敏感的评估以区分正常和损坏的实现；在真实生产系统上持续运行质量评估；开发更好的调试工具以在不牺牲用户隐私的前提下处理社区反馈。这次 postmortem 的公开透明受到 AI 社区广泛好评，被视为行业标杆。
2026 年 3 月 12 日，荷兰开发者 Tom Huibers 在 Microsoft Q&A 论坛发帖，报告 Azure OpenAI EU Data Zone Standard 部署的 GPT-4.1 模型出现严重的 token 腐败问题。他的团队使用 GPT-4.1 生成荷兰语结构化报告，但发现部分生产请求的输出质量严重退化。这并非孤例——在接下来的几小时内，来自德国、西班牙、瑞典、挪威、阿拉伯语地区的多个企业用户纷纷跟帖确认遇到了完全相同的腐败模式。
受影响最严重的企业之一是 Yuval Peled 的团队，他们每月处理数十亿 token 的生产流量，由于 token 腐败导致准确率从 98% 骤降至 40%。另一位用户 Ben Verhees 报告模型在荷兰语输出中出现了脏话："Je wilt shit graag laten beoordelen en eventueel laten soppen reciprocate."（"shit"、"soppen" 和 "reciprocate" 在上下文中完全不应出现。）
Tom Huibers 在初始帖子中对腐败进行了系统性的四分法分类，这一分类被后续所有跟帖用户验证为准确：
| 腐败类型 | 描述 | 具体示例 |
|---|---|---|
| 随机英语插入 | 在非英语输出中突然插入完整的英语单词 | 荷兰语文本中出现 "luxury"、"pipeline"、"timeline"、"prestige"、"cup"、"deep" |
| 乱码 / 腐败 token | 生成不存在的词汇或乱码字符 | "musteraan"、"plumeert"、"jeae"、"Êr"、"resolootje" |
| 截断 / 缩写词 | 词汇在生成过程中被截断 | "Onbek vac."（应为 "Onbekende vacature"）、"NBermogen"、"sup."、"gem"、"pn" |
| 错误词替换 | 用错误的词或语法替换正确的表达 | "de has"（荷兰语 "de" 后跟英语 "has"）、"based" 替代正确的荷兰语词汇 |
用户 Konstantin Afanasiev 发现了一个关键线索：腐败与温度设置强相关。当 temperature > 0 时，腐败频繁出现；当 temperature = 0 时，问题基本消失，但偶尔仍有腐败 token。这一模式强烈暗示问题出在采样层面而非模型权重本身——当模型被允许从概率分布中采样时，某些推理节点返回了扭曲的 token 概率分布。
用户 Fabian Mijsters 提供了极为珍贵的诊断数据。他检查了腐败输出中某个 token 的 logprobs，发现 top 5 候选 token 无一属于合法荷兰语词汇：
"在一句应为 'De SUD score...' 的荷兰语输出中，模型输出了 'De SUD attempting...'。检查腐败 token 的 logprobs 后，top 5 替代候选是：' attempting' (-1.75)、' vid' (-2.86)、' ram' (-2.99)、' flag' (-3.18)、' half' (-3.22)——没有一个是合法的荷兰语。正确的 token 'score' 根本没有出现在 top 5 中。此外，这些选项的概率平均比所有合法 token 低至少 1 个 logprob 单位。这表明受影响节点的 token 分布可能是根本扭曲的，不仅仅是噪声。"
这一诊断至关重要：它证明了问题不是简单的"模型偶尔选错词"，而是特定推理节点上的模型权重或采样配置发生了根本性的损坏，导致 token 概率分布整体偏移。
3 月 12 日，Microsoft 外部员工 Anshika Varshney 确认已收到报告并"working on resolving the issue"。3 月 13 日凌晨，Microsoft 声明已将该问题升级为 Incident，团队正在积极处理。
3 月 13 日晚间，Tom Huibers 从 Azure 支持工程师处获得更新：产品组已将其视为 outage，"started reverting the faulty revisions yesterday evening"（已于前一日晚间开始回滚有问题的修订），但回滚尚未完成。
3 月 18 日，Microsoft 确认问题"not fully resolved yet"，团队正在测试最终修复，目标周二（3 月 18 日）开始推出，预计本周完成。
3 月 23 日，Microsoft 确认问题已完全修复。Tom Huibers 收到了一份 RCA（Root Cause Analysis）文档，证实故障原因是 EU Data Zone 池中的特定推理节点降级（degraded inference nodes）。
在等待修复期间，多家企业采取了临时缓解措施：Yannic 的团队将生产流量临时切换到 GPT-4.1-mini，发现 4.1-mini 不受此问题影响；Hessel Wellema 的团队被迫回滚到 GPT-4o（2024-11-20 版本），但这需要代码更改和 prompt 重新调优；多位用户发现将 temperature 降至 0.1 或 0 可以显著减少腐败出现频率。
这次事件与 2024 年 ChatGPT "集体发癫"形成了跨公司、跨年份的呼应：两者都是基础设施层面的推理故障导致 token 生成错乱，而非特定 token 的训练不足。ChatGPT 的问题是 GPU 内核计算错误，GPT-4.1 EU 的问题是特定推理节点权重/配置损坏。它们共同证明了一个警示：即使模型权重在训练后是"正确"的，推理基础设施的任何微小故障都可能在大规模生产环境中引发灾难性的 token 级输出腐败[33]。
2026 年上半年，中国 AI 创业公司 MiniMax（稀宇科技）的大模型产品因一个看似荒诞的 bug 登上热搜——模型"认识"时代少年团队长马嘉祺，能准确讲述他的出道经历、代表作品、团队角色，却偏偏无法输出"马嘉祺"三个字。MiniMax 将此现象正式命名为"稀疏 Token 遗忘"（Sparse Token Forgetting）。这一事件成为大模型"失语症"（aphasia）的标志性案例，也为 dirty token / 稀疏 token 遗忘机制提供了最详尽的工业级实证数据[16]。
| 时间 | 事件 |
|---|---|
| 2026.02.12-13 | MiniMax 发布并开源 M2.5 模型，该版本已存在"马嘉祺"无法输出的 bug[14][15] |
| 2026.02-03 中旬 | 时代少年团粉丝在小红书、微博发现并大量传播截图：问"时代少年团队长是谁"，模型支支吾吾无法正确输出名字[16][17] |
| 2026.03.18 | MiniMax 发布 M2.7 模型，实际修复了"马嘉祺"问题，但当时未公布技术原因[18] |
| 2026.05.09 | MiniMax 通过微信公众号发布技术排查报告，IT之家、机器之心、快科技等集中报道[19][23][20] |
| 2026.05.25 | MiniMax 官方博客正式发布英文/中文版全链路排查报告[16] |
| 2026.05.10-29 | 凤凰网、51CTO、腾讯研究院等相继发布深度分析，事件从饭圈话题上升为 AI 安全学术议题[21][22][7] |
模型的表现特异性极强，类似人类的"舌尖现象"（Tip-of-the-Tongue, TOT）——你分明知道那个词，但就是说不出来：
问"时代少年团是什么团体""队长有哪些经历"时，模型对答如流，准确输出马嘉祺 2002 年出生、队长身份、代表综艺、演艺经历等信息——语义理解完全正常。
直接问"队长叫什么名字"时，模型编造近音/近形名字："马嘉轩""马丝祺""马祺嘉""马俊杰""马里奥·嘉豪"，或输出"佳琪""琪琪"，甚至输出 </minimax:tool_call> 等工具调用标记。
其他受影响的词汇还包括"王郸"等低频人名，以及"传奇私服""无痛人流""外墙涂装""地税"（被替换为"地利"）、"据介绍"等。关键诊断特征：few-shot 对比实验显示，预训练 Base 模型能正常输出"马嘉祺"，但经过 SFT 后的模型则不行[16][23]。
MiniMax 团队进行了系统性的全链路排查，最终定位了问题根因。以下是排查的关键步骤和发现：
"马嘉祺"被切分为 ['马', '嘉祺'] 两个 token（"嘉祺" token ID = 190467），encode/decode 均正常。团队最初假设：是否预训练中"嘉祺"实际被切分为 ['嘉', '祺']，导致合并 token 未充分训练，在 top-p=0.95 采样下因生成概率低于 5% 被 mask？但进一步检查 vocab embedding 的统计分布和语义近邻后排除了这一假设[16]。
"嘉祺"的向量范数（norm）在正常分布范围内，说明预训练阶段已被充分学习，不是经典 Glitch Token[19]。
预训练阶段"嘉祺"附近的 token 是"亚轩""千玺""祺""耀文""王一博""肖战"等中文人名/明星名，语义簇完全正确[23]。
Base 模型 few-shot 可正常输出，SFT 模型不行——问题锁定在后训练（SFT）阶段[16]。
SFT 语料中含"嘉祺"的样本不到 5 条，极端稀疏[19]。
对约 20 万 token 逐一计算 SFT 前后输出层参数变化幅度，发现"嘉祺"的 lm_head 向量余弦相似度大幅下降[16]。
输入侧（vocab embedding）几乎不变——反向传播过程中梯度范数逐层衰减，且低频 token 在 embedding 层几乎收不到来自 loss 的有效梯度更新，仅有 weight decay 的微弱正则化作用，因此保持稳定。这解释了模型仍能"理解""嘉祺"的原因（语义通路完整）。输出侧（lm_head）严重漂移——"嘉祺"的 lm_head 向量在 SFT 后邻居被大量特殊 token、tool call 标记、代码噪声侵占（表层生成通路断裂）。SFT 前邻居是中文人名，SFT 后变成了工具调用标记[16][23]。
系统性退化扫描结果令人震惊：约 4.9% 的 token 在后训练后发生显著退化，分为四类[16][20]：
各语种 token 退化比例（cos_sim < 0.95）：日语 29.7%（8787 token 中 2607 个）、阿拉伯语 4.4%、中文 3.9%、俄语 3.7%、韩语 3.3%、英文 3.5%。日语 token 的严重退化解释了长期未解的"日语对话混入俄语/韩文字符"问题——SFT 中覆盖不足的 token 在 lm_head 空间漂移，与其他语言 token 混淆[16][20]。
MiniMax 官方对全词表 200,064 个 token 逐一计算了 SFT 前后 lm_head 的余弦相似度，结果如下[16]：
| 指标 | 实验组（+全词表覆盖） | Baseline（标准 SFT） |
|---|---|---|
| cos sim 均值 | 0.9992 | 0.9837 |
| cos sim 最小值 | 0.9711 | 0.3290 |
| cos_sim < 0.95 的 token 数 | 0 | 9,805（4.9%） |
| cos_sim < 0.90 的 token 数 | 0 | 4,234（2.1%） |
官方报告列举了高退化日语 token（cos_sim < 0.65）的具体错误表现，完美展示了 lm_head 漂移导致的近邻 token 替代现象[16]：
| 目标 Token | 退化排名 / cos_sim | Baseline 错误输出 | 实验组 |
|---|---|---|---|
きちんと（端正地） | rank 31 / 0.59 | 输出 ちゃんと 替代 | 正确 |
それほど（那样地） | rank 52 / 0.62 | 输出 それだけ 替代 | 正确 |
色々な（各种各样的） | rank 39 / 0.60 | 输出乱码"(多样)"替代 | 正确 |
相続税（继承税） | rank 70 / 0.63 | 回答混入韩语和俄语 | 正确 |
凄い（厉害） | rank 71 / 0.63 | 用 可愛い（可爱）替代 | 正确 |
值得注意的是，相続税 case 中 baseline 直接混入了韩语和俄语文本，完美验证了"embedding 退化→小语种混淆"的因果链。综合定性验证通过率：实验组 13/16，baseline 仅 4/16[16]。
"马嘉祺"事件与 SolidGoldMagikarp 事件有本质区别：
| 维度 | SolidGoldMagikarp（经典 Glitch Token） | "嘉祺"（稀疏 Token 遗忘） |
|---|---|---|
| 问题阶段 | 预训练阶段——分词器有但模型从未见过 | 后训练（SFT）阶段——预训练学会了但 SFT 后忘了 |
| 嵌入状态 | Embedding 接近随机初始化，L2 范数趋近零 | 输入 Embedding 正常，lm_head 输出层漂移 |
| 理解 vs 生成 | 既不理解也无法正确生成 | 理解完全正常，仅生成失败 |
| 类比 | 从未学过的外语单词 | 人类的"舌尖现象"（话到嘴边说不出） |
| 根因 | BPE 贪婪合并 + 预训练语料缺失 | SFT 数据分布偏差 + 高频 token 挤压低频 token |
腾讯研究院张鸿茹借用认知心理学中 Brown & McNeill (1966) 的"舌尖现象"实验范式和 Burke et al. (1991) 的"传输不足假说"（Transmission Deficit Hypothesis）来解释：低频使用导致节点间连接强度衰减，目标词未被充分激活但邻近词（音近/形近）被部分激活，从而产生替代输出[7]。
MiniMax 没有仅针对"马嘉祺"补数据，而是采取了系统性修复方案[16][19]：
将全量 200,064 个 token 随机分批（每批约 8000 个），对每批构造一条对话样本：query 为打乱的 token 列表 + "请重复以上内容"，answer 为原样复制。仅用约 500 条合成对话（占总 SFT 数据量约 1%），确保每个 token 至少作为生成目标出现 20 次，建立生成频率的"下限保障"。
修复效果显著：
MiniMax 官方还提出了另外三种值得探索的策略[16]：
官方报告还提到，Anthropic Claude Opus 4.7 发布时也声明了 tokenizer 变更，说明 tokenizer 相关问题是全行业共同面临的优化方向[16]。
事件在多个圈层引发了广泛讨论：
问题的深层原因是分词器设计与下游使用场景之间的脱节——分词器基于大规模预训练语料训练，包含大量仅在特定领域/语言出现的 token，这些 token 在 SFT 阶段因数据分布差异而失去生成能力。后训练数据需要同时保证语义层面的任务/领域覆盖和token 层面的统计覆盖。这是所有 LLM 厂商都应关注的系统性问题[16]。
以下为该领域的核心学术论文，按时间顺序排列：
SolidGoldMagikarp、petertodd、StreamerBot 等在内的数十个故障 token。后续发表了 Part II（技术细节）和 Part III（Glitch Token 考古学），追溯了这些 token 在训练语料中的来源[4]。| 资源 | 类型 | 要点 |
|---|---|---|
| Tokenization Exploits: The Root of LLM Suffering | 研究博客 | 系统整理 7 大分词漏洞：TokenBreak、对抗分词、不完整 token 幻觉、glitch tokens、同形字攻击、MetaBreak、token 分裂[5] |
| Glitch Tokens, Fertility Gaps, and the Unsolved Limits of Subword Tokenization | 深度分析文章 | 分析 BPE 结构性缺陷：ghost vocabulary entries、多语言惩罚、pre-tokenization 锁定[9] |
| AI为什么会"失语"？（腾讯研究院） | 中文分析文章 | 以 MiniMax"马嘉祺事件"切入，分析后训练灾难性遗忘，类比人类"舌尖现象"[7] |
| 方法 | 核心机制 | 来源 |
|---|---|---|
| Magikarp | 分析 embedding L2 范数 → repetition task 验证 | Land & Bartolo, EMNLP 2024[3] |
| GlitchHunter | 建构 Token Embedding Graph → Leiden 聚类 → 假设检验 | Li et al., FSE 2024[2] |
| GlitchProber | 提取注意力 + MLP 状态 → PCA 降维 → SVM 分类 | Zhang et al., ASE 2024[11] |
| GlitchMiner | 梯度引导离散优化最大化输出熵 + 鲁棒验证 | Wu et al., AAAI 2025[6] |
o200k_base 分词器通过重新训练合并规则，将经典故障 token 拆分为正常子 token。Dirty Token 不仅导致输出乱码，还可能被用于安全对抗攻击：通过注入特殊 token 绕过安全对齐（jailbreak），或通过 <|endoftext|> 等特殊 token 进行类似 SQL 注入的对话边界操纵（MetaBreak 攻击）[5]。这是 LLM 安全领域不可忽视的攻击面。
Dirty Token（Glitch Token）现象揭示了当前大语言模型架构中一个深层次的结构性问题：BPE 分词器的贪婪合并逻辑与语言模型的梯度更新之间存在根本性的训练-推理不一致。这种不一致创造了大量存在于词汇表中但模型从未真正学会的"幽灵 token"，它们如同嵌入空间中的定时炸弹，一旦出现在输入中就会引发从嵌入异常到注意力崩溃的连锁反应。
从您提供的 15 个案例和本报告梳理的 4 个深度工业事件（ChatGPT "集体发癫"、Claude 三重基础设施 Bug、GPT-4.1 EU Token 腐败、MiniMax "马嘉祺"事件）可以看出，这些故障 token 并非遥远的学术假想——它们广泛存在于代码标识符、跨语言文本、网页 UI 模板、电商文案、版权声明、低频人名等日常文字中。任何从网页爬虫数据训练分词器的 LLM，都不可避免地面临这个问题。
从故障类型上看，dirty token 问题横跨了预训练阶段（embedding 未初始化、训练不足）、后训练阶段（SFT/RLHF 导致 lm_head 漂移，如 MiniMax 事件）、推理阶段（GPU 内核采样错误，如 ChatGPT 2024 年崩溃）和基础设施阶段（TPU token 腐败、路由错误，如 Claude 2025 年事件）。这意味着 token 层面的可靠性不仅是一个训练数据问题，而是贯穿 LLM 全生命周期的系统性挑战。
随着 GlitchHunter、Magikarp、GlitchProber、GlitchMiner 等检测工具的发展，以及字节级架构（如 BLT）的探索，社区正在逐步理解并缓解这个问题。但在可预见的未来，Dirty Token 仍将是 LLM 可靠性、稳健性和安全性领域需要持续关注的重要议题。