高频面试题

Token 是什么？为什么 AI 应用开发必须理解 Token？

面试官问 Token，不是想听“文本会被切成小块”，而是在看你能否把上下文窗口、计费、延迟、截断和产品体验连成一个工程闭环。

适合阶段：前端转 AI 应用开发 / 一面核心能力：Token Budget · Context Window · Cost · Latency

面试官角度分析，想考什么

• Token 是什么？和字符、单词有什么区别？
  考你能否把 Token 说成模型真实读写的离散单位，而不是把它误解成前端输入框里的字符数。

• Token 如何影响一次 LLM 请求？
  考机制链路：system prompt、历史消息、RAG 片段、工具 schema、用户输入和模型输出都在消耗同一个上下文与计费预算。

• 工程上怎么管理 Token 边界？
  考落地取舍：如何估算、截断、摘要、检索、缓存、降级，以及如何避免用户在长文本场景里“无感失败”。

可直接抄走的 30 秒参考答案

Token 是大模型真正处理的文本单位，不等于字符，也不一定等于一个词。它重要是因为上下文窗口、API 计费、首字延迟、输出长度和截断风险基本都围绕 token 管理。做 AI 应用时，我不会只看用户输入了多少字，而是会把 system prompt、历史消息、RAG 内容、工具 schema、文件解析结果和预期输出一起做 token budget。超过预算时，用摘要、检索、分段处理、缓存和明确的前端提示兜底，避免模型丢关键约束或用户只看到一个模糊报错。

面试回答详解，知其所以然

这道题的核心不是背 tokenizer 算法，而是理解 Token 是 LLM 应用的资源单位。你能不能管理好 Token，直接决定一个 AI 产品是否可控、可解释、可计费、可扩展。

1. Token 是模型读写文本的基本单位

用户看到的是自然语言，模型看到的是 token id 序列。一次请求进入模型前，会先经过 tokenizer，把文本切成 token，再映射成数字 ID；模型每一步也是预测下一个 token。

用户文本 -> tokenizer -> token ids -> LLM 推理 -> output token ids -> 输出文本

Token 和字符、单词都不是一回事：

• 中文：一个汉字、词片段或标点都可能被切成不同 token，不能简单按字数等价换算。
• 英文：常见词可能是一个 token，长词、罕见词、后缀和空格组合可能被拆成多个 token。
• 代码：缩进、括号、符号、长变量名、JSON 字段名都会占 token，所以代码生成和结构化输出经常比直觉更“贵”。

所以面试里不要只说“Token 是文本切片”，要补一句：Token 是模型上下文、计费和推理过程共同使用的度量单位。

2. Token 会同时影响上下文、成本、延迟和可靠性

一次 LLM 请求里，真正进入模型的不只是用户输入框里的内容。常见输入结构大概是：

system prompt
  + few-shot examples
  + conversation history
  + retrieved documents
  + tool schemas
  + tool results
  + user input
  + reserved output tokens
= total context budget

这会带来四类工程影响：

• 上下文窗口：模型有最大上下文限制。输入 token 加预留输出 token 超过窗口后，请求可能失败，或生成到窗口边界时提前停止。
• 成本：多数商业 API 会区分 input token 和 output token 计费；长 prompt、长历史、长工具 schema 都会放大账单。
• 延迟：长输入主要拖慢 prefill，长输出主要拖慢 decode。用户感知上的“首字慢”，很多时候不是网络慢，而是模型正在处理长上下文。
• 可靠性：盲目压缩可能丢关键信息，盲目塞上下文又会增加噪声、位置偏置和指令冲突，最终表现为答非所问或约束失效。

这也是为什么长上下文模型不等于“可以不管 Token”。它只是把上限抬高了，不代表更便宜、更快，也不保证模型能稳定利用所有信息。

3. 工程上要把 Token 管理做成产品和服务端协作

