人工智能、推理和代币，真是让人惊叹！

好了，各位，现在立刻停下来。 我听到“代币”和“模型”这些词像 TikTok 上的 Z 世代俚语一样被乱用，而且多数情况下用得根本不对。 

我的话很明确。 

现在正是讲清楚基于推理的应用怎么构建、令牌如何生成与使用，以及各部分如何协同运作的时刻。 来杯咖啡，我们马上开始深入探讨。 

我本不该从这里说起，但我还是会讲。 当我们说“推理”时，其实指的是大型语言模型（LLM）在大量数据中进行思考的过程。 你不能直接调用LLM。 实际上并不存在所谓“LLM API”，如果你说了，我会给你“妈妈般的严厉注视”。 

用于调用推理的 API 会通过推理服务器进行处理并等待结果。 

推理服务器负责运行 AI 模型，就如同应用服务器负责运行 Java 及其他开发语言环境一样。 一般情况下，没有推理服务器你不会直接在本地运行模型。 常见方案包括 Ollama、vLLM、NVIDIA Triton 和 HuggingFace 文本生成接口 (TGI)。 

现在，和部署应用包到应用服务器类似，您会在推理服务器上部署“AI 包”（模型）。 该服务器通过 API 提供 AI 模型功能，仅包含一组精简的 API 端点（例如 REST 或 gRPC 中的 /generate、/completions 或 /embeddings），专注于文本生成、分词或嵌入等模型推理任务。

要与推理服务器交互，你需要构建一个应用程序。没错，一个传统的应用（当然，也可能是现代的），它会与推理服务器通信。 

用户也可以通过浏览器或手机使用应用程序，通常通过普通的API与您开发的应用通信。 就这样！ 您拥有完整的消息流，从客户端到应用再到推理服务器，然后返回。 

是的，它确实只是重新诠释了三层 Web 应用结构，只不过将数据层替换成了推理层。 我明白，这感觉确实让人有些失望，不是吗？ 

最简单的 AI 应用形式是三层网络应用，将数据层替换为推理服务器。

1. 接收 JSON 请求，您可以选择执行检索增强生成（RAG），然后用 JSON 调用推理服务器。 RAG 的流程通常是：先生成用户查询的嵌入，再在向量或搜索索引中查找相似内容，把相关片段拼接进提示中。 所有操作依然是在传输 JSON 格式的数据。 此时还未生成模型令牌。
2. 推理服务器解析 JSON，并将文本拆分为模型识别的标记，检查上下文与配额，批量处理兼容请求，执行模型，再将输出标记解码成文本。 然后返回 JSON 响应给调用者。 若为流式处理，标记生成时即解码并发送。 多数 API 同时提供包含输入输出标记统计的使用情况块。

这就是推断。 这是一种新的应用工作负载形式，它基于我们一贯重视的运营纪律，现在用令牌、上下文和数据流来代替会话、Cookie 和查询。

人们往往在这里犯错，错误使用词语，违背了术语使用的基本准则。 标记是大型语言模型（LLM）处理的最小文字单元。 它们由推理服务器上的分词器正式生成。 

您可以在应用中加入标记器，提前计算令牌数以预测成本和限制本地请求速率，但最终的令牌计数发生在推理层。 令牌是模型的表示形式，而非网络流量；实际上传输的是 JSON 文本。 只有在 API 明确返回令牌 ID 时，您才能看到它们。 

默认情况下，基础设施看不到令牌。 它只识别 JSON。 令牌不会在网络上传输。 如果您希望基础设施处理令牌，必须在网关使用相同的标记器进行计数，或者利用模型服务器提供的计数数据。 令牌是 AI 的通用计费单位，但如果您不揭示它们，它们大多存在于推理堆栈内部。