万字长文：解密 AI 时代的原子——Token 的分词、计费与隐私计算

jack.yang

修改于 2026-03-25 13:40:04

2260

引言：Token——AI 世界的通用货币

在与 ChatGPT、Claude 或任何大语言模型（LLM）交互时，你可能已经注意到一个无处不在的概念：Token。API 调用按 Token 计费，模型有上下文长度限制（如 128K tokens），甚至你的输入和输出都会被拆分成一串 Token ID。

但 Token 究竟是什么？它仅仅是“单词”吗？为什么一个简单的标点符号也要收费？当你的敏感数据被转换成 Token 发送给云端模型时，隐私如何保障？

本文将摒弃浅显的比喻，深入到 Hugging Face Transformers 库、OpenAI API 规范、以及前沿的隐私计算技术中，为你揭示 Token 背后的完整技术图景。

第一章：Token 的诞生——大模型分词器（Tokenizer）全解析

Token 并非天然存在，而是由一个名为 Tokenizer（分词器） 的组件创造出来的。它是连接人类语言与机器语言的桥梁。

1.1 为什么需要分词？从字符到语义单元

大模型的神经网络无法直接处理原始字符串。它们的输入是一个数字序列（ID）。因此，我们需要一个映射： "Hello, world!" → [15496, 11, 995, 0]

这个映射过程就是分词。早期的分词方法（如 Word-level）存在严重问题：

词汇表爆炸：英语有数十万单词，加上专有名词、拼写错误，词汇表会无限增长。
未知词（OOV）问题：遇到训练时未见过的词（如新造词 “selfie”），模型就懵了。

为了解决这些问题，现代 LLM 普遍采用 子词（Subword）分词算法。

1.2 核心算法：Byte Pair Encoding (BPE)

BPE 是目前最主流的分词算法，被 GPT 系列、Llama 系列等广泛采用。其核心思想是：从字符开始，逐步合并最常见的相邻字符对，形成新的“词元”。

让我们通过 Hugging Face tokenizers 库的源码来理解 BPE 的工作流程。

# Hugging Face tokenizers: tokenizers/src/models/bpe/model.py

class BPE:
    def __init__(self, vocab: Dict[str, int], merges: List[Tuple[str, str]]):
        self.vocab = vocab      # 词汇表：{"h": 0, "e": 1, ..., "hello": 100}
        self.merges = merges    # 合并规则：[("h", "e"), ("he", "l"), ...]

    def _encode_word(self, word: str) -> List[str]:
        """对单个单词进行 BPE 编码"""
        # 1. 初始化：将单词拆分为字符列表
        # "hello" -> ['h', 'e', 'l', 'l', 'o']
        tokens = list(word)
        
        # 2. 循环应用合并规则
        while len(tokens) > 1:
            # 找到 tokens 中第一个存在于 merges 列表中的相邻对
            pair_to_merge = self._find_pair_to_merge(tokens)
            if pair_to_merge is None:
                break
            
            # 3. 执行合并
            # 例如，合并 ('h', 'e') -> 'he'
            tokens = self._merge_tokens(tokens, pair_to_merge)
        
        return tokens  # 返回子词列表，如 ['hel', 'lo']

    def encode(self, text: str) -> List[int]:
        """对整个文本进行编码"""
        words = text.split()  # 简化的按空格分词
        all_subwords = []
        for word in words:
            subwords = self._encode_of_word(word)
            all_subwords.extend(subwords)
        
        # 4. 将子词映射为 ID
        return [self.vocab[subword] for subword in all_subwords]

BPE 的关键优势：

解决 OOV 问题：任何新词都可以被分解为其组成的字符或已知的子词。例如，“unhappiness” 可以被分解为 ["un", "happi", "ness"]。
压缩词汇表：常用词作为一个整体（如 “the”），不常用词或新词则被拆分，有效控制了词汇表大小（通常在 30K-100K 之间）。

1.3 实战：不同文本的 Token 化差异

让我们用 OpenAI 的 tiktoken 库（GPT-4 使用的分词器）来直观感受：

import tiktoken

enc = tiktoken.get_encoding("cl100k_base") # GPT-4 的编码

# 英文：单词通常是一个 Token
print(enc.encode("Hello"))          # [15496]
print(enc.encode("Hello, world!"))  # [15496, 11, 995, 0]

# 中文：每个汉字通常是独立的 Token
print(enc.encode("你好"))           # [92543, 92728]
print(enc.encode("人工智能"))       # [88917, 87760, 91985, 93285]

