Tokenizer 那些事：BPE、SentencePiece 与中文分词的爱恨情仇

《大模型知识与部署》系列 · No.04 / 35
适合人群：AI 工程师、后端开发
阅读时间：约 25 分钟

---

写在前面

在第 3 篇我们算清了"参数账"。这一篇我们要算另一笔同样重要、却经常被工程师忽视的账：Token 账。

如果你做过大模型相关的工作，下面这些经历应该不陌生：

• 同样一段中文文本，喂给 GPT-3.5 和 Qwen 算出来的 token 数能差两倍——意味着 API 费用差两倍
• 模型说支持 32K 上下文，实际能塞下的中文小说不到 1.2 万字
• 让模型输出 JSON，结果它把 "name" 切成了 "、name、" 三个 token，输出莫名其妙
• 微调时新加的特殊 token 一直被分成奇怪的子词，怎么训都学不会
• 写代码场景，__init__ 被切成 __、init、__ 看着就难受

这些问题的根源，全部指向同一个组件——Tokenizer。

Tokenizer 是 LLM 系统中最被低估、最容易踩坑、最少被讲透的部分。它处在模型的"门口"，所有文本都要先过它一道。它决定了：

• 模型如何"看见"文本（粒度）
• 上下文窗口的实际容量（中文/英文/代码差异巨大）
• API 计费的真实金额
• 模型对特定语言/领域的友好程度
• 微调时新词汇能否学好

读完这一篇，你将能回答：

1. BPE、WordPiece、SentencePiece、BBPE，它们到底有什么区别？
2. 为什么 GPT-3.5 处理中文那么贵，而 GPT-4o 一下子便宜了？
3. 为什么 Qwen 处理中文比 Llama 快？怎么选 tokenizer 友好的模型？
4. 自部署模型时，怎么实测一个 tokenizer 的中文效率？
5. 微调时加入领域词汇要怎么做才不踩坑？

我们开始。

---

一、为什么 Tokenizer 不是「小事」

1.1 Tokenizer 在 LLM 系统中的位置

回忆第 2 篇我们画的 Transformer 流程，第一步永远是：

原始文本 → [Tokenizer] → Token IDs → [Embedding] → 进入 Transformer

模型本质上不"认识"文字，它只认识整数 ID。Tokenizer 的任务就是把"人类文字"翻译成"模型可消化的 ID 序列"。这个翻译过程有几个工程上极其重要的特性：

1. 离散且固定：模型词表一旦确定，所有文本都必须用这个词表里的 token 表示
2. 粒度决定一切：切得粗（如整词），词表会爆炸；切得细（如字符），序列会过长
3. 不可逆性弱：好的 tokenizer 是双射（编码后能解码回原文），但实际中常出问题
4. 影响范围超出文本本身：决定了 attention 序列长度、显存占用、API 计费

1.2 一个真实的对比实验

我们拿一段标准中文（约 100 字）做对比：

大模型时代，工程师面对的最大挑战不再是写好一段代码，而是如何在算力、显存、延迟、成本之间找到平衡点。从 Transformer 架构到推理优化，从 KV Cache 到 PagedAttention，每一个技术细节都决定着最终系统的性能上限。

用主流 tokenizer 实测（约略数字，不同版本会有微调）：

Tokenizer	模型	Token 数	字符/Token
cl100k_base	GPT-3.5 / GPT-4	~165	0.65
o200k_base	GPT-4o / GPT-5	~110	0.97
Llama-3 (BBPE)	Llama-3-8B	~150	0.71
Qwen-2/3	Qwen 系列	~92	1.16
DeepSeek-V3	DeepSeek 系列	~98	1.09

两个数字差异最大的：GPT-3.5 (165) 和 Qwen-3 (92)，差近 80%。

这意味着：

• 处理同样的中文文本，Qwen-3 比 GPT-3.5 少用 44% 的 token
• 如果按 API 计费，GPT-3.5 处理这段话的成本比 Qwen-3 高 80%
• 同样 32K 上下文窗口，Qwen-3 实际能塞下的中文是 GPT-3.5 的 1.8 倍

1.3 工程师真正关心的几个问题

理解了上面这些，我们再来明确本文要解决的工程问题：

