🚀 功能、动机和推销
动机
在涉及多个组件的生产系统中，使用通用请求ID/UUID进行日志记录是一种常见做法。我的团队希望使用上游的UUID来追踪vLLM的OpenAI兼容Web服务器生成的日志，但似乎这并不受支持。目前，vLLM为每个请求生成自己的UUID,但它有以下两个问题：1. 它是一个单独的ID,给追踪带来了困难；2. 请求ID并不总是返回给API调用客户端，例如在出现错误的情况下。
解决方案
允许用户通过请求向OpenAI兼容的前端服务器传递额外的参数，以便可以通过记录器传播和记录这些参数。
- 目前，服务器会因为通过请求体传递的额外参数而抛出错误。
- 当前的建议是允许通过请求体传递任何额外的参数，并且与支持的参数不匹配的额外参数只会在记录日志时被记录
- 以下是替代方案
替代方案
- 或者，允许用户通过请求头而不是请求体传递额外的参数
- 或者，允许用户通过单个字段(例如
"extra_args": "{ field1 : val1, field2: val2}")传递所有额外的参数，这样我们就不会破坏在未知请求字段被传递时的当前行为，即抛出错误。
其他上下文
如果这个建议被批准并且细节最终确定下来，我可以开始工作并提交PR!
5条答案
按热度按时间kxkpmulp1#
我认为标题是一个不错的选择，因为它不会破坏OpenAI API的兼容性。你怎么看？@njhill@rkooo567
kjthegm62#
是的，听起来很棒。我们现在没有通过头部传递任何额外的参数，对吗？
umuewwlo3#
我不这么认为，但如果有人纠正我的话就太好了。我尝试在头部传递随机额外参数，但它们没有在日志中输出。我也看不到一个选项来开启或关闭它。
如果我要处理这个问题，我们应该只记录除了授权之外的所有头部信息吗？包括模型名称等？还是只记录那些已经被vLLM定义的头部参数？
slmsl1lt4#
我同意通过header的方式来做这件事，这比在body/payload中更好。
同时感谢ronensc的PR,关于OpenTelemetry的集成：#4687。
8qgya5xd5#
鉴于OpenTelemetry集成已经合并，我是否仍然可以继续处理这个问题？只是检查一下。