Supervised fine-tuning
Train on your own conversations. The model learns only from the assistant’s side of each one.
- Chat-formatted examples
- Loss on the assistant’s turns only
A training run, start to finish.
The console your team works in: a dataset, a base model, a run you can watch, and a model you serve.
Open the consoleRelease gate3 of 3 over the frontier baseline
15:07:14eval at step 3,900: gulf-dialect 0.80, policy 0.93
15:20:14epoch 3 done: gulf-dialect 0.81 +0.19 against baseline
15:20:14run complete, weights written to s3://collections-assist/run-03
Try it. Point along the line, pick an eval, pause the run, change the base model and start another, then deploy it.
Illustrative run, computed in your browserFrom an open model to your model.
Four steps, all of them on the machines you choose. Nothing is sent away to be trained.
Your infrastructure
Choose a base
Pick an open model that suits the task and the hardware you have.
- Open model families, loaded from your own storage
- The engine lists what it serves
- Several base models side by side
Train an adapter
A LoRA adapter learns your terms and your decisions. The base model is left as it is.
- A fraction of the compute of full training
- Many adapters on one base model
- Checkpoints you can resume from
Check it
Sample from any checkpoint against your own test cases before anyone relies on it.
- Sampling from saved weights
- Loss and step figures from every pass
- A console to watch runs and try a model
Serve it
The weights you approved become a private endpoint, in the same place they were trained.
- Training and serving through one API
- Each served model traced to its run
- A personal key for every developer
Built for the people who train models.
Your engineers drive training from Python, through an API compatible with the Tinker SDK. The loop is theirs; the GPUs, the adapters and the serving are the engine’s.
- Each person signs in with their own key
- Forward pass, backward pass and optimiser step are separate calls
- Saved weights are served by the same client
import os
import tinker
from tinker import types
client = tinker.ServiceClient(
base_url="https://engine.your-org.internal",
api_key=os.environ["SHARQ_API_KEY"], # your own key
)
# A LoRA adapter on an open base model the engine serves
models = client.get_server_capabilities().supported_models
training = client.create_lora_training_client(
base_model=models[0].model_name, rank=16,
)
for batch in batches: # your prepared examples
training.forward_backward(batch, "cross_entropy").result()
training.optim_step(types.AdamParams(learning_rate=1e-4)).result()
# The weights you trained become the model you serve
weights = training.save_weights_for_sampler("claims-assistant-v1").result()
assistant = client.create_sampling_client(model_path=weights.path)More than one way to teach a model.
Different problems need different training. The engine does the common ones through the same API.
Reinforcement learning
For work where an answer can be checked automatically, the model is rewarded for getting it right.
- GRPO-style training
- Tasks with a verifiable answer
Distillation
Teach a smaller, cheaper model to behave like a larger one, on the smaller model’s own answers.
- A teacher and a student
- Matched token by token
Custom objectives
Bring your own loss when the standard one does not fit, such as preference training mixed with likelihood.
- Defined in your own code
- On both training backends
Supervised fine-tuning
Train on your own conversations. The model learns only from the assistant’s side of each one.
- Chat-formatted examples
- Loss on the assistant’s turns only
Reinforcement learning
For work where an answer can be checked automatically, the model is rewarded for getting it right.
- GRPO-style training
- Tasks with a verifiable answer
Distillation
Teach a smaller, cheaper model to behave like a larger one, on the smaller model’s own answers.
- A teacher and a student
- Matched token by token
Custom objectives
Bring your own loss when the standard one does not fit, such as preference training mixed with likelihood.
- Defined in your own code
- On both training backends
Runs on your terms.
Keep training next to the data it learns from. One file says which models the engine serves.
Your GPUs
- 1API for training and for serving
- 2training backends, Hugging Face and FSDP
- 0API keys kept in readable form
- 4ways to train, through the same calls
# sharq_config.yaml
supported_models:
- model_name: Qwen/Qwen3-8B
model_path: /data/Qwen3-8B
$ sharq launch --port 10610 \
--config sharq_config.yaml- Model families
- Qwen, Llama, Mistral, Falcon, Jais
- Adapters
- Many LoRA adapters per base model, each with its own checkpoints
- Access
- A personal API key for every developer, stored only as a hash and revocable in the console
- Watching it
- OpenTelemetry traces, metrics and logs
- Recovery
- Optional saved state, so a crash does not lose the session
- Where it runs
- Your GPUs, or Sharq capacity in-region
Questions ML teams ask.
Anything missing, ask us directly. We reply within one business day.
Do we need to train a model from scratch?
No. The engine adapts open base models with LoRA, which takes a fraction of the compute and keeps the base model’s general ability.
Can we use our existing training code?
If it speaks the Tinker SDK, mostly yes: point the client at your engine and use your own key.
Who can see our training data?
Only your people. Data, checkpoints and the finished model stay on the infrastructure you choose.
Can several teams share one engine?
Yes. It is built for many users on shared GPUs: each developer has their own key, and one base model carries many adapters at once.
Is the model we train the model we serve?
Yes. The weights saved from a run are what the engine serves, through the same API, so a served model can always be traced to the run that made it.
Start with one workflow.
A pilot trains one model on your own data, inside your boundary, and measures it against the numbers you already report.