feat(qwen3-8b): first Ascend variant -- Qwen3-8B on one 910B card

[zhanghaohit]

What

Adds qwen3-8b, the catalog's first non-NVIDIA variant: Qwen3-8B in bf16 on
a single Ascend 910B card, served by vLLM's Ascend backend.

requires:
  gpus: 1
  topology: single-node
  vendor: ascend
image:
  repository: quay.io/ascend/vllm-ascend
  tag: v0.23.0.post1
  digest: sha256:ffe9306186781ddb80812eda574134e601ee8499693ea36e4a97173111ddf7e7

Why this model

One card, one pod, no tensor-parallel topology to get wrong — the cheapest way
to prove a non-NVIDIA node can serve at all.

The entry is deliberately minimal

extraArgs is two flags, and both can be justified:

--enable-prompt-tokens-details    without it cached_tokens is always null
--gpu-memory-utilization=0.9      every variant in this catalog states it

No --reasoning-parser or --tool-call-parser. Upstream main registers a
qwen3 parser serving both roles, but this image is vllm-ascend
v0.23.0.post1, and v0.23's vllm/parser/ holds only abstract_parser.py and
parser_manager.py — the per-model parsers and their registered names arrived
in a later refactor. A parser name that does not exist in the running version
fails at startup, so neither is worth asserting before someone has run this
image. They can be added in a follow-up version file.

tags is therefore chat only. The model can reason and call tools; this
variant configures no parser for either, so the entry does not advertise them.

Why no Kubernetes resource strings in values

requires.vendor is what decides the extended resource, and the README is
explicit that the mapping (ascend → huawei.com/Ascend910) lives in swiss.

I checked that the vllm chart does not block this: it hardcodes
nvidia.com/gpu when rendering model.gpus, but with model.gpus: "" it emits
no GPU resource at all, leaving the accelerator resource to the caller.
Confirmed by rendering — nvidia.com/gpu: False. No chart change needed.

Why the digest is an index, not a platform manifest

Atlas 800T A2 is aarch64; an amd64-only image would not run there at all.
v0.23.0.post1 is multi-arch (linux/amd64 + linux/arm64), and pinning the
index digest keeps a pull resolving to the right architecture. It is also the
newest non-rc tag — the alternatives upstream are v0.26.0rc*, v0.27.1rc1
and nightlies.

lifecycle uses vllm's keys

shutdownTimeout: 120, not sglang's forceShutdown — caught by the helm
validator, see the thread below. terminationGracePeriodSeconds is 1200:
drainSeconds 600 plus the shutdown ceiling plus room.

What is verified, and what is not

Verified: the image exists, is multi-arch with arm64, and its digest is
pinned; Qwen/Qwen3-8B exists on HF; the values render against the vllm chart
at >=0.7.6 with the expected args, grace period and preStop; schema,
naming/layout and index build all pass.

Not verified: nothing in here has been started on a 910B card. The Ascend
machine that proved a pod can get a card (ascend-docker-runtime mounts
/dev/davinci* without the container declaring them, and vllm-ascend served
Qwen3-8B on one card over a ClusterIP Service) was removed from the test cluster
on 2026-09-30 and is no longer reachable, so this could not be re-checked.

Merging makes the model visible and schedulable. The first real deploy should be
treated as the measurement — and is also when the parser flags can be settled.

[huskcass]

helm values render check ⚠️

Validated every variant's values: with helm template against the sglang chart — both the pinned version and the latest published (>=0.7.6). Some variants failed to render — see details below. (Checked with the deploy-time modelRoute.nginx.outputConfigMap set, which swiss injects since the catalog schema rejects per-deploy values by design.)

• vllm-tp1-910b @ chart >=0.7.6: `Error: values don't meet the specifications of the schema(s) in the following chart(s):
  vllm:
• at '/lifecycle': additional properties 'forceShutdown' not allowed`
• vllm-tp1-910b @ chart 0.7.6: `Error: values don't meet the specifications of the schema(s) in the following chart(s):
  vllm:
• at '/lifecycle': additional properties 'forceShutdown' not allowed`

