推理 Benchmark 设计吞吐、延迟和成本要一起看一、单一指标会误导推理性能评测里吞吐、延迟、显存、成本都很重要。只看 QPS可能牺牲尾延迟只看首 token可能忽略总生成时间只看显存可能忽略硬件利用率。Benchmark 要反映真实使用场景而不是只挑一个好看的指标。推理 Benchmark 的目标是帮助选型和调优而不是制造宣传数字。二、先定义请求分布flowchart TD A[真实流量] -- B[Prompt 长度分布] A -- C[输出长度分布] A -- D[并发分布] B -- E[Benchmark 场景] C -- E D -- E固定 128 token 输入、128 token 输出的测试很容易跑但不一定代表真实业务。RAG、对话、代码生成、摘要的长度分布差别很大。inference_benchmark: prompt_tokens_p50: 800 prompt_tokens_p95: 6000 output_tokens_p50: 300 concurrency: [1, 8, 32, 64]请求分布要来自业务日志或明确假设。三、指标要分阶段metrics { time_to_first_token_ms: [], tokens_per_second: [], total_latency_ms: [], gpu_memory_gb: [], }首 token 延迟衡量交互反馈总延迟衡量完成时间tokens/s 衡量生成效率显存和 GPU 利用率衡量成本。对于流式输出平均 tokens/s 不够还要看生成过程中是否抖动。用户会感受到停顿。四、Benchmark 要可复跑每次测试要记录模型版本、量化方式、推理框架、硬件、驱动、batch 策略、采样参数。benchmark_metadata: model: llama-family-7b quantization: int4 engine: vllm gpu: a10 temperature: 0.0解码参数也会影响速度。temperature、top_p、beam search、max tokens 都要写清楚。还要避免预热影响。第一次请求可能加载模型、初始化 kernel、填充缓存。测试前要预热或者单独报告冷启动指标。最后成本要进入报告。每千 token 成本、每并发成本、每台机器吞吐都比单纯 QPS 更接近生产决策。Benchmark 还要区分冷启动和稳态。冷启动包含模型加载、权重搬运、kernel 初始化稳态才代表持续服务能力。两者混在一起指标会很难解释。benchmark_phases: cold_start: report_separately warmup_requests: 20 steady_state_duration_minutes: 10还要记录失败率。高并发下如果 5% 请求超时只看成功请求延迟会过于乐观。失败请求也要进入吞吐和稳定性判断。对于流式输出可以记录 token 间隔分布。平均生成速度不错但中间频繁停顿也会影响体验。最后Benchmark 报告要能复跑。请求集、脚本、参数、硬件信息都要保存否则下一次优化无法和基线公平比较。五、总结推理 Benchmark 要基于真实请求分布同时报告首 token、总延迟、吞吐、显存、利用率和单位成本。吞吐、延迟和成本要一起看。只拿一个指标做结论选型很容易跑偏。
