feat(server): integrate Ling 3 Flash on DGX Spark

[davide221]

Summary

• add native bailingmoe3 loading and serving for Ling 3.0 Flash
• implement Ling's MLA and KDA graph blocks in the dedicated src/bailingmoe3 module
• reuse the existing hybrid runtime through small, architecture-guarded dispatch points
• support Ling's grouped expert routing, shared experts, latent KV layout, and recurrent state
• add the official Ling chat format, request-controlled thinking, tool rendering, model-card detection, and README model-table entry
• keep Ling's asymmetric V cache isolated from the existing Qwen path
• suppress undeclared Bailing tool protocol blocks instead of leaking them into assistant content
• explicitly gate unsupported split, drafting, paged-cache, and tree paths for this first integration
• add focused coverage for chat rendering, grouped routing, cache layout, model-card detection, tool-protocol handling, and capability gates

Scope

This PR is intentionally limited to the native model integration:

• 1,508 additions, 104 deletions, 22 files
• no benchmark harnesses, profiling infrastructure, speculative policy, or experimental kernel changes

The previously validated performance work is preserved separately on codex/ling3-flash-performance for focused follow-up review.

Validation

Validated from commit e49abac on an NVIDIA DGX Spark / GB10 (sm_121):

• full CUDA CMake build completed successfully
• all 453 test_server_unit cases passed
• all 8 focused Ling, cache-layout, and capability-gate tests passed
• git diff --check passed

Model

• architecture: bailingmoe3 (the GGUF architecture identifier)
• model: inclusionAI Ling 3.0 Flash, 124B MoE
• intended first target: NVIDIA DGX Spark

[davide221]

main reconciliation note

A dry-run merge against current main conflicts in nine files. One conflict is semantic and must be tested, not resolved mechanically: GGML_OP_SSM_CONV mode 2 is now the generic DFlash fused-step path on main, while this tested Ling branch uses mode 2 for direct persistent-state AR.

The likely integration is to reserve a new mode for Ling direct-state AR, update the CUDA support/fusion dispatch consistently, then rebuild on GB10 and rerun both generic Qwen DSpark and Ling AR/DSpark exact-output regressions. I did not push an unbenchmarked remap into this draft. The current branch remains the byte-identical source used for its DGX Spark build and reported measurements.

[cubic-dev-ai]

All reported issues were addressed

_{You’re at about 90% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.}

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 5 files (changes from recent commits).

_{You’re at about 94% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.}

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="server/src/bailingmoe3/bailingmoe3_graph.cpp">

<violation number="1" location="server/src/bailingmoe3/bailingmoe3_graph.cpp:57">
P0: The Ling backend never executes either builder in this file. Route `BailingMoe3Backend` through these builders (and the corresponding Ling FFN/cache graph) before shipping, otherwise `bailingmoe3` models use the incompatible Qwen3.5 graph instead of the native implementation.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P0: The Ling backend never executes either builder in this file. Route BailingMoe3Backend through these builders (and the corresponding Ling FFN/cache graph) before shipping, otherwise bailingmoe3 models use the incompatible Qwen3.5 graph instead of the native implementation.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At server/src/bailingmoe3/bailingmoe3_graph.cpp, line 57:

<comment>The Ling backend never executes either builder in this file. Route `BailingMoe3Backend` through these builders (and the corresponding Ling FFN/cache graph) before shipping, otherwise `bailingmoe3` models use the incompatible Qwen3.5 graph instead of the native implementation.</comment>

<file context>
@@ -0,0 +1,249 @@
+// absorption through attn_k_b turns the 128 non-RoPE Q dimensions into the
+// same latent space, and attn_v_b expands the attention result back to 128
+// value dimensions per head.
+ggml_tensor * build_bailingmoe3_mla_block(
+    ggml_context * ctx,
+    ggml_cgraph * gf,
</file context>

[davide221]

Addressed all four valid Cubic findings in the current head (e49abac): the README row now remains inside the model table, request-level thinking controls override an opposite system directive, asymmetric V-cache allocation is limited to Bailing/Ling, and undeclared Bailing tool blocks are suppressed end-to-end. Added regressions for the latter three paths.

The reported P0 about the Ling builders is a false positive: bailingmoe3_loader.cpp sets is_bailingmoe3, and the inherited Qwen runtime dispatches that flag to build_bailingmoe3_mla_block / build_bailingmoe3_kda_block in qwen35_target_graph.cpp.

The exact head builds on DGX Spark (sm_121); all 453 server tests and all 8 focused tests pass.