KV-cache dispatch doesn't recognize CudaQwen3HybridDenseTransformerModel, causing host-RAM OOM (paged + non-paged) #274

Summary

Found while running OllamaBenchmarks against Bonsai-27B (Architecture.Qwen3HybridDense, CUDA). ServerStartup's KV-cache-backend dispatch only pattern-matches model is CudaTransformerModel / is HybridTransformerModel. CudaQwen3HybridDenseTransformerModel matches neither, so it silently falls through to the generic CPU-hosted path in both configurations, with two distinct OOM failure modes:

1. Paged KV-cache (default): startup OOM

Falls through to PagedKvCacheFactory, which pre-allocates a fixed 64K-token host-RAM block pool sized for the model's full per-layer KV geometry regardless of the model actually being GPU-resident. For a 27B hybrid model this is tens of GB — an unhandled OutOfMemoryException at server startup on a 36GB-RAM host. Worked around with --no-paged (the model appears to manage KV state internally, ignoring the passed-in kvFactory for this architecture).

2. Non-paged (--no-paged): per-request OOM under sustained load

Falls through to SimpleKvCache instead, which does not itself crash at startup, but its per-request allocation is evidently sized against something far larger than the actual prompt+max_tokens need for this architecture. Under a sustained request stream (an 40-task tool-use benchmark), 25/40 requests failed with:

System.OutOfMemoryException at DotLLM.Engine.KvCache.SimpleKvCache..ctor
  -> TextGenerator.AllocateKvCache -> TextGenerator.ResolveKvCache

starting partway through the run and persisting for the rest of the process's lifetime (did not self-recover; required a full server restart). Free host RAM returned to baseline (~14.85GB) immediately after the run ended, ruling out a simple monotonic per-request leak — more consistent with each request computing an oversized KV-cache allocation for this large/long-context hybrid architecture specifically.

Suggested fix direction

• Extend the CUDA hybrid-dense (and MoE-hybrid) architecture classes to be recognized by ServerStartup's KV-cache dispatch (or have them report their actual KV-cache ownership/requirements so the dispatcher doesn't need a type-based special case per architecture).
• Investigate SimpleKvCache's per-request sizing logic for the Qwen3HybridDense/GDN case specifically — likely computing against the architecture's full context length or a similarly oversized dimension rather than the actual GDN + full-attention KV footprint needed.

References

• Found during the Bonsai-27B OllamaBenchmarks round; see commits f1f4830 and 84eec89 on branch dotllm-bonsai27b-benchmark in the OllamaBenchmarks repo for full repro detail and stack traces.