tokcalc MCP Server

---

---

tokcalc 将你的大模型流量、上下文长度、延迟 SLO、缓存行为和模型选择，转化为可靠的服务拓扑与成本方案，并提供透明的公式和有出处的基准数据。

这是面向大模型推理部署前决策的工程级工具，而非又一个静态的“每秒 token 数”计算器。

立即试用

tokcalc.vercel.app — 无需注册、不跟踪用户、没有付费墙。

tokcalc 是一款开源大模型服务容量规划工具，包含 44 个模型、31 种加速器和 16 种量化格式。它通过网站、MCP 服务和命令行共用的目录与计算引擎，估算模型适配情况、KV/状态内存、吞吐量、延迟、拓扑和成本。

选择模型、GPU 和工作负载，即可立即获取容量方案：

• 生成速度（tok/s）
• 预估首 token 延迟 + token 间延迟（ITL）
• 含 KV 缓存规格的显存预算
• 多 GPU 拓扑建议（单 GPU → TP×2/4/8 → 上下文并行）
• 月度成本 + 与 API 定价相比的盈亏平衡点
• GPU 实时价格，覆盖 Azure + AWS + GCP + Vast.ai 市场（并行获取）
• 可分享的 URL — 配置编码在 URL 哈希中，可发送给同事
• 复制为 Markdown — 将完整结果粘贴到 GitHub issue / Slack / 文档中

GitHub Action — 在每个 PR 上进行规划检查

如果仓库声明了服务方案，tokcalc 就可以检查它。在仓库根目录添加 .tokcalc.json：

{
  "model": "llama3-70b",
  "gpu": "h100-sxm",
  "quantization": "fp8",
  "numGpus": 2,
  "contextTokens": 32768,
  "concurrency": 16
}

然后将以下内容添加到 .github/workflows/plan.yml：

name: tokcalc
on:
  pull_request:
    paths: [".tokcalc.json"]

jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: stevecrates489-commits/[email protected]
        with:
          fail-on-infeasible: true

每个涉及方案的 PR 都会收到一条评论，其中包含显存预算、KV 缓存规格、吞吐量、TTFT/ITL 和成本——这样审阅者无需离开差异视图，就能检查模型/GPU 的选择。

像上面这样固定到发布标签，而不是使用 @main，这样 Action 就不会在两次运行之间发生变化。

该 Action 运行本仓库中 tokcalc 自己的 src/lib/token-calc.ts，因此报告的数据与网站和 MCP 工具生成的数据一致，不存在可能产生偏差的第二套实现。

你可以在每次运行时覆盖任意字段，也可以完全跳过配置文件：

- uses: stevecrates489-commits/[email protected]
  with:
    model: mixtral-8x7b
    gpu: h200-sxm
    quant: fp8
    gpus: 2
    context: 32768
    concurrency: 32

无需使用 Action，也可以在本地执行相同的检查：

npx @tokcalc/mcp-server plan --config .tokcalc.json
npx @tokcalc/mcp-server plan --model llama3-70b --gpu h100-sxm --quant fp8 --format json

方案符合要求时，退出码为 0；不符合时为 2；用法错误时为 1——因此它可以用作 CI 门禁。

为什么选择 tokcalc？

市面上有几十种“每秒 token 数”计算器和自托管与 API 盈亏平衡工具（induwara.lk、gigagpu、kickllm、cloudparity、curlscape、profitable.ai）。但没有一款是统一的容量规划工具，也没有一款会展示其计算过程。

tokcalc 能回答而竞品无法回答的问题

“我能否在 2× H100 上以 128K 上下文为 20 个并发用户提供 Qwen 2.5 72B 服务？”

“要达到每分钟 1,000 个请求且 P95 TTFT < 2s，我需要多少张 H200？”

“综合考虑质量、KV 缓存和引擎支持后，FP8 还是 AWQ 能省下更多成本？”

“每天的请求量达到多少时，H100 的价格会低于 GPT-4o？”

“目前在 Azure / AWS / GCP / Vast.ai 中，哪家的 H100 最便宜？”

“如果一个 Agent 调用模型 8 次、调用工具 3 次，并且上下文每轮增加 5K 个 token，成本和延迟会如何变化？”

“对于这个工作负载，前缀缓存、连续批处理还是 PD 分离能节省更多成本？”

功能

计算器选项卡

