大语言模型（LLM）正驱动着从聊天机器人到内容生成器的各种应用。但在你打开一个模型的仪表盘或者阅读其文档时，经常会看到四个关键指标，它们最初看起来可能有些神秘：Tokens（令牌）使用量、质量指数、首个令牌生成时间（延迟）和每秒 Tokens 生成量（吞吐量）。本文将深入剖析这些指标的含义，以及它们在你构建或评估一个 LLM 驱动的应用程序时的重要性。理解这些指标，能帮助你更好地选择和优化模型，提升用户体验并控制成本。
Tokens：大模型的基础构建块
Tokens 是 LLM 消费或产生的文本的最小单位。之所以使用 sub-word pieces（子词片段）而不是完整的词，是为了让模型能够处理罕见词、拼写错误以及多种语言，同时保持在一个固定的词汇表范围内。例如，“language”这个词可能会被分解为“lan”、“gua”、“ge”三个 Tokens；而“GPT-4”则可能被分解为“GPT”、“-”、“4”三个 Tokens。
在计费和使用方面，你通常需要为输入 Tokens（你提供的提示 prompt）和输出 Tokens（模型生成的响应）付费。价格通常以每百万 Tokens 为单位报价，以简化成本估算。举个例子，假设一个模型的输入价格是每百万 Tokens 5 美元，输出价格也是每百万 Tokens 5 美元。如果你使用该模型生成一篇 1000 字的文章，这篇文章包含了 1500 个 Tokens，那么你需要支付 0.0075 美元（(1500/1000000)*5）。
因此，精确理解和管理 Tokens 对于成本控制至关重要。一些企业通过优化 prompt，减少不必要的词汇和信息，来降低 Tokens 使用量，从而显著降低运营成本。例如，将一个冗长的指令简化为更简洁的表达方式，可以节省大量的 Tokens 开销，尤其是在高并发、大规模应用场景下。
质量指数：衡量 LLM 的“好坏”
质量指数是一个综合评分，通常在 0.0 到 1.0 之间，反映了模型在基准测试任务中的表现。常见的基准测试包括 MMLU（Massive Multitask Language Understanding）、BIG-bench（Beyond the Imitation Game benchmark）或人类评估，用于评估模型在问题解答、摘要生成和推理等任务中的能力。
质量指数的解读如下：
- 0.80+：在标准学术基准测试中表现出色，通常代表着业界领先的模型。例如，GPT-4 在某些基准测试中的得分超过了 0.90，展示了其卓越的语言理解和生成能力。
- 0.50–0.80：对于许多实际应用来说已经足够可靠，但在某些情况下可能会出现错误。很多开源模型或者中等规模的商业模型都处于这个区间。
- <0.50：更适合简单或高度专业化的应用。例如，一些专门用于代码生成的模型，可能在通用 质量 指数上表现不高，但在代码相关任务中表现出色。
需要注意的是，质量指数只是一个参考，不能完全代表模型在所有场景下的表现。在选择模型时，应该结合具体的应用场景和业务需求进行综合评估。例如，对于需要高度准确性的金融领域，可能需要选择 质量指数更高的模型，即使这意味着更高的成本和更长的延迟。
延迟：争分夺秒的用户体验
延迟，或者说 Time to First Token (TTFT)，指的是从发送 prompt 到看到模型响应的第一个 Token 之间的时间延迟（以秒为单位）。在构建 LLM 应用时，延迟是一个至关重要的考虑因素，因为它直接影响用户体验。
延迟的重要性体现在：
- 对于交互式体验（例如，聊天机器人、实时编码助手）至关重要。用户希望能够快速获得响应，从而保持对话的流畅性和连贯性。
- 较低的延迟意味着更快的响应速度和更好的用户参与度。一个延迟过高的聊天机器人，会让用户感到沮丧，甚至放弃使用。
典型的延迟范围如下：
- < 0.5 秒：超快响应速度，通常适用于较小或经过优化的模型。例如，一些轻量级的模型可以实现亚秒级的延迟，非常适合实时对话应用。
- 0.5–2 秒：通用 LLM 的标准延迟。大多数商业 LLM 都在这个范围内。
- > 2 秒：对于实时聊天来说可能感觉迟缓。这种延迟可能会严重影响用户体验。
为了降低延迟，可以采用以下策略：
- 选择更小的模型：较小的模型通常具有更低的计算复杂度，从而可以更快地生成响应。
- 优化模型架构：通过模型压缩、剪枝等技术，可以降低模型的体积，提高推理速度。
- 使用更快的硬件：使用 GPU 或 TPU 等加速硬件可以显著提高模型的推理速度。
- 优化 prompt：简洁的 prompt 可以减少模型的计算量，从而降低延迟。
- 采用缓存机制：对于频繁出现的查询，可以将其结果缓存起来，避免重复计算。
吞吐量：高效生成长文本的关键
吞吐量，或者说 Tokens Per Second (TPS)，指的是在第一个 Token 出现后，模型持续生成 Tokens 的速度（以 Tokens/秒为单位）。吞吐量与延迟共同决定了模型的总响应时间。
吞吐量的重要性体现在：
- 决定了长输出的生成速度。例如，如果你使用 LLM 来生成一篇长篇小说，那么 吞吐量将直接影响生成所需的时间。
- 与延迟相结合，定义了总响应时间。一个高延迟、低吞吐量的模型，即使最终能够生成高质量的内容，也无法提供良好的用户体验。
大致的吞吐量指南如下：
- 100+ Tokens/秒：快速生成器，适合长篇内容。例如，某些大型模型的 吞吐量可以达到数百 Tokens/秒，能够快速生成高质量的长篇文章。
- 50–100 Tokens/秒：平衡的性能。适合大多数应用场景。
- < 50 Tokens/秒：可能较慢，但通常具有更高的准确性。一些注重准确性的模型，可能会牺牲一部分 吞吐量，以换取更高的 质量。
为了提高吞吐量，可以采用以下策略：
- 使用更强大的硬件：GPU 和 TPU 等加速硬件可以显著提高模型的 吞吐量。
- 采用并行计算：将计算任务分解为多个子任务，并行执行，可以提高整体 吞吐量。
- 优化模型架构：一些模型架构具有更高的并行性，可以实现更高的 吞吐量。
- 调整 batch size：适当增加 batch size 可以提高 GPU 的利用率，从而提高 吞吐量。但需要注意的是，过大的 batch size 可能会导致内存溢出。
综合应用：构建高效的问答助手
让我们考虑一个实际场景：构建一个问答助手，它需要接收 300 Tokens 的问题，并返回 600 Tokens 的答案。
| 指标 | 假设值 | 影响 |
| ———- | —— | ——————————————————– |
| Tokens 使用量 | 900 | 每次问答消耗 0.0009 百万 Tokens |
| 质量指数 | 0.85 | 对正确性的高置信度 |
| 延迟 | 1.2 秒 | 用户等待约 1.2 秒后开始流式传输 |
| 吞吐量 | 80 Tokens/秒 | 600 Tokens 在第一个 Token 出现后需要约 7.5 秒 |
| 总响应时间 | ≈ 8.7 秒 | 1.2 秒 + 7.5 秒 |
| 成本估算 | | 例如，以 5 美元/百万 Tokens 的价格，每次问答大约需要 0.0045 美元 |
通过这些数据，你可以选择合适的模型：例如，为了更快的聊天速度，可以选择一个较小的模型；对于复杂的推理，可以选择一个更高级的模型。
最佳实践：打造卓越的 LLM 应用
以下是一些构建高效、经济高效的 LLM 应用的最佳实践：
- 跟踪 Tokens 使用量以预测成本。
- 针对你的用例（例如，实时聊天 vs. 批量任务）进行 延迟 和 吞吐量 基准测试。
- 平衡 质量 与速度：更高 质量 的模型通常具有更高的 延迟 或成本。
- 优化 prompt：简洁的 prompt 使用更少的 Tokens，并且可以提高 延迟。
- 缓存频繁的查询以减少重复调用。
理解 Tokens、质量、延迟 和 吞吐量 有助于你构建高效、经济高效的 LLM 应用程序。无论你是在笔记本电脑上进行原型设计，还是在进行大规模部署，这些基准测试都是你选择模型和调整用户体验的指南针。最终目标是在满足用户需求的同时，最大限度地降低成本和提高效率。在实际应用中，往往需要根据具体的场景进行权衡和优化，才能达到最佳的效果。例如，对于需要快速响应的在线客服场景，可以牺牲一定的 质量，选择 延迟 更低的模型；而对于需要生成高质量报告的场景，则可以优先考虑 质量，适当放宽对 延迟 的要求。
希望通过本文的解读，你能够更清晰地理解 LLM 的关键指标，并在实际应用中更好地利用它们，打造卓越的 LLM 应用。记住，选择合适的模型只是第一步，持续的优化和调整才是成功的关键。