Inspiration
Smallholder farmers often need timely, practical agricultural advice, but access to agricultural extension services is limited, and reliable internet connectivity cannot be assumed in many rural environments. In Uganda, for example, published reports have described extension coverage of approximately one agricultural extension worker for every 5,000 farmers.
We wanted to explore whether a small language model could provide useful first-line agricultural support locally and offline, without requiring a cloud API or continuous internet connection. This led to Kuza AI, an agricultural assistant designed for East African farmers and extension workers.
The African context is central to the project. Kuza currently supports English and Swahili and is designed around the hardware, connectivity, and agricultural information constraints of the region.
What it does
Kuza AI is an offline agricultural assistant for practical crop and livestock questions. It can provide guidance on topics such as animal care, crop management, agricultural practices, and other farm-level questions.
The model runs locally through llama.cpp, so inference does not require an external API or internet connection. The current prototype supports English and Swahili.
Kuza is designed as a decision-support tool rather than a replacement for agricultural extension workers, veterinarians, or other professionals. Safety-critical recommendations still require human and expert validation.
How we built it
We started by benchmarking several small and medium-sized language models under the same local environment. Gemma 4 E2B provided the strongest throughput among the candidates we evaluated while maintaining a suitable model footprint, so we selected the Unsloth gemma-4-E2B-it-qat-q4_0-unquantized checkpoint as the base model.
The main fine-tuning dataset was constructed from approximately 1.45 million farmer-initiated Q&A pairs from the Digital Green FarmerChat dataset. We separated high-priority and long-tail queries, sampled representative examples, and used Llama-3.3-70B-Versatile for cleaning and information-density improvement. This produced an intermediate corpus of approximately 56K examples. We then removed malformed examples, duplicates, and semantically near-duplicate answers to obtain a final English training corpus of approximately 25.6K examples.
A Swahili SFT dataset was subsequently generated from the English corpus using GPT-OSS-120B. We also incorporated a small adversarial dataset for safety-oriented training.
For deployment, we experimented with several GGUF quantization strategies. The final model uses Q4_K_M for most weights, with higher precision Q6_K and Q8_0 tensors in selected components. We also used an importance matrix (imatrix) during quantization after observing a better quality/efficiency trade-off than naïve quantization.
The complete pipeline was developed under constrained compute using free Kaggle T4 sessions, which required a modular and restartable workflow.
Challenges we ran into
The biggest challenge was balancing agricultural knowledge, model quality, and edge-device constraints. A larger model could potentially provide better reasoning, but the target environment was an approximately 8 GB RAM laptop with CPU-only inference.
Dataset construction was another major challenge. Agricultural conversations contain filler, duplicated questions, malformed records, and semantically repetitive answers. Training directly on the raw corpus would waste a significant portion of the model's limited capacity, so we focused on creating a smaller, knowledge-dense dataset.
We also explored constructing training data directly from agricultural manuals and extension guidelines, but found that reverse-generating farmer questions from extracted facts produced less realistic interactions than starting from real farmer queries.
Finally, multilingual quality remains challenging. Some Swahili outputs still show semantic and linguistic failures, which means the current Swahili model requires additional cleaning and evaluation before it can be considered reliable for deployment.
Accomplishments that we're proud of
We built an agricultural LLM that can run fully offline on a low-resource consumer laptop without a discrete GPU or cloud inference.
On our participant development machine, an AMD Ryzen 3 7320U laptop with 7 GB RAM, the submitted model achieved:
- 5.47 tokens/s generation throughput
- 5.81 s time to first token
- 4.94 GB peak resident memory
We are also proud of the end-to-end optimization rather than treating fine-tuning as the only part of the problem. The project combines model selection, agricultural data curation, multilingual adaptation, adversarial examples, calibration-aware quantization, and CPU-oriented deployment.
Most importantly, the system was designed around a real deployment constraint: making agricultural AI available where cloud connectivity cannot be taken for granted.
What we learned
Our biggest lesson was that building a useful edge AI system is not just about selecting the best model. Data quality, language quality, quantization, hardware constraints, and evaluation all interact.
We also learned that a model can produce fluent and convincing agricultural responses while still making problematic numerical or domain-specific recommendations. This is especially important for agriculture because incorrect quantities, dosages, spacing, or treatment advice can have real consequences.
Our current experiments therefore reinforced the importance of evaluating not only whether a response sounds good, but whether it is factually grounded, relevant to the exact question, appropriately cautious, and understandable in the target language.
What's next for Kuza AI
The next priority is quality and safety evaluation, particularly expert review of agricultural recommendations and systematic testing of numerical factuality, uncertainty handling, and Swahili response quality.
We also want to improve the Swahili training pipeline by filtering translation errors and semantic contamination before further fine-tuning. On the deployment side, we will continue optimizing first-token latency and CPU inference efficiency.
Longer term, Kuza could expand beyond text to agricultural images and voice interactions, while preserving the offline-first design. The goal is to move from an experimental edge LLM toward a rigorously evaluated agricultural decision-support system that can complement, rather than replace, local extension services.
Log in or sign up for Devpost to join the conversation.