功能	计算内容
模型适配 / VRAM	模型 + KV 缓存能否装入 GPU 内存？
吞吐量	Decode tok/s（单流）+ 总吞吐量（批处理）+ Prefill tok/s
延迟拆分	首 Token 时间（= prefill）+ Token 间延迟（= decode）
连续批处理	用户可调的 1.0–4× 倍数（引用 SOSP 范围 1.5–4×）
推理 Token	添加到计费输出中的隐藏推理预算（o1 / R1 / Claude thinking）
提示词缓存	自托管 vLLM APC + Anthropic 5m/1h TTL + OpenAI 缓存 Token 优惠 50%
推测解码	用户可调的 1.2–4× 加速系数
多 GPU TP	1× → 8× 张量并行，含 NVLink 效率系数
长上下文容量	KV 内存 + 最大并发数 + 4K → 1M 上下文下的 prefill 时间
拓扑建议	单 GPU → TP×2 → TP×4 → TP×8 → TP×8 + 上下文并行（RingAttention）
成本分析	GPU $/hr → $/百万输出 Token → $/请求 → 月度成本
实测基准校准	粘贴 vLLM/SGLang/TRT-LLM JSON → 查看公式准确性判定（已验证 / 低估 / 高估）

自建还是购买选项卡

独立计算器（状态分离），用于比较：

• 自托管：模型 + GPU + 量化 + 利用率 + 批处理 → $/百万 Token + 月度成本
• API：13 家提供商（OpenAI / Anthropic / Gemini / Groq / DeepSeek / Mistral / Together）
• 判定：自托管更便宜 / API 更便宜 / 请求量不足 — 并显示盈亏平衡所需的每日请求数

参考选项卡

首页上的一个选项卡（tokcalc.vercel.app → 参考），不是单独的路由。 包含 6 个子表 — 数据完全透明，并尽可能为每条记录附上来源链接：

• 模型（44 个条目：Llama 4 Scout/Maverick、Qwen 3 系列、DeepSeek V3/R1、Pixtral、BGE-M3、GPT-OSS 20B/120B、Kimi K3、GLM-5.3 等）
• 加速器（31 个条目：H100/H200/B200/B300、AMD MI300X/MI325X、Intel Gaudi 3、TPU v5p/Trillium、Groq LPU、Cerebras WSE-3、Apple M2/M3/M4 Ultra 等）
• 量化（16 种格式：FP16/BF16、GGUF Q2_K→Q8_0、GPTQ、AWQ、EXL2、FP8、NVFP4）
• API 定价（13 个模型，含输入 / 缓存 / 输出价格，以及已退役 / 当前状态）
• 云 GPU 定价（所有 $/hr > 0 的加速器及常见提供商 — 静态整理）
• 🔴 实时定价（并行实时获取 Azure + AWS + GCP + Vast.ai 的价格 — 显示 LIVE 徽章 + 时间戳）

长上下文容量规划器（差异化功能）

Perplexity 研究简报称，这是“tokcalc 应明确展示的最重要内容”：

$$ \text{KV bytes/request} = 2 \cdot L \cdot T \cdot H_{\text{kv}} \cdot D_h \cdot B $$

对于稠密注意力，prefill 成本会随上下文长度超线性增长：

$$ \text{prefill FLOPs} = \underbrace{2 \cdot N \cdot T}{\text{线性}} + \underbrace{T^2 \cdot H{\text{kv}} \cdot D_h \cdot L}_{\text{注意力}} $$

tokcalc 会显示：

• 上下文长度为 4K / 8K / 16K / 32K / 64K / 128K / 256K / 512K / 1M 时的最大并发用户数
• 各上下文长度下每个请求的 KV 内存
• Prefill 时间（超过 32K 后会进行超线性注意力修正）
• 所需拓扑（单 GPU → TP×2/4/8 → TP×8 + 上下文并行）
• 需要 CP 时引用 RingAttention

实时 GPU 定价（新）

Reference 中的 🔴 实时定价子选项卡通过 Promise.allSettled 并行从 4 家提供商获取实时 GPU 价格：

提供商	API	身份验证	缓存 TTL
Azure	Retail Prices API	无（公开）	24h
AWS	EC2 bulk pricing file	无（公开）	24h
GCP	Cloud Billing Catalog API	GCP_API_KEY 环境变量	24h
Vast.ai	Marketplace bundles API	无（公开）	5m（现货价格变动迅速）