# 数字和特殊符号
print(enc.encode("2023年"))         # [2023, 269] # 数字 "2023" 是一个 Token！
print(enc.encode("$100"))           # [28, 100]   # "$" 和 "100" 分开

结论：

Token ≠ 单词：它是一个更细粒度的语义/字形单元。
语言依赖性：英文 Token 效率高（一个词一个 Token），中文、日文等则效率较低（一个字一个 Token）。
计费基础：API 按 Token 计费，意味着发送一段中文文本的成本大约是同等意思英文文本的 2-3 倍。

第二章：Token 的代价——大模型 API 计费模型深度剖析

理解了 Token 是什么，我们就能看透各大厂商的计费策略。

2.1 OpenAI 的计费逻辑：输入与输出分离

OpenAI 的定价清晰地分为两部分：

Input Tokens: 你发送给模型的提示（Prompt）所消耗的 Token。
Output Tokens: 模型生成的回答所消耗的 Token。

为什么分开计费？

成本驱动：模型在生成每个 Output Token 时，都需要重新处理整个 Input Context。Input 越长，生成每个 Output Token 的计算成本就越高。
激励优化：鼓励用户编写更精炼的 Prompt，减少无效信息。

源码视角（伪代码）：

def calculate_cost(model, prompt, completion):
    input_tokens = tokenizer.count(prompt)
    output_tokens = tokenizer.count(completion)
    
    # 不同模型有不同的单价
    input_price = PRICING[model]["input"]
    output_price = PRICING[model]["output"]
    
    total_cost = (input_tokens * input_price) + (output_tokens * output_price)
    return total_cost

2.2 上下文窗口：Token 的“内存”限制

模型的上下文长度（如 GPT-4 Turbo 的 128K tokens）是其能“记住”的最大信息量。这不仅仅是技术限制，更是经济模型的一部分。

长上下文 = 高成本：处理 128K tokens 的计算资源消耗远高于 8K tokens。
滑动窗口 vs. 全局注意力：一些模型（如 Claude）声称支持超长上下文，但可能采用了近似算法（如滑动窗口），并非对所有 Token 都给予同等注意力。这直接影响了在长文档中检索信息的准确性。

开发者启示：

精简 Prompt：移除不必要的说明、重复信息。
摘要先行：对于长文档，先用一个小模型生成摘要，再将摘要送入大模型，可以大幅降低成本。

第三章：Token 的隐私——当你的数据变成一串 ID

当你调用云端大模型 API 时，你的数据（无论是邮件、代码还是病历）首先被 Tokenizer 转换成一串数字 ID，然后发送到服务器。这是否意味着你的数据是安全的？

答案是：否。Tokenization 不等于 Encryption（加密）。

3.1 Tokenization 的可逆性

BPE 分词器是完全可逆的。只要攻击者拥有相同的词汇表（vocab.json）和合并规则（merges.txt），就能轻松将 Token ID 序列还原成原始文本。

# Hugging Face tokenizers: 解码过程
def decode(self, ids: List[int]) -> str:
    # 1. 将 ID 映射回子词
    tokens = [self.decoder[id] for id in ids]
    # 2. 将子词拼接成原始字符串
    text = "".join(tokens)
    return text

这意味着，Token ID 序列本身就包含了完整的原始信息。如果你的数据包含 PII（个人身份信息），那么这些信息同样暴露给了 API 提供商。

3.2 隐私计算：在不泄露原始数据的前提下使用大模型

为了解决这个问题，业界正在探索多种 隐私计算（Privacy-Preserving Computation） 技术。

方案一：本地 Tokenization + 安全多方计算（SMC）

思路：用户的敏感数据在本地被 Tokenize，然后通过 SMC 协议（如 Garbled Circuits）与模型的权重进行安全计算。
挑战：计算开销巨大，目前仅适用于小型模型。

方案二：同态加密（Homomorphic Encryption, HE）

思路：直接对加密后的 Token ID 进行计算。模型在密文上运行，返回的结果也是加密的，只有用户能解密。
现状：HE 技术仍在发展中，对 Transformer 这种复杂模型的支持尚不成熟，延迟极高。

方案三：可信执行环境（Trusted Execution Environment, TEE）

思路：利用 Intel SGX 或 AMD SEV 等硬件技术，在 CPU 内创建一个隔离的“飞地”（Enclave）。数据在进入 Enclave 前是加密的，只有在 Enclave 内部才被解密和处理。
代表产品：Microsoft Azure Confidential Computing, Alibaba Cloud vSGX。
优势：性能损失相对较小，是目前最可行的方案之一。