gRPC GenerateRequest.max_tokens is required — should be optional with an engine-side default (parity with LLM API)

Summary

In the native gRPC service (TrtllmService, smg_grpc_proto), GenerateRequest.max_tokens is marked REQUIRED. A client that omits it has no way to defer to an engine-chosen default — the field must carry a concrete value.

Why this is a problem

TRT-LLM's gRPC service is the outlier among comparable surfaces for an omitted max_tokens:

• TRT-LLM's own Python LLM API defaults an omitted max_tokens to the model's remaining context (roughly max(1, max_seq_len - prompt_len)).
• vLLM's gRPC service treats an unset max_new_tokens (0) as a server-side default.
• TRT-LLM's gRPC alone requires the field.

OpenAI-style APIs treat max_tokens as optional (omitting it means "generate until EOS / context limit"). A gRPC client forwarding such requests (e.g. a router/gateway) is therefore forced to either reject the request or re-derive the default client-side, which duplicates engine logic and requires the client to independently know max_seq_len.

Proposed fix

Make max_tokens optional in the gRPC GenerateRequest. When unset, apply the same default the Python LLM API uses (fill the remaining context, or the engine's configured default) rather than requiring the caller to supply one.

Environment

Observed in tensorrt-llm/release:1.3.0rc21 via python -m tensorrt_llm.commands.serve <model> --grpc.

Start by tracing GenerateRequest.max_tokens through TrtllmService and smg_grpc_proto, then compare its handling with the Python LLM API and the serve --grpc entry point. Done means an omitted value is accepted and receives the engine-side default while explicitly supplied values continue to work, with coverage for both cases.