A few short steps. You answer in your own terms (items, days); the page turns them into the inputs the LCOAI standard needs, using published unit prices you can overwrite. If you run the model yourself, it also sizes the machine: model, precision, memory and speed. Nothing is sent anywhere.
Pick the job. One "output" is one unit of that job done.
Which of these must be true? They decide which ways of running it are even allowed, before any cost is looked at.
How many items the AI will handle. Count the work as it is done today; if nothing is done today, estimate it and treat the result as an estimate.
Pick two to compare. Greyed options fail a requirement from the first step and get no cost: that is the rule of the method. If you pick rented or owned machines, the next step sizes them.
From your job and volume we estimate the model, how it is stored and the GPU memory it needs. Then you choose in three steps: the model, its precision, the machine.
Bigger models are usually more accurate but need more memory, so more expensive GPUs. Each row is shown at 8-bit, the precision that keeps almost all quality. The verdict compares the model with what your job needs.
AI needs people: some to set it up once, some to keep it running. Build your team: who you will hire or assign, how many hours each works and what each costs per hour. We filled in a starting team from the published case studies; change any cell, add or remove people.
You said a person must check outputs. The check is part of the system, so its time is inside the cost.
AI is sometimes wrong. LCOAI only counts answers you can use as they are, so a cheap AI that is often wrong can cost more per useful answer than a better one. We picked our best estimate; change it if you know better, ideally by trying 10 or 20 of your own items.
The five numbers the method needs, filled from your answers and the published unit prices. Change any of them; the result follows. Or load a published case study into either column.
LCOAI adds the one-time setup cost to the running cost of each year, discounts each year back to today, subtracts any resale value, and divides by the discounted number of outputs over the same years. Dividing by all outputs gives the cost per 1,000 delivered; dividing by the good ones gives the cost per 1,000 accepted, the headline figure. An option that fails a requirement gets no figure; an option below your quality bar is shown for information only. The full method (17 cost categories, per-year schedules, energy and emissions, shared-cluster allocation, conformance check) and the Excel calculator for a formal report are in the published package.
Memory needed = weights (parameters × bits per weight ÷ 8) + KV cache (requests at once × tokens per request × KB per token) + runtime (1 GB plus 5% of weights, an estimate). The machine is usable up to 90% of its memory, the default the vLLM serving software keeps. KV cache per token is a planning estimate from common model layouts (8B-class 128 KB, 32B-class 256 KB, 70B+ 320 KB at 16-bit); models with hybrid attention need less.
Speed: generating text reads the weights once per step for all requests together, plus each request's KV cache, so tokens per second = memory efficiency × bandwidth × requests ÷ (weights read per step + KV read per step). Efficiency is calibrated from published llama.cpp runs where they exist, otherwise 0.65 and marked estimated. Reading the input scales the measured prompt speed by model size. This ignores the compute limit, so very high request counts are optimistic; the published Annex runs remain the measured reference. More GPUs in one machine add memory, not speed, in this estimate.
The recommender filters models by memory, input length and image support, then ranks by BenchLM's BenchAlign v5.8 overall score. It is a lookup, not a trained model.