每家提供商都会显示 LIVE 徽标、时间戳和缓存状态。对比表会显示 4 家提供商中每款 GPU 的最低价格（以翡翠绿突出显示）以及各家提供商的价格明细。

如果某家提供商失败（例如，未设置 GCP_API_KEY），其他提供商仍可正常工作——每家提供商都能优雅降级。

数学原理，透明可查

上面的每个数字都来自可供检查的公式。没有黑箱。

解码 tokens/秒（受内存带宽限制）

$$ \text{decode tok/sec} \approx \frac{\text{HBM BW} \cdot \eta_{\text{mem}} \cdot \text{quant_eff}}{\text{model size}} $$

其中：

• HBM BW = GPU 内存带宽（例如，H100 SXM 为 3350 GB/s）
• η_mem = 0.65 = 典型的实际内存利用率（35% 开销）
• quant_eff = 反量化效率乘数（FP16 为 1.0，H100 上的 FP8 为 1.5，INT4 为 0.85）
• model size = active_params × bytes_per_param（MoE 使用活跃参数，而非总参数）

参考资料：PagedAttention 论文（arxiv.org/abs/2309.06180）

预填充 tokens/秒（受计算能力限制）

$$ \text{prefill tok/sec} \approx \frac{\text{GPU FLOPS} \cdot \eta_{\text{compute}}}{2 \cdot \text{active params}} $$

其中：

• GPU FLOPS = 密集计算 FP16/BF16 TFLOPS（不使用稀疏值）
• η_compute = 0.50 = 典型的计算利用率
• 系数 2 = 每个 token 的每个参数执行一次乘法和一次加法

对于长上下文（>32K），适用上方的超线性注意力修正。

连续批处理乘数（取决于工作负载）

$$ \text{aggregate tok/sec} = \text{decode tok/sec} \cdot \text{batch size} \cdot \text{continuous batching multiplier} $$

重要注意事项：连续批处理乘数并无通用值。vLLM 报告称，相较于 HF Transformers，速度提升 14–24×（极端情况）；相较于 TGI，提升 2.2–2.5×。SOSP 论文发现，相较于 FasterTransformer/Orca，典型提升为 2–4×。tokcalc 默认采用较保守的 1.5×，并允许你自行调整。

参考资料：

• vLLM 博客（2023-06-20）
• PagedAttention 论文
• Anyscale 连续批处理研究

提示词缓存的成本效益（Anthropic / OpenAI）

对于长度为 $T_p$ 的共享前缀、长度为 $T_u$ 的后缀、输出 $O$， 缓存命中率为 $h$：

$$ \text{API input cost} = N \cdot \left[ (1-h) \cdot T_p \cdot P_{\text{write}} + h \cdot T_p \cdot P_{\text{read}} + T_u \cdot P_{\text{input}} \right] $$

Anthropic 乘数（已于 2025-2026 年核实）：

• 5 分钟缓存写入：基础输入价格的 1.25×
• 1 小时缓存写入：基础输入价格的 2.0×
• 缓存读取：基础输入价格的 0.1×（节省 90%）

OpenAI：缓存输入可享 50% 折扣，不另收写入费用。

参考资料：

• Anthropic 提示词缓存文档
• OpenAI 提示词缓存指南

多 GPU 拓扑建议

$$ \text{total needed} = \text{model weights} + (\text{KV per request} \cdot \text{batch size}) $$

逐步选择能满足需求的最小拓扑：

• 单 GPU：总量 ≤ VRAM × 1
• 张量并行 ×2/4/8：总量 ≤ VRAM × N（权重 + KV 均匀拆分）
• TP×8 + 上下文并行：总量 > VRAM × 8 — 使用 RingAttention 在多个节点间分片 KV

参考资料：RingAttention 论文

自托管与 API 的盈亏平衡点

$$ \text{self-host $/M tokens} = \frac{\text{GPU $/hr}}{3600 \cdot \text{effective tok/s} \cdot \text{utilization}} \cdot 10^6 $$

$$ \text{break-even req/day} = \frac{\text{monthly self-host cost}}{30 \cdot \text{API cost per request}} $$

决定性因素是实际利用率，而非峰值吞吐量。GPU 的利用率若只有 10%，每个 token 的成本就是理论最低值的 10 倍。

## 与相邻工具的对比

能力	induwara / techfuelhq / pcmasterstudio	gigagpu / kickllm / cloudparity	HF Open LLM Leaderboard / MLPerf	tokcalc
模型 × 加速器 × 量化 tok/s	✓	部分支持	部分支持	✓
模型适配 / VRAM	基础支持	少见	少见	✓
按上下文 + 并发计算 KV 缓存	—	—	隐含支持	✓
Prefill 与 decode 拆分（TTFT/ITL）	—	—	引擎特定	✓
连续批处理 / 分页注意力	—	—	仅文档	✓
长上下文（128K–1M）规划	—	—	—	✓
拓扑推荐（TP/CP）	—	—	部分支持	✓
提示词缓存成本分析	—	仅部分 API	—	✓
推理 token（o1/R1/Claude thinking）	—	—	—	✓
API 与自托管的盈亏平衡分析	部分支持	✓	—	✓
云 GPU 实时定价（4 家提供商）	—	—	—	✓
基于实测基准的校准	—	—	—	✓
面向 AI Agent 的 MCP 服务	—	—	—	✓
公开托管的 MCP 端点 + 自助生成密钥	—	—	—	✓
透明公式 / 开源	不一	通常不支持	不一	✓
每种配置的引用基准证据	少见	少见	✓（不用于规划）	✓（进行中）
每种配置均可分享 URL	—	—	—	✓
将结果复制为 Markdown	—	—	—	✓

路线图

已发布

• ✅ 44 种模型、31 种加速器、16 种量化格式
• ✅ 连续批处理、推理 token、提示词缓存
• ✅ 首 token 延迟 / ITL 拆分估算、长上下文超线性注意力
• ✅ 长上下文容量规划器 + 拓扑推荐
• ✅ 自建与购买计算器（13 家 API 提供商，含已退役 / 当前状态）
• ✅ 参考目录（含实时定价在内的 6 个子表）
• ✅ GPU 实时定价（并行获取 Azure + AWS + GCP + Vast.ai 定价，并显示 LIVE 徽标）
• ✅ 基于实测基准的校准（粘贴 vLLM/SGLang/TRT-LLM JSON → 获取判定结果）
• ✅ MCP 服务 v0.3.4 — 10 个只读工具 + 1 个校准写入工具，支持 stdio + Streamable HTTP 传输
• ✅ 单一核心 MCP 架构 — 使用一个 src/lib/mcp/core.ts，通过 shim 接入托管端点和 npm 包，确保两个入口保持一致
• ✅ 已发布到 MCP Registry，并通过 OIDC 工作流在每个 v* 标签发布时保持最新
• ✅ 准确核算 MoE — 分别报告驻留（完整）权重和激活（每个 token）参数，而非将两者混为一谈
• ✅ 严格的工具架构 — 使用 Zod 4 原生 JSON Schema；拒绝未知参数，并提示有效名称
• ✅ 公开托管的 MCP 端点 tokcalc.vercel.app/api/mcp，支持 bearer 身份验证 + Upstash Redis 速率限制
• ✅ 自助生成 API 密钥，地址：tokcalc.vercel.app/mcp（输入邮箱 → 即时获取密钥）
• ✅ 4 个 SEO 落地页：/compare/h100-vs-h200、/compare/gguf-q4-k-m-vs-q5-k-m、/self-host-vs-openai-api、/mcp（安装文档）
• ✅ 分享 URL + localStorage 持久化
• ✅ GitHub Action — 直接将容量与成本计划添加到你的 PR
• ✅ 将结果复制为 Markdown（适用于 GitHub issue / Slack / 文档）
• ✅ 深色模式切换
• ✅ 简明易懂的术语表（28 个术语，带悬停提示）
• ✅ OG 图片 + Twitter 卡片 + 社交媒体元数据
• ✅ Plausible Analytics（注重隐私）+ Sentry 错误监控

未来 30 天

• ⏳ 版本化价格与基准溯源信息 — 每个费率和基准都注明来源 URL + 获取日期
• ⏳ P/D 解耦规划器（分离 prefill + decode 资源池）
• ⏳ 适配引擎的预设（vLLM / SGLang / TensorRT-LLM / llama.cpp）— 集成到 UI
• ⏳ 多轮 / Agent 工作流成本分析 — 在成本模型中纳入持续增长的上下文和工具调用轮次

未来 90 天

• ⏳ 多 LoRA 容量规划器（Punica / S-LoRA 成本分析）
• ⏳ VLM 图像 token 核算（按模型计算 patch/tile token 化）

