🚀 功能、动机和宣传
vLLM 目前提供了一些关于模型性能和负载的指标，这些指标非常有用。今天有一些指标缺失，如果添加这些指标，将使任何编排器(如 Kubernetes)更容易为自动扩展 vLLM 服务器或在多个 vLLM 服务器之间更有效地分配负载提供更好的支持。我们在 Kubernetes Serving WG 中有一个提案，旨在向流行的模型服务器添加这些额外的指标。我们也希望将这些指标添加到 vLLM 中。
有关我们想要添加到 vLLM 的指标的 Google doc 链接，其中包含我们想要添加的指标集以及添加它们的背后原因 - https://docs.google.com/document/d/1SpSp1E6moa4HSrJnS4x3NpLuj88sMXr2tbofKlzTZpk/edit?usp=sharing&resourcekey=0-ob5dR-AJxLQ5SvPlA4rdsg 。(如果您无法查看，请请求访问权限)
列出我们确定要包含在 vLLM 中的指标：
**| 指标名称 | 类型 | 单位 |
| model_load_time | 计数器 | 秒 | |
| time_per_output_token_per_batch_size | 直方图 | 毫秒 | |
| request_wait_time(总时间 - 花费在推理上的时间) | 直方图 | 毫秒 | |
| request_queue_time | 直方图 | 毫秒 | |
| max_token_capacity | 计数器 | Tokens | |
| time_per_prefill_token | 直方图 | 毫秒 | |
| total_tokens_in_current_batch | Jmeter | Tokens | |
| estimated_max_prefill_tokens_per_second | Jmeter | Tokens | |
| estimated_max_batch_before_compute_saturation | Jmeter | Tokens | |
| request_input_length | 直方图 | Tokens | |
| request_output_length | 直方图 | Tokens | |
| request_with_evicted_tokens | 计数器 | Count | |
| total_evicted_tokens | 计数器 | Tokens | ** |
为了可观察性和高效的编排，最好同时添加这些指标。
其他方案
- 无响应*
其他上下文
cc @WoosukKwon@robertgshaw2-neuralmagic
6条答案
按热度按时间ubbxdtey1#
+1,如果有这些就太棒了！
z4bn682m2#
它们对我来说确实很有用！期待他们的贡献！同时@ywang96提醒大家。
qxsslcnc3#
这太棒了——谢谢@achandrasekar!
请注意，列表中的一些指标(例如，request_input_length, request_output_length)已经由vLLM支持，所以将它们整合到您即将做出的贡献中会很好。我认为我们目前确实缺少一个与队列时间相关的指标，这对于决定何时扩展推理服务非常重要。
um6iljoc4#
@ywang96 这两个实现在一个分支中。将进行优先级排序并帮助合并。
yzckvree5#
@achandrasekar,你介意将这个带到otel语义约定团队会议上讨论吗？我们正在为LLM语义约定工作，这是一个我们现在还没有的领域。
otel语义约定中的一个相关问题：open-telemetry/semantic-conventions#1079
会议信息如下：https://docs.google.com/document/d/1EKIeDgBGXQPGehUigIRLwAUpRGa7-1kXB736EaYuJ2M/edit#heading=h.ylazl6464n0c
beq87vna6#
是的，感谢你提出这个问题。我们在上次LLM语义约定会议上讨论过这个问题。我已经创建了一个问题(open-telemetry/semantic-conventions#1102)和一个初始PR(open-telemetry/semantic-conventions#1103)来创建服务器指标。让我们在那里协作。我们也可以在下一次semconv会议上讨论。