fix(sglang): derive enable_eagle from SpeculativeAlgorithm.is_eagle() (covers EAGLE3)

[yifjiang]

Problem

components/src/dynamo/sglang/register.py sets ModelRuntimeConfig.enable_eagle = True from a hand-maintained name set ("EAGLE", "NEXTN"). The KV router uses enable_eagle (lib/llm/src/discovery/watcher.rs) to bigram-align the frontend's prompt-block hashes (window = stride + 1, lib/kv-router/src/protocols.rs) so they match the worker's KV events.

But the worker's radix cache bigram-keys its KV-event hashes iff SpeculativeAlgorithm.is_eagle() (srt/managers/scheduler.py) = {EAGLE, EAGLE3, FROZEN_KV_MTP}. The name set had drifted from that predicate:

• EAGLE3 was missing → an EAGLE3 worker publishes enable_eagle=false → the frontend hashes at plain page_size while the worker emits bigram-keyed hashes → overlap is always 0 → KV-aware routing is cache-blind for EAGLE3 (falls back to load-only).
• "NEXTN" is dead: ServerArgs .upper()s the value and _resolve_speculative_algorithm_alias normalizes NEXTN/EAGLE → EAGLE (or FROZEN_KV_MTP for Gemma4 drafts) before register sees it, so the literal never matches "NEXTN" — and FROZEN_KV_MTP (is_eagle()=true) was also missing.

Fix

Derive enable_eagle from spec_algorithm.is_eagle() — the same predicate the radix cache uses — so the frontend window and the worker's events stay in lockstep by construction; this covers EAGLE3 and FROZEN_KV_MTP and drops the dead literal:

- if server_args.speculative_algorithm in ("EAGLE", "NEXTN"):
+ if _eagle_enabled_for(server_args.speculative_algorithm):   # SpeculativeAlgorithm.from_string(...).is_eagle()
      runtime_config.enable_eagle = True

e2e before/after (public repro)

Stock dynamo + sglang (nvcr.io/nvidia/ai-dynamo/sglang-runtime:1.3.0-dev.1-cuda12, sglang 0.5.12.post1), Qwen/Qwen3-4B + AngelSlim/Qwen3-4B_eagle3 (EAGLE3 draft), single warm node, --router-mode kv --router-kv-events, EAGLE3 spec, a repeated ~930-token prefix (page-size 16 → 58 blocks). Same binary, same models — only register.py differs between phases:

Phase	published enable_eagle	KV-router effective cached blocks on the warm repeat
Before (stock register.py)	false	0.00 — cache-blind every repeat
After (this fix)	true	58.00 — full prefix credited

Before, the router's Formula logged with 0.00 effective cached blocks on every warm request (EAGLE3 worker's bigram events never matched the plain-token frontend hashes). After, the same warm prefix logs with 58.00 effective cached blocks — the worker's events now match, so KV-aware routing sees the cache. (The bug and enable_eagle: false were also reproduced on a separate EAGLE3 deployment; this Qwen3-4B run is the public, reproducible demonstration.)

Testing

• New parametrized unit test test_eagle_enabled_for_speculative_algorithm pins the enabled set to is_eagle(): EAGLE/EAGLE3/FROZEN_KV_MTP → True; DFLASH/NGRAM/STANDALONE/NONE/None → False — guarding against the set drifting again.
• The downstream half is already covered: lib/kv-router/src/protocols.rs::test_compute_block_hash_for_seq_eagle_windows exercises is_eagle = Some(true) → the stride+1 bigram window. So once enable_eagle tracks is_eagle(), EAGLE3/FROZEN_KV_MTP flow through the same validated bigram-window path EAGLE already used.

Scope

Any EAGLE3 (or FROZEN_KV_MTP) model under --router-mode kv with ≥2 workers and worker KV events; single-worker / no-router / no-kv-events unaffected.

[github-actions]

👋 Hi yifjiang! Thank you for contributing to ai-dynamo/dynamo.

Just a reminder: The NVIDIA Test Github Validation CI runs an essential subset of the testing framework to quickly catch errors.Your PR reviewers may elect to test the changes comprehensively before approving your changes.

🚀

[datadog-official]

⚠️ Warnings

🚦 4 Pipeline jobs failed

PR | deploy-operator     

PR | deploy-status-check     

PR | dynamo-runtime / rust-gpu     

View all 4 failed jobs.

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: e4b95f4 | Docs | Give us feedback!}