Cloudflare Clef decisions on native CUDA: /v1/systemone through Clef's joint schema head (Clef-Flash 9B passes) #1360

Summary

Cloudflare's Clef models answer /v1/systemone decisions: one prompt pass over a record, then a small joint schema head scores every option of every question from the final hidden rows. Cloudflare/clef-flash (Apache-2.0) is a full post-trained Qwen3.5-9B with that head. The native server has /v1/systemone for its own decision paths, but not Clef's head.

This proposes --clef DIR: the server encodes the record as Cloudflare's encode_record does, takes the engine's final rows for the prompt (a new hidden call on the lane host, implemented by the Qwen3.5 CUDA family), and runs the head on the host. It is separate from #1191's JointHead (a different, trained side-head on the 27B Metal engine), but touches the same systemone.zig and cli.zig.

Measured on one DGX Spark (GB10, 128 GB), Cloudflare/clef-flash in bf16

• Reference: Cloudflare's own load_release_model + joint_schema_model.py (transformers 5.10.2, bf16) on 60 records / 557 questions (32 Decision Index rows + 28 synthetic, 245 to 16,384 tokens).
• Native vs that reference: mean KL 5.7e-5 (max 2.4e-3), top choice 99.64%; by length: ≤1K 7.3e-5 / 95.5% (1 of 22), 1–4K 100%, 4–10K 99.6%, >10K 100%.
• Concurrency: 4 concurrent requests return exactly the probabilities of one at a time (60/60 records); bench_concurrent --alone --serial 0 unequal at 1 and 4 streams.
• Latency (one request at a time, prompt cache off), p50 / p95: ≤1K 0.35 / 0.60 s, 1–4K 1.22 / 2.04 s, 4–10K 4.29 / 5.49 s, >10K 8.80 / 9.67 s. About 6 s of a 16K record is the bf16 prompt pass (~2,660 tok/s), the rest the host head.

The checkpoint loads as is once its config.json declares "quantization_config": {"quant_method": "compressed-tensors"}: there are no packed or scaled weights, so every projection is read as bf16. Native loading of plain bf16 Qwen3.5 checkpoints is #1137's subject, so this does not touch the loader.

The 27B Cloudflare/clef is not served this way yet: its release is a merged checkpoint, and folding the adapter into the 4-bit weights we serve loses too much (KL 0.016, 94.6% top choice against the same gate). That needs the adapter applied at runtime, as a follow-up.

A PR follows with the head, the endpoint and the receipts.