Train for your task. Test before and after.
Define useful answers on your examples, compare the starting model with prompt changes and fine-tuned candidates, and measure quality and deployment cost together.
- Engagement
- Scoped to your workload
- Price and dates
- Agreed in your proposal
- Support
- With the researcher who builds it, under agreed terms.
Who this is for
- Your examples reveal a task, terminology or output-format gap.
- You need to evaluate Hebrew or another workload-specific requirement before committing to training.
What you receive
- Held-out evaluation examples and agreed quality checks.
- A comparison of the baseline and tested candidates.
- Training artifacts and configuration where training is approved and licensing permits delivery.
- Deployment measurements and operating instructions within the agreed scope.
What we need from you
Examples you have the right to use, reviewers who know the task, and a definition of acceptable output.
How it runs
Build the evaluation
Separate training examples from the examples used to judge the result.
Test the intervention
Compare prompt changes and training against the starting model.
Check the deployment
Measure quality, memory and response time together before selecting the result.
Hebrew quality starts with your examples
The lab researches Hebrew models and tokenization. Your task still needs its own evaluation; tokenizer compression is not proof of better answers.
A measurement can change the training decision
This research note separates a replay result from a live-generation question.
Read the research notememra is the lab’s from-scratch Rust + CUDA inference engine for Blackwell. Its kernels, quantization arithmetic and speculative decoding are developed and measured in public.
This is research provenance, not a claim that this engine runs the deployment trial or predicts your results.
Scope, handover and support
Your proposal sets out the work, price, start and handover dates, and what is needed from you. Hardware, cloud charges, engineering and ongoing operation belong in the cost discussion. On-site days and continuing support are agreed as part of the engagement. The researcher who builds the system keeps supporting it under those terms.
Questions about the work
How is the price decided?
From your workload, hardware and the implementation and support scope we agree together. Your proposal separates the engineering work from hardware, cloud and ongoing operating costs.
Who keeps supporting the system?
The researcher who built it. We agree support coverage, on-site work and how to handle problems before starting.
Do I need to buy hardware first?
No. Start with your workload and budget. We compare the options before recommending a purchase or deployment.