123,398 plant descriptions across 16 languages. Text that was already written and simply had to exist in fifteen more languages.
Does the text have to be written or only translated
PlantGeekz ships in 16 languages. Part of the text was written with a paid model because it had to be right. The rest is translated on our own GPU because there are a hundred thousand of them. The line between the two is not size, and it took us a while to work that out.
FIG. 01
The arithmetic
The bought pile is the bigger one
When the app had to exist in 16 languages, it looked like one job. It is two, and they have almost nothing in common. One is writing something that does not exist yet and getting the terminology and the botanical names right. The other is taking text that is already written and making it exist in fifteen more languages. We tried to solve both with the same tool, and that was the expensive way to learn the difference.
412 editorial genus and family guides, each in 16 languages. These had to be written from scratch, not merely translated.
Buttons, labels and error messages in the app and the API. Nothing in volume, but the text a user reads every single day.
Note the order. What we pay for is larger than what we run ourselves. So volume decides nothing at all.
FIG. 02
The line
Writing is not the same job as translating
It looked like a decision about volume. It is a decision about what the text has to go through.
Written by a paid model
- The hub articles: 412 genus and family guides, written from research
- The twelve hundred or so UI strings in the app and the API
- Anything where a botanical name or a technical term has to be right first time
- Anything where tone and editorial judgement are part of the job
Translated on our own GPU
- The 123,398 plant descriptions that were already written in English
- Feed content from users, translated live and never finished
- Anything where the text already exists and only has to change language
- Anything containing something one user wrote to another
A hub article is a care guide for an entire genus. It has to be researched, it has to have a point of view, and it has to use the right words about the plant. That is writing, and it is exactly where an expensive model earns its money. The 412 hubs exist in 16 languages each, and they are the single most expensive line in the project. They were worth it.
The plant descriptions are the opposite job. They were already written, there are a hundred thousand of them, and nobody reads them all. No judgement is required. The same thing simply has to appear in fifteen more languages, and that is a very different thing to ask for.
FIG. 03
The bill
The cheap model is not the shortcut
The obvious move is to push the heavy work down onto a cheaper model and keep buying. It does not work here. We measured it on our own content: the small and mid-sized models drift on botanical Latin and technical terms. They rewrite a genus name, they turn one chemical compound into another, and they do it quietly without flagging that they were unsure. A wrong species name is worse than no text at all, because it looks right.
So the cheap column does not exist for this kind of text. Either you buy the expensive model or you do it yourself. And that changes the arithmetic entirely. The 34 million characters sitting in the database now come to roughly ten million tokens in and nine million out. On the model that can actually handle it, that is a couple of hundred dollars. Easy to overlook, if it were the whole job.
But we are about two per cent done. There is text on 9,428 plants, and the target is all of the roughly 450,000 species. Scaled up, that is over ten thousand dollars for a single run. And we have already redone that run once, because the first translation model turned out to handle terminology and Chinese badly. On our own machine that mistake cost a few hours of GPU time. On a metered bill it would have cost the whole thing a second time.
The first run
It is the one everybody works out, and it is usually affordable. It is also the only one in the budget when someone decides to buy their way out of the problem.
Every run after it
The source text gets corrected. A language is added. A model turns out to be poor at the terminology. Each of those costs the full amount again, and they happen more often than you expect while the content is still being built.
The one that never stops
User content has to be translated while people are writing it, and it never ends. It is the only line you cannot cap, and it grows at exactly the rate the product succeeds.
FIG. 04
The machine
What is actually running
Nobody trained anything. We pulled a model tuned for the one job and set it to do the one job.
Find the language
A one-megabyte language detector works out what the text is written in. It runs on CPU and takes up nothing. If source and target are the same language, it stops here.
Hide what must not be translated
Mentions of users and plants, and tags, are masked before the text goes out and restored afterwards. Without that step an @name went missing in transit, and it took a while to notice.
Translate
translategemma, a translation-tuned Gemma 3 with four billion parameters, runs in a local Ollama on the same GPU as the plant recognition. A plant description takes under three seconds while the machine is doing three other things.
Keep the answer
The result goes in the database. The same text is never translated twice, and that is genuinely the cheapest optimisation in the whole chain.
The point of a translation-tuned model is that it holds on to the words it does not understand instead of guessing at them. That is exactly the property a small general-purpose model lacks, and the reason this job can move in-house even though the writing cannot.
FIG. 05
The other side
It is not free, it is just a different kind of bill
Moving it in-house saves tokens. You pay somewhere else, and that belongs in the arithmetic too.
You have to measure the quality yourself
Nobody tells you the model is drifting on terminology. You find out by reading some of it in a language you know. We did that too late, and it is the mistake I would make differently.
It needs looking after
There is one more container to keep running, one more model to update, and a GPU to share with other things. It is not much work, but it is not nothing.
It costs time instead of money
A couple of seconds per text turns into days when there are a hundred thousand of them. It runs in the background and bothers nobody, but it is not something that finishes this afternoon.
The point is not that you should run everything yourself. We still pay for the expensive model where it earns its money, and that pile is larger than the one we run at home. The point is that the question is not how much text there is. The question is whether the text has to be written or only translated. If it has to be written, buy the best model you can afford. If it only has to be translated, a small specialised model on your own machine is both cheaper and better than a cheap general one you pay for.
FIG. 06
Next
More to read
Plant recognition on our own GPU
How PlantGeekz puts a name on a plant photo with BioCLIP 2 on our own GPU. What it can do, what it cannot, and why keeping it at home is an advantage.
Read the article
Large data volumes
What happens to a system when the tables grow from a hundred thousand rows to twenty million. What it costs not to have the data model under control, and what I do about it.
Read the article
Got something that needs building properly?
Write a few lines about what you are dealing with. I will come back with what I think, including if the answer is that someone else would do it better.