面试日记 第 12 天

这轮面试有个小插曲。

我刚坐下，面试官没有打开我的项目，也没有让我讲 RAG。他先拿出一张打印出来的用量面板，上面是某个企业 AI 工具的月度支出：不同团队、不同用户、不同命令的调用成本分得很细，还有 75%、90% 这种支出告警线。

他用笔圈了一行，说：“你看，这个开发者一天开了几十次 Claude Code。你要是负责这个系统，怎么判断这钱花得值不值？”

我第一反应是讲 ROI，讲提效，讲节省人力。

面试官没让我展开，直接把问题压低了一层：“先别讲管理。一次对话为什么会花钱？输入 Token 和输出 Token 为什么还要分开计价？”

我一下就知道，他要问的是大模型调用成本的基本账，吐槽账单贵解决不了这个问题。

这几天 Claude Enterprise 官方也在加强用量和成本分析能力，管理员可以按用户、组、产品行为查看成本，还能设置支出告警。这个方向其实很现实：AI 应用上线以后，效果只是第一关，成本看不住，业务也跑不久。

面试官最后把原题写了出来：

“大模型的 Token 是什么？输入 Token 和输出 Token 在计费上有什么区别？”

面试结束后，我把这个题重新整理了一遍。下面是我的面试复盘。

回答重点

这题先抓一句话：Token 是大模型处理文本的基本单位，输入 Token 和输出 Token 会分开计费，输出通常更贵。

大模型处理文本时，会先通过 Tokenizer 把用户输入切成一串 Token，再把这些 Token 转成向量进行理解和生成。

一个 Token 不一定等于一个字。

英文里，一个常见单词通常就是 1 个 Token，长一点的单词可能被拆成 2 到 3 个 Token。中文通常一个汉字会接近 1 到 2 个 Token，具体取决于模型使用的分词器。标点、空格、代码里的符号，也都会影响 Token 数量。

计费时，输入 Token 和输出 Token 通常分开算。输入 Token 指你发给模型的内容，包括用户问题、系统提示词、上下文、检索到的文档、工具返回结果。输出 Token 指模型生成出来的回答。

为什么输出更贵？

原因在生成机制。输入 Token 可以一次性并行处理，效率高。输出 Token 要一个一个生成，模型生成第 N 个 Token 时，必须依赖前 N-1 个 Token 的结果。这个自回归过程没法像输入那样一次算完，所以计算成本更高。

所以在实际开发里，成本优化不能简单理解成缩短 Prompt。很多时候要把必要信息放在输入端，但让输出尽量简洁精准。输入多一点可能还可控，输出一旦啰嗦，成本会明显上升，延迟也会变长。

扩展知识

先看分词。

主流大模型常用 BPE 或它的变体做分词。BPE 全称 Byte Pair Encoding，思路是从更小的字符或字节片段开始，不断合并出现频率高的片段，最后形成常见词、子词和符号的词表。

高频词更容易成为一个 Token，低频词、长单词、特殊符号、代码变量名，可能会被拆成多个 Token。比如 “the” 这种高频英文词通常很短，“unhappiness” 可能被拆成 “un” 和 “happiness” 这类子词组合。

如果想精确估算，可以用分词工具。比如 OpenAI 生态里常用 tiktoken：

import tiktoken

enc = tiktoken.encoding_for_model("gpt-5")
tokens = enc.encode("你好，世界")
print(len(tokens))

不过面试里不要只停在“会用工具算”。面试官更关心你能不能把 Token 和成本、延迟、上下文窗口联系起来。

第一个实战点是 Prompt Caching。

如果系统提示词很长，而且每次请求前缀都相同，就适合做 Prompt Caching。它会复用相同前缀对应的 KV Cache，后续请求命中缓存后，不需要重复计算这部分输入。客服机器人、批量文档分析、固定角色设定的助手，收益都比较明显。

第二个实战点是长文本压缩。

很多成本失控都来自“把整篇文档、整段历史对话、整批工具结果全部塞进去”。更稳的做法是先摘要、再检索、再裁剪，只把和当前问题有关的信息放进上下文。长文本任务里，先做摘要再喂给模型，经常能省掉一大截输入 Token。

第三个实战点是约束输出。

如果模型每次都写一大段解释，输出 Token 会很快变贵。可以用 JSON Schema、固定字段、字数限制、列表格式来约束输出。比如只需要判断结果，就不要让模型写完整分析过程；只需要结构化抽取，就让它输出固定 JSON。

再看上下文窗口。

每个模型都有上下文窗口上限。这个上限同时覆盖输入和输出。输入 Token + 输出 Token 的总数不能超过模型窗口。假设一个模型窗口是 128K，你塞进去 120K Token，理论上留给输出的空间就只剩 8K。长文本场景如果不预留输出空间，模型回答可能被截断。

所以面试里可以这样讲：Token 同时影响三件事，成本、延迟、上下文容量。做大模型应用时，不能只关心模型效果，也要关心每次请求用了多少输入、生成了多少输出、哪些前缀能缓存、哪些上下文可以裁剪。

这也是为什么企业版产品开始强调用量分析和成本控制。AI 真进了公司，不能让每个人随便开一个最强模型无上限跑。管理员需要知道谁在用、用在哪、花了多少钱、有没有接近预算线。

面试官追问

追问：BPE 分词为什么不直接按字或按词来切？

回答：按字切粒度太细，序列会变长，注意力计算量上去，效率很差。按词切又会遇到没见过的新词，也就是 OOV 问题。BPE 是折中方案，高频词可以保持完整，低频词拆成子词，既控制词表大小，又能处理新词、拼写变体和代码符号。

追问：为什么输出 Token 不能像输入 Token 一样并行处理？

回答：因为大多数生成式语言模型是自回归生成。生成第 N 个 Token 时，必须知道前面已经生成了什么，后一个 Token 依赖前一个 Token 的结果。输入阶段可以一次性看到完整上下文，输出阶段要逐步生成，所以输出更慢，也更贵。

追问：Prompt Caching 的原理是什么？什么场景收益最大？

回答：Prompt Caching 会把重复前缀对应的 KV Cache 缓存起来。下一次请求如果前缀相同，就可以复用这部分计算。收益最大的场景是系统提示词很长、前缀固定、调用频率高，比如客服机器人、批量文档处理、固定规范的代码审查助手。如果每次 Prompt 都完全不同，缓存收益就不明显。

追问：如果线上成本突然上涨，你会怎么排查？

回答：先拆输入和输出，看是上下文变长了，还是模型回答变啰嗦了。再按用户、接口、功能模块分组，找调用量最高和单次成本最高的请求。常见原因包括检索返回文档太多、历史对话没裁剪、工具结果原样塞进上下文、输出没有长度限制、批处理任务用了实时高价模型。定位后再做摘要、裁剪、缓存、模型路由和输出约束。

Token 是大模型理解和生成文本的基本单位，决定了上下文容量、推理成本和响应延迟。输入 Token 通常可以并行处理，输出 Token 需要自回归逐个生成，所以输出价格往往更高。实际开发时，要通过上下文裁剪、Prompt Caching、结构化输出和模型路由来控制成本。

这题我后来重新整理了一遍，发现完整答案其实要讲 Token 定义、BPE 分词、输入输出计费差异、上下文窗口、Prompt Caching，以及线上成本排查。

篇幅有限，更多大模型工程和 AI 应用开发相关面试题，可以进入面试鸭进行查阅。