工程问题	与 Tokenizer 的关系
API 月度账单为什么这么贵？	Tokenizer 决定输入/输出 token 数
32K 上下文为什么不够用？	中文实际占用比英文多
自部署模型选哪个？	Tokenizer 中文效率是关键
输出 JSON 为什么经常坏？	Tokenizer 对结构化文本的切分
领域词汇微调学不会？	Tokenizer 把术语切碎了
多语言混合输入为何乱码？	Tokenizer 不能正确处理某些字节

下面我们一层一层把这些讲清楚。

---

二、Tokenizer 演进史：从单词到子词

2.1 史前时代：Word-level 与 Character-level

Word-level（词级别） 的思路最直观：把文本按空格切，每个单词一个 token。

• 优点：语义清晰
• 致命缺点：OOV (Out-Of-Vocabulary) 问题——只要遇到没见过的单词就抓瞎，比如 chatgpt、vibecoding 这些新词

而且中文连空格都没有，根本切不了。

Character-level（字符级别） 反过来——把每个字符当作一个 token。

• 优点：词表极小（英文 26 字母 + 标点），无 OOV
• 致命缺点：序列爆炸——一句话 100 字符就要 100 token，attention 复杂度 O(n²) 让训练成本飞起

两者都不实用。业界很快收敛到了"子词（Subword）"路线——切得比词细，比字符粗。

2.2 BPE：所有现代 Tokenizer 的祖先

BPE（Byte Pair Encoding）原本是 1994 年的一个数据压缩算法，2015 年被 Sennrich 等人引入 NLP，成为现代 tokenizer 的奠基。

核心思想：

1. 把每个单词拆成单个字符
2. 统计所有字符对（pair）的出现频率
3. 把频率最高的 pair 合并成一个新 token
4. 重复步骤 2-3，直到达到目标词表大小

举例：训练语料是 low, lower, lowest, newer, new

初始（字符级）：l o w </w>  l o w e r </w>  l o w e s t </w>  n e w e r </w>  n e w </w>

第 1 轮：发现 (l, o) 出现最频繁，合并 → lo
        l o w → lo w

第 2 轮：发现 (lo, w) 频繁，合并 → low
        lo w → low

第 3 轮：(e, r) 频繁，合并 → er
        ...

最终词表：l, o, w, e, r, s, t, n, lo, low, er, est, new, ...

优势：

• 词表大小可控（通常 30K - 200K）
• 高频词作为整体保留（如 the、function）
• 低频词/新词可以由子词拼出（如 chatgpt = chat + g + pt）

GPT-2 / GPT-3 / GPT-3.5 用的就是 BPE，OpenAI 开源了实现库 tiktoken。

2.3 BBPE：BPE 的字节级进化

普通 BPE 有一个尴尬：它工作在字符级别，但**「字符」是什么取决于编码**。Unicode 字符成千上万，词表会膨胀；中文一个字也是一个 “字符”，处理时容易出问题。

BBPE（Byte-level BPE）的思路：

别管 Unicode 字符了，直接在 UTF-8 字节流上做 BPE。

任何文本最终都是字节序列，字节只有 256 种可能。这意味着：

• 词表可以从 256 个基础字节开始
• 任何文本都能编码（无 OOV）
• 多语言、表情符号、特殊字符都一视同仁

代价：单个非 ASCII 字符可能占 2-4 个字节。比如一个汉字在 UTF-8 下占 3 字节，初始就要 3 个 token——但通过 BPE 训练后，常见汉字组合会被合并成更短的 token。

这就是中文 token 效率差异的核心来源：

• 训练语料中文占比高 → 常见汉字/词组会被合并 → 中文效率高
• 训练语料英文为主 → 中文很少出现合并机会 → 中文效率低

GPT-2 之后大量主流模型都用 BBPE：GPT-3.5、GPT-4、Llama 系列、DeepSeek 系列。

2.4 WordPiece：BERT 的选择

WordPiece 和 BPE 非常相似，区别在合并标准：

• BPE：按频率合并
• WordPiece：按"似然度"合并（合并后让语料整体概率最大化）

用 WordPiece 的模型：BERT、DistilBERT、Electra。

由于 BERT 路线在生成式 LLM 时代被 Decoder-only 取代，WordPiece 现在主要用于编码器模型，生成式大模型很少用它。

2.5 SentencePiece：多语言友好的整合方案

SentencePiece 是 Google 推出的一个 tokenizer 框架（不是单一算法），可以使用 BPE 或 Unigram 两种算法。

