Models and inference
Model discovery methodology
The model discovery workflow connects the canonical Qwen3.5-9B and Qwen3.8-27B catalog records to their prepared Q6_K and Q5_K_M Cloud configurations. It explains how to compare task scope and missing evidence without borrowing a publisher benchmark or fictional sample as proof of SAVRN runtime performance.
SAVRN Cloud · Coming soon · Public preview · Browser-local simulation · No live compute or payments
Begin with the base model record
Use the canonical Qwen3.5-9B Model Hub entry and Qwen3.8-27B Model Hub entry to inspect model identity and supporting discovery evidence. A catalog description does not establish available capacity, service pricing or suitability for a university project. Preserve the source and date of a publisher claim rather than presenting it as a SAVRN measurement.
The prepared Cloud configurations add a more specific artifact choice: Q6_K for the utility candidate and Q5_K_M for the coding candidate. Quantization is part of the configuration under consideration. The Cloud profile should not imply that the base model's published benchmark results were reproduced on that artifact.
Compare the decision, not an invented ranking
Open Compare models. Review the intended workload, artifact precision, proposed limits and current qualification gaps side by side. Both candidates propose 8,192 total context tokens and 1,024 output tokens for a future pilot. There are no qualified quality scores, speed results or customer prices to rank here. Missing measurements remain unknown.
Use the utility candidate to prepare an evidence-review or extraction task, and the coding candidate to prepare research-code assistance. These starter associations guide evaluation design; they do not prove that one candidate is more accurate or faster.
Read demonstration profiles separately
Research 8B, Code 14B, Reasoning 32B and Embedding 1B are fictional profiles used to demonstrate workflow controls. They are not aliases for the prepared Qwen configurations. A candidate-prepared playground request records the intended candidate while a fictional fixture supplies the browser sample. Selecting either kind of profile does not download model weights.
What turns a candidate into a service
Connected execution remains Coming soon. Qualification must bind the exact artifact to its serving runtime, hardware, supported features and accepted limits. It also needs a suitable taskset, failure analysis and an independently approved capacity allocation. License eligibility, access and pricing are separate decisions. Follow model and deployment concepts before interpreting a prepared profile as a runnable offer.
Build toward the work that matters.
Tell SAVRN what your institution needs to run, who reviews the results and where its data must stay. That workload defines the next service to qualify.
Discuss an AI project