成熟的 Token 管理不是简单 max_tokens 一设了事，而是请求前、请求中、请求后都有治理。

• 请求前做预算：服务端按模型 tokenizer 或供应商 token counting API 估算总输入，把系统提示词、历史、检索内容、工具定义和输出预留都算进去。
• 上下文分层：把信息分成必须保留、可以摘要、可以检索、可以丢弃四类，不要让旧对话、低相关文档或冗长工具结果挤掉核心指令。
• 超限前置处理：长文档走分段解析、摘要、RAG 或批处理；长对话走摘要轮转；工具返回大结果时返回摘要、分页游标或文件句柄。
• 前端给出可理解反馈：上传文件时显示解析和裁剪状态，输入接近上限时提前提示，超限时告诉用户该拆分、摘要还是缩小范围。
• 线上记录 usage 和 trace：记录 input/output token、命中缓存、被裁剪内容、模型、耗时和错误原因，方便定位成本异常和质量回退。

面试里最容易答浅的点，是只说“用 tokenizer 算一下”。更好的说法是：Token 预算要和上下文治理、成本监控、延迟优化、失败恢复一起设计。

面试官追问3个问题

追问一：为什么不能直接按字符数限制？

• 考察点：是否理解 tokenizer 差异，以及前端限制和真实模型成本不是同一层东西。
• 回答方向：字符数只能做粗略提示，不能作为精确预算。不同模型 tokenizer 不同，同样文本在中文、英文、代码、JSON 下 token 比例也不同。生产里可以前端做轻量预估，服务端用真实 tokenizer 或供应商 token counting 能力做最终校验，并以实际 usage 作为账单和监控依据。

追问二：上下文窗口超了以后应该怎么处理？

• 考察点：是否能把超限从“报错问题”转成“上下文治理问题”。
• 回答方向：先区分是输入本身超限，还是输入加预留输出超限。处理上不要简单从头截断，而要按信息价值裁剪：系统约束和当前问题优先保留，历史对话做摘要，文档内容改为检索召回，工具结果用摘要或分页，必要时让用户选择范围。前端要提前提示，而不是等后端返回一个不可理解的 400。

追问三：Token 优化会不会影响回答质量？

• 考察点：是否理解成本优化和质量之间的取舍。
• 回答方向：会，所以不能为了省 token 机械删除上下文。优化应该以任务质量为边界：先删低相关、重复、过期信息；再做结构化摘要和检索；最后用离线评测和线上 badcase 验证质量是否下降。对高风险任务，宁可多保留证据和约束，也不要为了省一点 token 牺牲正确性。

扩展知识

Token Budget 的一个实用拆法

面试中可以用这个公式快速说明你会做预算：

输入预算 = system + examples + history + retrieved context + tool schemas + tool results + user input
输出预算 = max_output_tokens 或业务预期输出长度
总预算 = 输入预算 + 输出预算 <= 模型上下文窗口

在 AI 应用里，max_output_tokens 不是越大越好。它既影响成本，也占用上下文窗口预留；如果设得太小，答案可能被截断；设得太大，又可能放大延迟和账单。

Prompt Caching 省钱，但不扩大上下文窗口

Prompt caching 可以复用稳定前缀，比如固定 system prompt、长文档前缀、工具定义或多轮对话中的历史部分，从而降低重复处理成本和延迟。但缓存命中的 token 通常仍然占上下文窗口，它优化的是“重复计算和计费”，不是让模型无限记住内容。

相关能力可以和本站这些章节一起理解：上下文缓存、上下文压缩、推理参数详解、推理优化。

官方资料里对 Token 的共同口径

OpenAI Text Generation 文档把输入、输出、streaming、结构化输出和模型能力放在同一个 API 使用语境里讨论；Anthropic Token Counting与Prompt Caching文档也把请求前计数、上下文窗口和缓存成本放在工程治理里处理。面试时把这些能力串起来，比单独背 tokenizer 算法更像真实工程经验。