Skip to content

[BUG] BenchmarkJob's direct endpoint form cannot run: --api-key and --model-tokenizer are never passed #789

Description

@weetime

What happened?

A BenchmarkJob that points at a plain URL instead of an InferenceService — the
spec.endpoint.endpoint form — cannot run. The controller emits only three flags for that
path, and genai-bench needs two more that are never supplied.

buildArgsFromEndpoint (pkg/controller/v1beta1/benchmark/utils/utils.go:110, main @ 5e4857e):

func buildArgsFromEndpoint(endpoint *v1beta1.Endpoint) map[string]string {
	return map[string]string{
		"--api-backend":    endpoint.APIFormat,
		"--api-model-name": endpoint.ModelName,
		"--api-base":       endpoint.URL,
	}
}

Neither --api-key nor --model-tokenizer is produced. buildBenchmarkCommand
(controller.go:499) only appends those two when the map contains them, so on this path they
are silently dropped. The InferenceService path sets both, which is why the gap is invisible
there.

Both are mandatory on the genai-bench side (verified against genai-bench 0.0.5):

--api-key TEXT           The API key for authentication. Required for OpenAI backend only.
--model-tokenizer TEXT   The tokenizer to use. ... [required]

The resulting Job dies immediately:

Pod STATUS: Error
Error: Invalid value for '--api-key': API key is required for openai backend

Removing that first obstacle only exposes the second — with --model-tokenizer missing,
genai-bench falls through to an interactive prompt, which aborts under a non-TTY container:

[transformers] PyTorch was not found. ...
Model tokenizer: Aborted!

What did you expect to happen?

Either the direct-endpoint form produces a runnable command, or it is rejected at admission
with a clear message, rather than admitting the resource and failing inside the container.

How can we reproduce it (as minimally and precisely as possible)?

apiVersion: ome.io/v1beta1
kind: BenchmarkJob
metadata:
  name: probe-direct-endpoint
spec:
  endpoint:
    endpoint:
      url: "http://<any-openai-compatible-endpoint>:8080"
      apiFormat: openai
      modelName: "<the served model name>"
  task: text-to-text
  trafficScenarios: ["D(50,50)"]
  numConcurrency: [1]
  maxTimePerIteration: 1
  maxRequestsPerIteration: 2
  outputLocation:
    storageUri: "pvc://<pvc>/benchmarks"

The webhook admits it. The generated Job carries:

benchmark --api-backend openai --api-base http://... --api-model-name ...
          --task text-to-text --max-time-per-run 1 --max-requests-per-run 2
          --traffic-scenario D(50,50) --num-concurrency 1
          --experiment-folder-name ... --experiment-base-dir /benchmarks

— no --api-key, no --model-tokenizer — and the pod exits Error as above.

Anything else we need to know?

There is no workaround available from the CRD, which is what makes this a dead end rather
than an inconvenience:

  • The Endpoint struct (pkg/apis/ome/v1beta1/benchmark_job.go) carries only URL,
    APIFormat and ModelName — there is no field for an API key or a tokenizer.
  • PodOverride has Image / Env / EnvFrom / VolumeMounts / Resources / Tolerations /
    NodeSelector / Affinity / Volumes — no Command or Args, so the command line cannot be
    amended.
  • Environment variables do not help either: genai-bench's CLI has no auto_envvar_prefix, so
    GENAI_BENCH_MODEL_TOKENIZER is ignored (verified — the run still stops at the same
    interactive prompt). --api-key likewise has no envvar binding; only --model-api-key binds
    to MODEL_API_KEY.

Scope note, to be accurate about what is verified: that OME never emits these two flags on this
path is read directly from the source above and is version-independent. That the omission is
fatal was verified against genai-bench 0.0.5; I have not re-checked the required-ness of these
flags in the 0.1.x line that config/configmap/benchmarkjob.yaml and the samples point at.

Related: #781 covers a separate defect on the InferenceService path.

I am happy to send a PR if you would like this fixed, though the shape depends on a decision
that is yours to make — the two missing values have to come from somewhere, and adding API
surface to Endpoint is not something I want to presume.

Environment

  • OME version: main @ 5e4857e
  • Kubernetes version: v1.29.15
  • Cloud provider or hardware configuration: bare-metal GPU node
  • OS: Linux
  • Runtime and version: vLLM 0.8.5.post1
  • Model being served: Qwen2.5-0.5B-Instruct
  • Install method: Helm
  • Benchmark container: genai-bench 0.0.5

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions