套餐方案

消耗倍率

不同模型使用套餐配额的比例不同。以下倍率以 DeepSeek V4 Flash 输入为基准（1×）：

模型	消耗倍率
DeepSeek V4 Flash	1×
DeepSeek V4 Pro	3.8×

例如：使用 Pro 模型消耗 1,000 tokens，实际扣除 3,800 单位配额。

套餐档位

所有套餐有效期均为 30 天，以下保底配额以 DeepSeek V4 Flash 输入为基准（1×），配额用完即停，不会超支。

档位	保底配额	参考价格
Lite	1,500 万	—
Standard	5,000 万	¥19.9
Pro	1.2 亿	—
Max	2.5 亿	—
Premium	5 亿	—

Premium 用户福利

Premium 用户享受 全场 95 折——所有模型消耗再打 95 折，实际配额更耐用。

缓存说明

TokiToken 底层自动缓存上下文，缓存命中时配额消耗大幅降低。

Prompt Caching 是目前各大 LLM 厂商（OpenAI、Anthropic、Google、DeepSeek 等）普遍支持的一项降本增效核心技术。它通过复用已计算的 KV Cache（模型处理输入时的中间状态），避免对相同前缀内容的重复计算，从而大幅降低费用（可低至原价的 10%）和延迟（首 Token 响应时间可缩短至 1/8）。

核心原理：所有厂商的缓存都基于严格前缀匹配（Prefix Matching）——从请求的第一个字节开始，逐字节向后比对，直到出现第一个不同的字节为止。匹配上的部分可以走缓存，后面的部分需要重新计算。

---

导致缓存失效（Cache Miss）的常见情形

以下行为会导致前缀断裂，使得缓存完全无法命中，费用飙升：

1. 在 System Prompt 中插入动态变量

这是最常见的错误！很多开发者习惯在 system prompt 里插入动态信息：

# 致命错误：每次调用 system prompt 都不一样
system_prompt = f"""你是一个助手。
当前时间：{datetime.now()}          # 每次变化！
用户ID：{user_id}                  # 每个用户不同！
会话ID：{session_id}               # 每次不同！
用户名：{user_name}                # 每个用户不同！
"""

# 正确做法：把动态信息移到 user message 的最后
system_prompt = "你是一个助手。请根据以下信息回答用户问题。"
user_message = f"""
当前时间：{datetime.now()}
用户信息：{user_name} (ID: {user_id})
---
用户问题：{question}
"""

2. 在提示词前缀中使用随机数或 UUID

# 每次请求的 request_id 不同，导致 system prompt 前缀直接断裂
system_prompt = f"[Request-{uuid4()}] 你是一个专业的翻译官..."

3. 动态裁剪/滑动窗口式处理对话历史

当对话过长时，很多人会"裁剪"中间的历史消息，这会破坏前缀一致性：

# 错误：删除了中间的消息，导致从删除点开始后续全部 cache miss
if len(messages) > 20:
    messages = [messages[0]] + messages[-19:]  # 删除了中间的历史

# 正确：保留完整前缀，只在末尾截断，或者使用 Anthropic 的多断点策略

4. Tool / Function 定义顺序随机

# 错误：工具列表顺序每次都变
tools = get_available_tools()  # 返回的列表顺序不确定

# 正确：强制按名称排序
tools = sorted(get_available_tools(), key=lambda x: x['name'])

5. 在 ReAct Agent 循环中将工具结果塞入 System Prompt

做 Agent 开发时，很多人把工具调用（Tool Call）的结果追加到 system prompt 中：

# 错误：每执行一步 tool，system prompt 就变一次，缓存完全失效
system_prompt += f"\n[Tool Result]: {tool_output}"

# 正确：工具结果以 tool message 的形式追加到 messages 数组末尾
messages.append({"role": "tool", "tool_call_id": id, "content": tool_output})

6. 未达到最小 Token 门槛

OpenAI 要求至少 1024 tokens 的前缀才能触发缓存。如果你的 system prompt 只有几百个 token，缓存根本不会生效。

• 解决：如果系统提示词太短，可以考虑将一些固定的参考资料、Few-shot 示例也放在前面，凑够缓存门槛。

7. 请求间隔过长（TTL 过期）

如果你上午 10 点发了一次请求，下一次是下午 2 点，缓存早就被清除了。

• 对于低频但高成本的场景（如长文档分析），考虑使用 Google Gemini 的 Context Caching（支持自定义 TTL，最长数小时）。

8. 频繁切换模型或模型版本

缓存是绑定在特定模型上的。例如deepseek-v4-flash 和 deepseek-v4-pro 之间的缓存不互通。

9. 高并发导致的路由分散

如果同一前缀的请求并发量过高，多余的请求会被路由到不同的计算节点，而缓存是节点级别的（内存中），导致部分请求 cache miss。

10. 不必要的参数变化

某些实现中，改变 temperature、top_p、max_tokens 等参数可能不会影响 KV Cache 的命中（因为 KV Cache 是 prefill 阶段的产物），但在某些厂商的实现中，请求的完整元数据可能参与缓存键的计算。建议保持参数一致。

一句话总结

把 Prompt 当成一条不可变的流水线：固定的、共享的、大块的内容放最前面；变化的、个人的、零碎的内容放最后面。永远不要在前缀中插入任何"会动的东西"。