一旦 #2316 被合并，我愿意贡献以下指标，我相信这些指标对于监控 vllm 的使用情况是有帮助的。
| # | 指标 | 类型 | 标签 | 描述 |
|---|---|---|---|---|
| 1. | vllm:request_success | 计数器 | finish_reason= stop|length | 已成功处理的请求数量。 |
| 2. | vllm:request_params_max_tokens | 直方图 | max_tokens 请求参数的值。 | |
| 3. | vllm:request_params_n | 直方图 | n 请求参数的值。 | |
| 4. | vllm:request_total_tokens | 直方图 | 请求的总序列长度(输入令牌 + 生成令牌)。 | |
| 5. | vllm:request_prompt_tokens | 直方图 | 已处理的预填充令牌数量。 | |
| 6. | vllm:request_generation_tokens | 直方图 | 已处理的生成令牌数量。 |
注意事项：
指标 5 和 6 已经存在，但作为计数器(vllm:prompt_tokens_total 和 vllm:generation_tokens_total)。我认为直方图更有意义。为了向后兼容，我们可以保留这两种类型(计数器和直方图)。
请告诉我您的想法。
3条答案
按热度按时间brvekthn1#
aborted_requests的数量当前对端到端延迟的分析的一个很大的限制是，没有对处理的令牌数量进行标准化。我们可能无法完全做到这一点，但是通过将端到端延迟除以生成的令牌数量来标准化可能会给出一个更好的标准化指标，因此也许在这方面有所扩展会是很好的
30byixjq2#
感谢您的建议！
aborted_requests度量听起来是一个重要的补充。然而，我不太清楚它如何根据处理的令牌数量来对端到端延迟进行归一化。您能提供更多细节吗？ego6inou3#
哦，抱歉，这些是完全独立的，应该分成两个要点。