LLM Context-Window Token Cost & Latency Sizer
根据 context window 估算 LLM 请求大小、输入/输出 token 成本、prefill/decode 延迟及并发序列的 KV cache 内存。价格和 throughput 均由用户提供；这不是供应商报价或 benchmark。
结果
Context window 状态
每次请求的估算成本
估算 30 天 token 成本
估算 prefill + decode 时间
每个序列的 KV cache
并发序列的 KV cache 总量
剩余 context token 数
超出 context window 的 token 数
使用方法 工具
- 输入完整 Prompt token 数（包括 system 和 tool context）、生成 token 数及模型 context window。
- 输入每 1M token 的输入/输出价格、每日请求数，以及实测 prefill/decode throughput。
- 估算 KV cache 时，输入 Transformer 层数、KV heads、head dimension、每元素字节数及并发序列数。
- 查看 context window 是否适配、token 成本、串行 prefill 加 decode 时间和 KV cache 大小，并与实测 serving 行为比较。
假设条件
- Prompt token 数包含全部输入 context；输出 token 数也计入 context window 适配和 KV cache 长度。
- KV cache 估算假设每层使用相同字节数的常规 dense K/V cache；不包括权重、allocator/page-table 开销、量化元数据、prefix sharing、sliding-window 层和碎片。
- 延迟是根据实测 throughput 简单相加的 prefill 与串行 decode 时间；不包括排队、batching 收益、网络时间、TTFT 开销和 speculative decoding。
- Token 价格是用户输入的固定 GBP/1M token 费率；不包括供应商价格源、税费、缓存折扣或分级费率。
技术细节：字段含义
- 每次请求的 Prompt token 数
promptTokens - 平均请求的所有输入 token，包括 system prompt、检索 context 和 tool 描述。
- 每次请求生成的 token 数
outputTokens - 每次请求平均生成的 token 数。
- Context window 大小
contextWindowTokens - 所选部署和配置的最大模型 context token 数。
- 每日请求数
requestsPerDay - 每日计费的平均请求数；月度估算按 30 天计算。
- 每 1M 输入 token 的价格
inputPricePerMillionTokensGbp - 输入 token 每 1M 个的 GBP 价格。填写供应商或内部成本模型中的费率。
- 每 1M 输出 token 的价格
outputPricePerMillionTokensGbp - 生成 token 每 1M 个的 GBP 价格。
- 实测 prefill throughput
prefillThroughputTokensPerSecond - 该模型和部署的实测 prompt prefill throughput，而非供应商宣称的峰值。
- 实测 decode throughput
decodeThroughputTokensPerSecond - 在待估算的 batch 和 serving 配置下，每个序列的实测 decode throughput。
- Transformer 层数
modelLayers - 用于 KV cache 估算的 Transformer 层数。
- KV heads 数
kvHeads - Key/value attention heads 数，而非 query heads。使用模型配置中的 KV-head 数量。
- Head dimension
headDimension - 每个 attention head 的元素维度。
- 每个 KV cache 元素的字节数
bytesPerElement - 每个 KV cache 元素的存储字节数，例如 FP16/BF16 为 2 字节。
- 并发序列数
concurrentSequences - 需要同时驻留其 KV cache 的活跃序列数。
方法说明
请求成本 =（prompt token 数 × 输入价格 + 输出 token 数 × 输出价格）÷ 1,000,000。30 天成本 = 每次请求成本 × 每日请求数 × 30。估算串行延迟 = prompt token 数 ÷ 实测 prefill token/s + 输出 token 数 ÷ 实测 decode token/s。每序列 KV cache 字节数 = 2（K 和 V）× 层数 × KV heads × head dimension × 每元素字节数 ×（prompt token 数 + 输出 token 数）；总 KV cache 再乘以并发序列数。MiB/GiB 使用 1024 的幂。
计算示例
8,192-token context、每日 5,000 次请求和八个并发序列
输入项: 每次请求的 Prompt token 数: 4096 tokens, 每次请求生成的 token 数: 1024 tokens, Context window 大小: 8192 tokens, 每日请求数: 5000 requests/day, 每 1M 输入 token 的价格: 2 GBP/1M tokens, 每 1M 输出 token 的价格: 8 GBP/1M tokens, 实测 prefill throughput: 800 tokens/s, 实测 decode throughput: 60 tokens/s, Transformer 层数: 32 layers, KV heads 数: 8 heads, Head dimension: 128 elements, 每个 KV cache 元素的字节数: 2, 并发序列数: 8 sequences
结果: 请求适配 context window，剩余 3,072 个 token。估算成本为每次 £0.01638，或每 30 天 £2,457.60；串行 prefill + decode 为 22.19 秒。每序列 KV cache 为 640 MiB，八个序列共 5.00 GiB。
实用指南
- 使用准确的模型配置：KV heads、head dimension、层数和 cache 数据类型可能因模型版本及量化模式而异。
- 在确定生产容量前，针对实际 serving batch、缓存策略和供应商，对 prefill/decode throughput 与 token 价格进行 benchmark。
常见错误
- 在 grouped-query attention 中误用 query heads 数代替 KV heads。
- 只计算用户可见的 Prompt 文本，遗漏 system、检索或 tool token。
- 将 KV cache 估算误认为模型总 VRAM；模型权重和运行时开销不在其中。
常见问题
此工具能预测供应商延迟吗？
不能。它将用户输入的实测 prefill 和 decode 速率相加，不模拟排队、batching、网络或供应商调度。
KV cache 会按整个 context window 计算吗？
此估算按每个活跃序列的 prompt 加生成 token 数计算，而不是未使用的 context window 余量。
上次审核： 2026-10-18
这是针对单一模型配置和平均请求的用户输入估算。它不会获取模型规格、价格、供应商限制或实时 serving 遥测。
此工具 根据上述假设提供参考估算值。
主题和工具偏好设置，以及已保存和最近使用的列表仅存储在此浏览器中。