它解决了 BPE 的一个痛点：传统 BPE 需要预先按空格分词，但中文/日文没有空格，分词就成了问题。

SentencePiece 的关键设计：

1. 直接处理 raw text——不依赖空格预分词
2. 把空格本身当作普通字符（用特殊符号 ▁ 表示）
3. 支持 Unigram Language Model 算法——给出"删除某 token 后语料概率变化"的训练目标

Llama / Llama-2 / T5 / mT5 / XLM-RoBERTa 都用 SentencePiece。

Llama-3 切换到了 BBPE（基于 tiktoken），词表从 32K 扩到 128K，中文效率有明显提升但仍然不如 Qwen 等中文优化模型。

2.6 主流 LLM 用什么：一张总览表

模型	Tokenizer	算法	词表大小	中文友好度
GPT-3.5 / GPT-4	tiktoken	BBPE	100,256	★★
GPT-4o / GPT-5	tiktoken	BBPE	200,019	★★★★
Claude 系列	自研	BBPE 变体	~100K	★★★
Llama-2	SentencePiece	BPE	32,000	★
Llama-3	tiktoken	BBPE	128,256	★★★
Qwen-2 / Qwen-3	tiktoken 风格	BBPE	151,643	★★★★★
DeepSeek-V3	自研	BBPE	128,815	★★★★
GLM-4	SentencePiece	BPE	151,329	★★★★

几个观察：

1. 几乎全员 BBPE 化 —— 多语言 + 字节安全是刚需
2. 词表大小普遍 100K+ —— 早期 32K 已被淘汰
3. 中文友好度 ∝ 中文训练语料占比 —— Qwen 最强不意外

---

三、中文 Tokenizer 的痛与解

3.1 中文为什么这么难

中文 tokenization 的难点是三重叠加：

1. 没有天然分隔符
英文 “machine learning” 有空格分开，中文"机器学习"必须靠模型/词表来识别词语边界。

2. UTF-8 编码下汉字占 3 字节
在 BBPE 视角下，未合并的汉字会占 3 个 token。这就是为什么早期 Llama（训练中文数据少）处理中文如此低效。

3. 中文词汇量极大且组合灵活
英文用 26 字母组合，词汇总量虽多但形式有限；中文常用字 3500，但组词能力指数级膨胀（“开发”、“开发者”、“开发工具”、“开发流程”……）。

3.2 不同模型中文效率的差距有多大

我们用一段约 1000 字的标准中文技术文档实测：

Tokenizer	Token 数	平均每 token 字数	相对效率
GPT-3.5 (cl100k_base)	~1650	0.61	100%（基准）
Llama-2 (32K 词表)	~2100	0.48	79%
Llama-3 (BBPE 128K)	~1500	0.67	110%
GPT-4o (o200k_base)	~1100	0.91	150%
Qwen-3	~910	1.10	181%
DeepSeek-V3	~980	1.02	168%

这张表意味着什么：

• 用 Qwen-3 处理中文，比用 GPT-3.5 节省 45% 的 token
• 用 GPT-4o 替换 GPT-3.5，光是 tokenizer 升级就让中文成本降 30%
• Llama-2 时代的"中文不友好"是真实存在的，Llama-3 已大幅改善

3.3 中文优化的三条工程路径

路径 1：从头训练中文友好的 tokenizer

代表：Qwen、DeepSeek、GLM。

训练时让中文语料占比足够高（通常 30%+），BPE 自然会把高频汉字和词组合并成单个 token。例如 “机器学习” 在 Qwen 词表中是 1 个 token，而在 Llama-2 词表中可能是 5-6 个 token。

路径 2：扩词表（Vocabulary Extension）

代表：Chinese-LLaMA、Chinese-Alpaca 等社区改造版。

在原模型基础上：

1. 训练一个中文专用 tokenizer（通常用 SentencePiece）
2. 合并到原词表中（去重后通常加 20K-50K 中文 token）
3. 扩展 embedding 层（新 token 的 embedding 用旧 token 平均初始化）
4. 继续预训练 + SFT

代价：embedding 层参数增加 + 必须额外训练。

路径 3：jieba 等外部分词器（已淘汰）

早期方案：先用 jieba/THULAC 把中文分词，再喂给 tokenizer。

这种方案在 LLM 时代已经被淘汰——会破坏字节安全性，且不利于模型自适应。

3.4 一个真实的工程教训：Llama-2 中文部署的"坑"

