On-Prem AIFree calculatorPDF, Excel, Word exportLabWare LIMSLaboratory and Quality

LabWare LIMS AI Assistant Sizing and Value Calculator

This calculator sizes a private AI assistant for LabWare LIMS: how many GPUs the busiest hour needs, how much index space your documents take, and whether the time saved pays for the build. It uses simple, visible formulas you can check.

Your numbers

users
35 %

Daily active users as a percent of named users. 20 to 50 is common after the first quarter.

questions
tokens

Includes retrieved context. Retrieval-heavy answers are often 2,000 to 6,000 tokens.

20 %
tokens/s

Aggregate batched throughput for your model and GPU under vLLM. Measure on your hardware; 500 to 3,000 is a wide realistic range.

documents
pages
minutes
$/hr
$/month

Amortized hardware, power, cooling and support. Not a cloud price.

$

Your results

GPUs needed (before redundancy)
1
Peak tokens per second divided by sustained tokens per second per GPU, rounded up, minimum one. Add one for high availability.
Net monthly value
$29,963
Daily active users
53
Questions per day
263
Tokens per day
918,750
Peak-hour tokens per second
51.04
Busiest-hour tokens divided by 3,600 seconds.
Chunks to index
2,160,000
Assumes about 3 chunks per page.
Index size
13.1674
Per chunk: a 1,024-dimension float32 vector plus about 2 KB of text and metadata. Approximate, before index overhead.
Hours saved per month
578 hrs
22 working days per month.
Monthly value of time saved
$31,763
Monthly GPU cost
$1,800
Payback
2 months
One-time cost divided by net monthly value. Zero means no payback at these inputs.

Planning estimate only. Throughput depends on model, quantization, context length and hardware; measure on your own GPUs. Time saved is an assumption you should validate with a pilot.

Save results:

Net monthly value vs named users

Sweeps Named users from 20 to 600, holding your other inputs fixed.

Validate these numbers with a pilot

Optional: Netray can run a small read-only pilot on LabWare LIMS and replace the assumptions with measured throughput and time saved. The calculator works without it.

Optional. The tool and every export work without this. No spam.

How to use it

Start with named users and the share who use the assistant on a typical day. Set questions per active user per day from a pilot or from comparable tools. Average tokens per question should include the retrieved context sent to the model, not only the typed question. Then enter the sustained tokens per second you expect per GPU, the number of documents and pages to index, minutes saved per question, and costs. The primary results are GPUs needed and net monthly value, with payback in months.

  • Use a pilot to replace guesses
  • Keep tokens per question realistic for retrieval
  • Measure GPU throughput with your own model
  • Include only costs you will actually bear

Formulas and assumptions

Daily active users = named users x active share. Questions per day = active users x questions each. Tokens per day = questions x tokens. Peak tokens per second = questions x busiest-hour share x tokens / 3,600. GPUs = ceil(peak tokens per second / tokens per second per GPU), minimum one. Index size = documents x pages x 3 chunks x (4 KB vector at 1,024 dimensions + 2 KB text). Hours saved = questions x 22 x minutes / 60. Payback = one-time cost / (monthly value - GPU cost).

Reading the results

For most deployments the GPU count is small, one or two, because peak load is bursty and answers are short compared with training workloads. The index is usually modest, a few gigabytes to a few tens of gigabytes. The sensitive input is minutes saved per question: halve it and see whether payback still works. If it does not, the project may still make sense for risk or compliance reasons, but you should say so honestly. In this context: GxP and 21 CFR Part 11 or Annex 11 where applicable: assistant stays advisory, read-only in phase one, no result entry or approval.

Common mistakes

Sizing on average load instead of the busiest hour, ignoring retrieved context in the token count, and assuming vendor tokens-per-second figures apply to your model and prompt lengths are the usual errors. Another is counting time saved on questions people would never have asked before. Count only replaced effort, and add a safety factor for growth and for a redundant GPU.

  • Average instead of peak load
  • No redundancy GPU
  • Optimistic minutes saved
  • Forgetting re-indexing and evaluation time

Frequently Asked Questions

What tokens per second per GPU should I use?

It depends on model size, quantization, context length and batching. A range of 500 to 3,000 aggregate tokens per second on a single data-center GPU is realistic for mid-size open-weight models under vLLM. Benchmark your own setup before committing.

Why does the calculator size for the busiest hour?

Users ask questions in bursts, such as the start of a shift or before a meeting. Sizing on the daily average would leave the system slow when it matters, so the model uses a configurable busiest-hour share of daily questions.

Does the index size include the model?

No. Index size covers the vectors and text of your documents only. Model weights are separate: a 14B model at 4-bit is roughly 8 to 10 GB, and a 70B model is several times that.

Is the value figure a guaranteed saving?

No. It multiplies questions by minutes saved and hourly cost, all of which are assumptions. Validate minutes saved with a pilot and treat the result as a range, not a promise.

If you want these numbers checked against your real usage, Netray can run a short pilot on LabWare LIMS and replace the assumptions with measurements.