AXHUB DEEP READ · 01

Running an AI content factory
on a 1GB server

Reading time about 12 minType not someone else's case study, but our own operating logFor individuals and small teams starting small

The translation and topic classification of the overseas articles on this site are done by AI. Yet the server the site runs on is a single virtual machine with 1GB of memory, one of the smallest tiers there is. The trick — and this is the whole point, not a gotcha — is that not a single line of AI runs on that server: a Mac at home does the heavy lifting, and the server only serves. This piece is a record of that architecture and of the things that broke while we built it. The figures are the actual configuration values, and the failures are told without embellishment.

1The problem — AI is heavy, the server is small

Even the small model we use for translation takes about 2GB once loaded into memory.

The model for classification and summarization is 25GB.

The server has 1GB. From the start, it was a matchup the numbers couldn't win.

"Then just use an API" looks like the right answer, and in many cases it is.

But for a service still in its experimental stage, the monthly API bill itself becomes a burden. Because the cost scales with the number of attempts rather than with traffic, the urge to save money ends up reducing how much you experiment.

We took a third path.

2The architecture — separate the factory from the store

The conclusion first. Not a single line of AI runs on the server.

A Mac sitting at home is the factory. Collection, translation, classification, summarization — all of it finishes here, with free open models.

The server is the store. It receives the finished content and only displays it.

This separation gives us three things.

No need to scale up the server. It stays at 1GB.
No model usage fees. We run open models on our own computer.
Experiment and service are decoupled. Even if the factory is down for a day, the store stays open for business.

It isn't a new invention. Work that doesn't need real-time responses — content processing, reports, summaries — has long been handled this way, in batches. There was no reason AI should be different.

3What you need

One Mac you already have. With local models, the more memory, the larger the model you can load. We load a classification model as large as 25GB. If you have less memory, just start with a smaller model.
Two open models, at zero cost. A small translation-only model — Tri-1.8B-Translation (4-bit) — and a larger instruct model for classification — currently Qwen3.6-35B-A3B (4-bit, a mixture-of-experts model with ~3B active parameters, which is why it runs at usable speed on a Mac). We started with a 12B dense model and upgraded later; the architecture didn't change, only the model name in one environment variable.
One 1GB virtual server. The one you already had.
A path from factory to store. A single transfer API that sends only the published items over HTTPS (token-authenticated).

Beyond the server bill, there was no additional cost. Just about the electricity.

4The pipeline — six steps

Collect. Pull in new pieces from domestic and overseas sources and stack them as "drafts." This step is not publication.
Translate. The 1.8B translation-only model. It attaches English to Korean articles, and Korean to English ones. If its output leaks the wrong script (a known small-model quirk), the pipeline falls through to the larger instruct model.
Classify. The 35B instruct model tags each article with operations-oriented topic labels (adoption, governance, organizational change, tools…). The topic clusters on the home page are built from these labels.
Topic digest. Gather what's being talked about today in overseas developer communities and summarize each in a line.
Curation. A person scans the draft list and picks only what to publish. More on this below.
Transfer. Only the published items are sent to the server. The server just receives and stores; it creates nothing.

There are constraints inside the factory too. Loading the translation model and the classification model at the same time is too much even for the Mac. So when translation finishes, we unload that model and load the classification model. Deciding that order was itself part of the design.

5What broke

That's the end of the architecture talk, and from here is probably the more useful part.

The newest model wouldn't answerWhen we used a fashionable reasoning-style model for classification, the answers kept coming back blank. This family sometimes writes its answer in the "thinking" box and sends the "answer" box empty. What the pipeline needs is not thinking but the answer. Switching to an ordinary instruct model that follows instructions ended it (a 12B at the time; since upgraded to the 35B MoE). The criterion is fit for purpose, not newest or biggest.

Too small was also troubleConversely, a 0.5B micro-model slapped the same label on any article. Without hesitation, and very confidently. Beware a small model's confidence.

