降低首字延迟（TTFT）的利器：深入解析预计算提示词（Pre-computed Prompts）

各位同仁，各位技术爱好者，欢迎来到今天的讲座。我是你们的向导，一名在软件工程和人工智能领域摸爬滚打多年的实践者。今天，我们将深入探讨一个在大型语言模型（LLM）应用中至关重要且极具优化潜力的技术点——“预计算提示词”（Pre-computed Prompts）。我们将从理论到实践，从概念到代码，一步步揭示它如何通过静态提示词模板的优化，显著降低我们赖以提升用户体验的首字延迟（Time To First Token, TTFT）。

1. 理解首字延迟（TTFT）及其在LLM应用中的关键性

在探讨预计算提示词之前，我们必须首先理解其所要解决的核心问题：首字延迟（TTFT）。

什么是首字延迟（TTFT）？

TTFT指的是用户发送请求后，大型语言模型开始生成并返回第一个可识别的词元（token）所需的时间。这个时间包含了多个阶段：

1. 网络传输延迟： 用户请求发送到LLM服务提供商（如OpenAI、Anthropic）或私有部署模型服务器的网络耗时。
2. 请求处理与队列： 服务器接收请求后，可能需要进行认证、授权、负载均衡，并将请求放入处理队列等待计算资源。
3. 提示词处理（Prompt Processing）： 这是TTFT中非常关键且常被忽视的一部分。它包括：
   • 文本编码（Encoding/Tokenization）： 将人类可读的提示词文本转换为模型能够理解的数字序列（token IDs）。
   • 上下文准备： 如果是对话模型，可能需要将历史对话转换为模型期望的格式。
   • 注意力机制计算（Attention Mechanism）： 模型需要对整个提示词序列进行自注意力计算，以理解上下文和生成第一个token的条件。这是计算量最大的部分之一。
4. 模型推理启动： 在完成提示词处理后，模型才开始实际生成第一个token。

为什么TTFT如此重要？

在用户体验（UX）设计中，TTFT扮演着至关重要的角色。

• 感知速度： 人类对延迟非常敏感。即使总响应时间相同，一个立即开始生成并逐步呈现内容的系统，也比一个长时间无响应然后一次性给出完整内容的系统，给用户带来更好的“速度感”。TTFT直接影响这种感知。
• 用户耐心： 首字延迟过长，用户可能会感到应用卡顿、无响应，从而产生焦虑和不耐烦，甚至放弃等待。
• 交互流畅性： 对于聊天机器人、智能助手等实时交互应用，TTFT是衡量其“流畅性”的核心指标。一个低TTFT的系统能够提供更自然、更像人类对话的体验。
• 资源利用率（间接影响）： 尽管TTFT直接衡量用户体验，但其优化往往也意味着模型启动推理的效率提升，间接可能影响计算资源的调度和利用。

为了更好地理解TTFT的构成，我们可以将其分解为以下几个主要阶段：

阶段	描述	耗时特点
网络与队列	请求传输、服务器排队、认证	波动性较大，受网络状况、服务器负载影响
提示词编码	将文本转换为token IDs	与提示词长度成正比，CPU密集型操作
提示词处理（前向传播）	模型理解提示词，计算注意力权重，准备生成第一个token的初始状态	GPU密集型操作，与提示词长度的平方成正比（对于Transformer）
首字生成	模型根据初始状态生成第一个token	相对固定，取决于模型大小和硬件性能
后续字生成	循环生成后续token	相对固定，取决于模型大小、硬件性能和生成长度（不计入TTFT，但影响总响应）

今天的重点，将聚焦于“提示词编码”和“提示词处理”这两个环节，特别是如何通过优化提示词编码来间接加速提示词处理，从而显著降低TTFT。

2. 传统动态提示词构建的挑战与开销

在大多数LLM应用中，我们的提示词往往是动态构建的。这意味着每次用户请求到来时，我们都需要从零开始构建一个完整的提示词字符串，然后将其发送给LLM API或推理服务。

考虑一个简单的聊天机器人场景，它需要一个固定的系统指令，然后将用户的输入插入到其中：

SYSTEM_INSTRUCTION = "你是一个乐于助人的AI助手，请提供简洁明了的回答。"
USER_QUERY_TEMPLATE = "用户：{user_input}n你："

def build_prompt_dynamic(user_input: str) -> str:
    """动态构建完整提示词的函数。"""
    system_part = SYSTEM_INSTRUCTION
    user_part = USER_QUERY_TEMPLATE.format(user_input=user_input)
    return system_part + "n" + user_part

# 示例使用
query1 = "请解释一下量子力学。"
prompt1 = build_prompt_dynamic(query1)
print(f"提示词1:n{prompt1}n---")

query2 = "Python的GIL是什么？"
prompt2 = build_prompt_dynamic(query2)
print(f"提示词2:n{prompt2}n---")