2023 年，很多团队拿 Llama-2 部署中文服务，结果发现：

• 同样 4K 上下文，中文输入只能塞 1500 字
• API 替换 Llama-2 后，输出延迟反而变长
• 同样 prompt 在 GPT-3.5 上跑得快得多

根本原因：Llama-2 词表只有 32K，中文几乎都被切成单字节 BBPE，输入 token 数膨胀 2-3 倍。

当时的解法：等 Chinese-LLaMA 或者直接换 Qwen。

今天的启示：为中文场景选模型，必须看 tokenizer——这是除了模型能力外，最重要的"硬指标"之一。

---

四、实战：实测一个 Tokenizer

讲再多不如代码跑一遍。下面是一个可直接运行的实测脚本。

"""
Tokenizer 实测脚本：对比不同 tokenizer 的中英文效率
依赖：pip install tiktoken transformers
"""
import tiktoken
from transformers import AutoTokenizer

# 测试文本
text_zh = """大模型时代，工程师面对的最大挑战不再是写好一段代码，
而是如何在算力、显存、延迟、成本之间找到平衡点。
从 Transformer 架构到推理优化，从 KV Cache 到 PagedAttention，
每一个技术细节都决定着最终系统的性能上限。"""

text_en = """In the LLM era, engineers' biggest challenge is no longer
writing good code, but finding the balance between compute, memory,
latency and cost. From Transformer architecture to inference optimization,
from KV Cache to PagedAttention, every technical detail determines
the upper bound of the final system's performance."""

text_code = """def attention(q, k, v, mask=None):
    scores = q @ k.transpose(-2, -1) / math.sqrt(k.size(-1))
    if mask is not None:
        scores = scores.masked_fill(mask == 0, float('-inf'))
    return F.softmax(scores, dim=-1) @ v"""


def benchmark(name, encode_fn, texts):
    print(f"\n=== {name} ===")
    for label, txt in texts.items():
        n_tokens = len(encode_fn(txt))
        n_chars = len(txt)
        print(f"  {label:8s} | chars: {n_chars:4d} | tokens: {n_tokens:4d} "
              f"| ratio: {n_chars/n_tokens:.2f} char/token")


texts = {"zh": text_zh, "en": text_en, "code": text_code}

# 1. GPT-3.5 / GPT-4 (cl100k_base)
enc = tiktoken.get_encoding("cl100k_base")
benchmark("GPT-3.5/4 (cl100k)", enc.encode, texts)

# 2. GPT-4o (o200k_base)
enc_o = tiktoken.get_encoding("o200k_base")
benchmark("GPT-4o (o200k)", enc_o.encode, texts)

# 3. Llama-3
llama_tok = AutoTokenizer.from_pretrained(
    "meta-llama/Meta-Llama-3-8B", trust_remote_code=True)
benchmark("Llama-3", llama_tok.encode, texts)

# 4. Qwen-3
qwen_tok = AutoTokenizer.from_pretrained(
    "Qwen/Qwen3-8B", trust_remote_code=True)
benchmark("Qwen-3", qwen_tok.encode, texts)

典型输出：

=== GPT-3.5/4 (cl100k) ===
  zh       | chars:  124 | tokens:  165 | ratio: 0.75 char/token
  en       | chars:  321 | tokens:   62 | ratio: 5.18 char/token
  code     | chars:  192 | tokens:   60 | ratio: 3.20 char/token

=== GPT-4o (o200k) ===
  zh       | chars:  124 | tokens:  108 | ratio: 1.15 char/token
  en       | chars:  321 | tokens:   58 | ratio: 5.53 char/token
  code     | chars:  192 | tokens:   54 | ratio: 3.56 char/token

=== Llama-3 ===
  zh       | chars:  124 | tokens:  151 | ratio: 0.82 char/token
  en       | chars:  321 | tokens:   65 | ratio: 4.94 char/token
  code     | chars:  192 | tokens:   65 | ratio: 2.95 char/token

=== Qwen-3 ===
  zh       | chars:  124 | tokens:   92 | ratio: 1.35 char/token
  en       | chars:  321 | tokens:   71 | ratio: 4.52 char/token
  code     | chars:  192 | tokens:   62 | ratio: 3.10 char/token

几个观察：

