feat(k3): Kimi-K3 vLLM plugin vision + DSpark draft support

[sajandhy]

Motivation

Note: This PR is being opened on behalf of others. The implementation is primarily from whx-sjtu / hexwang (xiaowang990929@gmail.com), ganyi (ygan@amd.com), Guanbao Yu (Guanbao.Yu@amd.com), and zejchen (zejchen@amd.com) on branch hexwang/k3_dspark_026_vision; I am submitting a cleaned rebased extraction to the upstream repo from my fork.

Land the remaining Kimi-K3 vLLM OOT work from hexwang/k3_dspark_026_vision onto current main as a clean, single-commit PR:

• Multimodal / vision path for Kimi-K3 in the vLLM plugin
• DSpark draft model registration and auxiliary hidden-state taps for speculative decoding
• MLA / metadata / model-wrapper plumbing needed for mixed KDA batches and draft KV alignment
• Recipe and design/plan docs for the plugin launch and DSpark speculative config

Earlier pieces of that branch already merged via squash PRs (#1752, #1782, #1806, #1876, #1820, etc.). This PR keeps main's later versions of those shared files and overlays only the still-unique delta.

Technical Details

• Register K3DSparkModel → atom.plugin.vllm.models.kimi_k3_dspark:KimiK3DSparkVllm
• Extend plugin kimi_k3.py with segmented KDA forward, aux hidden-state collection, and multimodal outer/inner classes; add kimi_k3 to _PLUGIN_SUPPORTED_MULTIMODAL_MODELS
• Attention / metadata / model-wrapper updates for multi-token draft queries and dtype-aligned draft KV pages
• Update recipes/atom_vllm/Kimi-K3.md (prefix caching + DSpark speculative launch) and add recipes/atom_vllm/KVV.md plus vision design/plan docs
• Expand tests/plugin/test_vllm_kimi_k3.py

Source branch (dirty history, 75 behind / 37 ahead): hexwang/k3_dspark_026_vision. This PR is a rebased extraction of the remaining tip delta.

Test Plan

• black . and ruff check .
• python -m pytest tests/ (non-GPU unit tests, including tests/plugin/test_vllm_kimi_k3.py)
• Confirm no @support_torch_compile decorated model files were modified (native kimi_k3.py untouched)
• vLLM plugin smoke: text-only Kimi-K3 serve per recipes/atom_vllm/Kimi-K3.md
• Multimodal / vision path smoke (when image assets available)
• DSpark speculative decode smoke with Inferact/Kimi-K3-DSpark and num_speculative_tokens=7

Test Result

Pending — draft PR for review of the extracted delta. Draft PRs do not trigger heavy CI.

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

[github-actions]

🏷️ CI Guide

Runs automatically on every eligible PR before approval:

• ✅ Pre Checkin: Black, Ruff, catalog schema validation, non-GPU unit tests

Heavy model tests:

• ✅ Run after the PR is approved and Pre Checkin passes
• ✅ Run immediately when an approval review is submitted
• ✅ Can be requested before approval with labels

Label	Tests
ci:full	Run all heavy PR model tests: native ATOM, vLLM, and SGLang
ci:atom	Run native ATOM model accuracy tests
ci:vllm	Run ATOM vLLM OOT model accuracy tests
ci:sglang	Run ATOM SGLang model accuracy tests

Heavy jobs are skipped when the PR is not approved and no matching ci:* label is present.
Add labels via the sidebar or gh pr edit 1910 --add-label <label>

[valarLip]

why can't plugin follow the same way?

[sajandhy]

Native ATOM can use the default path because DSparkProposer calls write_context_kv immediately after the target forward, while forward_context().attn_metadata still describes the target step — so slot_mapping[:N] is the verified-token slots we need.

In the vLLM plugin, context KV is written from the speculator via precompute_and_store_context_kv(..., slot_mappings=...), not from ATOM's proposer/forward context. vLLM builds those slots from block tables, and they can differ per layer when the draft spans multiple KV cache groups — so the plugin passes slot_mappings explicitly rather than reading a single global attn_metadata.slot_mapping.

Both paths end up in the same write_context_kv → write_context_kv_latent store; only the source of the slot indices differs. During the later draft backbone pass, attn_metadata.slot_mapping would describe the draft block, not the context rows — so we can't rely on forward context for this write in either design.

[sajandhy]

@valarLip, @whx-sjtu, @zejunchen-zejun,
Please complete the review.
Thanks
Satya

[sajandhy]

@zejunchen-zejun,
Please take a look at this PR.
Thank you