[Bug] Derive cache service identity from an explicit flag, not EnableKVSync

[hamacekh]

Pull Request Description

Adds an explicit IsGateway field to cache.InitOptions, sets it in cmd/plugins, and extracts the component classification in InitWithOptions into a unit-testable serviceIdentity(). Behaviour for metadata-service and controller-manager is unchanged.

Why. InitWithOptions inferred the calling component from opts.EnableKVSync — effectively assuming the gateway always has prefix-cache KV event sync enabled. It usually does not: cmd/plugins passes EnableKVSync: kvSyncEnabled && remoteTokenizerEnabled, and both default to false. A default gateway was therefore classified "metadata", and that branch force-disables enableGPUOptimizerTracing. So AIBRIX_GPU_OPTIMIZER_TRACING_FLAG=true was silently discarded, initTraceCache never ran, no aibrix:<model>_request_trace_<ts> keys were written, and the GPU optimizer — with no workload signal — reported "scaled to minimum" indefinitely.

Two side effects worth flagging. EnableKVSync: true alone no longer implies "gateway" — harmless, as cmd/plugins is the only caller in the tree that sets it and it now sets IsGateway: true too. And this restores enableModelGPUProfileCaching on the gateway, which defaults to true and was disabled by the same block.

Testing. TestServiceIdentity covers all five classification cases. make test green on golang:1.22 (go fmt, go vet, full unit suite).

Runtime verification. On a live cluster the gateway now logs service="gateway" with enableGPUOptimizerTracing=true, the trace ticker starts, and aibrix:<model>_request_trace_<ts> keys appear in Redis with real bucket data that the GPU optimizer consumes. That build was v0.7.0 plus this patch while the PR targets main; the patched region is identical between them (cmd/plugins/main.go is the same blob, the InitOptions / InitWithOptions bodies unchanged), so the behaviour transfers, though I have not run a main build on a cluster.

Related Issues

Resolves: #1713, #1014

Important: Before submitting, please complete the description above and review the checklist below.

---

Contribution Guidelines (Expand for Details)

We appreciate your contribution to aibrix! To ensure a smooth review process and maintain high code quality, please adhere to the following guidelines:

Pull Request Title Format

Your PR title should start with one of these prefixes to indicate the nature of the change:

• [Bug]: Corrections to existing functionality
• [CI]: Changes to build process or CI pipeline
• [Docs]: Updates or additions to documentation
• [API]: Modifications to aibrix's API or interface
• [CLI]: Changes or additions to the Command Line Interface
• [Misc]: For changes not covered above (use sparingly)

Note: For changes spanning multiple categories, use multiple prefixes in order of importance.

Submission Checklist

• PR title includes appropriate prefix(es)
• Changes are clearly explained in the PR description
• New and existing tests pass successfully
• Code adheres to project style and best practices
• Documentation updated to reflect changes (if applicable)
• Thorough testing completed, no regressions introduced

By submitting this PR, you confirm that you've read these guidelines and your changes align with the project's contribution standards.

[gemini-code-assist]

Code Review

This pull request introduces an IsGateway option to InitOptions to explicitly identify the gateway-plugins service. It refactors the service identification logic in InitWithOptions into a dedicated helper function serviceIdentity and adds comprehensive unit tests to verify its behavior. There are no review comments, so no additional feedback is provided.

[hamacekh]

Build image (gateway-plugins) failure is a transient module fetch, not a compile error — could a maintainer re-run the job?

The job log shows go build failing while fetching from the module proxy, not while compiling:

#19 125.1 api/model/v1alpha1/groupversion_info.go:24:2: sigs.k8s.io/controller-runtime@v0.19.2:
  read "https://proxy.golang.org/sigs.k8s.io/controller-runtime/@v/v0.19.2.mod":
  stream error: stream ID 125; INTERNAL_ERROR; received from peer

All six error lines are the same single failed read, reported once per importing file.

This PR touches three files (pkg/cache/cache_init.go, cmd/plugins/main.go, cache_init_test.go), none of them zmq-gated, and test / lint / verify all passed. I also reproduced the exact build locally — both go build -trimpath -tags=zmq -ldflags="-s -w -linkmode=external ..." and a full docker build -f build/container/Dockerfile.gateway succeed.

I don't have permission to re-run the job — could a maintainer trigger it?

[hamacekh]

I have rebased it in hope it might trigger the job without approval this time, but it didn't. Will need maintainer to do that for me.