infermark 是一个专注于大语言模型推理性能评测的开源工具，支持测量首Token延迟、Token间延迟、吞吐量和分位数延迟等关键指标，兼容所有 OpenAI 协议的推理端点。

infermark：LLM推理性能评测的实用工具箱\n\n## 为什么需要专门的推理性能评测工具？\n\n在部署大语言模型（LLM）时，"能不能跑"只是第一步，"跑得怎么样"才是关键。推理性能直接影响用户体验：首Token多久能出来？生成过程是否流畅？高并发下会不会卡顿？\n\n然而，2025年两个主流的 LLM 性能评测工具 llmperf 和 llm-bench 相继被归档停止维护，社区急需一个现代化的替代方案。infermark 正是为了填补这一空白而诞生的。\n\n## 核心功能：测量真正重要的指标\n\ninfermark 专注于测量对用户体验影响最大的几个核心指标：\n\n### 首Token时间（TTFT, Time To First Token）\n\n这是用户感知到的"响应速度"。TTFT 衡量从发送请求到收到第一个生成Token的时间。在对话场景中，用户希望 AI 能"秒回"，而不是等待数秒才开始输出。\n\n### Token间延迟（ITL, Inter-Token Latency）\n\n这决定了生成过程的"流畅度"。ITL 测量相邻Token之间的时间间隔。如果 ITL 过高，用户会看到明显的卡顿感，即使 TTFT 很快，整体体验也会大打折扣。\n\n### 吞吐量（Throughput）\n\n以每秒生成的Token数（tok/s）衡量，反映系统处理能力的上限。对于批量处理或高并发场景，吞吐量是核心指标。\n\n### 分位数延迟（P50/P95/P99）\n\n平均延迟往往具有误导性。infermark 提供完整的延迟分布统计，帮助发现尾部延迟问题——少数慢请求可能严重影响用户体验。\n\n### 错误率和每秒请求数（RPS）\n\n在高负载下，系统是否稳定？能支撑多少并发请求？这些指标对于生产环境的容量规划至关重要。\n\n## 技术特性：简洁而强大\n\n### 零配置开箱即用\n\ninfermark 的设计理念是"一个命令，无需配置文件"。只需指定端点地址和模型名称，即可开始评测：\n\nbash\n# 基础用法\ninfermark run http://localhost:8000/v1 --model meta-llama/Llama-3-70B -n 50\n\n# 并发梯度测试\ninfermark run http://localhost:8000/v1 -c 1,4,8,16,32,64 -n 100\n\n# 保存 JSON 结果\ninfermark run http://localhost:8000/v1 -o results.json\n\n\n### 广泛的兼容性\n\n任何兼容 OpenAI Chat Completions API 的端点都可以被评测，包括：\n\n- vLLM：目前最流行的开源推理引擎，支持连续批处理和PagedAttention\n- Text Generation Inference (TGI)：Hugging Face 推出的生产级推理服务\n- SGLang：针对结构化生成优化的推理框架\n- Ollama：本地运行大模型的便捷方案\n- llama.cpp：针对消费级硬件优化的轻量级推理\n- LiteLLM Proxy：统一多模型提供商的代理层\n- 商业 API：OpenAI、Anthropic、Together、Fireworks 等\n\n### 多种输出格式\n\ninfermark 支持将结果导出为不同格式，适应不同使用场景：\n\n- 终端表格：实时显示进度和结果，基于 Rich 库渲染\n- JSON：便于程序化分析和集成到 CI/CD 流水线\n- Markdown：可直接粘贴到文档、PR 描述或技术博客\n\n### 对比分析功能\n\nbash\n# 分别评测不同端点\ninfermark run http://gpu1:8000/v1 --model llama-3 -o vllm.json\ninfermark run http://gpu2:8080/v1 --model llama-3 -o tgi.json\ninfermark run http://gpu3:11434/v1 --model llama-3 -o ollama.json\n\n# 并排对比\ninfermark compare vllm.json tgi.json ollama.json\n\n\n这对于技术选型特别有价值——你可以用相同的工作负载测试 vLLM、TGI 和 Ollama，用数据说话，而不是凭感觉选择。\n\n## 编程接口：灵活的集成方式\n\n除了命令行工具，infermark 还提供了简洁的 Python API：\n\npython\nfrom infermark import BenchmarkConfig, run_benchmark\n\nconfig = BenchmarkConfig(\n url=\"http://localhost:8000/v1\",\n model=\"meta-llama/Llama-3-70B-Instruct\",\n concurrency_levels=[1, 4, 8, 16, 32],\n n_requests=100,\n max_tokens=256,\n)\n\nreport = run_benchmark(config)\n\n# 获取最佳吞吐量配置\nbest = report.best_throughput()\nprint(f\"峰值: {best.tokens_per_second:.1f} tok/s @ 并发{best.concurrency}\")\n\n# 获取最低延迟配置\nlow = report.lowest_latency()\nprint(f\"最低P50: {low.latency.p50 * 1000:.1f} ms @ 并发{low.concurrency}\")\n\n\n同时也支持异步接口，便于集成到异步应用中：\n\npython\nimport asyncio\nfrom infermark import BenchmarkConfig, run_benchmark_async\n\nasync def main():\n config = BenchmarkConfig(url=\"http://localhost:8000/v1\", model=\"llama-3\")\n report = await run_benchmark_async(config)\n print(f\"峰值吞吐量: {report.best_throughput().tokens_per_second:.1f} tok/s\")\n\nasyncio.run(main())\n\n\n## 评测流程的科学性\n\ninfermark 的评测流程经过精心设计，确保结果的可信度：\n\n1. 预热阶段（Warmup）：正式评测前发送若干请求，让服务器的 KV Cache 预热、JIT 编译完成，避免冷启动影响结果\n\n2. 并发梯度测试：在每个并发级别（如 1、4、8、16、32），使用 asyncio 并发发送 N 个请求\n\n3. 流式测量：解析 SSE 数据流，精确测量 TTFT 和 ITL\n\n4. 统计计算：从原始计时数据计算 P50/P75/P90/P95/P99、均值、最小值、最大值、标准差\n\n这种设计确保了评测结果既反映了真实负载下的表现，又提供了足够的统计可信度。\n\n## 生态系统：stef41 LLM 工具链\n\ninfermark 是 stef41 维护的 LLM 全生命周期工具链的一部分。这个生态还包括：\n\n- tokonomics：Token 计数和成本管理\n- datacrux：训练数据质量检查（去重、PII检测、污染检测）\n- castwright：合成指令数据生成\n- datamix：数据集混合与课程学习优化\n- toksight：Tokenizer 分析与对比\n- trainpulse：训练健康度监控\n- ckpt：Checkpoint 检查、对比与合并\n- quantbench：量化质量分析\n- modeldiff：行为回归测试\n- vibesafe：AI 生成代码安全扫描\n- injectionguard：提示词注入检测\n\n这种模块化的工具链设计，让开发者可以根据需要选择组件，构建完整的 LLM 开发和运维流程。\n\n## 使用建议与最佳实践\n\n1. 评测前确保服务稳定：关闭调试模式，确保 GPU 温度正常，避免其他负载干扰\n\n2. 选择合适的并发梯度：根据实际使用场景选择并发级别。如果是个人使用，重点看 1-4 并发；如果是服务端部署，需要测试更高的并发\n\n3. 多次运行取平均：网络波动和系统缓存会影响结果，建议每个配置运行 3-5 次取平均\n\n4. 结合实际使用场景：评测用的 prompt 长度和 max_tokens 应该与实际应用场景接近\n\n5. 关注尾部延迟：P99 延迟往往比平均值更能反映用户体验的下限\n\n## 总结\n\ninfermark 是一个设计精良、使用便捷的 LLM 推理性能评测工具。它填补了 llmperf 和 llm-bench 归档后的工具空白，为社区提供了一个现代化的基准测试方案。\n\n无论是进行技术选型、优化推理配置，还是监控生产环境性能，infermark 都能提供可靠的数据支撑。对于任何需要部署和运维 LLM 服务的团队来说，这都是一个值得加入工具箱的开源项目。

