[serve.llm] deploying gptoss throws an error due to missing disable-log-requests from async engine args

[kouroshHakha]

What happened + What you expected to happen

vllm-project/vllm#21739 has hard deprecated the disable_log_requests parameter without keeping the backward compatibility at this layer. As a result ray serve llm does not work with the latest wheel released with gptoss (vllm 0.10.1). We need to basically upgrade ray serve llm to use enable_log_requests which will be introduced after 0.10.1 is officially released. Then the nightly of ray will work with gpt-oss deployment.

To get around this issue you can comment out this part: https://github.com/ray-project/ray/blob/master/python/ray/llm/_internal/serve/deployments/llm/vllm/vllm_models.py#L100 and build ray from source.

Versions / Dependencies

ray nightly @commit 9fb05f
vllm 0.10.1+gptoss

Reproduction script

from ray import serve
from ray.serve.llm import LLMConfig, build_openai_app

llm_config = LLMConfig(
    model_loading_config=dict(
        model_id="openai/gpt-oss-20b",
    ),
    deployment_config=dict(
        autoscaling_config=dict(
            min_replicas=1, max_replicas=2,
        )
    ),
    # You can customize the engine arguments (e.g. vLLM engine kwargs)
    engine_kwargs=dict(
        tensor_parallel_size=2,
    )
)

app = build_openai_app({"llm_configs": [llm_config]})
serve.run(app, blocking=True)

Issue Severity

Low: It annoys or frustrates me.

[lk-chen]

what's the stacktrace? I thought vllm-project/vllm#21739 from_vllm_config said disable_log_requests will have no effect, but shouldn't break anything hard?

[kouroshHakha]

disable_log_requests does not exist as a parameter to AsyncLLMEngineArgs anymore. the stack trace is about that.

[hmellor]

diisable_log_requests has not been hard deprecated from AsyncEngineArgs, it still exists as a @property which should be settable and gettable

[hmellor]

From looking at the snippets you have linked the issue comes from the fact that Ray constructs the engine_kwargs using the field names of the AsyncEngineArgs dataclass, which is not compatible with the way we deprecate engine args.

[kouroshHakha]

From looking at the snippets you have linked the issue comes from the fact that Ray constructs the engine_kwargs using the field names of the AsyncEngineArgs dataclass, which is not compatible with the way we deprecate engine args.

yep, so my point is that for users who use AsyncEngineArgs directly via the dataclass constructor this way of deprecation does not work. so it would be great if we can consider it going fwd. We can fix the ray side with the upcoming vllm release which I believe is happening today.

[hmellor]

Sorry about the iinconvenience, in future we'll also keep a InitVar around so that __init__ can still accept deprecated fields