[Serve][1/N] Add Serve accelerator config schemas

[ryanaoleary]

Description

PR split from #63179 based on this comment: #63179 (review). This PR contains just the new AcceleratorConfig schemas and the plumbing through @serve.deployment, Deployment.options, DeploymentSchema and the serve proto. This PR should be merged first, since the other PR contains these same changes.

Related issues

#57137

Additional information

Optional: Add implementation details, API changes, usage examples, screenshots, etc.

[gemini-code-assist]

Code Review

This pull request introduces AcceleratorConfig and TPUAcceleratorConfig to Ray Serve, enabling structured hardware accelerator specifications for deployments, with an initial focus on TPU support. The changes span configuration models, protobuf definitions, and the deployment API, including validation logic to enforce mutual exclusivity between accelerator_config and gang_scheduling_config. Review feedback highlights an opportunity to improve security and cross-version compatibility by using JSON serialization instead of cloudpickle for the new configuration fields. Additionally, it is recommended to standardize the error messages for mutual exclusivity checks across the API, deployment, and schema modules for better consistency.

[jeffreywang88]

can we add some tests for the followings?

• YAML/CLI integration tests : example
• serve deployment decorator unit tests: example
• .options unit tests: example

[jeffreywang88]

Let's prefer a typed AcceleratorConfig message with a oneof for subtypes rather than bytes.

Suggested change

	bytes accelerator_config = 24;
	AcceleratorConfig accelerator_config = 24;

  message AcceleratorConfig {
    oneof config {
      TPUAcceleratorConfig tpu = 1;
    }
  }

  message TPUAcceleratorConfig {
    string topology            = 1;
    string accelerator_version = 2;
    int32  num_slices          = 3;
    optional int32 chips_per_vm = 4;
    map<string, double> resources_per_bundle = 5;
  }

[jeffreywang88]

we may need to adjust how to encode/decode the proto field in config.py

[ryanaoleary]

done in 14c0807, they're now proto messages and we encode it like serve_pb2.TPUAcceleratorConfig

[ryanaoleary]

can we add some tests for the followings?
YAML/CLI integration tests : example
serve deployment decorator unit tests: example
.options unit tests: example

added coverage for each in 14c0807

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 70bdeae. Configure here.}

[github-actions]

This pull request has been automatically marked as stale because it has not had
any activity for 14 days. It will be closed in another 14 days if no further activity occurs.
Thank you for your contributions.

You can always ask for help on our discussion forum or Ray's public slack channel.

If you'd like to keep this open, just leave any comment, and the stale label will be removed.

[ryanaoleary]

From offline discussion we're favoring implementing ray-project/enhancements#66 so that serve.deployment can consume standard PG APIs rather than abstracting away custom PG reservation logic through the implementation in these PRs.

The AcceleratorConfig logic from these PRs can instead be implemented as a utility that return the bundles, bundle_label-selector, topology_strategy, etc. for a given topology and accelerator_type. Users can then passed the returned values to the serve.deployment1 options.

Going to close these PRs and follow-up on the above.