One source dumped 934 itemsWith no collection cap in place, the entire back catalog of a single overseas blog flowed into the draft bin. It was 934 items. We tidied it up by setting a "max 8 at a time" cap per source. A pipeline's safeguard is not intelligence but a cap.

The model couldn't be found from inside the containerThe app runs inside a container and the model runs on the Mac, but the app kept coming back empty-handed. Inside a container, "localhost" is not the Mac — it's the container itself. We spent half a day here. When it fails, start by asking "who is localhost right now."

Translation invented a nameThe 1.8B translation model handled sentences fine but was weak on proper nouns. We found the name of a world-famous researcher rendered as an odd spelling. So we left a human-check step after the translation.

One field quietly vanishedTo add a new field to an article and send it to the server, we had to fix all three points along the transfer path — and if you missed one, that value just disappeared, with no error. A silent failure is scarier than a loud one. After we wrote those three points into the operating docs, it became a five-minute job.

6Where the human stays

The classification model's labels are hints, not filters. A person presses the publish button. We deliberately did not build a bulk-publish feature.

We learned why early on. Academic papers and technical articles for developers came in wearing the plausible label "tools," but they weren't what our readers wanted. A local fire-drill article once got classified as an "adoption case."

So the machine attaches labels and a person scans the list and filters. A few minutes a day is enough.

It's our own home version of the "AI handles it, humans check only the exceptions" line we've repeated across the card series.

7If you want to try it

We recommend not building it all at once. This is the order we actually followed.

Collection first, without AI. Just as far as new pieces from your sources piling up in the draft bin. Be sure to set a per-source cap here.
One model, one job. Attach just one — translation or summarization — and confirm the result appears on the drafts.
Add classification. Be prepared to be disappointed by label accuracy, and use it only as a hint.
Decide the human-check point. Where you look with your own eyes and publish. It's the most important decision of the six steps.
Build the transfer. Published items only, to the server. The server only receives.

It took us 2–3 weeks, running it alongside other work. Doing it in one push would be shorter, but going step by step, checking the real thing (drafts, translations, labels) with our own eyes at each stage, turned out faster in the end.

8The gist

The site this piece sits on is the product. The overseas-article translations, the topic clusters, and today's talking points on the home page all came through this pipeline. The server is still 1GB.

Changing the architecture instead of adding hardware. That's the kind of thing our AX turned out to be.

9Questions we expect (and honest answers)

What exactly are the models? Translation: Tri-1.8B-Translation (4-bit), a purpose-built translator. Classification: Qwen3.6-35B-A3B (4-bit MoE), served by a local OpenAI-compatible runtime on the Mac. There is also a paid cloud fallback (GLM 5.2) in the chain — it only fires when the local chain fails, which is rare; the bulk runs local and free.
Why not just use an API for everything? Because at the experiment stage, cost scales with attempts, not traffic. When every retry costs money, you stop retrying — and retrying is most of the work of getting a pipeline right.
Why SQLite and no Redis on the server? 1GB doesn't leave room for a second database process. Rails 8's Solid Cache/Queue/Cable run everything on SQLite, and at this traffic level it has never been the bottleneck.
Isn't the title a cheat if the AI runs on a Mac? The separation is the article. The claim isn't "we squeezed a 25GB model into 1GB" — it's that you don't have to: batch work doesn't need to live on the serving box.
What actually costs money? The server bill for the 1GB VM, electricity for the Mac, and nothing per-token for the local models. We deliberately don't publish exact currency figures here; the point survives any provider's pricing page.

Want the next guide? Email me — I read every reply.

To try it by hand → AXHub lectures, 5 parts — 30-minute hands-on each · Deep Read contents

This piece is transcribed from AXHub's operating log (June 2026 work log); the specs, model sizes, and counts are actual values. The pipeline still runs on the same architecture — model names in the text are the ones running as of August 2026.

Running an AI content factoryon a 1GB server