← All posts

Training a 6.4M-Parameter Transformer for Recipe Tasks

A developer built a compact PyTorch transformer from scratch, trained it for recipes, and runs it on CPU without external APIs.

Training a 6.4M-Parameter Transformer for Recipe Tasks
Contents

In brief

The author of Rasaveda trained RasavedaGPT, a 6.4-million-parameter transformer for recipe-related tasks. It uses no pretrained weights or hosted inference endpoint, and runs on CPU within the application's FastAPI backend.

The project is not an attempt to replace general-purpose LLMs. It is a useful demonstration that a tightly scoped problem, controlled data, and explicit output formats can make a small model viable.

What happened

The developer replaced external model calls with a decoder-only transformer written in PyTorch. Its custom BPE vocabulary contains 6,000 tokens; the context window is 512 tokens. The model has six transformer layers, eight attention heads, a 256-dimensional embedding, and 6,392,320 parameters in total.

Training happened in two stages. Three epochs on WikiText-2 gave the randomly initialized model basic language fluency. The author then fine-tuned it on 2,139 recipe examples, repeating the data eight times per epoch with shuffling. Both stages took roughly 40 minutes on a single Google Colab T4.

Rasaveda combines the model with semantic recipe retrieval. Search finds relevant recipes and missing ingredients; the model produces recommendations, critiques cooking steps, and answers questions from that retrieved context.

Why it matters

A smaller, domain-specific model changes the operating trade-offs. It avoids API keys, per-token charges, provider outages, and sending prompts to a third party. In return, the application owner must prepare the data, train the model, assess failures, and maintain the serving path.

The article also distinguishes prompting from task training. RasavedaGPT learned three control tokens: RECOMMEND for structured JSON suggestions, IMPROVE for step-by-step recipe critique, and CHAT for conversational responses. The desired response shape is therefore part of training, rather than a request repeated in a prompt.

That is valuable for a narrow and well-understood domain, but it is not a shortcut to a general assistant. Broad reasoning and knowledge outside the training material still favor a pretrained foundation model.

In practice

Treat the experiment as a practical starting point for evaluating a niche model, not as a drop-in production blueprint.

  1. Define a bounded task, an owned dataset, and a measurable quality target before selecting model size.
  2. Separate retrieval from generation: Rasaveda uses vector search to ground recipe answers before generation.
  3. Supervise output structure exactly. Small models need explicit input/output examples to produce reliable JSON.
  4. Watch for overfitting. The author's first fine-tuning attempt did not generalize the desired structure; repeated, shuffled examples improved it.
  5. Compare the full cost of ownership, including dataset work, evaluation, compute, and maintenance—not only hosted API pricing.

The final point matters most. Moving inference in-house removes a vendor bill but transfers responsibility for quality and reliability to the team.

Takeaway

RasavedaGPT is a concrete learning project: a compact transformer can be written, trained, and shipped for a focused task without pretrained weights. Its appeal is not raw capability, but control over the vocabulary, architecture, data, and response path.

For a narrow domain, that trade-off can be sensible. For an open-ended assistant it will usually create more work than value, but it remains a strong way to understand model training and test a specialized product workflow.