暂不计划

• i18n（中文 / 日文 / 韩文） — 需要长期维护 44 种模型 × 31 种加速器 × 11 种工具的翻译，而目前流量绝大多数来自 CI 和 Agent 安装，而非人工读者。只有当分析数据中出现 CJK 流量时才重新考虑。
• OAuth 2.1 / PKCE — 为只有一位用户的产品搭建身份验证基础设施。自助签发密钥加上 Upstash 速率限制已足以满足实际需求。按需重新考虑。
• 训练 / 微调 FLOPs、能耗 / 碳排放、嵌入模式 — 这些各自都是独立领域中的独立产品。“容量规划器”定位鲜明；将其扩展为通用 AI 基础设施计算器套件，投入大于收益。

开源核心模式

tokcalc 采用开源核心模式——计算器和目录开源；云端 / 数据 / 团队功能则为付费功能。

资产	许可证	说明
源代码	Apache 2.0	本仓库。可免费使用、修改和分发
模型 / GPU / 量化目录	CC0 1.0	公有领域数据。任何人都可以使用，无需注明出处
基准测试来源数据	CC-BY-SA 4.0	任何人都可以使用，但必须注明出处并以相同方式共享
文档	CC-BY 4.0	复制时必须注明出处
“tokcalc”名称 + Logo	商标	即使未正式注册，也享有普通法权利
云端 SaaS 层	专有	实时价格 API、基准测试数据库、团队工作区（即将推出）

采用这种结构的原因

• 信任：开源公式相较于不透明的竞争产品更能建立可信度
• 社区：贡献者可以提交模型、加速器、量化方案和基准测试
• 防御力：商标 + 云端功能 + URL 分享带来的病毒式传播循环，可抵御分叉
• 收入：云端套餐为持续开发以及价格 / 基准测试数据维护提供资金

贡献

欢迎贡献！请参阅 CONTRIBUTING.md，了解：

• 如何添加模型（以 HuggingFace config.json 为来源）
• 如何添加加速器（包括 B200/B300 空值 FP16 字段的重要防护措施）
• 如何添加量化格式（以实测文件大小为来源）
• 如何提交基准测试（三级置信度模型）
• 如何改进公式（注明来源，不使用魔法数字）

最需要的贡献

• 🟢 新模型（Qwen 3、Mistral Large 4、Llama 4 系列新版本发布时）
• 🟢 新加速器（B300、AMD MI400、Apple M5 Ultra 发布时）
• 🟢 新量化格式（mxFP8、MXFP4、BitNet 2）
• 🟢 真实基准测试数据（运行 vLLM 基准测试并附来源信息提交）
• 🟢 翻译（尤其是中文、日文和韩文）

MCP 服务——在 AI Agent 中使用 tokcalc

tokcalc 提供一个 MCP（Model Context Protocol） 服务，让 AI Agent（Cursor、Claude Desktop、Cline）在设计评审期间调用 tokcalc。

npm 包：@tokcalc/mcp-server（最新版本：v0.3.4） 公共端点：https://tokcalc.vercel.app/api/mcp（Streamable HTTP，Bearer 身份验证，带速率限制） 安装文档：https://tokcalc.vercel.app/mcp

11 个工具 — 10 个只读工具 + 1 个校准写入工具

工具	功能	访问权限
estimate_capacity	单个配置的 VRAM/KV/吞吐量/延迟/成本	只读
compare_gpus	针对单个工作负载的加速器排名比较	只读
recommend_topology	TP/CP 拓扑建议	只读
estimate_api_vs_self_host	盈亏平衡分析	只读
list_models	查找受支持的模型 ID	只读
list_gpus	查找受支持的加速器 ID	只读
get_mlperf_benchmarks	精选的 MLPerf Inference v4.1 审核参考配置	只读
find_config_for_slo	逆向规划器 — 根据 SLO + 流量查找可行配置，并按成本/吞吐量/价值排序	只读
plan_deployment	一次调用生成决策简报 — 内存 + 性能 + 自建与采购比较 + 风险 + 后续步骤	只读
fetch_model_spec	将目录与 HuggingFace 实时 config.json 对比（缓存 24 小时）	只读
record_measured	存储实际 tok/s 测量值；后续估算将自动校准	写入状态

