[New Model]: Add Valen-Preview-0923 reference serving — community help wanted

[hsliuustc0106]

Model and motivation

• Reference implementation: Liuziyu77/Valen
• Released checkpoint: Valen-Team/Valen-Preview-0923
• Execution contract: Valen architecture

Valen evaluates text, images and video against supplied candidates without autoregressive answer generation. Its Qwen3.5 backbone overlaps with System1-Omni's existing backend work, while its learned decision head and multimodal processing require model-specific integration.

The released 2B preview is Sokoban-trained and requires both the Valen checkpoint and its pinned Qwen3.5-2B base. The separate General results are not evaluation results for this preview.

First integration slice

Serve the reference implementation behind the existing Rust frontend. Target text and single-image choice requests first; document unsupported question types and media explicitly. Broader noul, score, video and native acceleration can follow as separate slices after the reference path is usable.

Done when

• Pin the reference code, base model and adapter/checkpoint revisions and record their respective licenses.
• Document input construction, candidate ordering, decision-head readout, probability normalization, confidence and usage semantics.
• Implement model-owned loading, preprocessing, execution and response construction under src/models/valen/.
• Preserve all trained components required by the preview: decision head, language LoRA, visual merger and trained visual blocks. Do not load only the head.
• Compare real text and image outputs with the pinned reference, using declared probability tolerances and decision-agreement criteria.
• Validate a real first inference after readiness and the Rust-frontend request path; report the tested hardware and any checks that could not run.
• Add setup, launch and example requests under recipe/valen/, tests under root tests/, and update the support matrix, docs navigation and [Tracking]: Model support status #83.

Follow CONTRIBUTING.md. Coordinate response-field decisions with #61. Native vision work for Cua-S1 (#56, #59, #63, #64) is related infrastructure, not evidence that Valen already runs natively.

Community help wanted

Help with checkpoint/reference investigation, the worker adapter, CPU contract tests, GPU parity checks, or an independently reproduced recipe. Contributors familiar with Valen or Qwen3.5 vision are especially welcome.

Please comment with the slice you would like to take and any relevant environment. The first goal is a faithful, runnable reference service; performance claims come with separate measured evidence.

[MrDongsls]

I’d like to take this issue. Will coordinate with #61 and update #83 during the integration.

[hsliuustc0106]

Thanks @MrDongsls, please go ahead—you’re already assigned.

The reference worker with text and single-image choice is a good first slice. Start by pinning the upstream code, base model and preview checkpoint, then bring up the worker and compare its outputs with the reference through the Rust frontend. Please keep all trained visual/LoRA components when loading the preview.

Coordinate confidence/usage semantics with #61, and update #83 with the implementation and validation status as the work progresses. A small draft PR for the worker and recipe is welcome; native acceleration can follow once this path is reproducible.

[hsliuustc0106]

@MrDongsls, one additional requirement: please follow the updated architecture and integration contracts and contributing guide.

Keep the Valen integration split into clear stages:

• Model-specific preprocessing prepares inputs and response context; postprocessing handles normalization, confidence, usage and response reconstruction.
• The model executor owns the forward pass, learned head, weights and device state.
• Shared admission/scheduling belongs in the runtime; reusable CUDA operations belong under src/backends/. The frontend owns HTTP transport and response delivery.

The Python reference worker is suitable for the first slice. Preserve these processor/executor boundaries so native follow-ups can use Rust host orchestration and the shared runtime. Reuse the current worker interface while the remaining shared processing and batching layers are being developed.

Please include the prepared-input/output contract and ownership boundaries in the draft PR, and keep tests under the root tests/ tree.

[MrDongsls]

@MrDongsls, one additional requirement: please follow the updated architecture and integration contracts and contributing guide.

Keep the Valen integration split into clear stages:

• Model-specific preprocessing prepares inputs and response context; postprocessing handles normalization, confidence, usage and response reconstruction.
• The model executor owns the forward pass, learned head, weights and device state.
• Shared admission/scheduling belongs in the runtime; reusable CUDA operations belong under src/backends/. The frontend owns HTTP transport and response delivery.

The Python reference worker is suitable for the first slice. Preserve these processor/executor boundaries so native follow-ups can use Rust host orchestration and the shared runtime. Reuse the current worker interface while the remaining shared processing and batching layers are being developed.

Please include the prepared-input/output contract and ownership boundaries in the draft PR, and keep tests under the root tests/ tree.

Thanks for the guidance. I’ll proceed in line with the project’s conventions and the direction discussed here.