Know what to run before you buy hardware.
Compare models, API use, cloud and local hardware against your task, quality requirements and total operating budget. Start with a measured recommendation rather than a shopping list.
- 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
- You are choosing between an API, cloud GPUs and hardware you control.
- Your prototype works, but its quality, response time or operating cost needs a closer look.
What you receive
- A comparison of model candidates on representative inputs.
- A baseline for quality, response time and resource use.
- A total-cost recommendation with its assumptions.
- A proposed scope for the next step.
What we need from you
Representative inputs, the checks that define a useful result, expected traffic and your hardware budget. Rough estimates are enough to start.
How it runs
Define the decision
Agree the task, constraints and acceptance checks.
Measure the candidates
Test the relevant model and hardware options on your examples.
Explain the recommendation
Document what fits, what does not and why. Keeping your current API remains a valid outcome.
Give each model a job
Chat models handle conversation and tool use. Embeddings find candidate information; rerankers order the results. Specialist models handle narrower tasks. We choose the combination for the workload, not the size of a catalog.
Evaluation before intervention
Read a lab experiment where a cleaner comparison changed the conclusion.
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.