fix: allow k,v combo values for draft_cache_mode

[dripston]

Problem

draft_cache_mode: 4,3 in config.yml fails to start the server, even though the field's own generated documentation (config_sample.yml) says the k_bits,v_bits combo form is supported — the same form cache_mode already accepts.

Root cause

common/config_models.py:

CACHE_SIZES = Literal["FP16", "Q8", "Q6", "Q4"]
CACHE_TYPE = Union[CACHE_SIZES, constr(pattern=r"^[2-8]\s*,\s*[2-8]$")]

cache_mode is typed Optional[CACHE_TYPE] (accepts both the legacy literals and the "k,v" combo). draft_cache_mode was typed Optional[CACHE_SIZES] — only the legacy literals — so Pydantic validation rejects "4,3" before the value ever reaches DraftModel.create_cache() in backends/exllamav3/model.py, which already parses the combo form via the same create_cache() helper used for the main cache.

Fix

Change draft_cache_mode's annotation from CACHE_SIZES to CACHE_TYPE, matching cache_mode, and update its description to mention the combo form (mirroring cache_mode's existing description).

Testing

• python3 -c "import ast; ast.parse(open('common/config_models.py').read())" — syntax check passes.
• Confirmed config_sample.yml's existing (already-committed) description text for draft_cache_mode already documented the k_bits,v_bits form, and traced backends/exllamav3/model.py's create_cache() to confirm it parses "k,v" generically for both the main and draft cache — so no runtime changes are needed, only the validation type.
• No local exllamav3/CUDA environment available to run the server end-to-end; this is a type-annotation-only change with no behavioral code path changes beyond widening what Pydantic accepts.

Fixes #482

🤖 Generated with Claude Code