Skip to content
Rush Labs

We helped build the on-device search and GPU inference behind PixaFind, an offline AI file search app.

Rush Labs is an applied AI lab. We fine-tune open models, make them fast on GPUs and ship them inside products that keep your data on your own machines.

Built with

  • PyTorch
  • CUDA
  • Hugging Face
  • vLLM
  • llama.cpp
  • ONNX Runtime

How we build a model

The same three moves sit under every model we train, for our own projects and for our partners.

  1. 1

    Start from the data

    Every model starts as an eval set: real examples of the job, with the answers we expect. We clean and shape the training data around the gaps that eval shows, before any GPU time is spent.

  2. 2

    Tune and measure

    We fine-tune open models on NVIDIA GPUs, with LoRA or full training, and score every run against the base model and the best API option on the same eval. Only a clear win moves on.

  3. 3

    Ship it small

    The winning model is quantised and packaged to run where it is needed: a laptop, a desktop app or your own servers. Fast, private and cheap to run, with the eval still watching every release.

From the lab

Open-source tools we have released, each with its code, tests and evals in the open.

All projects

What we are good at

Four skills the lab is built on. Most models we ship use all of them.

  • Fine-tuning & post-training

    Make an open model very good at one job.

    • Dataset curation, cleaning and synthetic data
    • LoRA, QLoRA and full fine-tunes on NVIDIA GPUs
    • Preference tuning when tone and judgement matter
  • Fast, efficient inference

    Smaller, quicker models that cost less to run.

    • Quantisation to 4-bit and 8-bit with quality checks
    • Serving with vLLM, TensorRT-LLM, llama.cpp or ONNX Runtime
    • GPU batching with CPU fallback for desktop apps
  • Search & retrieval

    Find things by meaning, across text and images.

    • Text and image embeddings
    • Local and server-side vector indexes
    • Hybrid search and rerankers for better answers
  • Evaluation

    Proof that a model got better, not just different.

    • Eval sets built from real usage
    • Regression gates before every release
    • Quality, speed and cost compared side by side

Building with partners

We take on a few design partners whose problem fits what the lab is building. This is how it runs.

  1. 1

    Problem

    One task, one measurable target. We agree what “better” means before anything is trained.

  2. 2

    Data

    We build the eval set first, from real examples, then shape the training data around its gaps.

  3. 3

    Model

    Fine-tune, compare against the base model and the best API option, and keep only what wins.

  4. 4

    Ship

    Quantised and packaged for your hardware or ours, with the eval running on every release.