{"slug": "i-built-a-40m-parameter-multilingual-language-model-for-delivery-riders-in-28", "title": "I Built a 40M-Parameter Multilingual Language Model for Delivery Riders in 28 Minutes.", "summary": "A developer writing on Medium trained a roughly 39.7-million-parameter multilingual language model covering English, Hindi, Bengali, Marathi and Tamil in approximately 28 minutes on a single NVIDIA Tesla T4 GPU using Google Colab's free tier, publishing it on Hugging Face as Indic-Delivery-Rider-SLM. The model is intended to run on-device for delivery riders so common communication tasks work without network connectivity or a cloud inference call, following an earlier approximately 30-million-parameter English-oriented version called Delivery-Rider-Assistant-SLM. The author frames the experiment as a study of how tokenizer design, multilingual data, architecture and training objectives interact under tight compute limits, not as a production-ready assistant.", "body_md": "**Project:** [Indic-Delivery-Rider-SLM on Hugging Face](https://huggingface.co/learner-subodh/Indic-Delivery-Rider-SLM)\n\n**Languages:** English, Hindi, Bengali, Marathi, and Tamil.\n\n**Training:** Approximately 28 minutes on a single NVIDIA Tesla T4 GPU using Google Colab’s free tier.\n\nImagine a delivery rider standing in the basement of a large apartment complex.\n\nIt is raining. There are two orders on the bike. One customer has just called.\n\n“Bhaiya, I entered the wrong flat number. Can you come to B-wing instead?”\n\nThe rider needs to acknowledge the change, confirm the location, and perhaps ask for a landmark.\n\nA simple interaction. Nothing extraordinary.\n\nExcept the phone has almost no network connectivity.\n\nThe delivery application is struggling to load. Its cloud-based support assistant cannot be reached. And the rider is left trying to solve a small problem without the digital assistance that the application normally provides.\n\nNow imagine something different.\n\nA compact language model running directly on the rider’s phone. No API call. No cloud dependency. No waiting for a remote inference server.\n\nThe model understands the request and suggests a short, polite response.\n\nThis is the idea behind a **Driver SLM — a small, domain-focused language model designed to assist delivery partners and drivers with common operational and communication scenarios.**\n\nIt is a deceptively interesting engineering problem.\n\nWe have spent the last few years making language models larger, more capable, and more expensive to operate. But not every problem needs a model with hundreds of billions of parameters.\n\nSometimes, the more interesting question is:\n\n**Can we build a small enough model that is genuinely useful for one specific job, even when the internet is unavailable?**\n\nI decided to explore that question by building a small language model from scratch, and then pushing the experiment in a more interesting direction: multilingual support.\n\nThe first version was a compact, approximately 30-million-parameter English-oriented Transformer.\n\nYou can refer to it here:\n\n**Delivery-Rider-Assistant-SLM — Hugging Face**\n\nThe next iteration became a roughly 39.7-million-parameter model designed to work across five languages: English, Hindi, Bengali, Marathi, and Tamil.\n\nI built the second model using PyTorch on a single NVIDIA Tesla T4 GPU through Google Colab’s free tier. The training run took approximately 28 minutes.\n\nThat does not mean I built a production-ready multilingual delivery assistant in 28 minutes. The experiment is more useful than that claim would suggest: it gave me a way to study how tokenizer design, multilingual data, architecture choices, training objectives, and evaluation interact when compute and model capacity are limited.\n\nThis article is about the journey: the problem, the architecture, the algorithms, the engineering decisions, the numbers, and most importantly — the lessons that apply well beyond this particular experiment.\n\nI will share the foundations with key implementation details. The objective is to explain how to think about building an SLM, not to publish a copy-and-run reproduction of the project.\n\nYou can explore the model and its technical details here:\n\n**Indic-Delivery-Rider-Assistant-SLM — Hugging Face**\n\nLet’s start with an uncomfortable question.\n\nWhy would anyone spend time building a 30M-parameter language model when open models with billions of parameters are readily available?\n\nImagine hiring an exceptionally knowledgeable assistant.\n\nThis person knows almost everything. They can explain physics, write code, summarize research papers, and discuss world history.\n\nBut they are expensive, take time to reach, and need a reliable internet connection before they can answer your question.\n\nNow imagine hiring someone specifically trained for a particular job.\n\nThey may not know everything, but they understand the situations they encounter every day.\n\nThat is the intuition behind a domain-specific SLM.\n\nFor a delivery partner, the useful tasks are relatively focused:\n\nA general-purpose LLM is capable of much more than this. But that additional capability comes with resource requirements that may not be justified for every interaction.\n\nA small model creates an interesting alternative.\n\n**1. Connectivity independence**\n\nA locally executed model can generate responses without making a request to a cloud inference service.\n\nThis matters in basements, remote areas, warehouses, highways, and other environments where connectivity is unreliable.\n\n**2. Lower inference footprint**\n\nA model with 30 million parameters has a much smaller weight footprint than a multi-billion-parameter model.\n\nAt FP16, its raw parameter storage is approximately:\n\n30M parameters × 2 bytes (FP16) ≈ 60 MB\n\nThat is only the weight storage — not the complete runtime memory requirement — but it gives us an idea of the scale.\n\n**3. Task specialization**\n\nInstead of trying to solve every possible language task, we can concentrate model capacity on a narrower problem.\n\nThis does not automatically make a small model better. Its ability is still constrained by architecture, data quality, and training.\n\nBut it gives us more control over the system we are trying to build.\n\nNot necessarily.\n\nIf the objective is to achieve the best possible performance with limited development effort, fine-tuning a suitable pretrained model is often the more practical route.\n\nA pretrained model already understands a substantial amount of language structure. Training a model from scratch means learning those patterns through your own training process.\n\nSo why do it?\n\nBecause building one from scratch is an excellent way to understand what actually happens inside a language model.\n\nYou work with tokenization, embeddings, attention, positional information, normalization, optimization, backpropagation, and autoregressive generation.\n\nYou stop treating the Transformer as a black box.\n\nFor this experiment, that was an important part of the objective.\n\n**The goal was not to compete with general-purpose LLMs. It was to understand how far a compact, purpose-oriented language model could go under severe compute constraints.**\n\nThe second version of the project is a multilingual, decoder-only language model implemented from scratch in PyTorch.\n\nThe model is available here:\n\n[Indic-Delivery-Rider-SLM — Hugging Face](https://huggingface.co/learner-subodh/Indic-Delivery-Rider-SLM)\n\n**Model architecture**\n\nThe teal dashed line shows the output projection reusing the embedding matrix. Next is what happens inside each of the 10 blocks.\n\n**Tokenizer and language coverage**\n\n**Training environment**\n\nA few architectural decisions are worth examining.\n\nFirst, this is still a decoder-only causal Transformer. It receives a sequence of tokens and learns to predict the next token, making it suitable for autoregressive text generation.\n\nThe architecture uses 10 Transformer layers, a hidden dimension of 512, and Grouped-Query Attention.\n\nIt also uses RoPE for positional information, RMSNorm for normalization, and SwiGLU in the feed-forward network. These choices make the implementation closer to the design patterns used in modern decoder-only language models.\n\nThe tokenizer and training pipeline has been designed to cover five languages.\n\nThis has effects in almost every stage of the project: vocabulary design, data preparation, sequence lengths, model training, and evaluation.\n\nAnd perhaps the most interesting part: the complete training run took approximately 28 minutes on a single Tesla T4 GPU.\n\nThat is not a claim that we have built a production-ready mobile assistant in 28 minutes. It is a demonstration that a compact Transformer can be trained and explored with a surprisingly modest compute budget.\n\nBeing precise about these details matters.\n\nHere is one of the most important lessons from building small language models:\n\n**A small model has very little room to compensate for poor training data.**\n\nA large pretrained model has already encountered enormous amounts of language. It has learned grammar, vocabulary, common relationships, and many general patterns.\n\nA compact model trained from scratch starts with much less prior knowledge.\n\nIf we give it repetitive, irrelevant, or poorly structured examples, it will learn those patterns too.\n\nImagine teaching a delivery rider using only conversations about delayed orders.\n\nThe rider may become excellent at apologizing for delays but completely unprepared to handle an incorrect address or an inaccessible apartment.\n\nA language model behaves similarly.\n\nFor an instruction-oriented assistant, a training example can be represented as a user message followed by an assistant response.\n\nFor example:\n\n**User:** The customer says the delivery address is incorrect. What should I ask?\n\n**Assistant:** Politely ask the customer to confirm the correct building, wing, and flat number before proceeding.\n\nAnother example:\n\n**User:** The apartment entrance is restricted and security is not allowing entry.\n\n**Assistant:** Contact the customer, explain the access issue, and request instructions for an approved entry point.\n\nThese examples illustrate the desired interaction format. They are not claims about the exact records used in the experiment.\n\nThe multilingual experiment uses three sources, with different roles in the training pipeline.\n\n**1. Bitext customer-support data**\n\nI started with the Bitext customer-support instruction dataset as the English conversational foundation. The notebook uses up to 12,000 training examples and 400 validation examples from this source.\n\nThis provides examples of customer-support interactions and response patterns. It is not a dataset of actual delivery-rider conversations.\n\n**2. NLLB-200 translations**\n\nTo extend the experiment to Indian languages, I used the distilled NLLB-200 600M translation model to translate a stratified subset of the English data into Hindi, Bengali, Marathi, and Tamil.\n\nThe translation pipeline includes filters for issues such as unresolved placeholders, script mismatches, repetition, and unsuitable length. Translation outputs are cached so that the preparation process does not need to be repeated every time the notebook runs.\n\nThis is an important distinction: translated examples increase language coverage, but they are not equivalent to independently collected and native-speaker-verified conversations.\n\n**3. Aya instruction data**\n\nI also incorporated native-script instruction examples from the Aya dataset for Hindi, Bengali, Marathi, and Tamil.\n\nThis adds multilingual instruction data beyond machine-translated customer-support examples. However, Aya is general instruction data, not a delivery-specific corpus.\n\n**The resulting dataset**\n\nThe final prepared dataset contains:\n\nThe dataset is intentionally mixed. English examples come from Bitext, while the four Indian languages draw from translated Bitext examples and Aya data.\n\nThe language distribution is not perfectly uniform. For example, English has 12,000 Bitext training examples, while the Indian-language portions combine different quantities of translated and Aya examples.\n\nThat matters because a multilingual model does not automatically become balanced simply because it has multiple languages in its training data.\n\nThere are three limitations worth keeping in view.\n\nFirst, the translated examples inherit some of the limitations of machine translation. They need native-speaker review before being treated as reliable training targets.\n\nSecond, the general instruction examples do not establish delivery-domain expertise. They help expose the model to language and instruction patterns, but they do not teach verified platform policies or operational workflows.\n\nThird, the dataset is relatively small for training a multilingual model from scratch. The results should therefore be interpreted as an experiment in architecture and training under constrained compute, not as evidence of broad multilingual competence.\n\nFor a production-oriented system, I would want a much stronger dataset: real or carefully simulated rider scenarios, native-speaker review, verified operational responses, and explicit coverage of regional expressions and code-switching.\n\nThe final dataset contained 25,012 examples: 23,816 for training and 1,196 for validation, spanning English, Hindi, Bengali, Marathi and Tamil.\n\nEnglish examples came from the Bitext customer-support dataset, while the four Indic languages combined Aya instruction data with machine-translated Bitext examples. This gave the model multilingual training coverage, although the dataset was not a collection of real delivery-rider conversations.\n\n**Data and licensing note:** The experiment combines datasets and model-derived translations with different licensing terms. In particular, the NLLB-200 component is identified as CC-BY-NC-4.0. The resulting model should not be assumed to be cleared for commercial use. Anyone intending to distribute or use the weights commercially should review the applicable dataset and model licenses and obtain appropriate legal guidance.\n\n**Duplicate leakage**\n\nSuppose the training set contains:\n\n“Customer has entered the wrong flat number.”\n\nAnd the validation set contains:\n\n“The customer provided an incorrect apartment number.”\n\nThese examples are not identical, but they are very similar.\n\nIf related examples appear in both training and validation, the validation result may look better than actual generalization.\n\nDeduplication and careful data splitting are essential.\n\n**Coverage imbalance**\n\nIf most examples describe delivery delays, the model may become disproportionately good at responding to delays.\n\nInspect the distribution of scenarios rather than relying only on the total number of training records.\n\n**Incorrect or unsafe responses**\n\nA model should not learn to invent payment outcomes, make unsupported promises, or recommend actions that contradict platform policy.\n\nFor sensitive operational situations, verified business rules and human escalation should remain part of the system design.\n\nA useful way to think about the dataset is this:\n\nThe model’s training examples are its operating experience. Repeating the same experience thousands of times does not make it an expert in every situation.\n\nOnce we have text, we need to convert it into numbers.\n\nNeural networks cannot directly process a sentence as a sequence of ordinary words. They process numerical representations.\n\nA tokenizer converts text into token IDs.\n\n```\ntoken_ids = tokenizer.encode(    \"Please confirm the apartment number.\")\n```\n\nThe resulting IDs represent the token sequence according to the tokenizer’s vocabulary.\n\nTokens are not necessarily complete words. They can represent words, subwords, punctuation, and other text units.\n\nThis is why subword tokenization is useful.\n\nA delivery application may encounter building names, abbreviations, unusual spellings, local expressions, and unfamiliar combinations of words.\n\nA word-level tokenizer struggles with unseen words. Character-level tokenization can produce very long sequences.\n\nSubword tokenization offers a practical compromise.\n\nByte Pair Encoding, or BPE, starts with smaller text units and repeatedly merges frequent adjacent pairs.\n\nSuppose a corpus contains many variations of the word “delivery.”\n\nThe tokenizer may learn recurring combinations of characters or subword units and add them to its vocabulary.\n\nOver time, common patterns can be represented by fewer tokens.\n\nA simplified pair-merging operation looks like this:\n\n``` python\ndef merge_pair(tokens, pair, replacement):    merged = []    i = 0\nwhile i < len(tokens):        if tokens[i:i + 2] == list(pair):            merged.append(replacement)            i += 2        else:            merged.append(tokens[i])            i += 1\nreturn merged\n```\n\nThis illustrates the core operation, not a complete BPE training and encoding implementation.\n\nThe first experiment used the GPT-2 tokenizer through tiktoken. That was convenient, but it was not an ideal choice for a model intended to handle several Indian languages.\n\nA tokenizer that represents English efficiently can behave very differently on scripts it was not designed to handle efficiently.\n\nConsider the number of tokens required to represent a piece of text. If a tokenizer splits a sentence into too many pieces, the model must process a longer sequence to represent the same content.\n\nThat affects more than convenience:\n\nFor this experiment, **I trained a SentencePiece BPE tokenizer with a vocabulary of 20,000 tokens.**\n\nThe tokenizer includes byte fallback, digit splitting, and special markers for user messages, assistant responses, and language identification.\n\nI also upsampled underrepresented languages in the tokenizer-training corpus, with the aim of giving their scripts sufficient representation in the learned vocabulary.\n\nRather than assuming the new tokenizer was better, I compared it with GPT-2 BPE on held-out text.\n\nI measured tokenizer fertility: the number of tokens produced per whitespace-delimited word. Lower values indicate that fewer tokens are needed to represent the same sample under this measurement.\n\nThe results were:\n\nThe difference is particularly striking for the Indian-language samples.\n\nFor Tamil, the measured fertility fell from 23.44 tokens per word to 1.81 (92.28% fewer tokens per word). For Bengali, it fell from 12.79 to 1.45 (88.66% fewer tokens per word).\n\nThis is a tokenizer-efficiency result, not a language-understanding result. It does not prove that the model understands Tamil or Bengali better. It shows that the new tokenizer represents the tested text much more compactly.\n\nThat distinction matters. Better tokenization can make multilingual training more practical, but it cannot compensate for insufficient data, weak training, or poor evaluation.\n\nFor a small model, tokenizer design is not a preprocessing detail. It is part of the model architecture and its parameter budget.\n\nHere is where tokenization becomes an architectural decision.\n\nEvery vocabulary token requires an embedding vector.\n\nThe embedding matrix contains 50,000 tokens, each represented by a 384-dimensional vector.\n\n50,000 × 384 = 19.2 million parameters.\n\nThat is 19.2 million parameters in the embedding table alone.\n\nIn a model with only 30 million parameters, that would be an enormous allocation.\n\nThis is why vocabulary design is especially important for compact models.\n\nA smaller domain-oriented vocabulary could reduce the embedding footprint. But making it too small can increase sequence length because common words are split into more pieces.\n\nThere is a trade-off between:\n\nIn this experiment, I used GPT-2 BPE encoding through tiktoken. It is a convenient, established tokenizer choice, rather than a custom tokenizer trained specifically for delivery language.\n\nFor a future version, I would investigate domain-oriented vocabulary design as an explicit optimization step.\n\nNow we have token IDs.\n\nHow does the model learn to understand their relationships?\n\nWe use a decoder-only Transformer.\n\nThe idea is easier to understand if we break it into components.\n\nA token ID is just an integer.\n\nAn embedding layer maps it into a learned vector.\n\nIf the vocabulary size is (V) and the embedding dimension is (d), the embedding matrix is:\n\nE ∈ R^(V × d)\n\nThe model looks up the vector corresponding to each input token.\n\nThese vectors are learned during training. We do not manually assign semantic meanings to them.\n\nConsider:\n\n“The rider called the customer.” vs.\n\n“The customer called the rider.”\n\nThe same words appear, but the meaning is different.\n\nA Transformer therefore needs a way to represent token positions.\n\nThis version uses Rotary Position Embeddings, commonly called RoPE.\n\nInstead of simply adding a learned position vector to each token embedding, RoPE applies position-dependent rotations to query and key representations inside the attention mechanism.\n\nThe important intuition is that the attention calculation becomes sensitive to the relative positions of tokens.\n\nThis is useful because language is not just a collection of words. The relationship between two words also depends on where they appear in a sequence.\n\nRoPE has become a widely used positional-encoding approach in modern decoder-only Transformer architectures.\n\nThis is the heart of the Transformer.\n\nImagine the model reading:\n\n“The customer requested a different address because the original building was closed.”\n\nWhen processing the end of the sentence, it needs to connect the current information with what appeared earlier.\n\nAttention lets each token determine which other tokens in the available context are relevant.\n\nIt uses three representations:\n\nThe scaled dot-product attention equation is:\n\nAttention(Q, K, V) = softmax((Q × Kᵀ) / √dₖ) × V\n\nThe intuition:\n\nIn other words, attention lets the model look back at relevant parts of the input rather than treating every token independently.\n\nA language model predicts the next token.\n\nDuring training, it must not see future tokens when making that prediction.\n\nThis is enforced using a causal mask.\n\nA simplified implementation using PyTorch’s scaled-dot-product attention looks like this:\n\n```\ny = F.scaled_dot_product_attention(    q,    k,    v,    is_causal=True)\n```\n\nThe causal setting prevents a position from attending to future positions.\n\nWithout it, the model could indirectly access information it is supposed to predict.\n\nWhy have multiple attention heads?\n\nDifferent heads can learn different relationships.\n\nOne may focus on nearby tokens. Another may learn relationships between words that are farther apart. Another may respond to structural or grammatical patterns.\n\nThe outputs of these heads are combined to form a richer representation.\n\nThis model uses Grouped-Query Attention (GQA), with eight query heads and four key/value heads.\n\nIn standard multi-head attention, each query head has its own key and value head. GQA allows multiple query heads to share a key/value head.\n\nThe benefit is a more compact key/value representation, which can reduce the memory required for the attention cache during autoregressive inference.\n\nFor this architecture, eight query heads share four key/value heads. It is a practical compromise between the expressiveness of multi-head attention and the efficiency benefits of multi-query attention.\n\nAttention gathers information from the sequence. The feed-forward network transforms the representation at each position.\n\nThis model uses SwiGLU, a gated feed-forward design.\n\nAt a high level, SwiGLU uses two learned projections: one contributes the content representation, while the other provides a learned gate. Their interaction is followed by a projection back to the model dimension.\n\nThe gating mechanism gives the network a more flexible way to control which information flows through the feed-forward block.\n\nThe feed-forward hidden dimension in this experiment is 1,408.\n\nThis is one of the architectural differences between the original compact GPT-style experiment and the newer Llama-style implementation.\n\nDeep networks need stable information and gradient flow.\n\nResidual connections provide a direct path around a transformation:\n\ny = x + f(x)\n\nThis implementation uses RMSNorm rather than standard LayerNorm.\n\nRMSNorm normalizes representations using their root-mean-square magnitude. It does not perform the mean-centering step used by LayerNorm.\n\nIt is a simpler normalization operation that is widely used in modern decoder-only Transformer designs.\n\nTogether, residual connections and RMSNorm help maintain stable information and gradient flow through the Transformer blocks.\n\nTogether, these components make it easier to train multiple Transformer blocks.\n\nThe architecture follows this high-level flow:\n\n```\nInput Token IDs      |      vToken Embeddings      |      v+-----------------------------+|     10 Transformer Blocks   ||                             ||  RoPE + GQA + RMSNorm       ||  SwiGLU Feed-Forward        |+-----------------------------+      |      vFinal RMSNorm      |      vVocabulary Projection      |      vNext-Token Logits\n```\n\nThe model has 10 Transformer layers, a hidden dimension of 512, eight query heads, and four key/value heads.\n\nThe input and output embeddings are tied, meaning the model shares the embedding weights with the output vocabulary projection rather than learning two independent matrices.\n\nThe result is a compact decoder-only architecture that incorporates several design choices used in modern language models, while remaining small enough to train in a constrained environment.\n\nOne of the most interesting parts of building a small model is understanding where the parameters go.\n\nA model’s parameter count is not simply a measure of its size. It is an allocation decision.\n\nWe must distribute capacity across:\n\nIncreasing the hidden dimension can improve representational capacity, but it also increases the size of several matrices.\n\nIncreasing the number of layers adds depth, but also increases computation and memory requirements.\n\nIncreasing the vocabulary can make tokenization more efficient, but may substantially increase embedding parameters.\n\nThe model contains approximately 39.7 million parameters.\n\nThe parameter breakdown is particularly interesting:\n\nThe embedding table is still a substantial part of the model, but its share is considerably more controlled than in the original experiment.\n\nThis is one reason the tokenizer change mattered. A vocabulary of 20,000 tokens, combined with a hidden dimension of 512, gives an embedding allocation of approximately 10.2 million parameters.\n\nThe remaining capacity is available for the Transformer layers, attention projections, feed-forward networks, and normalization components.\n\nI also retained weight tying between the input embeddings and output projection. This avoids maintaining two separate sets of vocabulary-sized weights.\n\nThe broader lesson is that parameter count should be treated as a budget. Vocabulary size, hidden dimension, layer count, attention design, and feed-forward width all compete for that budget.\n\nA model with more parameters is not automatically better. The question is whether those parameters are allocated in a way that supports the task and the constraints of the target system.\n\nThere is no free improvement.\n\nOne useful technique is weight tying.\n\nA language model has an input embedding matrix and an output projection that maps hidden states back to vocabulary logits.\n\nThese can share weights:\n\nW_output = E_tokenᵀ\n\nThis reduces the number of independent parameters.\n\nFor compact models, that saving can matter.\n\nI initially made a simple mistake: I estimated the model size mentally.\n\nThe project description said 45M parameters. The actual model was approximately 30M.\n\nThat is a good reminder to measure rather than guess.\n\n```\ntotal_params = sum(    p.numel()    for p in model.parameters())\nprint(f\"{total_params / 1e6:.2f}M parameters\")\n```\n\nIt is a small detail, but it reflects an important engineering habit: verify the actual artifact, not the configuration you intended to build.\n\nWe now have the data, tokenizer, and Transformer.\n\nThe next step is training.\n\nThe objective is next-token prediction.\n\n“The rider reached the building”\n\nThe model receives the sequence and learns to predict the next token at every position.\n\nThe input and target sequences are shifted versions of each other.\n\n**Step 1**\n\nInput: The\n\nTarget: rider\n\n**Step 2**\n\nInput: The rider\n\nTarget: reached\n\n**Step 3**\n\nInput: The rider reached\n\nTarget: the\n\n**Step 4**\n\nInput: The rider reached the\n\nTarget: building\n\nAt each training step, the model receives the preceding tokens as context and learns to predict the next token. As the sequence grows, the context expands, allowing the model to learn how words relate to one another.\n\nThe model produces logits representing its predictions over the vocabulary.\n\nWe calculate cross-entropy loss against the correct next tokens.\n\nThe objective can be written as:\n\nLoss = -(1 / N) × Σ log P(xᵢ | previous tokens)\n\nThe model is penalized when it assigns a low probability to the actual next token.\n\nBackpropagation calculates how each parameter contributed to the error, and the optimizer updates the parameters.\n\nThis process repeats across batches.\n\nThe model is trained using next-token prediction, but the training objective includes an important detail: different parts of the formatted sequence receive different loss weights.\n\nThe examples contain user messages, assistant responses, language markers, and structural tokens.\n\nI used response-weighted loss:\n\nWhy do this?\n\nThe objective is to build an instruction-following model, not simply to reproduce the entire input sequence equally well.\n\nThe user’s prompt provides context. The assistant’s response is the primary output we want the model to learn to generate.\n\nGiving response tokens a higher weight places more emphasis on the part of the sequence that matters most for the intended interaction.\n\nThe prompt is not ignored; it still contributes to the learning process, but with a smaller weight.\n\nThe optimizer determines how the model’s parameters change during training.\n\nAdam maintains moving averages of gradients and squared gradients, allowing adaptive parameter updates.\n\nAdamW separates weight decay from the gradient-based update. This is an important distinction from simply adding an L2 penalty to the loss.\n\nThe experiment used AdamW with:\n\nThe learning rate followed a warmup-plus-cosine schedule.\n\nWarmup gradually increases the learning rate during the early part of training. Cosine decay then reduces it towards the minimum learning rate.\n\nThe schedule was tied to the available training-time budget, which is useful when working in a constrained notebook environment.\n\nThe training run used FP16 automatic mixed precision.\n\nThe idea is to use lower-precision operations where appropriate to reduce memory consumption and improve hardware efficiency.\n\nThis is particularly useful when working with limited GPU memory.\n\nHowever, precision support depends on the actual GPU and runtime. The important engineering habit is to verify the precision mode and actual performance rather than assume that a configuration is efficient simply because it executes.\n\nThe broader lesson:\n\n**A training script that runs is not necessarily a training script that runs efficiently.**\n\nAlways check the hardware, precision mode, and actual performance.\n\nThe learning rate controls the size of parameter updates.\n\nStarting with an aggressive learning rate can destabilize early training.\n\nWarmup gradually increases the learning rate before the main training phase.\n\nCosine decay then reduces it smoothly.\n\nThink of it as accelerating gradually and slowing down as you approach the destination.\n\nThis is a common and useful training strategy for Transformer models.\n\nThe second model was trained on a single NVIDIA Tesla T4 GPU through Google Colab’s free tier.\n\nThe actual run lasted approximately 28.1 minutes.\n\nA few numbers help put the run into perspective:\n\nThe model was trained using FP16 mixed precision and AdamW, with a warmup-plus-cosine learning-rate schedule.\n\nThe best response-only validation negative log-likelihood was approximately 1.925, reached around 17.8 minutes into training.\n\nTraining loss continued to decrease after that point, eventually reaching approximately 0.622 near the end of the run. However, validation loss began increasing after its best point and reached approximately 1.982.\n\nThat divergence is an early overfitting signal.\n\nIt is also a useful reminder that the final checkpoint is not necessarily the best checkpoint. The experiment retained the checkpoint with the best validation result rather than simply using the last set of weights.\n\nOne important clarification: this validation metric is not directly comparable with the 0.7974 validation loss from the earlier model. The two experiments use different model architectures, tokenizers, datasets, and loss formulations. The newer experiment also reports response-only validation NLL.\n\nComparing the two numbers as if they measured the same task under the same conditions would be misleading.\n\n**First: the training budget is an engineering constraint.**\n\nA free GPU session is not an unlimited resource. Data preparation, training, evaluation, checkpointing, and export all compete for time.\n\nThe pipeline needs to be designed around the actual available compute.\n\n**Second: the best checkpoint may occur before training ends.**\n\nThe training loss continued improving while validation loss began deteriorating. Tracking validation performance and retaining the best checkpoint is essential.\n\n**Third: a lower loss is not the same as a better assistant.**\n\nThe loss curve tells us how well the model predicts held-out tokens under the chosen objective. It does not tell us whether a rider would receive a correct, concise, or operationally safe answer.\n\nThat requires a separate evaluation process.\n\n**First: evaluation consumes compute.**\n\nIt is tempting to evaluate hundreds of batches after every few training iterations.\n\nBut evaluation requires forward passes too.\n\nOn a free GPU, excessive evaluation can consume a significant portion of the available training budget.\n\nUse representative evaluation batches and choose sensible evaluation intervals.\n\n**Second: gradient accumulation changes the training schedule.**\n\nWhen using gradient accumulation, the learning-rate scheduler should advance with optimizer updates, not with every micro-batch.\n\nOtherwise, the schedule can finish earlier than intended.\n\n**Third: checkpoint selection matters.**\n\nThe last training checkpoint is not necessarily the best one.\n\nTrack validation loss and preserve the best checkpoint.\n\nA compact model trained on a limited dataset can overfit sooner than expected.\n\nThis is where the real work begins.\n\nA language model can generate fluent sentences and still misunderstand the problem.\n\nConsider this prompt:\n\n“The customer says the building entrance is closed, but the order is marked as delivered.”\n\nA response might sound professional but recommend an incorrect action.\n\nThat is not a successful result.\n\nFor a practical assistant, we need to evaluate behavior rather than rely exclusively on training metrics.\n\nI evaluated the model at two different levels: held-out language-model performance and a small set of generation checks.\n\nThe first gives us a quantitative view of next-token prediction. The second gives us a preliminary look at what the model actually generates.\n\nToken-level loss is difficult to compare across languages when different tokenizers split text into very different numbers of tokens.\n\nTo get a more comparable view of the model’s held-out performance, I also examined bits per byte.\n\nThe measured domain-data results were:\n\nFor the general-data evaluation:\n\nA general-data result was not reported for English in this evaluation.\n\nLower bits per byte indicates better predictive performance on the evaluated text under this metric. It does not establish task correctness or conversational quality.\n\nThese values should also be interpreted within the limits of the evaluation data. They are not a substitute for a representative benchmark of real delivery-rider interactions.\n\nI also tested generation using three hand-written prompts per language.\n\nThe checks included:\n\nThe automatic language-identification check returned 1.00 for all five languages on this small prompt set.\n\nHowever, three prompts per language are far too few to establish robust language identification or reliable multilingual performance. Script-based checks can also mistake text in the right script for a correct answer.\n\nThe generation results were mixed. Some outputs were recognizably in the requested language, but others were generic, incomplete, or irrelevant to the prompt.\n\nFor example, one Marathi generation was only:\n\n“जयसिंगाने”\n\nThat is not a useful answer to a delivery-support request. It is a clear failure, and it is important to show it rather than hide it behind aggregate metrics.\n\nThe English outputs were more fluent, but some included unsupported promises such as saying that an address would be updated immediately, even though the model was not connected to an order-management system.\n\nThis is exactly why generation quality must be evaluated separately from script detection and language-model loss.\n\nThe experiment demonstrates that a small model can be trained with a multilingual tokenizer and data pipeline covering five languages.\n\nIt also provides preliminary evidence that the tokenizer represents the tested Indian-language text more efficiently than GPT-2 BPE.\n\nIt does not establish that the model is a reliable delivery assistant in all five languages.\n\nThe generation checks are small, the data is not a field-collected delivery corpus, and the outputs still contain clear failures.\n\nA more serious evaluation would require:\n\nThe model should not independently decide payment, safety, or dispute outcomes. Verified business systems must remain the source of truth. The model can help formulate communication, but it should not invent operational decisions.\n\nFor me, this is one of the most valuable findings from the experiment: a multilingual model that can produce text in a script is not necessarily a multilingual assistant that can solve the user’s problem.\n\nThese are short excerpts from the model’s saved generations. They are included to show both the progress and the limitations of the experiment.\n\n**English**\n\n“Please provide us with the new address, and we will make sure to update it for you right away.”\n\n**Hindi**\n\n“हम आपकी चिंताओं को शीघ्रता से संबोधित करने के लिए प्रतिबद्ध हैं।”\n\n**Bengali**\n\n“আশ্বস্ত হোন, আমি এখানে আছি আপনাকে প্রক্রিয়াটি পরিচালনা করতে এসেছি।”\n\n**Marathi**\n\n**Tamil**\n\n“இந்த செயல்முறையில் உங்களுக்கு உதவ எங்கள் குழு இங்கே உள்ளது.”\n\nThese are raw excerpts, not human-verified translations or evidence of task success. The Marathi example is visibly incomplete, and the English excerpt makes an operational promise the model cannot independently fulfill. Native speakers should review the examples before they are treated as meaningful language-quality demonstrations.\n\nI find four categories particularly useful.\n\n**Fluent and correct:** The response is relevant, understandable, and appropriate.\n\n**Fluent but incorrect:** The response sounds convincing but gets the situation wrong.\n\n**Off-topic:** The model fails to address the actual request.\n\n**Repetitive:** The model repeats phrases or gets stuck in a generation loop.\n\nThe second category is especially important.\n\nA confident wrong answer can be more problematic than a model that simply asks for clarification.\n\nFor a real deployment, I would go further:\n\nThe evaluation dataset should be kept separate from training data, ideally with scenario-level separation to reduce leakage.\n\nAnd one rule should be non-negotiable:\n\n**The model should not independently decide sensitive payment, safety, or dispute outcomes.**\n\nVerified business systems should remain the source of truth. The model can help communicate information, but it should not invent operational decisions.\n\nTraining a model is not the same as deploying an application.\n\nFor this version, I added an export path that maps the custom model’s weights into a Hugging Face Llama-compatible model structure.\n\nThe notebook constructs a LlamaForCausalLM configuration, transfers the model weights, and includes a numerical comparison between the custom implementation and the exported model's logits.\n\nThe purpose of this check is to verify that the exported model preserves the original model’s forward-pass behavior.\n\nThe notebook contains the comparison code, but the output was not saved in the version I reviewed. I would therefore rerun that cell and capture its numerical result before claiming that the equivalence check passed.\n\nThe export also includes the SentencePiece tokenizer model and a format configuration file. The SentencePiece model remains important: the tokenizer should not be assumed to be interchangeable with an arbitrary tokenizer simply because the model weights have been exported into a standard architecture.\n\nThe artifact is not automatically interchangeable with an arbitrary Hugging Face AutoModel architecture.\n\nA deployment system needs to know how the model was constructed.\n\nThus, it would need to:\n\nThe model export is a useful step towards interoperability. It is not evidence that the model has already been deployed on a phone.\n\nA simplified generation process looks like:\n\n```\nUser message     |     vTokenizer     |     vToken IDs     |     vTransformer forward pass     |     vNext-token probabilities     |     vToken selection     |     vAppend token and repeat     |     vDecode response\n```\n\nThe model predicts one token at a time.\n\nThe application controls when generation stops, how many tokens may be generated, and how the response is presented.\n\nFor a short delivery interaction, concise generation is often preferable to an elaborate answer.\n\nA model with approximately 39.7 million parameters has a relatively small raw weight footprint.\n\nUsing the parameter count and nominal precision, the approximate storage requirements for the weights alone are:\n\nThese are approximate weight-storage estimates, not measurements of a complete deployed application.\n\nActual memory requirements also include the model runtime, tokenizer assets, intermediate tensors, key/value cache, and application components.\n\nThe notebook also includes a CPU forward-pass sanity check. On the tested environment, it measured approximately 14.4 forward passes per second using two CPU threads, without a KV cache.\n\nThat is useful as a basic execution check, but it is not a mobile-device benchmark. It should not be interpreted as tokens per second or as evidence of acceptable phone latency.\n\nI have not established a production mobile deployment, nor completed GGUF or ONNX conversion and device-level benchmarking. Those remain future engineering steps.\n\nFor a genuine edge deployment, I would measure:\n\nA model that runs on a desktop CPU or training GPU may behave very differently on a mobile device. The target hardware must be part of the evaluation process, not an assumption made from parameter count alone.\n\nThese are theoretical weight-storage estimates, not complete application memory requirements.\n\nActual deployment also needs memory for the runtime, tokenizer, KV cache, intermediate tensors, and application components.\n\nQuantization can reduce the model footprint, but it may affect output quality.\n\nThe right way to evaluate it is to compare the original and quantized models on the same representative scenarios.\n\nFor a mobile deployment, I would measure:\n\nA model that performs well on a training GPU may behave very differently on a low-cost mobile device.\n\nThat is why deployment benchmarking must happen on the actual target hardware.\n\nThere is an important distinction I want to make about this project.\n\n**This was a fun, compact engineering exercise — not a claim that a production-grade Driver SLM can be delivered in 23 minutes.**\n\nThe objective was to understand the foundations of building and training a language model from scratch, using a constrained compute environment.\n\nBut the underlying training fundamentals are not limited to a 30M-parameter experiment.\n\nThe same broad workflow can be extended to a much more serious system:\n\nThe SLM Development Pipeline\n\nWhat changes is the scale, rigor, and supporting infrastructure.\n\n**1. Domain-specific data engineering**\n\nThe general customer-support dataset would be supplemented or replaced with carefully curated delivery-specific examples.\n\nThis would involve realistic rider interactions, approved operational workflows, language variations, and verified responses.\n\nData governance, privacy, consent, licensing, and quality controls would become first-class requirements.\n\n**2. Stronger evaluation**\n\nWe would need a proper benchmark covering scenario coverage, correctness, robustness, safety, and generalization.\n\nWe would also compare the from-scratch model against a fine-tuned pretrained SLM.\n\nThe goal would be to justify the architecture through evidence, not preference.\n\n**3. System-level architecture**\n\nA production assistant would not rely on a language model for every decision.\n\nIt could combine:\n\nThis is an important architectural principle.\n\nA useful AI product is often a system of cooperating components, not a model operating in isolation.\n\n**4. Mobile inference optimization**\n\nThe model would be exported to a suitable mobile runtime, quantized, and benchmarked on representative low-end devices.\n\nMemory, latency, power consumption, and offline behavior would become explicit engineering objectives.\n\n**5. Continuous evaluation and improvement**\n\nA production system would need monitoring, failure analysis, versioning, regression tests, and a controlled update process.\n\nThe model should improve based on validated evidence rather than blindly learning from every interaction.\n\nThe important takeaway is that the foundational training recipe remains relevant.\n\nThe data pipeline, tokenizer, architecture, optimization, validation, and generation process are the same broad building blocks. Production engineering adds scale, governance, reliability, integration, and much stronger evaluation.\n\nThat is why I find this experiment valuable beyond the immediate use case.\n\nEvery useful experiment should leave us with a better set of questions.\n\nThis version answered some questions about multilingual tokenization and constrained training, but it also exposed several areas that need more work.\n\nIf I were taking the project forward, I would prioritize five things.\n\n**1. Improve the quality of multilingual data.**\n\nThe current pipeline combines English customer-support data, machine-translated examples, and general multilingual instruction data.\n\nThe next step would be native-speaker review and a more carefully curated set of delivery-specific interactions in each language.\n\n**2. Build a proper multilingual evaluation benchmark.**\n\nThree prompts per language are useful for an initial smoke test, not for establishing reliable language performance.\n\nI would build a larger held-out benchmark with scenario-level separation, native-speaker review, task correctness criteria, and explicit tests for unsupported claims.\n\n**3. Compare against pretrained multilingual baselines.**\n\nTraining from scratch was valuable for understanding the architecture and training process.\n\nBut it does not establish that training from scratch is the best way to build this application. I would compare the model with suitable pretrained multilingual small language models fine-tuned on the same data.\n\n**4. Improve response quality and operational grounding.**\n\nThe model should learn to ask for clarification when information is missing and avoid promising actions it cannot perform.\n\nFor real order, payment, and delivery information, the assistant should rely on verified application APIs and deterministic business logic rather than generating answers from model parameters alone.\n\n**5. Validate actual edge deployment.**\n\nThe model’s parameter count makes mobile inference worth investigating, but the CPU sanity check is not a substitute for phone testing.\n\nI would export and quantize the model, benchmark it on representative devices, and measure latency, memory, battery consumption, and response quality.\n\nThe next iteration should be driven by those measurements rather than by model size alone.\n\nThe Driver SLM is one example of a much broader opportunity.\n\nThink about people who work outside conventional office environments.\n\nAgricultural workers in areas with poor connectivity.\n\nField technicians who need quick access to repair procedures.\n\nDelivery partners who handle repetitive customer interactions.\n\nIndustrial workers who need context-specific instructions.\n\nRemote teams that cannot depend on a reliable cloud connection.\n\nNot every AI interaction requires a giant model.\n\nSometimes, the task is narrow, the vocabulary is predictable, and the environment imposes strict constraints on connectivity, latency, cost, and hardware.\n\nThat creates an interesting opportunity for small language models.\n\nThe challenge is not simply to shrink an existing model.\n\nIt is to understand the task, choose the right architecture, prepare the right data, and define what useful performance actually means.\n\nFor me, the most valuable part of this experiment was not simply getting a Transformer to train.\n\nIt was seeing how decisions that can look like isolated implementation details — tokenizer vocabulary, language sampling, attention design, loss weighting, validation strategy, and checkpoint selection — interact when model capacity and compute are limited.\n\nThe first version helped me understand the mechanics of building a compact language model. The multilingual version made the engineering problem more interesting: the model had to account for different scripts, different tokenization behavior, different data sources, and uneven evaluation quality.\n\nIt also reinforced an important lesson: a successful training run is only one milestone. The real work is establishing whether the model solves the intended problem reliably.\n\nThe future of AI will not be defined only by who builds the largest model. It will also be shaped by who can identify the right problem, build an appropriately sized solution, and validate it where it is actually needed.\n\nSometimes, a 40-million-parameter model and a clearly defined engineering question are a very good place to start.\n\nIt will not reliably solve every unfamiliar problem. It should not make consequential decisions without verification. And this particular experiment still needs much stronger data, evaluation, and device-level testing before it can be trusted in a real delivery workflow.\n\nBut it is a useful starting point for exploring a different approach to AI deployment:\n\n**Small. Specialized. Multilingual. And designed around the constraints of the person who needs it.**\n\nOne of the most interesting things about this project wasn’t just that I managed to train a language model from scratch. It was how little infrastructure I needed to get there.\n\nThere’s a common perception that building language models requires expensive GPUs, large compute clusters, substantial cloud budgets, and access to enterprise-grade infrastructure. That perception is understandable when we’re talking about frontier-scale models. But it doesn’t have to be true for every AI problem.\n\nFor the multilingual version, I used:\n\nThe training run took approximately 28.1 minutes.\n\nThere was also a separate data-preparation stage involving translation and tokenizer preparation. The notebook estimates approximately 15–20 minutes for this one-time preparation, with generated translations and tokenizer artifacts cached for reuse.\n\nTo put the training run in context, consider the AWS EC2 g4dn.xlarge instance. It provides one NVIDIA T4 GPU, four vCPUs, 16 GiB of system memory, and local NVMe storage.\n\nUsing indicative Linux On-Demand rates:\n\nThe 28.1-minute training run alone would therefore cost approximately:\n\nIf the same GPU instance remained allocated for the 15–20 minutes of preparation and the 28.1-minute training run, the combined 43–48.1 minutes would cost approximately:\n\nThese are indicative compute-only estimates, not an AWS experiment I actually ran. They exclude storage, data transfer, taxes, provisioning overhead, and other possible charges. Actual pricing should be checked using the AWS Pricing Calculator.\n\nThe point is not that an enterprise-ready multilingual assistant costs less than a dollar to build. It does not. Data curation, native-speaker review, engineering, evaluation, security, integration, deployment, and maintenance are much larger parts of a serious product effort.\n\nThe narrower point is that a small Transformer experiment can be conducted with a surprisingly modest amount of GPU time.\n\nAt approximately 39.7 million parameters, the model’s nominal weight-storage requirements are:\n\nThese figures cover weights alone. They do not include the memory required by the runtime, tokenizer, intermediate tensors, key/value cache, or the surrounding application.\n\nQuantization could make the model easier to distribute and potentially run in a resource-constrained environment. But the actual result would need to be measured on the target device, including any loss in response quality.\n\nThe important distinction is between a model that is small enough to make edge deployment worth investigating and one that has actually been proven to run well on a phone.\n\nThis experiment establishes the former, not the latter.\n\nNo dedicated GPU server. No paid cloud infrastructure. No distributed training setup. No expensive proprietary training framework.\n\nThe actual training run took approximately 28 minutes.\n\nGoogle Colab was convenient for this experiment, but let’s look at the economics from an enterprise engineering perspective.\n\nCompanies typically use cloud infrastructure rather than relying on free notebook environments. So, what would it cost to reproduce this training run using a commercial cloud provider?\n\nAWS provides an interesting comparison through its EC2 g4dn.xlarge instance, which comes with:\n\nThis is a close GPU-backed cloud equivalent to the hardware used in our experiment.\n\nUsing indicative AWS Linux On-Demand pricing:\n\nOur actual training run took approximately 23 minutes.\n\nThat translates to:\n\nThese are compute-only estimates. A real engineering workflow would also account for instance provisioning, environment setup, storage, data transfer, experimentation, and evaluation.\n\nEven if we allocate a full hour of GPU-instance time, the compute expenditure would be approximately $0.53–$0.58.\n\nThat’s a useful perspective.\n\nWe trained a 30-million-parameter language model from scratch, using a GPU-backed environment that is also available through a standard commercial cloud provider, without requiring an expensive multi-GPU cluster.\n\nOf course, this is not the cost of developing an enterprise-ready AI product. Engineering time, domain-specific data, comprehensive evaluation, security, deployment, monitoring, and ongoing inference all contribute to the total cost of ownership.\n\nBut it demonstrates that **the cost of experimenting with and training a reasonably sized language model can be surprisingly small.**\n\nThe important engineering decision is to match the model architecture, dataset, and training objective to the problem rather than automatically reaching for the largest available infrastructure.\n\n*Pricing reference: AWS EC2 G4dn instance specifications and indicative regional On-Demand pricing. Prices are subject to change and should be verified using the* *AWS Pricing Calculator**.*\n\nGoogle explicitly provides free access to computing resources, including GPUs, through Colab. However, free-tier GPU availability and usage limits are dynamic, and a particular GPU is not guaranteed for every session. This makes it an excellent environment for educational projects and appropriately sized experiments, rather than a dependable foundation for production training infrastructure.\n\nThe answer comes down to matching the model architecture and training workload to the available hardware.\n\nWe weren’t attempting to train a multi-billion-parameter foundation model. We were building a compact, approximately 39.7-million-parameter multilingual Transformer with:\n\nThese architectural choices kept the model’s computational requirements manageable while allowing us to experiment with five languages: English, Hindi, Bengali, Marathi, and Tamil.\n\nWe also used FP16 automatic mixed-precision training. Instead of performing every operation in full 32-bit floating-point precision, compatible operations could use 16-bit precision. This helped reduce memory requirements and made better use of the available GPU.\n\nThe training workload was also deliberately constrained. The prepared dataset contained 23,816 training examples and approximately 3.045 million tokens per epoch. We used a training-time budget of approximately 28 minutes, completing 2,239 optimizer steps over roughly 18.1 epochs.\n\nThe other important decision was keeping the model and dataset appropriately scoped. We weren’t trying to teach the model everything about language, the world, or every possible domain. We were experimenting with a compact multilingual model using a manageable combination of customer-support data, machine-translated examples, and multilingual instruction data.\n\nIn other words, we didn’t solve a large infrastructure problem by buying more infrastructure. We designed the experiment around the infrastructure we had.\n\nA single T4 was sufficient to conduct this training experiment. That doesn’t mean it would be sufficient for every stage of a production multilingual assistant, particularly large-scale data preparation, extensive evaluation, or production inference.\n\nCompute cost is only one part of the economics of building an SLM. Model size also affects storage and deployment.\n\nFor a model with approximately 30 million parameters, the theoretical weight-storage requirements are:\n\nWeight precisionApproximate weight storage:\n\n**FP32:** 120 MB\n\n**FP16:** 60 MB\n\n**INT8:** 30 MB\n\n**INT4:** 15 MB\n\nThese are estimates for model weights alone. They do not include tokenizer assets, runtime overhead, activations, KV cache, or other memory requirements.\n\nNevertheless, the difference is significant. A compact model can be much easier to distribute and potentially run on resource-constrained devices than a substantially larger model.\n\nThis is particularly relevant to the original motivation behind the Delivery Rider Assistant SLM: exploring the possibility of local, offline assistance on mobile devices.\n\nQuantization, runtime optimization, and device-specific benchmarking would be necessary steps before making any production deployment claims. But the economics of a small model give us a useful starting point.\n\nThere is an important distinction I want to make here.\n\nTraining a model cheaply is not the same as building a good model.\n\nThe multilingual experiment produced a compact model, a tokenizer with substantially improved measured fertility on the tested Indian-language samples, and preliminary held-out evaluation results.\n\nBut the generation tests also exposed obvious weaknesses. Some outputs were generic, some did not answer the prompt, and at least one Marathi output was incomplete.\n\nThe training data was a mixture of general customer-support examples, machine-translated examples, and general multilingual instruction data. It was not a verified corpus of actual delivery-partner conversations.\n\nThe model has also not been validated on real phones or integrated with order-management, payment, or delivery systems.\n\nSo the delivery-rider assistant remains the intended application, not a proven production capability.\n\nA production-oriented version would require native-speaker-reviewed data, verified delivery-specific scenarios, systematic task evaluation, operational integrations, mobile-device benchmarking, and mechanisms for handling uncertain or unsupported requests.\n\nThe point is not that a free GPU can replace an entire production AI infrastructure. It cannot.\n\nThe point is that we can use modest infrastructure to investigate serious engineering questions — and be precise about what the resulting evidence does and does not show.\n\nI find this particularly interesting from an engineering perspective.\n\nIt’s tempting to equate more parameters, larger GPUs, bigger datasets, and higher infrastructure budgets with better AI. But those resources only create value when they are justified by the problem being solved.\n\nFor a narrowly defined application, a smaller model with an appropriate architecture, carefully selected training data, and a well-designed evaluation strategy may be a much more practical starting point.\n\nIt can also open up possibilities that are difficult to explore with larger models: local inference, reduced network dependency, lower deployment costs, and greater control over the application.\n\nThis is why I consider building this SLM a useful exercise beyond the model itself. It demonstrates the fundamentals of model architecture, tokenization, optimization, training, evaluation, and deployment without requiring an expensive infrastructure setup.\n\nAnd perhaps that’s the most encouraging takeaway from the project:\n\n**Building good AI systems isn’t always about spending more. Sometimes, it’s about understanding the problem well enough to know how little you actually need to get started.**\n\nLet’s return to the basement parking lot.\n\nThe rider is still waiting. The network is still unreliable. The customer still needs a response.\n\nA cloud model may be more capable, but it cannot help if the application cannot reach it.\n\nA small local model offers another possibility.\n\nIt may not understand every situation. It may need verified business logic, careful guardrails, and human escalation. It may need several rounds of data and architecture improvements before it becomes genuinely useful.\n\nBut it can run close to the user, respond without a network connection, and focus on a narrow set of problems.\n\nIt was understanding how tokenization, parameter allocation, attention, optimization, numerical precision, and evaluation interact when every megabyte and every training step matters.\n\nAnd perhaps that is the most interesting lesson.\n\nIt will also be shaped by who can identify the right problem, build the smallest effective solution, and deliver it reliably where it is needed.\n\n**Sometimes, 30 million parameters and a clear purpose are a pretty good place to start.**\n\n**Architecture:** Approximately 39.7M-parameter Llama-style decoder-only Transformer\n\n**Training:** Single NVIDIA Tesla T4\n\n**Environment:** Google Colab Free Tier\n\n**Training time:** Approximately 28.1 minutes.\n\n*This project is an educational and experimental prototype. Its results should not be interpreted as evidence of production readiness. A production deployment would require delivery-specific data, systematic task and safety evaluation, device-level benchmarking, verified operational integrations, and appropriate human oversight.*\n\n[I Built a 40M-Parameter Multilingual Language Model for Delivery Riders in 28 Minutes.](https://pub.towardsai.net/i-built-a-40m-parameter-multilingual-language-model-for-delivery-riders-in-28-minutes-db1b51e42475) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/i-built-a-40m-parameter-multilingual-language-model-for-delivery-riders-in-28", "canonical_source": "https://pub.towardsai.net/i-built-a-40m-parameter-multilingual-language-model-for-delivery-riders-in-28-minutes-db1b51e42475?source=rss----98111c9905da---4", "published_at": "2026-11-10 18:01:03+00:00", "updated_at": "2026-11-10 18:23:05.528277+00:00", "lang": "en", "topics": ["large-language-models", "natural-language-processing", "ai-research", "ai-tools"], "entities": ["Indic-Delivery-Rider-SLM", "Delivery-Rider-Assistant-SLM", "Hugging Face", "NVIDIA Tesla T4", "Google Colab", "PyTorch"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/i-built-a-40m-parameter-multilingual-language-model-for-delivery-riders-in-28", "markdown": "https://wpnews.pro/news/i-built-a-40m-parameter-multilingual-language-model-for-delivery-riders-in-28.md", "text": "https://wpnews.pro/news/i-built-a-40m-parameter-multilingual-language-model-for-delivery-riders-in-28.txt", "jsonld": "https://wpnews.pro/news/i-built-a-40m-parameter-multilingual-language-model-for-delivery-riders-in-28.jsonld"}}