[Core]acceleratorclass cheapest selection policy logic update

[pallasathena92]

What this PR does

• Fix cheapest accelerator selection to compare costs within the same unit group instead of mixing different pricing types (e.g., "$/hour" vs "$/million-tokens")

• Costs are now compared in priority order: hourly (spot + on-demand) → per-million-tokens → tier

• Compare candidates in unit groups, not individual cost types:

  • Hourly group (SpotPerHour + PerHour): For each candidate, use SpotPerHour if available, else PerHour. Compare all candidates that have either. Pick cheapest.
    • Key insight: SpotPerHour and PerHour are both $/hour, so they CAN be compared directly. Spot is just a discounted hourly rate — if B's PerHour < A's SpotPerHour, B is genuinely cheaper.
  • Token group: If no candidate has hourly pricing, compare by PerMillionTokens. Pick cheapest.
  • Tier fallback: If no numeric cost, compare tier strings (low=1, medium=2, high=3). Pick lowest.

Why we need it

The previous selectCheapest used getCandidateCost to extract a single cost per candidate with a fixed priority (spot > on-demand > token > tier), then compared all candidates against each other. This caused two issues:

• Cross-unit comparison: A candidate's "$/hour" could be compared against another's "$/million-tokens" — different units that produce meaningless results.
• Unfair candidate exclusion: If candidate A had SpotPerHour and candidate B only had PerHour, the old per-candidate priority meant they were compared on different cost types (spot vs on-demand) rather than being recognized as the same unit ($/hour).

Fixes #518

How to test

Checklist

• Tests added/updated (if applicable)
• Docs updated (if applicable)
• make test passes locally

[gemini-code-assist]

Code Review

This pull request refactors the selectCheapest logic to group and prioritize accelerator costs by type (hourly, token-based, and tier) rather than using a single global priority. It also cleans up associated helper functions and tests. A significant concern was raised regarding the removal of documentation for empty AcceleratorClasses lists; there appears to be a logic discrepancy where some parts of the codebase treat an empty list as 'supporting all accelerators' while others treat it as 'supporting none'. This inconsistency should be resolved to ensure predictable behavior.

[pallasathena92]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the selectCheapest logic to prioritize cost types in groups (hourly, token, and tier) and updates SupportsAcceleratorClass to return false when requirements are undefined. It also modifies candidatesFromNames to preserve the order of names during deduplication. Feedback suggests refactoring the selectCheapest loop into a single pass to improve efficiency and code structure.

[gemini-code-assist]

The current implementation iterates over the withCost slice three times, once for each cost group (hourly, token, tier). This is slightly inefficient and leads to some code repetition.

Consider refactoring this to first categorize candidates into their respective cost groups in a single pass, and then find the cheapest within each group according to priority. This would improve efficiency by reducing passes over the data and could make the logic more modular.

For example:

// 1. Single pass to group candidates
hourlyCandidates := []v1beta1.AcceleratorClass{}
tokenCandidates := []v1beta1.AcceleratorClass{}
tierCandidates := []v1beta1.AcceleratorClass{}
for _, c := range withCost {
    // categorize and append to appropriate list based on cost type
}

// 2. Process groups in order of priority
if len(hourlyCandidates) > 0 {
    // find and return cheapest from hourlyCandidates
}

if len(tokenCandidates) > 0 {
    // find and return cheapest from tokenCandidates
}

if len(tierCandidates) > 0 {
    // find and return cheapest from tierCandidates
}