infermark：LLM推理性能评测的实用工具箱\n\n为什么需要专门的推理性能评测工具？\n\n在部署大语言模型（LLM）时，"能不能跑"只是第一步，"跑得怎么样"才是关键。推理性能直接影响用户体验：首Token多久能出来？生成过程是否流畅？高并发下会不会卡顿？\n\n然而，2025年两个主流的 LLM 性能评测工具 llmperf 和 llm-bench 相继被归档停止维护，社区急需一个现代化的替代方案。infermark 正是为了填补这一空白而诞生的。\n\n核心功能：测量真正重要的指标\n\ninfermark 专注于测量对用户体验影响最大的几个核心指标：\n\n首Token时间（TTFT, Time To First Token）\n\n这是用户感知到的"响应速度"。TTFT 衡量从发送请求到收到第一个生成Token的时间。在对话场景中，用户希望 AI 能"秒回"，而不是等待数秒才开始输出。\n\nToken间延迟（ITL, Inter-Token Latency）\n\n这决定了生成过程的"流畅度"。ITL 测量相邻Token之间的时间间隔。如果 ITL 过高，用户会看到明显的卡顿感，即使 TTFT 很快，整体体验也会大打折扣。\n\n吞吐量（Throughput）\n\n以每秒生成的Token数（tok/s）衡量，反映系统处理能力的上限。对于批量处理或高并发场景，吞吐量是核心指标。\n\n分位数延迟（P50/P95/P99）\n\n平均延迟往往具有误导性。infermark 提供完整的延迟分布统计，帮助发现尾部延迟问题——少数慢请求可能严重影响用户体验。\n\n错误率和每秒请求数（RPS）\n\n在高负载下，系统是否稳定？能支撑多少并发请求？这些指标对于生产环境的容量规划至关重要。\n\n技术特性：简洁而强大\n\n零配置开箱即用\n\ninfermark 的设计理念是"一个命令，无需配置文件"。只需指定端点地址和模型名称，即可开始评测：\n\nbash\n基础用法\ninfermark run http://localhost:8000/v1 --model meta-llama/Llama-3-70B -n 50\n\n并发梯度测试\ninfermark run http://localhost:8000/v1 -c 1,4,8,16,32,64 -n 100\n\n保存 JSON 结果\ninfermark run http://localhost:8000/v1 -o results.json\n\n\n广泛的兼容性\n\n任何兼容 OpenAI Chat Completions API 的端点都可以被评测，包括：\n\n- vLLM：目前最流行的开源推理引擎，支持连续批处理和PagedAttention\n- Text Generation Inference (TGI)：Hugging Face 推出的生产级推理服务\n- SGLang：针对结构化生成优化的推理框架\n- Ollama：本地运行大模型的便捷方案\n- llama.cpp：针对消费级硬件优化的轻量级推理\n- LiteLLM Proxy：统一多模型提供商的代理层\n- 商业 API：OpenAI、Anthropic、Together、Fireworks 等\n\n多种输出格式\n\ninfermark 支持将结果导出为不同格式，适应不同使用场景：\n\n- 终端表格：实时显示进度和结果，基于 Rich 库渲染\n- JSON：便于程序化分析和集成到 CI/CD 流水线\n- Markdown：可直接粘贴到文档、PR 描述或技术博客\n\n对比分析功能\n\nbash\n分别评测不同端点\ninfermark run http://gpu1:8000/v1 --model llama-3 -o vllm.json\ninfermark run http://gpu2:8080/v1 --model llama-3 -o tgi.json\ninfermark run http://gpu3:11434/v1 --model llama-3 -o ollama.json\n\n并排对比\ninfermark compare vllm.json tgi.json ollama.json\n\n\n这对于技术选型特别有价值——你可以用相同的工作负载测试 vLLM、TGI 和 Ollama，用数据说话，而不是凭感觉选择。\n\n编程接口：灵活的集成方式\n\n除了命令行工具，infermark 还提供了简洁的 Python API：\n\npython\nfrom infermark import BenchmarkConfig, run_benchmark\n\nconfig = BenchmarkConfig(\n url=\"http://localhost:8000/v1\",\n model=\"meta-llama/Llama-3-70B-Instruct\",\n concurrency_levels=[1, 4, 8, 16, 32],\n n_requests=100,\n max_tokens=256,\n)\n\nreport = run_benchmark(config)\n\n获取最佳吞吐量配置\nbest = report.best_throughput()\nprint(f\"峰值: {best.tokens_per_second:.1f} tok/s @ 并发{best.concurrency}\")\n\n获取最低延迟配置\nlow = report.lowest_latency()\nprint(f\"最低P50: {low.latency.p50 * 1000:.1f} ms @ 并发{low.concurrency}\")\n\n\n同时也支持异步接口，便于集成到异步应用中：\n\npython\nimport asyncio\nfrom infermark import BenchmarkConfig, run_benchmark_async\n\nasync def main():\n config = BenchmarkConfig(url=\"http://localhost:8000/v1\", model=\"llama-3\")\n report = await run_benchmark_async(config)\n print(f\"峰值吞吐量: {report.best_throughput().tokens_per_second:.1f} tok/s\")\n\nasyncio.run(main())\n\n\n评测流程的科学性\n\ninfermark 的评测流程经过精心设计，确保结果的可信度：\n\n1. 预热阶段（Warmup）：正式评测前发送若干请求，让服务器的 KV Cache 预热、JIT 编译完成，避免冷启动影响结果\n\n2. 并发梯度测试：在每个并发级别（如 1、4、8、16、32），使用 asyncio 并发发送 N 个请求\n\n3. 流式测量：解析 SSE 数据流，精确测量 TTFT 和 ITL\n\n4. 统计计算：从原始计时数据计算 P50/P75/P90/P95/P99、均值、最小值、最大值、标准差\n\n这种设计确保了评测结果既反映了真实负载下的表现，又提供了足够的统计可信度。\n\n生态系统：stef41 LLM 工具链\n\ninfermark 是 stef41 维护的 LLM 全生命周期工具链的一部分。这个生态还包括：\n\n- tokonomics：Token 计数和成本管理\n- datacrux：训练数据质量检查（去重、PII检测、污染检测）\n- castwright：合成指令数据生成\n- datamix：数据集混合与课程学习优化\n- toksight：Tokenizer 分析与对比\n- trainpulse：训练健康度监控\n- ckpt：Checkpoint 检查、对比与合并\n- quantbench：量化质量分析\n- modeldiff：行为回归测试\n- vibesafe：AI 生成代码安全扫描\n- injectionguard：提示词注入检测\n\n这种模块化的工具链设计，让开发者可以根据需要选择组件，构建完整的 LLM 开发和运维流程。\n\n使用建议与最佳实践\n\n1. 评测前确保服务稳定：关闭调试模式，确保 GPU 温度正常，避免其他负载干扰\n\n2. 选择合适的并发梯度：根据实际使用场景选择并发级别。如果是个人使用，重点看 1-4 并发；如果是服务端部署，需要测试更高的并发\n\n3. 多次运行取平均：网络波动和系统缓存会影响结果，建议每个配置运行 3-5 次取平均\n\n4. 结合实际使用场景：评测用的 prompt 长度和 max_tokens 应该与实际应用场景接近\n\n5. 关注尾部延迟：P99 延迟往往比平均值更能反映用户体验的下限\n\n总结\n\ninfermark 是一个设计精良、使用便捷的 LLM 推理性能评测工具。它填补了 llmperf 和 llm-bench 归档后的工具空白，为社区提供了一个现代化的基准测试方案。\n\n无论是进行技术选型、优化推理配置，还是监控生产环境性能，infermark 都能提供可靠的数据支撑。对于任何需要部署和运维 LLM 服务的团队来说，这都是一个值得加入工具箱的开源项目。