Algeria AgencyArtificial intelligence
Hosting the model or calling it: what actually decides
The comparison is nearly always drawn between a price per million tokens and the price of a machine. Both figures are true and neither answers the question.
A technical director in Blida presents two columns to his board. On the left, the monthly subscription at a foreign supplier. On the right, the amortisation of a machine. The right-hand column wins, the board approves, and the machine spends eleven months of the year doing nothing while somebody watches it.
Both figures were accurate. What was missing is what actually decides between them, and it is neither the price per million tokens nor the price of the hardware: it is utilisation. This article gives the lines on each side, the formula that sets them against each other, and the measurement that fills it in with your figures.
It does not cover the law — what the law allows you to send where is an earlier decision, and it can close the left-hand column on its own. It assumes that question settled and asks the next one: at a given volume, which architecture costs less, and from what point does that reverse. An artificial intelligence project is decided in that order.
The question arrives after the prototype, and that is already too late
The prototype is nearly always built against a foreign interface, because that is what starts in an hour. The hosting question comes afterwards, at go-live, and it then presents itself as a migration rather than as a choice.
A migration at that point costs what neither column allowed for: rewriting the call, revalidating the answers, redoing the measurements, and discovering that the behaviour is not identical. The prototype was right to start there; what was missing was knowing, from the outset, that the question would arise.
The safeguard is one line of design and costs nothing at the moment it is applied: route every call to the model through a single point in your code. While that boundary is in one place, changing sides is a few days’ work; when it is scattered, it is a rebuild.
It is the only recommendation in this article that holds before you have any figures at all. The rest depends on your volumes; this one depends on nothing.
What is really being compared: two shapes of spending, not two prices
Calling an interface is variable spending: it is nil on a Sunday with no traffic and rises with use, with no ceiling other than the one you set. Running a machine is fixed spending: it is identical on the quiet Sunday and on the busy Tuesday.
That difference of shape matters more than the difference of level, because it decides who carries the risk. With the interface, a forecasting error is paid proportionally: twice the use, twice the cost. With the machine, a forecasting error is paid in full one way and not at all the other — too small and it saturates; too large and it costs the same while nobody notices.
There is one more asymmetry, specific to this market: the variable spending is in foreign currency and the fixed spending is largely in dinars. That is not only a question of rate, it is a question of procedure, and what each currency outflow costs administratively belongs to the left-hand column as much as the listed price does.
The right way to frame the comparison is therefore not “which is cheaper” but “from what level of use does fixed spending become cheaper than variable, and am I there”.
The interface side: three lines, and only one is the model
The first line is the call itself, billed on the volume of text processed. It is the one everybody compares, and it is often the smallest of the three in real professional use.
The second is everything that accompanies the call and is not the model: hosting your own layer, the database holding your content, the measurement tool, the test environment. A useful assistant is not a call, it is a system around a call, and that system runs somewhere.
The third is the administrative cost of paying, and it is the one that appears in no quote because no supplier collects it. It is counted in procedures per year rather than as a percentage, which has a counter-intuitive consequence: it pushes towards paying more and less often.
Adding those three is the only way to get an honest left-hand column. A comparison that keeps only the first compares a subscription against an infrastructure, which means nothing in a two-column table.
The machine side: six lines, and two of them are people
The hardware first, with the local particularity that replacing a specialised part means importing it. A machine whose critical component takes weeks to come back does not have the same availability as an identical machine elsewhere, and that goes into the column as a spare part or a contract.
Then the electricity, and the room that goes with it: a machine of this kind runs hot and needs cooling, which consumes in its turn. Then the network, which does not disappear because the model is on your premises — your users still reach it.
The fifth line is updating: an installed model ages, the machine’s security patches come out every month, and the version you run today will be overtaken by what the left-hand column offers without you doing anything.
The last two are people, and they are what tips most calculations. Somebody installs and updates; somebody restarts it when it stops. A business without those two in-house buys them, and that is one more subscription in the column everybody thought was fixed.
Electricity, and the meter reading that settles the discussion
We publish no typical consumption and have no reliable one to publish: it depends on the hardware, the load and the cooling, and a figure taken from a foreign market would describe a different room from yours. What is measurable is your meter.
The measurement takes a day and it is exact: plug the machine you are considering, or a comparable one, into a socket with a meter, and read the consumption over twenty-four hours without sending it a single request. That figure is the floor of the right-hand column, and it rarely lands where it is expected.
Power quality is the second half of the subject, and it is specific. Cuts and fluctuations slowly damage hardware that is expensive to replace, which turns an undersized inverter into deferred expenditure; the state of the power supply is one of the first things an audit records, and it is better known before installing than three months after.
The point to hold is one sentence: a machine consumes when nobody is using it, and an interface bills nothing when nobody calls it. It is the same asymmetry the next section measures a different way.
Utilisation decides, not volume
Two businesses handling the same number of requests per month do not have the same answer if one receives them spread out and the other concentrated into three hours. The machine is sized on the peak and paid for over the whole month; the interface is paid on the total and ignores the shape.
That is what makes “how many calls a month” insufficient on its own. The right question is double: how many in total, and what proportion of the time the machine would actually be busy. Ten per cent utilisation means nine tenths of the fixed spending buys availability, which is sometimes exactly what you want to buy — and it should then be said that way.
The case where the machine clearly wins is recognisable: high volume, regular, and predictable over twelve months. The case where it clearly loses is too: jagged use, seasonal, or use nobody can say will still exist in the spring.
Between the two there is a wide band where the columns are level, and where the decision is taken on something else: the law, confidentiality, the availability of skills. That is good news, because those criteria are easier to discuss than a gap of a few per cent.
Latency: what changes, and what does not
Bringing the model closer removes an international round trip, and that is real. But latency is not bandwidth, and the round trip is only part of what a user waits for: the compute time remains, and it is longer on modest hardware than on a large supplier’s.
The result is frequently the opposite of the intuition. A model hosted locally on a single machine can be slower than an international call, because the queue at three simultaneous requests costs more than the milliseconds saved on the journey.
The difference shows in behaviour under load rather than in a measurement at rest. A remote interface absorbs a peak without you doing anything; a local machine queues it, and the waiting user does not distinguish “the network” from “the machine is busy”.
The honest measurement is therefore taken at realistic load and not idle. Measuring a local model one request at a time is the measurement that always favours the right-hand column, and it is the measurement nobody experiences.
The model you can run is not the one you call
This is the section comparisons leave out, and it changes more decisions than all the others. The models reachable by interface at large suppliers are bigger than the ones a business runs on a machine it buys. Comparing the two columns while assuming an identical result compares two different things.
The practical consequence is not that one is better: it is that the comparison has to be made at measured quality, on your own cases. A smaller model can be perfectly sufficient for sorting incoming requests and clearly insufficient for drafting a case summary, and that is established in an afternoon on thirty real examples.
There is one case where the question does not arise: when the task is narrow and repetitive. That is where the capability gap is least visible, and it is also, not coincidentally, the kind of task that produces steady volume — so the case where the right-hand column was already winning.
The bad reasoning, and it is very common, is to choose the machine and then discover the quality. The right order is the reverse: establish on your own cases what the hostable model can do, and only open the cost calculation if the answer is acceptable.
What breaks at three in the morning
With an interface, an incident at the supplier is endured and it is also shared: it is reported, documented, and it ends. With a machine, an incident is yours, and the question is not whether it will happen but who will deal with it.
That line is costed in the only honest way available: by writing the name of the person who gets up. If that name is the same one as for every other on-call duty in the business, the right-hand column has just added a load to somebody who already carries several, and that is called a single point of failure rather than a saving.
To it must be added what is lost when that person leaves. A machine installed by somebody who documented nothing is a machine the next person dares not update, and a machine nobody dares update becomes a security problem within a few months.
The honest counterweight exists and deserves saying: a machine on your premises does not disappear because an account was closed, and what is really lost in the cloud is not the server but the right to get into it. Each column has its own failure mode; neither is exempt.
The formula, and what to put in it
It fits on one line and needs none of our figures. The threshold is reached when the machine’s fixed monthly cost — amortised hardware, electricity, room, network, updating, on-call — falls below the interface’s variable monthly cost, plus the year’s administrative cost of currency outflows divided by twelve.
Three precautions make it usable. Amortise the hardware over a period you can stand behind, not the longest possible: a machine amortised over five years in a column assumes the model it runs will still be worth having in five years. Cost the on-call at its real cost, not at zero because the person is already on the payroll. And convert the left-hand column at the day’s rate, writing that rate and its date beside the result.
What the formula does not say matters too. It ignores quality — section 7 — and it ignores the law, which can rule out the left-hand column regardless of any calculation. A threshold crossed therefore decides nothing on its own; it eliminates one of the two columns when the gap is clear, and settles nothing when it is not.
We give no amount in this article and that is deliberate: the two inputs that decide yours are your real utilisation and the exchange rate, and neither is ours. A figure written here would be wrong for almost everybody and read as an order of magnitude by everybody.
The two-week measurement
Here is what fills the formula, and it is done without us. For two weeks, on your prototype or your existing service, record three things at every call: the time, the size of what is sent, and the size of what comes back. A text file is enough.
At the end you have three numbers. The total, which gives the left-hand column. The peak — the largest number of calls in a single hour — which sizes the right-hand column. And the ratio between them, which is your utilisation and which is the real answer.
Two weeks and not two days, for a precise reason: professional use has a weekly shape, with a trough on Friday and Saturday and a resumption on Sunday. Measuring three working days gives a credible peak and a total wrong by half.
If your service does not exist yet, the same measurement is taken on what it would replace: the number of messages, calls or documents actually handled over the same period. It is less precise and it is the same order, which is enough to know whether you are in the band where the calculation settles the question or in the one where it does not.
What we do, and what we refuse
We instrument the measurement above, build the two columns with your figures, and write the threshold with the date and rate used to calculate it. We also design the system with the call boundary in one place, which keeps the choice reversible later without a rebuild.
We measure quality before cost when the right-hand column is being seriously considered: thirty real cases, the hostable model against the interface one, and the result put in front of you before a machine is ordered. That is half a day, and it has cancelled more machine projects than it has confirmed.
We do not recommend local hosting on sovereignty grounds we could not stand behind. A machine within your walls does not make your processing compliant, does not replace a register, and relieves you of no obligation — it removes one question and one only, which is the transfer.
And we do not sell the machine. We take no margin on hardware, which is the only reason our calculation is worth anything: a supplier who profits from the right-hand column should not be the one comparing the two columns, and if we took an income from it you would be right to have the calculation redone elsewhere.
Frequently asked questions
Can we start with the interface and migrate later?
Yes, and it is the order we recommend in the great majority of cases, on one condition: that every call to the model goes through a single point in your code. With that boundary in place, migrating is a few days’ work; without it, it is a rewrite, and that is what turns a reversible decision into a final one.
Does a model hosted at our end make us compliant?
It removes the question of transfer outside the country, and it removes nothing else. The register, the logs, the impact assessment and the breach procedure remain owed identically, and a machine within your walls fills none of them. It is a real gain on one specific point, too often presented as a general one.
How long does it take to install a model in-house?
The installation itself is short and that is not where the time goes: it goes into measuring quality on your cases, into sizing, and into organising who looks after it. A business that has not answered the third question has installed a machine, not put a service into production.
Does second-hand hardware change the calculation?
It changes the first line and none of the other five, which moves the threshold less than people hope. It also adds a parts-availability question that weighs heavily here: a specialised card that takes weeks to replace turns a fault into a service outage, and that goes into the column just as the purchase price does.
What about a supplier hosting in Algeria on our behalf?
That is a third column, and often the right one to start with: the spending is local and in dinars, the currency outflow is the supplier’s problem, and you buy neither machine nor on-call duty. The questions to put to them are any subcontractor’s — where are the servers, who has access, what becomes of the data — and they are put in writing.
Why does this article give no amount?
Because the two inputs that decide yours are your real utilisation and the day’s exchange rate, and neither is stable or transferable. A figure written here would be wrong for most readers and read as an order of magnitude by all of them. The formula in section 9 does the same job with your numbers.
Where we come in
The two-week measurement gives a total, a peak and the ratio between them. It is the third that settles the question, and it is the one nobody records.
- We instrument your calls over the measurement period and pull the three numbers out of it.
- We test the hostable model against thirty of your real cases, and the result lands ahead of the purchase order.
- We place the call boundary at a single point in the code, so the choice stays reversible.
None of our revenue comes from hardware, and a machine is not sold here on sovereignty grounds: it lifts the transfer subject and nothing else.
Read next
Cloud hosting: what costs is not the storage
The line everybody compares is the cheapest on the invoice. The other three get paid on the day you need them most.The account, not the server: what you actually lose in the cloud
Everything you keep there passes through one login, one mailbox and one card. What breaks that chain, and in what order.What you are allowed to send to a model hosted abroad
A chatbot connected to your mailbox exports your customer file, one line at a time. Nobody around the table described it that way.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.