输出可能类似：

提示词1:
你是一个乐于助人的AI助手，请提供简洁明了的回答。
用户：请解释一下量子力学。
你：
---
提示词2:
你是一个乐于助人的AI助手，请提供简洁明了的回答。
用户：Python的GIL是什么？
你：
---

每次调用build_prompt_dynamic后，生成的完整提示词字符串都会被发送到LLM服务。LLM服务或其内部的推理引擎会执行以下步骤：

1. 接收字符串： 接收到完整的文本字符串。
2. 重新分词（Re-tokenize）： 使用其内部的tokenizer将整个字符串再次转换为token IDs序列。
3. 计算： 基于这些token IDs进行前向传播计算，准备生成第一个token。

这里的关键问题在于“重新分词”。即使SYSTEM_INSTRUCTION和USER_QUERY_TEMPLATE的静态部分在每次请求中都保持不变，它们仍然需要被反复地进行分词操作。对于短提示词，这开销可能不明显；但对于包含大量固定上下文、历史对话或复杂指令的长提示词，重复的分词开销会变得非常显著，直接贡献于TTFT的增加。

想象一下，一个拥有数百甚至数千个token的系统指令，每次请求都重复对其进行分词和前向传播计算，这无疑是巨大的资源浪费。这就是预计算提示词希望解决的核心痛点。

3. 核心概念：预计算提示词（Pre-computed Prompts）

预计算提示词（Pre-computed Prompts），顾名思义，是指在实际LLM推理请求发生之前，提前将提示词中那些静态不变的部分进行处理，将其转换为模型可以直接使用的中间形式（通常是token IDs序列），并缓存起来。当需要构建最终提示词时，我们只需将这些预计算的部分与少量动态变化的部分（例如用户输入）组合起来，从而避免重复的昂贵操作。

工作原理

其核心思想在于“分治”和“缓存”。

1. 识别静态与动态部分： 将一个完整的提示词模板分解为静态（固定不变）和动态（随每次请求变化）两部分。
2. 预分词静态部分： 在应用启动时或首次使用时，将静态部分的文本字符串通过LLM的tokenizer转换为token IDs序列。这些token IDs序列被缓存。
3. 运行时组合： 当实际请求到来时，只对动态部分进行分词。然后将预计算的静态token IDs序列与新生成的动态token IDs序列拼接起来，形成最终的完整token IDs序列，直接发送给模型进行推理。

这种方法类似于数据库中的“预编译语句”（Prepared Statements）或正则表达式的“编译”。

• 数据库预编译语句： 数据库引擎会提前解析、优化SQL查询语句中不变的部分，生成执行计划并缓存。每次执行时，只需绑定不同的参数，避免了重复的解析和优化。
• 正则表达式编译： 正则表达式引擎在匹配文本之前，会先将正则表达式模式编译成内部的自动机表示。这样，对于多次匹配同一个模式，就无需重复编译。

预计算提示词正是将这种优化思想应用到LLM的提示词处理流程中。它将提示词的“编译”阶段提前，从而在运行时减少开销。

预计算的优势

• 降低TTFT： 这是最直接和主要的好处。通过减少运行时分词和前向传播的计算量，模型能够更快地开始生成第一个token。
• 减少CPU/GPU负载： 避免了重复的计算，降低了推理服务的CPU（分词）和GPU（前向传播）负载。
• 提高吞吐量： 更快的TTFT和更低的资源消耗意味着服务器在相同时间内可以处理更多的请求。
• 简化提示词管理（通过模板）： 强制使用模板可以带来结构化和一致性，方便维护。

4. 静态提示词模板：预计算的基础

预计算提示词得以实现的基础是“静态提示词模板”。一个静态提示词模板是一个包含固定文本和占位符（placeholders）的字符串。固定文本是每次请求都保持不变的部分，而占位符则在运行时被实际的动态数据填充。

模板示例：

我们以一个更复杂的代码生成助手为例：

SYSTEM_PROMPT = """你是一个专业的Python编程助手。
请遵循以下规则：
1. 代码必须是Python 3兼容的。
2. 尽可能使用标准库。
3. 提供清晰的注释和文档字符串。
4. 示例用法（如果适用）。
---
"""

CODE_GENERATION_TEMPLATE = """根据以下要求生成Python代码：
要求：{requirements}
```python
# 在这里生成代码

"""

组合后的完整模板

FULL_TEMPLATE = SYSTEM_PROMPT + CODE_GENERATION_TEMPLATE

在这个`FULL_TEMPLATE`中：

*   `SYSTEM_PROMPT`是完全静态的。
*   `CODE_GENERATION_TEMPLATE`中，“根据以下要求生成Python代码：”、“```python”、“# 在这里生成代码”、“```”都是静态的。
*   `{requirements}`是一个占位符，它将在运行时被用户的具体需求替换。

