Specializing models is an engineering discipline, not a vibe: dataset preparation, LoRA and QLoRA training on our own pair, quantization trade-offs measured on real hardware, and the evaluation harness that decides whether the tune ships. Statuses are honest; IN PROGRESS is a valid public state.
EVALUATION IS THE GATESpecializing models is an engineering discipline: dataset preparation, LoRA and QLoRA training, quantization trade-offs, and the evaluation harness that decides whether the tune ships. Statuses are honest; IN PROGRESS is a valid public state.
The register carries the Lab's own fine-tune program first, then the serving economics and the evaluation method behind it.
The Lab's own fine-tune program: LoRA training on the second Spark with the first as serving judge, on an Apache-2.0 base model. The program is at the dataset stage, and that status is stated plainly; the training report publishes when it lands, with the evaluation loop, not just the result.
The tune is only as good as the pairs it learns from. Curation, cleaning, deduplication, and format discipline come first; the Lab's own Qwen program has sat honestly at this stage rather than rushing a weak dataset into a training run.
LoRA and QLoRA runs execute on Spark 2 while Spark 1 keeps serving. The idle-node pattern means a training program never takes production down, on our pair or on a client's.
The harness exists before the first epoch: held-out sets, task metrics, calibration checks, and a judge model on the serving node. Evals are the new tests; a tune that fails the harness goes back to the dataset, not to production.
The shipped artifact is the quantized, measured one: 4-bit where the accuracy cost is paid knowingly, with throughput and memory numbers recorded on the hardware that will run it.
Fine-tune when the behavior itself must change: tone, format discipline, domain reasoning, or tool-calling patterns that prompting cannot hold stable. Retrieve when the gap is knowledge that changes faster than you can train. Prompt when a frontier model already does the job and the volume is low. The Lab publishes its decision framework and applies it before any training run.
The Lab's own program is a domain LoRA on Qwen3.8-27B, an Apache-2.0 base, trained on the second Spark with the first as serving judge. It is at the dataset preparation stage, and that status is stated plainly; the training report publishes when it lands.
Measured on GB10 hardware: memory drops to roughly a quarter and throughput rises, while accuracy loss depends on task and format. The Lab's engineering notes show the arithmetic, including when KV-cache economics dominate the serving bill and where small specialized models beat one large generalist.
Calibration before capability: the tune passes an evaluation harness built before training starts, on held-out sets that represent the production distribution. A model that cannot state its own uncertainty does not ship, however good its average looks.
Yes. The same pipeline the Lab runs on its own pair (dataset preparation, QLoRA training, evaluation, quantized serving) deploys on client hardware, including air-gapped environments. Data never has to leave your building.
We don't pitch slide decks. We show you what we've already built in your domain, then engineer what your mission requires.