这十个规划工具没有副作用、不需要云凭据，也不会部署任何内容。record_measured 是唯一的写入工具：它会存储测量值，以便后续针对该模型 + GPU + 量化方式的估算进行自动校准。每个工具都会在 MCP 线上注释（readOnlyHint / destructiveHint / idempotentHint / openWorldHint）中声明这些信息，因此客户端在调用前就能区分读取和写入操作。

工具参数严格校验：未知键会被拒绝，而非忽略；错误信息会列出有效键。参数名称为 model 和 gpu（而非 modelId / gpuType）。

选项 A：公共托管端点（推荐 — 无需安装）

将 Cursor 或 Claude Desktop 指向公共端点。前往 /mcp 即可立即获取 API 密钥：

{
  "mcpServers": {
    "tokcalc": {
      "url": "https://tokcalc.vercel.app/api/mcp",
      "headers": { "Authorization": "Bearer <your-api-key>" }
    }
  }
}

功能：

• ✅ Bearer API 密钥身份验证（通过 crypto.timingSafeEqual 进行恒定时间比较）
• ✅ 基于 KV 的速率限制，使用 Upstash Redis（每个 IP 每分钟 30 次请求，每个密钥每分钟 120 次请求）
• ✅ 自助生成密钥 — 在 /mcp 输入电子邮件地址，即可立即获取密钥（每个 IP 每天限 5 个）
• ✅ 密钥在 90 天未活动后过期
• ✅ 使用 SHA-256 对密钥进行哈希处理（从不存储原始密钥）

选项 B：自托管 stdio（适用于本地 Cursor / Claude Desktop）

{
  "mcpServers": {
    "tokcalc": {
      "command": "npx",
      "args": ["-y", "@tokcalc/mcp-server"]
    }
  }
}

stdio（本地安装）无需 API 密钥。Cursor 会通过 npx 启动进程。

选项 C：自托管 HTTP（适用于气隙环境 / 自定义基础设施）

npm install -g @tokcalc/mcp-server
tokcalc-mcp-http  # defaults to port 3000

设置 MCP_API_KEY、UPSTASH_REDIS_REST_URL、UPSTASH_REDIS_REST_TOKEN 环境变量，以启用身份验证和速率限制。

Agent 提示词示例

“我需要为 50 个并发用户提供 Llama 3.3 70B 服务，上下文长度为 32K。你推荐什么 GPU 拓扑？每月费用是多少？”

Agent 会调用 list_models → list_gpus → recommend_topology → estimate_capacity，然后返回一份结构化方案，其中包含 VRAM、吞吐量、延迟、成本和数据来源。

开发与测试

# Typecheck (must stay at zero errors)
bunx tsc --noEmit

# Golden-number suite (33 tests) — hand-verified oracle values
bun test tests/mcp-golden.test.ts

# Surface-parity suite (13 tests) — every surface advertises the same 11 tools
bun test tests/mcp-surface-parity.test.ts

# Catalog suite (29 tests) — schema conformance, id stability, provenance,
# architecture-engine correctness, backward compatibility
bun test tests/catalog.test.ts

# Catalog validation (Zod schemas + id/provenance integrity) — CI gate
bun scripts/catalog-validate.ts

# Build the npm server dist + prepublish guard (freshness + version sync)
cd mini-services/mcp-server && bun run build && node scripts/prepublish-check.js

# 35-check black-box stdio QA battery against the freshly built dist
cd ../.. && node tests/qa-live-probe.mjs local
# …or against the PUBLISHED npm tarball:
node tests/qa-live-probe.mjs 0.3.4

# 20-check HTTP smoke probe against the hosted /api/mcp surface
MCP_API_KEY=<key> EXPECTED_VERSION=0.3.4 node tests/http-smoke.mjs http://localhost:3001
# …or against production:
MCP_API_KEY=<key> node tests/http-smoke.mjs https://tokcalc.vercel.app

GitHub Actions 会在每次推送时运行上述所有内容（已发布 tarball 模式除外）——请参阅 .github/workflows/ci.yml。

技术栈