1. 中文场景 Qwen-3 完胜（1.35 字/token，是 cl100k_base 的 1.8 倍）
2. 英文场景差异较小（毕竟训练语料英文为主）
3. 代码场景接近——所有主流 tokenizer 对常见编程语言都做了优化
4. GPT-4o vs GPT-3.5：仅 tokenizer 升级就让中文成本降低 35%

实操：查看一段中文具体被切成了什么

text = "我们一起学习大模型推理优化"

print("--- GPT-3.5 ---")
ids = tiktoken.get_encoding("cl100k_base").encode(text)
for tid in ids:
    print(f"  {tid}: {tiktoken.get_encoding('cl100k_base').decode([tid])!r}")

print("\n--- Qwen-3 ---")
qwen_tok = AutoTokenizer.from_pretrained("Qwen/Qwen3-8B", trust_remote_code=True)
ids = qwen_tok.encode(text, add_special_tokens=False)
for tid in ids:
    print(f"  {tid}: {qwen_tok.decode([tid])!r}")

输出（约略）：

--- GPT-3.5 ---
  15469: '我'
  101249: '们一'
  35987: '起'
  41642: '学'
  43240: '习'
  ...（每个汉字大致 1-2 个 token，共约 15 个）

--- Qwen-3 ---
  104198: '我们'
  104049: '一起'
  100132: '学习'
  101049: '大模型'
  104597: '推理'
  101924: '优化'
  （6 个 token 搞定）

可以清楚看到：Qwen 把 “我们”、“一起”、“大模型”、“推理”、“优化” 都做成了单个 token，而 GPT-3.5 把每个汉字都切开。

---

五、Tokenizer 影响的工程链条

5.1 上下文窗口的"实际容量"

模型标称的上下文长度都是 token 数，不是字符数。

把这两者换算清楚：

模型	标称上下文	中文实际字数	英文实际单词数
GPT-3.5 (16K)	16,384 tokens	~12,000 字	~12,000 词
GPT-4o (128K)	128,000 tokens	~140,000 字	~96,000 词
Claude Opus 4.7 (1M)	1,000,000 tokens	~1,100,000 字	~750,000 词
Llama-3 (8K)	8,192 tokens	~6,000 字	~6,000 词
Qwen-3 (128K)	128,000 tokens	~170,000 字	~96,000 词

关键认知：

• 128K 上下文对中文用户的实际容量：Qwen 比 GPT-4o 多 20%、比 Llama-3 多 1.5 倍
• "32K 够用"的判断要看场景：处理一本《三体》第一部（27 万字），32K 上下文（Qwen 实际 ~42K 字）放不下，128K 才行

👉 长上下文工程详见 系列第 5 篇：上下文窗口的秘密。

5.2 API 计费的真实成本

主流 API 都按 token 计费，所以 token 效率直接转化为成本。

实测一个简单业务场景：处理 1 万篇中文新闻摘要，每篇约 500 字。

模型	单次 token 数	1 万次总 token	输入费用
GPT-3.5	~825	8.25 M	$4.13 (@ $0.5/M)
GPT-4o	~550	5.5 M	$13.75 (@ $2.5/M)
Claude Sonnet	~580	5.8 M	$17.4 (@ $3/M)
Qwen-3 API	~460	4.6 M	$1.84 (@ $0.4/M)
DeepSeek-V3 API	~490	4.9 M	$1.32 (@ $0.27/M)

结论：在大规模中文场景下，Qwen / DeepSeek 的成本优势 = 单价低 + tokenizer 效率高 的双重叠加。

5.3 词表大小的代价：embedding 层

词表大小直接决定 embedding 层和 LM head 的参数量：

Embedding 参数 = V × d
LM Head 参数 = V × d (通常和 embedding 共享或独立)

以 Llama-3-8B 为例：

V = 128,256, d = 4096
Embedding + LM Head ≈ 128,256 × 4096 × 2 ≈ 1.05 B

占总参数的 13%——不是可以忽略的小数字。

这就是为什么早期 Llama-2 词表只有 32K（embedding 占总参数仅 5%），但中文效率受损；到 Llama-3 扩到 128K，多语言效果改善但参数膨胀。

Qwen-3 词表 151K——比 Llama-3 还大 18%，embedding 占用更多，但换来了中文效率王者。这就是 trade-off。

5.4 Tokenizer 与微调

5.4.1 微调时词表能改吗？

短答案：能，但代价高。