chart.version already uses a semver range — no pinning to flag. 👍

[zhanghaohit]

Good catch — the failure is real and I should have caught it myself.

Root cause. I adapted the values from qwen3.8-27b-fp8, which is an sglang variant, onto a vllm chart. The two charts have different lifecycle schemas:

key	vllm	sglang
forceShutdown	✗	✓
shutdownTimeout	✓	✗
preStop / preStopKill / shutdownReserveSeconds	✓	✓

Fix (8f68ad0): forceShutdown: true → shutdownTimeout: 120, which is how vllm expresses the same intent — vLLM aborts in-flight requests on SIGTERM at 0 and drains them under that ceiling above 0. Modelled on kimi-k3/vllm-tp8-b300, the only other vllm variant here that configures a lifecycle. Also added the preStop.enabled / endpointSyncSeconds keys it uses.

Along the way terminationGracePeriodSeconds went 3600 → 1200: 3600 came in with the TP8 variant I copied and is far more than drainSeconds: 600 plus the shutdown ceiling needs on a single-card 8B.

Verified the way you did, against the real chart rather than the catalog schema:

terminationGracePeriodSeconds: 1200
preStop: yes
--shutdown-timeout: 120
resources: ephemeral-storage only, no nvidia.com/gpu

Putting forceShutdown back reproduces the original error, so the check discriminates rather than just passing.

The gap in my own review: I validated against the catalog schema, which types values as "any object" and therefore cannot catch a key the chart rejects. I did render the chart earlier — but with a hand-written probe file, not with the variant's final values. Rendering the actual values against the actual chart is the only check that would have caught this, and it is exactly what this bot does.

The flags caveat in the PR description still stands: the extraArgs are derived, not measured on 910B hardware.

[huskcass]

helm values render check ✅

Validated every variant's values: with helm template against the sglang chart — both the pinned version and the latest published (>=0.7.6). All variants render cleanly. (Checked with the deploy-time modelRoute.nginx.outputConfigMap set, which swiss injects since the catalog schema rejects per-deploy values by design.)

chart.version already uses a semver range — no pinning to flag. 👍

[zhanghaohit]

@huskcass review

[huskcass]

Reviewed the fixed head (e4508fd) against the actual chart sources, not just the render check.

Lifecycle fix is correct. Verified against each chart's own values.schema.json:

• vllm chart lifecycle accepts exactly preStop, shutdownTimeout, shutdownReserveSeconds, preStopKill — no forceShutdown.
• sglang chart lifecycle accepts preStop, shutdownReserveSeconds, forceShutdown, preStopKill — no shutdownTimeout.

So the two charts genuinely have different lifecycle vocabularies, and shutdownTimeout: 120 is the right vllm expression of the same intent. The block matches kimi-k3's vllm-tp8-b300 shape; drain 600 vs 900 scaled to a single 8B card is sensible, and preStopKill: true is an allowed vllm-chart key. terminationGracePeriodSeconds: 1200 comfortably covers drain 600 + shutdown 120.

Rest of the values:

• model.contextLength: '' is a documented chart idiom — the vllm chart renders it as --max-model-len, and empty means "let vLLM use the model's own". Fine for Qwen3-8B's 32768.
• chart.version: ">=0.7.6" — semver range, nothing to flag.
• image.digest is well-formed (sha256: + 64 hex). Not registry-verified, but no catalog CI verifies digests today, so that's consistent with the current state, not a blocker here.
• The parser call is the right conservative one: a wrong --reasoning-parser name fails the container at startup, so omitting both until someone has actually run this image is correct. tags: [chat] matches the configured capabilities.

Nothing blocking from me. The automated render check (✅ on this head) plus this human pass.