通过这种方式，我们可以清晰地界定哪些部分可以提前处理，哪些必须在运行时动态处理。

**适用场景：**

静态提示词模板特别适用于以下场景：

*   **固定系统指令：** 聊天机器人、内容审核、风格转换等应用中，系统指令通常是固定的。
*   **结构化输出要求：** 要求LLM以特定格式（如JSON、XML、Markdown表格）输出的提示词。
*   **RAG（检索增强生成）系统：** RAG中，查询通常会带有固定的前缀或后缀，以及检索到的上下文。例如：“基于以下信息回答问题：[检索到的信息]n问题：[用户问题]”。
*   **代码生成：** 像上面例子所示，通常有固定的代码结构、语言规范等。
*   **多轮对话中的历史表示：** 如果历史对话的格式是固定的，例如 `用户：... n助手：...`，那么这些格式也可以被视为静态模板的一部分。

### 5. 预计算机制的实现细节与代码示例

现在，让我们深入到代码层面，看看如何实现预计算提示词。我们将使用Hugging Face `transformers`库中的`AutoTokenizer`作为分词器的具体实现，因为它具有广泛的兼容性和易用性。

**环境准备：**

首先，确保你安装了必要的库：

```bash
pip install transformers torch

（torch是transformers的常用后端，这里假设使用它，也可以是tensorflow或jax）

5.1 基础LLM交互（无预计算）

为了对比，我们先模拟一个没有预计算的场景。这里我们假设有一个LLMService类，它接收文本提示词，并模拟分词和推理。

import time
from transformers import AutoTokenizer

# 假设我们使用一个GPT-2 tokenizer作为示例
MODEL_NAME = "gpt2"
tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME)

# 模拟LLM服务
class MockLLMService:
    def __init__(self, tokenizer):
        self.tokenizer = tokenizer
        print(f"MockLLMService initialized with tokenizer: {tokenizer.name_or_path}")

    def generate(self, prompt_text: str, max_new_tokens: int = 10) -> str:
        """
        模拟LLM的生成过程。
        包括：
        1. 文本分词（Tokenization）
        2. 模拟模型前向传播（Prompt Processing）
        3. 模拟Token生成
        """
        start_time = time.perf_counter()

        # 1. 文本分词（Tokenization）- 这一步是TTFT的主要贡献者之一
        token_ids = self.tokenizer.encode(prompt_text, return_tensors="pt")
        tokenization_time = time.perf_counter()

        # 2. 模拟模型前向传播（Prompt Processing）
        # 实际LLM会在这里计算注意力等，我们用一个简单的延迟模拟
        # 延迟与token数量和模型复杂度正相关
        prompt_processing_delay = len(token_ids[0]) * 0.0005 # 假设每个token 0.5ms
        time.sleep(prompt_processing_delay)
        prompt_processing_time = time.perf_counter()

        # 3. 模拟Token生成 - TTFT的最后一步
        # 假设生成第一个token也需要一点时间
        first_token_generation_delay = 0.02 # 20ms
        time.sleep(first_token_generation_delay)

        ttft_end_time = time.perf_counter()

        # 模拟生成后续token
        generated_tokens = ["你好", "世界", "！"] # 简化，实际会是token IDs
        generated_text = self.tokenizer.decode(token_ids[0].tolist() + [123, 456, 789], skip_special_tokens=True) # 假设生成了一些新token

        # 打印各阶段耗时
        # print(f"  [DEBUG] Tokenization: {tokenization_time - start_time:.4f}s")
        # print(f"  [DEBUG] Prompt Processing: {prompt_processing_time - tokenization_time:.4f}s")
        # print(f"  [DEBUG] First Token Gen: {ttft_end_time - prompt_processing_time:.4f}s")

        return_string = "模拟LLM返回：" + prompt_text + "..." + "生成的文本片段。"

        return return_string, (ttft_end_time - start_time)

# 初始化模拟服务
llm_service_dynamic = MockLLMService(tokenizer)

# 定义我们的系统指令和模板
SYSTEM_INSTRUCTION = """你是一个乐于助人的AI助手，请提供简洁明了的回答。
请确保你的回答客观且避免主观臆断。
尽可能引用可靠的来源（如果适用）。
---
"""
USER_QUERY_TEMPLATE = "用户：{user_input}n你："

def get_full_prompt_text(user_input: str) -> str:
    """组合完整的提示词文本。"""
    return SYSTEM_INSTRUCTION + USER_QUERY_TEMPLATE.format(user_input=user_input)

print("n--- 动态提示词构建与调用 ---")
queries = [
    "解释一下什么是黑洞。",
    "Python的异步编程有什么优点？",
    "给我推荐几本关于人工智能的书籍。"
]

total_ttft_dynamic = 0
for i, query in enumerate(queries):
    full_prompt = get_full_prompt_text(query)
    print(f"n[{i+1}] 查询: '{query[:30]}...'")
    # print(f"  完整提示词:n{full_prompt}n---")

    response, ttft = llm_service_dynamic.generate(full_prompt)
    print(f"  TTFT (动态): {ttft:.4f}s")
    total_ttft_dynamic += ttft

print(f"n平均TTFT (动态): {total_ttft_dynamic / len(queries):.4f}s")

从上面的模拟中，我们可以看到每次调用generate时，都会发生tokenizer.encode()和模拟的time.sleep()，这些是TTFT的主要贡献者。

5.2 实现一个PrecomputedPromptManager

现在，我们来实现一个PrecomputedPromptManager类，它将负责预分词静态模板，并在运行时高效地组合提示词。

核心思路：

1. 解析模板： 找到模板中的占位符。
2. 分词静态部分： 将占位符前后的静态文本分别分词。
3. 缓存： 存储这些分词后的静态token IDs和占位符的位置信息。
4. 运行时组合： 接收动态变量，对其进行分词，然后与缓存的静态token IDs拼接。

from typing import Dict, List, Tuple, Any
import re
import torch

class PrecomputedPromptManager:
    def __init__(self, tokenizer: AutoTokenizer):
        self.tokenizer = tokenizer
        self.cache: Dict[str, Tuple[List[torch.Tensor], List[str], List[int]]] = {}
        print(f"PrecomputedPromptManager initialized with tokenizer: {tokenizer.name_or_path}")

    def _parse_template(self, template_string: str) -> Tuple[List[str], List[str]]:
        """
        解析模板字符串，分离静态文本和占位符。
        例如："Hello, {name}! How are you, {mood}?"
        返回 (["Hello, ", "! How are you, ", "?"], ["name", "mood"])
        """
        parts = re.split(r'({.*?})', template_string)
        static_texts = []
        placeholders = []
        for part in parts:
            if part.startswith('{') and part.endswith('}'):
                placeholders.append(part[1:-1]) # 提取占位符名称
            else:
                static_texts.append(part)
        return static_texts, placeholders

    def add_template(self, name: str, template_string: str):
        """
        预处理并缓存一个提示词模板。
        将静态部分分词并存储。
        """
        if name in self.cache:
            print(f"Warning: Template '{name}' already exists and will be overwritten.")

        static_texts, placeholders = self._parse_template(template_string)

        # 对静态文本部分进行分词
        # 注意：这里需要特别处理空白字符和特殊token，确保拼接后语义不变
        # 比如，如果一个静态部分是 "用户：" 另一个是 "你："，它们中间的变量
        # 可能会影响分词结果。通常的做法是，将所有静态部分独立分词，
        # 并注意是否添加前导空格，以模拟它们在完整字符串中的表现。
        # 为了简化，我们直接对每个静态文本进行编码。

        # 编码静态文本片段
        # 对于Hugging Face tokenizer，`add_prefix_space=True` 可以在编码前自动添加空格
        # 这对于BPE/WordPiece等分词器很重要，因为它们通常会将词首带空格的词元作为独立词元处理
        # 例如：" hello" 和 "hello" 的token ID可能不同

        # 为了更准确的模拟，我们对所有静态部分进行编码，
        # 并在它们之间假想插入一个占位符，如果占位符是空的，则考虑是否需要添加空格

        # 一个更鲁棒的方法是：将模板字符串中所有占位符替换成一个特殊的占位符token，
        # 然后对整个字符串进行分词，记录特殊占位符token的ID和位置。
        # 这里我们采用一种更直接但可能略微简化（但足以说明概念）的方法：
        # 分别编码每个静态文本片段。

        token_id_segments: List[torch.Tensor] = []
        for i, text in enumerate(static_texts):
            # 对于第一个静态片段，通常不加前缀空格
            # 对于后续片段，如果前一个片段或占位符后是空格，则当前片段可能不需要额外空格
            # 这是一个复杂的问题，取决于具体的tokenizer行为。
            # 简单的处理方式是，让tokenizer自行处理，或者手动控制`add_prefix_space`

            # 尝试一个更接近实际的策略：
            # 如果静态文本不是空字符串，就编码它。
            # 如果它前一个部分是占位符，并且它自己以非空白字符开始，
            # 那么可能需要添加一个前导空格以模拟完整的句子。
            # 但对于模板，通常占位符前后都是有明确分隔符的（如空格、标点、换行）。

            # 最简单的、在多数情况下表现良好的策略是：
            # 1. 对所有静态片段独立编码。
            # 2. 在运行时，将变量编码时也注意前导空格。
            # 3. 如果模板设计允许，可以在占位符前后加入明确的空格。

            # 这里我们直接编码，不额外处理前缀空格，因为tokenizer通常会处理好
            # 例如："用户：{input}n" -> "用户：", "n"
            # 当encode("用户：") + encode(input) + encode("n") 时，
            # 可能会丢失 "用户：" 和 input 之间的空格信息。
            # 更好的办法是：
            # 1. 编码所有静态片段。
            # 2. 记录占位符前后是否需要添加空格。

            # 为了实现与完整字符串编码结果一致，一个技巧是：
            # 将占位符替换为tokenizer的`unk_token`或一个独特的字符串，然后编码，
            # 找到这些特殊token的位置，再替换回来。
            # 但这增加了复杂性。

            # 这里我们采取一种更直接的方式：
            # 将模板中的占位符替换为一个特殊标记，然后分词，记录标记位置

            # 更好的方法：将占位符替换为特殊token，然后整体编码
            # 例如：template = "Hello, {name}!"
            # encoded_template = tokenizer.encode("Hello, <PLACEHOLDER_NAME>!", add_special_tokens=False)
            # 找到 <PLACEHOLDER_NAME> 的token ID和位置

            # 更通用的方法是，将模板切割成部分，然后对每个部分单独编码，并存储
            # 假设 tokenizer.encode 能够处理好每个小片段。

            if text: # 避免编码空字符串
                # 关键：为了确保拼接后结果与完整字符串编码一致，需要考虑前缀空格
                # 例如，"你好，" + "世界" 与 "你好，世界" 的编码
                # "你好，".encode() + "世界".encode() 可能不等于 "你好，世界".encode()
                # 一般而言，对于英文，单词前的空格会被合并到单词token中，如 " hello" -> [ID_of_space_hello]
                # 这里我们假设模板设计时，占位符前后已有自然分隔，如空格或标点

                # 为了简化并保持核心概念，我们直接编码每个静态文本片段
                # 实际应用中，需要根据具体tokenizer的`add_prefix_space`等参数进行精细调整
                segment_tokens = self.tokenizer.encode(text, add_special_tokens=False, return_tensors="pt")
                token_id_segments.append(segment_tokens)
            else:
                token_id_segments.append(torch.tensor([], dtype=torch.long).unsqueeze(0)) # 空片段

        # 将这些预编码的片段和占位符信息存储起来
        self.cache[name] = (token_id_segments, placeholders, [len(t[0]) for t in token_id_segments])
        print(f"Template '{name}' pre-computed. Static token segments: {len(token_id_segments)}, Placeholders: {placeholders}")

    def get_prompt_input(self, name: str, variables: Dict[str, str]) -> torch.Tensor:
        """
        根据缓存的模板和动态变量构建最终的token ID序列。
        """
        if name not in self.cache:
            raise ValueError(f"Template '{name}' not found in cache.")

        static_token_segments, placeholders, _ = self.cache[name]

        final_token_ids_list: List[torch.Tensor] = []

        # 迭代静态片段和占位符，进行组合
        for i, static_segment_tensor in enumerate(static_token_segments):
            final_token_ids_list.append(static_segment_tensor) # 添加静态片段

            if i < len(placeholders): # 如果还有占位符要处理
                placeholder_name = placeholders[i]
                if placeholder_name not in variables:
                    raise ValueError(f"Missing variable '{placeholder_name}' for template '{name}'.")

                # 对动态变量进行分词
                # 这里的关键是确保变量的分词方式与它在完整句子中的分词方式一致
                # 例如，如果模板是 "Hello, {name}!"，name是"World"，则编码 " World"
                # 如果模板是 "User:{input}"，input是"query"，则编码 "query"
                # 通常，LLM的tokenizer在处理完整字符串时，会在词与词之间自动处理空格
                # 如果我们单独编码，可能需要手动添加前导空格，或者依赖tokenizer的默认行为

                # 再次强调：`add_prefix_space=True`对许多分词器至关重要
                # 它会尝试在编码字符串前添加一个空格，模拟它在句子中间出现的情况
                # 但对于第一个占位符或紧跟标点符号的占位符，这可能不合适
                # 简单起见，我们对变量直接编码，不强制`add_prefix_space`

                variable_text = str(variables[placeholder_name])

                # 考虑分词器的特殊性：如果一个token本身是空格，或者前缀有空格
                # 我们可以尝试一个更通用的策略：
                # 如果当前静态片段的最后一个token不是空格，且变量的第一个字符不是空格，
                # 那么在变量前添加一个空格，以模拟自然语言间隔。
                # 但这仍然不完美，因为它依赖于对token内容的判断。

                # 最稳妥的方法是：
                # 在模板中明确指定占位符前后的空格，例如 "Hello, {name}!" 而不是 "Hello,{name}!"
                # 这样，"Hello, " 是一个静态片段，"!" 是另一个静态片段。
                # 变量 "name" 自身分词时，不会有前缀空格问题。

                # 为了简化，我们假设模板设计合理，占位符前后有自然分隔。
                # 如果需要严格与完整字符串一致，可能需要更复杂的逻辑，
                # 例如，对 "static_part" + "variable" + "static_part"
                # 进行虚拟编码，然后提取 "variable" 部分的token IDs。

                variable_token_ids = self.tokenizer.encode(
                    variable_text, 
                    add_special_tokens=False, # 变量不应引入BOS/EOS
                    return_tensors="pt"
                )
                final_token_ids_list.append(variable_token_ids)

        # 拼接所有token ID序列
        # 注意：如果存在空张量，需要过滤掉或者使用torch.cat的非空列表
        non_empty_tensors = [t for t in final_token_ids_list if t.numel() > 0]
        if not non_empty_tensors:
            return torch.tensor([], dtype=torch.long).unsqueeze(0) # 返回一个空的batch维度tensor

        return torch.cat(non_empty_tensors, dim=1)

# --------------------------------------------------------------------------------
# 测试 PrecomputedPromptManager
# --------------------------------------------------------------------------------

# 重新初始化模拟服务，这次用于预计算模式
llm_service_precomputed = MockLLMService(tokenizer)
prompt_manager = PrecomputedPromptManager(tokenizer)

# 定义我们的系统指令和模板
# 稍微修改模板，使其更清晰地展示占位符
SYSTEM_INSTRUCTION_PRECOMPUTED = """<|system|>
你是一个乐于助人的AI助手，请提供简洁明了的回答。
请确保你的回答客观且避免主观臆断。
尽可能引用可靠的来源（如果适用）。
</s>
""" # 假设使用OpenAI或类似的聊天格式

USER_QUERY_TEMPLATE_PRECOMPUTED = """<|user|>
{user_input}
</s>
<|assistant|>
"""

# 组合后的完整模板名称
FULL_TEMPLATE_NAME = "chat_template"
FULL_TEMPLATE_STRING = SYSTEM_INSTRUCTION_PRECOMPUTED + USER_QUERY_TEMPLATE_PRECOMPUTED

# 1. 预计算阶段：在应用启动时执行一次
print("n--- 预计算阶段：添加模板 ---")
prompt_manager.add_template(FULL_TEMPLATE_NAME, FULL_TEMPLATE_STRING)

# 2. 运行时阶段：使用预计算的模板
print("n--- 使用预计算提示词进行调用 ---")
queries = [
    "解释一下什么是黑洞。",
    "Python的异步编程有什么优点？",
    "给我推荐几本关于人工智能的书籍。"
]

total_ttft_precomputed = 0
for i, query in enumerate(queries):
    # 构建变量字典
    variables = {"user_input": query}

    # 获取预计算并组合后的token IDs
    token_ids_input = prompt_manager.get_prompt_input(FULL_TEMPLATE_NAME, variables)

    # 为了模拟LLM服务，我们需要将token IDs解码回文本，以便MockLLMService能处理
    # 实际生产中，LLM服务会直接接收token IDs，跳过文本到token IDs的转换
    # 这里为了对比TTFT，我们只计算token_ids_input的构建时间，然后将它传给MockLLMService

    # 模拟LLM服务接收token IDs并直接处理的场景
    # 我们可以修改MockLLMService，使其可以接收token_ids

    # 为了简化，我们让MockLLMService继续接收文本，但我们在这里模拟“跳过分词”的优化
    # 因此，我们先解码，然后传给MockLLMService，但TTFT计算时，不包含MockLLMService的tokenizer.encode

    # --- 关键修改：MockLLMService支持接收token_ids ---
    # 为了准确模拟TTFT，我们需要一个能接收token IDs的MockLLMService

class MockLLMServiceWithTokenIDs:
    def __init__(self, tokenizer):
        self.tokenizer = tokenizer
        print(f"MockLLMServiceWithTokenIDs initialized with tokenizer: {tokenizer.name_or_path}")

    def generate(self, token_ids: torch.Tensor, max_new_tokens: int = 10) -> str:
        """
        模拟LLM的生成过程，直接接收token IDs。
        跳过：文本分词（Tokenization）
        包括：
        1. 模拟模型前向传播（Prompt Processing）
        2. 模拟Token生成
        """
        start_time = time.perf_counter()

        # 1. 模拟模型前向传播（Prompt Processing）
        prompt_processing_delay = len(token_ids[0]) * 0.0005 
        time.sleep(prompt_processing_delay)
        prompt_processing_time = time.perf_counter()

        # 2. 模拟Token生成 - TTFT的最后一步
        first_token_generation_delay = 0.02
        time.sleep(first_token_generation_delay)

        ttft_end_time = time.perf_counter()

        # 模拟生成后续token
        # 这里为了演示，我们解码输入token_ids，并添加一些模拟生成
        decoded_input = self.tokenizer.decode(token_ids[0].tolist(), skip_special_tokens=True)
        return_string = "模拟LLM返回(预计算)：" + decoded_input + "..." + "生成的文本片段。"

        return return_string, (ttft_end_time - start_time)

# 重新初始化用于预计算模式的模拟服务
llm_service_precomputed_token_ids = MockLLMServiceWithTokenIDs(tokenizer)

print("n--- 使用预计算提示词进行调用（直接传Token IDs） ---")
total_ttft_precomputed_actual = 0
for i, query in enumerate(queries):
    start_prompt_build_time = time.perf_counter()
    variables = {"user_input": query}
    token_ids_input = prompt_manager.get_prompt_input(FULL_TEMPLATE_NAME, variables)
    prompt_build_time = time.perf_counter() - start_prompt_build_time # 这是我们节省下来的分词时间

    print(f"n[{i+1}] 查询: '{query[:30]}...'")
    # print(f"  构建Token IDs耗时: {prompt_build_time:.4f}s")
    # print(f"  Token IDs (前10个): {token_ids_input[0][:10].tolist()}...")

    response, llm_ttft = llm_service_precomputed_token_ids.generate(token_ids_input)
    # 这里的LLM TTFT是模型处理token IDs并生成首字的时间
    # 整个TTFT = PromptManager构建token IDs + LLM的TTFT

    full_ttft = prompt_build_time + llm_ttft
    print(f"  TTFT (预计算): {full_ttft:.4f}s")
    total_ttft_precomputed_actual += full_ttft

print(f"n平均TTFT (预计算): {total_ttft_precomputed_actual / len(queries):.4f}s")

# --------------------------------------------------------------------------------
# 性能对比
# --------------------------------------------------------------------------------
print("n--- 性能对比总结 ---")
print(f"平均TTFT (动态): {total_ttft_dynamic / len(queries):.4f}s")
print(f"平均TTFT (预计算): {total_ttft_precomputed_actual / len(queries):.4f}s")
print(f"提升百分比: {((total_ttft_dynamic - total_ttft_precomputed_actual) / total_ttft_dynamic) * 100:.2f}%")

代码解释与关键点：

1. MockLLMService vs MockLLMServiceWithTokenIDs：
   • MockLLMService模拟的是传统的LLM API，它接收文本字符串，并在内部执行分词，这部分时间被计入TTFT。
   • MockLLMServiceWithTokenIDs模拟的是一个优化后的LLM服务（或内部推理引擎），它直接接收token_ids，因此节省了每次请求的分词时间。这是预计算提示词能够带来TTFT降低的关键。
2. PrecomputedPromptManager._parse_template： 使用正则表达式re.split(r'({.*?})', template_string)来精确地将模板字符串分割成静态文本片段和占位符名称。
3. PrecomputedPromptManager.add_template：
   • 这是预计算的核心。它遍历解析出的静态文本片段，对每个片段使用self.tokenizer.encode(text, add_special_tokens=False, return_tensors="pt")进行编码。add_special_tokens=False是重要的，因为这些是模板的中间片段，不应该有BOS（Beginning of Sentence）或EOS（End of Sentence）标记。
   • 编码后的token_id_segments（列表中的torch.Tensor）和placeholders被缓存起来。
4. PrecomputedPromptManager.get_prompt_input：
   • 这是运行时调用的方法。它从缓存中取出预计算的静态token_id_segments。
   • 对于每个占位符，它从variables字典中取出对应的值（用户输入等），然后对其进行self.tokenizer.encode(variable_text, add_special_tokens=False, return_tensors="pt")编码。
   • 最后，使用torch.cat将所有静态和动态（已编码）的token ID序列拼接成一个完整的torch.Tensor，作为模型的最终输入。
5. TTFT计算的准确性：
   • 在动态模式下，MockLLMService.generate内部包含了分词时间。
   • 在预计算模式下，prompt_manager.get_prompt_input的时间（构建token_ids_input）加上MockLLMServiceWithTokenIDs.generate的时间（处理token_ids_input并生成首字），共同构成了完整的TTFT。通过这种方式，我们隔离了分词的开销，并展示了预计算如何将其从每次请求中移除。
   • 实际生产中，get_prompt_input的输出token_ids_input会直接通过API或内部接口传递给LLM推理引擎，从而避免了重复的分词。

通过运行这段代码，你会观察到预计算模式下的平均TTFT显著低于动态模式。这是因为prompt_manager.get_prompt_input中的分词操作只针对短小的动态变量，而无需每次都对冗长的静态系统指令进行分词。

6. 进阶考量与注意事项

预计算提示词并非万能药，在实际应用中，我们需要考虑更多细节和潜在挑战。

6.1 Tokenizer的细微差别与兼容性

不同的LLM模型使用不同的Tokenizer（例如BPE, WordPiece, SentencePiece）。这些Tokenizer在处理空格、特殊字符、以及如何将文本分割成token时，行为可能有所不同。

• 前导空格： 许多Tokenizer（尤其是基于BPE的）在编码单词时，会将前导空格包含在token中（例如，" hello"可能是一个token，而"hello"是另一个）。在拼接预计算和动态部分的token ID时，必须确保这种空格行为的一致性，否则可能导致语义错误或生成质量下降。
  • 解决方案： 在模板中明确控制空格，例如"User: {input}"而不是"User:{input}"。或者，在编码动态变量时，根据其在模板中的位置决定是否添加前导空格（例如，如果前一个静态片段的最后一个token不是空格，且当前变量不是以空格开头，则可以在变量前添加一个空格）。
• 特殊Token： <|endoftext|>, [SEP], <s>, </s> 等特殊token在不同模型中有不同含义。确保预计算时正确处理它们，并且它们不会被错误地添加或移除。
• 分词器版本： 随着模型更新，分词器也可能更新。确保你的PrecomputedPromptManager使用的分词器版本与LLM实际使用的分词器版本严格一致，否则可能导致不匹配的token IDs，进而影响模型性能。

6.2 上下文窗口限制与Token成本

预计算提示词仍然会占用LLM的上下文窗口。一个长而复杂的系统指令，即使被预计算，其token数量仍然会计入模型最大输入长度（max_seq_len）的限制。同样，每个token都会产生计算成本和API调用费用。因此，设计简洁高效的模板依然是最佳实践。

6.3 缓存管理与更新策略

• 内存消耗： 缓存大量预计算的提示词模板会占用内存。需要评估模板的数量和平均长度。
• 模板更新： 如果静态提示词模板需要更新，必须有机制来使缓存失效并重新预计算。这可能涉及版本控制或在模板字符串更改时自动触发重新计算。
• 并发访问： 在多线程或多进程环境中，PrecomputedPromptManager需要是线程安全的，或者每个线程/进程维护自己的实例。

6.4 混合策略

并非所有提示词都适合预计算。对于高度动态、结构不固定的提示词（例如，一个完全由用户自由输入构成的提示词），预计算的收益很小，甚至可能增加复杂度。在这种情况下，直接动态构建和分词可能更合适。

最佳实践是采用混合策略：

• 高频、固定结构： 积极使用预计算。
• 低频、高度动态： 使用传统动态构建。

6.5 安全性考量：提示词注入

预计算提示词模板本身并不能直接防御提示词注入。用户输入的变量仍然可能包含恶意指令。防止提示词注入的关键在于对用户输入进行严格的验证、过滤和转义，无论是否使用预计算。预计算只是优化了提示词的“物理”构建过程，而不是其“逻辑”安全性。

7. 真实世界应用场景

预计算提示词在许多LLM驱动的应用中都有广泛的应用潜力：

• 智能客服与聊天机器人： 固定的系统角色设定、行为规范、多轮对话的历史格式化（如Human: ... nAI: ...）都可以预计算。
• 内容创作与编辑助手： 固定的写作风格指南、文章结构要求、语言规范。
• 代码助手与IDE集成： 语言模型对代码的解释、补全、生成，通常会带有固定的代码上下文（如导入语句、函数签名、文件头部注释）或编程语言规范。
• 结构化数据提取： 固定的指令要求模型从非结构化文本中提取特定实体（如“从以下文本中提取姓名、年龄、城市，并以JSON格式返回：”）。
• RAG（检索增强生成）系统： 在RAG中，通常会将检索到的文档片段作为上下文添加到提示词中。例如，"根据以下信息回答问题：n{retrieved_docs}n问题：{user_query}n答案："。其中"根据以下信息回答问题：n"和"n问题："以及"n答案："都是静态的，可以预计算。
• Agentic AI系统： 在复杂的Agent工作流中，Agent的指令、工具使用规范、思考链（CoT）的模板等，都可以进行预计算，以加速每个思考步骤。

8. 总结与展望

预计算提示词是一种行之有效且相对容易实现的优化技术，它通过将提示词中静态部分的昂贵分词和初步处理操作前置到运行时之前，显著降低了大型语言模型应用的TTFT。这不仅提升了用户体验，减少了用户的等待感知，也间接提高了推理服务的效率和吞吐量。

虽然实现上需要对Tokenizer的特性有所了解，并对模板设计和缓存管理进行周密考量，但其带来的性能收益在许多高频、模板化场景下是显而易见的。作为一名编程专家，在设计和构建LLM应用时，我们应当将预计算提示词作为一项重要的优化策略，将其融入到我们的架构之中，以打造更快速、更流畅、更具响应性的智能系统。随着LLM应用边界的不断扩展，对性能的极致追求将永无止境，而预计算提示词正是我们在这一征程中的一个有力工具。