docs: clarify Flash Endpoint gpu= single-type vs list placement semantics

[justinwlin]

The Flash SDK's Endpoint(gpu=) accepts a GpuGroup, a GpuType, or a list of either, and the docs previously presented all three (and especially a list) as an ordered fallback of exact GPU models. In practice, a single GpuType is the only form guaranteed to pin workers to a specific card, while a list is treated at the pool/VRAM-tier level: the SDK converts each listed GpuType to its GPU pool when creating the endpoint (excluding unlisted pool members) and does not preserve list order, so workers may run on a different card with equivalent VRAM rather than one of the exact models listed — and no API field reports which GPU a worker was actually placed on. This PR documents that distinction everywhere gpu= semantics are described.

Fixes runpod/flash#366
Internal: CON-1231

What changed

• flash/configuration/gpu-types.mdx
  • Rewrote "GPU selection behavior": single GpuType = exact card (only guaranteed pin); single GpuGroup = any card in the pool; a list = any of the listed options, treated at the pool/VRAM-tier level, advisory placement, order not preserved.
  • Added a Note that no API field reports the placed GPU, so substitution is invisible (config reflects what was requested, not where workers ran); verify inside the worker (e.g. nvidia-smi).
  • Removed misleading ordered-fallback wording/comments from the multi-GpuType and hybrid examples ("Try X first / fall back to Y").
• flash/configuration/parameters.mdx (### gpu reference): same single-vs-list semantics as bullets, plus the no-placed-GPU-field Note; kept existing examples.
• flash/create-endpoints.mdx (GPU vs CPU): clarified the multi-type example and added a sentence on exact-card placement with a link to the behavior section.
• flash/troubleshooting.mdx (GPU availability): dropped the inaccurate "First choice / Fallback / Second fallback" order comments and cross-linked the behavior section.

Wording was checked against the SDK source (GpuGroup.to_gpu_ids_str in core/resources/gpu.py, _sync_input_fields_gpu in core/resources/serverless.py, _normalize_gpu in endpoint.py on runpod/flash @ 26263c7): client side, GpuType values map to pool IDs plus negations for unlisted pool members, and the gpuIds string is normalized so order is not preserved. The placement-guarantee statements are attributed to observed platform behavior (reported in runpod/flash#366: a GpuType list landed on a different equivalent-VRAM card 7/7; a single GpuType pinned the card 7/7).

How verified

• node scripts/validate-tooltips.js — passes (only pre-existing unused-import warnings on unrelated pages).
• node scripts/validate-redirect-sources.js — passes (293 redirects validated).
• Vale is not installed locally; edits follow .claude/style-guide.md (second person, active voice, sentence-case headings) and reuse the <Note>/<Tip> components already used on neighboring Flash pages.

For the reviewer

• Not in scope, but noticed: the pool-composition tables on flash/configuration/gpu-types.mdx (e.g. AMPERE_24, ADA_24 membership) don't match the SDK's POOLS_TO_TYPES mapping (e.g. SDK has ADA_24 = RTX 4090 only, AMPERE_24 = A5000/L4/3090). The tables may reflect the live API rather than the SDK enum — worth confirming separately.
• Server-side placement behavior (list treated as tier-level, no placed-GPU reporting) is documented as observed in A list of GpuTypes in gpu= does not constrain placement; a single GpuType does flash#366; if the platform later honors exact lists or exposes a placed-GPU field, these notes should be revisited.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
runpod-docs	🟢 Ready	View Preview	Aug 25, 2026, 2:44 PM