Other ERPsFree calculatorPDF, Excel, Word exportInfor System21Manufacturing

Infor System21 AI assistant sizing and value calculator

Use this calculator to estimate how many GPUs a private Infor System21 assistant needs, how large the retrieval index will be and whether the time saved justifies the cost. Every assumption is an input you can change.

Your numbers

users

People with a Infor System21 login who could use the assistant.

35 %

Share of named users who use the assistant on a given day.

questions
tokens

Include retrieved context. Retrieval-heavy questions often run 2,000 to 6,000.

documents
pages
min
$/h
$/GPU/month

Amortised purchase plus power, space and support, or a private cloud rental rate.

tokens/s

Aggregate throughput under batching for your chosen model. Measure on your hardware.

$

Integration, data dictionary, hardware purchase if not in monthly cost, testing.

Your results

GPU count estimate
1
Peak token rate divided by tokens per second per GPU, rounded up. Add redundancy separately.
Monthly value
$18,480
Daily active users
35
Questions per day
280
Tokens per day
840,000
Peak requests per second
0.0389
Assumes an 8-hour working day and a peak at 4 times the average rate.
Peak concurrent requests
5
Assumes each request streams at about 25 tokens per second.
Index size
1.8
About 2 chunks per page and about 6 KB per chunk for vector plus metadata. Result in GB.
Hours saved per month
410.67
22 working days per month.
Monthly GPU cost
$2,500
Simple payback
3.1 months
Setup cost divided by monthly value minus GPU cost. Zero means no payback at these inputs.

Planning estimate only. Throughput, tokens per question and minutes saved vary widely; measure them in a pilot before committing to hardware.

Save results:

Monthly value vs GPU cost by named users

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

Sizing review for your Infor System21 assistant

Optionally share your inputs for a short review of GPU count, model choice and the value assumptions.

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 daily. Estimate questions per user per day from a pilot or from similar tools; 5 to 15 is common. Set tokens per question to include retrieved context, not just the visible answer. Enter your GPU cost as a monthly figure and set tokens per second to a value you have measured, or leave the default for a first estimate. Read the GPU estimate and payback together.

  • Peak load drives GPU count, not daily totals.
  • Use measured throughput when you have it.
  • Run a few scenarios using the chart.

The formulas

Questions per day equal named users times active share times questions per user. Tokens per day equal questions times tokens per question. Peak requests per second equal questions per day divided by an 8-hour day in seconds, multiplied by a peak factor of 4. GPU count is peak token rate divided by tokens per second per GPU, rounded up. Index size multiplies documents, pages and an assumed chunk density. Monthly value is hours saved times loaded cost.

  • Peak factor 4 and 22 working days are fixed assumptions.
  • Concurrency assumes about 25 tokens per second per stream.
  • Index size is an order-of-magnitude estimate.

Reading the results

If payback is zero, the monthly GPU cost is higher than the value at your inputs; increase adoption or questions, or reduce model size and GPU count. A modest model on one GPU can serve a surprising number of users if questions are short. Long-context retrieval and big models push GPU count up quickly. Keep a safety margin of at least one spare GPU or a failover plan if the assistant becomes business critical.

  • Compare against the TCO calculator for a fuller picture.
  • Treat minutes saved as a hypothesis to test.
  • Do not count savings that are not realised in practice.

Common mistakes

People often size from average load rather than peak, forget retrieved context in token counts, or assume large time savings per question without evidence. Another mistake is ignoring the one-time work: for Infor System21, the data dictionary and permission mapping take real effort and belong in setup cost. Finally, remember that a simpler existing report may already answer the question for free.

  • Size for peak, not average.
  • Include context tokens.
  • Count setup effort honestly.
  • Validate with a pilot.

Frequently Asked Questions

What tokens per second should I use?

It depends on the model, quantisation, GPU and batching. Values from several hundred to a few thousand aggregate tokens per second are common. Measure with your own model and typical prompts, then update the input.

Why does the calculator use a peak factor of 4?

Usage clusters around shift start, after meetings and at period end. A factor of 4 over the daily average is a cautious planning figure. If your usage is flatter, the GPU count will be lower than the estimate.

Is the value figure reliable?

It is only as good as minutes saved per question and loaded cost. Treat it as a hypothesis and test it in a pilot by timing real tasks with and without the assistant.

Does it include power and rack space?

Only if you include them in the GPU monthly cost. Enter an amortised figure that covers hardware, power, cooling and support.

If you want these numbers validated on your own Infor System21 data and hardware, Netray can run a short sizing pilot on-prem.