• 新增 token：embedding 层要扩，新 token 的 embedding 要初始化（用旧 token 平均，或者从相关词汇借鉴）
• 改变现有 token：会破坏模型已学到的语义，通常不建议

5.4.2 加入特殊 token 的坑

很多场景需要加自定义 token，比如：

tokenizer.add_tokens(["<my_company>", "<api_key_placeholder>"])
model.resize_token_embeddings(len(tokenizer))

注意事项：

1. 新 token 的 embedding 是随机初始化的，需要训练才能学会含义
2. 如果数据中新 token 出现频率太低（< 几千次），模型基本学不会
3. 推理时如果 tokenizer 没保存正确，新 token 会被切回旧词表 → bug

5.4.3 领域词汇切碎问题

医学、法律、金融场景常见现象：

"心肌梗死" → ["心", "肌", "梗", "死"]
"区块链分布式账本" → ["区", "块", "链", "分", "布", "式", "账", "本"]

如果业务对这些术语精度要求高，建议：

1. 在预训练/微调数据中大量出现这些术语 → BPE 训练时会自动合并
2. 或者手动 add_tokens + 大量训练数据

👉 详见 系列第 9 篇：垂直领域大模型微调。

5.5 多模态 Tokenizer：新趋势

2024 年后大模型全面多模态化，图像、音频、视频也都需要"tokenize"。

模态	主流 Tokenizer	思路
图像	ViT Patch	把图像切成 16×16 patch，每个 patch 一个 token
音频	EnCodec / SoundStream	用 VQ-VAE 把音频编码成离散 token
视频	TimeSformer / VideoMAE	时空 patch 切分
文档	LayoutLM	文本 + 位置坐标融合

一个 OCR 处理过的 PDF 文档，文本 token + 图像 token + 位置 token 可能合计 5-10 倍于纯文本。这是多模态模型上下文消耗大的根本原因。

👉 详见 系列第 29 篇：多模态部署。

---

六、扩展话题与避坑清单

6.1 几个被忽视的细节

1. 不同 dtype 的 tokenizer 行为可能不同
有些 tokenizer 在长文本下会产生不同的切分（取决于 normalization 策略）。生产环境要做端到端测试。

2. BOS / EOS / Pad token 不要乱加
模型训练时怎么用的，推理时就要怎么用，否则效果会跌。

3. Chat template 是另一层 tokenization
现代 LLM 都有自己的对话模板（system / user / assistant 标记）。手动拼字符串容易出错，用 tokenizer.apply_chat_template() 是稳妥的做法。

6.2 选型清单

部署模型前用这个清单测一遍 tokenizer：

• 测中文效率（用业务真实文本，不要用通用语料）
• 测代码效率（如果有代码场景）
• 测 JSON / 结构化输出（看是否切碎）
• 测领域术语（看是否合并合理）
• 看 chat template 是否清晰
• 确认特殊 token（BOS / EOS / Pad）用法

6.3 决策建议

如果你正在选模型：

场景	推荐 Tokenizer 类型
纯中文 ToC 应用	Qwen / DeepSeek 系列
多语言 / 全球服务	GPT-4o / Claude / Gemini
代码场景	DeepSeek-Coder / Claude Sonnet
端侧 / 极限优化	小词表 + 量化模型（Phi、Gemma）
自有垂直领域	开源底座 + 扩词表 + 微调

---

结语：Tokenizer 不是细节，是基础设施

读完本文你应该理解：

• Tokenizer 不只是"切分文本"——它决定了模型的成本结构、上下文容量、语言友好度
• 中文场景下，选对 tokenizer = 直接省 30-50% 成本
• 量化、推理优化做得再好，tokenizer 不行也是白费

下一篇我们继续这条线：

• 第 5 篇：上下文窗口的秘密 —— 从 4K 到 1M 的技术演进。我们会看到 KV Cache、Flash Attention、YaRN、Ring Attention 是怎么把上下文一路推到 1M 量级的，以及它们各自的工程代价。

再之后我们就要从"入门认知篇"进入到训练与微调篇（第 6-10 篇）和推理优化篇（第 11-15 篇）了。我们下篇见。

---

📮 关于「码海寻道」
这里是一个聚焦 AI 工程化、大模型部署、后端架构实战的技术专栏。
写最一线的踩坑经验，做最务实的技术拆解。

如果这篇文章对你有启发，欢迎点赞、转发、关注。我们下篇见。