• 框架：Next.js 16（使用 App Router，Turbopack）
• 语言：TypeScript 5
• 样式：Tailwind CSS 4 + shadcn/ui（New York）
• 图表：Recharts
• 状态：React hooks（useState + useEffect + useMemo）
• 主题：next-themes（默认暗色模式）
• MCP SDK：@modelcontextprotocol/sdk v1.30.1（Streamable HTTP 传输，无状态模式）
• 身份验证：crypto.timingSafeEqual（恒定时间 Bearer 密钥验证）
• 速率限制：@upstash/ratelimit + @upstash/redis（滑动窗口，每个 IP 每分钟 30 次，每个密钥每分钟 120 次）
• 分析：Plausible（注重隐私，不使用 Cookie）
• 错误监控：Sentry
• 数据库：核心功能不使用数据库；使用 Upstash Redis 存储 API 密钥并进行速率限制

项目结构

tokcalc/
├── src/
│   ├── app/
│   │   ├── api/
│   │   │   ├── mcp/route.ts          # Public MCP endpoint (Streamable HTTP)
│   │   │   ├── keys/route.ts         # Self-serve API key generation
│   │   │   └── pricing/              # Live GPU pricing proxies
│   │   │       ├── aws/route.ts
│   │   │       ├── azure/route.ts
│   │   │       ├── gcp/route.ts
│   │   │       └── vast-ai/route.ts
│   │   ├── compare/                  # SEO landing pages
│   │   │   ├── h100-vs-h200/page.tsx
│   │   │   └── gguf-q4-k-m-vs-q5-k-m/page.tsx
│   │   ├── self-host-vs-openai-api/page.tsx
│   │   ├── mcp/page.tsx              # MCP install docs + self-serve key form
│   │   ├── page.tsx                  # Main calculator
│   │   └── layout.tsx
│   ├── lib/
│   │   ├── mcp/
│   │   │   ├── core.ts              # UNIFIED tool core — all 11 tools, both surfaces
│   │   │   ├── server.ts            # thin shim → core (createMcpServer factory)
│   │   │   ├── mcp-version.ts       # MCP_SERVER_VERSION — single source of truth
│   │   │   ├── mcp-store.ts         # per-install store (spec cache + calibration)
│   │   │   └── auth.ts               # validateApiKey (Redis + env var)
│   │   ├── token-calc.ts             # Core calculation engine
│   │   ├── mlperf-curated.ts         # 10 MLPerf v4.1 reference configs
│   │   ├── price-schema.ts           # PriceRecord type + helpers
│   │   ├── benchmark-schema.ts       # BenchmarkRecord + CalibrationResult
│   │   ├── engine-presets.ts         # 5 engine presets (vLLM/SGLang/TRT-LLM/llama.cpp/generic)
│   │   └── url-state.ts              # URL hash + localStorage persistence
│   └── components/
│       ├── benchmark-import.tsx      # Paste JSON → calibrate against estimate
│       └── confidence-badge.tsx      # 🟢🟡⚪ confidence dots
├── mini-services/
│   └── mcp-server/                   # Standalone npm package (for stdio + self-hosted HTTP)
│       ├── server.ts                 # thin shim → src/lib/mcp/core.ts (no duplicated handlers)
│       ├── auth.ts                   # Bearer auth middleware (Node http)
│       ├── rate-limit.ts             # Upstash rate limiter (Node http)
│       ├── http.ts                   # Standalone HTTP entry (tokcalc-mcp-http)
│       ├── index.ts                  # Stdio entry (tokcalc-mcp-server)
│       └── package.json              # @tokcalc/mcp-server npm package
├── public/
│   ├── og.png                        # OG image
│   └── manifest.json                 # PWA manifest
├── src/app/sitemap.ts                # Generated sitemap (859 URLs — built from the catalog)
├── server.json                       # MCP registry entry (packages + remotes)
├── package.json                      # Web app deps
└── next.config.ts

致谢

tokcalc 基于以下项目的成果构建：

• vLLM team — PagedAttention、连续批处理（arxiv.org/abs/2309.06180）
• llama.cpp / ggml-org — GGUF 格式和量化变体
• MLPerf / MLCommons — 标准化推理基准测试方法
• Stanford HELM — 考虑效率的模型评估框架
• Anthropic / OpenAI / Google — 已发布的提示词缓存定价规则
• Model Context Protocol team — MCP Streamable HTTP 传输规范（2025-03-26）
• NVIDIA / AMD / Intel / Google / Groq / Cerebras — 已发布的硬件规格
• Upstash — Redis + 速率限制基础设施

每个公式都附有引用。每个模型/GPU/量化条目都包含来源 URL（如有）。如果你发现未注明来源的说法，请提交 issue。

Star 历史

---