DEV Community: Umutesi Kelia

LLM Research Blog: The Model That Fits Our Project

Umutesi Kelia — Mon, 26 Oct 2026 13:44:18 +0000

LLM Research Blog: The Model That Fits Our Project

1. Introduction

During our course, we learned about Natural Language Processing (NLP), GPT-2, TinyGPT, Transformers, and other AI concepts. We also studied computer vision and learned that AI can be used in different ways to solve real problems. These lessons made me more interested in understanding how AI models work and how we can use them to build useful applications.

For my project, I am working on MiniChefGPT, a recipe-generation system. The idea is simple: a user provides the ingredients they have, and the model suggests a meal and explains how to prepare it step by step.

I chose this idea because sometimes people have ingredients at home but do not know what they can cook with them. I want MiniChefGPT to help people discover meal ideas and make better use of the food they already have.

However, choosing a model is not just about choosing the biggest one. I need a model that follows instructions, generates understandable recipes, and can run using the resources available to us. Since I want to experiment without paying for an API, I decided to research three open models: Qwen3-4B-Instruct-2507, SmolLM3-3B, and Phi-4-mini-instruct.

2. The models I researched

Qwen3-4B-Instruct-2507 — Qwen Team

Qwen3-4B-Instruct-2507 was developed by the Qwen team. It has 4 billion parameters and a native context window of 262,144 tokens. It uses the Apache 2.0 licence, which allows people to use and modify the model under the licence conditions. [1]

What interests me about this model is its focus on instruction following, reasoning, and text generation. In MiniChefGPT, the user might say, “I have Cassava, fish, spinach, and tomatoes. Suggest one meal and show me how to cook it.”

The model needs to understand the ingredients and provide a suitable meal with clear steps. It should also follow the requested format instead of giving a long, confusing answer.

Qwen3-4B-Instruct-2507 looks like a strong candidate for this task. However, its full-precision weights need around 8 GB of storage before accounting for the additional memory needed to run it. A free Google Colab T4 GPU has 16 GB of GPU memory, so the model may be possible to run, but memory use must be tested. Quantization can help reduce the memory requirement.

SmolLM3-3B — Hugging Face

SmolLM3-3B was developed by Hugging Face and has 3 billion parameters. Its standard context length is 65,536 tokens, and its licence is Apache 2.0. It is an instruction-oriented model that supports reasoning and multiple languages. [2]

One reason I considered SmolLM3 is its relatively small size. Since we may have limited computing resources, a smaller model could make experimentation easier.

For MiniChefGPT, I would test whether it can suggest reasonable meals, organize cooking instructions in the correct order, and avoid adding ingredients that the user does not have. I would also check whether its answers are simple enough for different users to understand.

However, a smaller model is not automatically better or faster for every task. Its actual speed and recipe quality need to be measured in the same environment as the other candidates.

Phi-4-mini-instruct — Microsoft

Phi-4-mini-instruct was developed by Microsoft. It has 3.8 billion parameters, supports a context window of up to 128,000 tokens, and is released under the MIT licence. It was designed for instruction following, reasoning, and chat-based applications. [3]

I included this model because MiniChefGPT needs more than text generation. It needs to understand a request and respond in an organized way.

For example, if someone provides rice, beans, and vegetables, the model should suggest a suitable meal and explain the preparation steps clearly. It should not ignore the ingredients or produce instructions that are difficult to follow.

Phi-4-mini-instruct is a useful candidate to test because of its instruction-following design and relatively small parameter count. However, I cannot say it is the best model for recipes without testing it on our actual project.

3. Comparing the models

Feature	Qwen3-4B-Instruct-2507	SmolLM3-3B	Phi-4-mini-instruct
Creator	Qwen Team	Hugging Face	Microsoft
Parameters	4 billion	3 billion	3.8 billion
Context window	262,144 tokens	65,536 tokens	128,000 tokens
Licence	Apache 2.0	Apache 2.0	MIT
Main strengths	Instruction following, reasoning, text generation	Small size, reasoning, multilingual capabilities	Instruction following, reasoning, chat tasks
Colab T4	Test memory; quantization may help	Worth testing because of its smaller size	Worth testing; measure actual memory use

The specifications come from the official model documentation. [1][2][3] All three models have public model repositories, so they can be downloaded for local experimentation without relying on a paid text-generation API. Their licences still need to be followed.

The context window is the amount of text a model can process in a sequence. MiniChefGPT normally needs only a short ingredient list and a recipe, so we do not need the largest context window. More important factors are the quality of the recipe, instruction following, speed, and memory use.

4. Which ONE model would I choose?

After comparing these models, I would choose Qwen3-4B-Instruct-2507 for our first implementation and evaluation of MiniChefGPT.

My main reason is its instruction-following design. Our project needs a model that can take ingredients as input and generate a meal suggestion with clear cooking steps. I believe Qwen3-4B-Instruct-2507 is a strong candidate for this kind of instruction-based task.

Another reason is its Apache 2.0 licence and public model repository. We can download the model and experiment with it locally without paying for each generated response through a hosted API. The public repository does not appear to require accepting a gated model licence, although we should always check the current model card before use.

The main challenge is running it on a free Google Colab T4 GPU with 16 GB of memory. The model's full-precision weights alone need approximately 8 GB, and the runtime also needs memory for other components. I would first try a memory-efficient setup, such as 4-bit quantization, and check whether the model loads and generates recipes successfully.

I would not claim that Qwen is the fastest model because I have not benchmarked all three models on the same hardware. To get evidence, I would test the same ingredient lists with each model, measure the time taken to generate a recipe, and record the GPU memory usage. If Qwen cannot run reliably or produces weaker recipes than another candidate, I would need to reconsider the choice based on those results.

5. How I will evaluate it

I would test Qwen3-4B-Instruct-2507 using several ingredient lists. For example, I could provide potatoes, eggs, tomatoes, and onions and ask it to suggest one meal with numbered cooking steps.

I would check whether the model uses the available ingredients, follows the requested format, gives steps in a sensible order, and avoids unnecessary explanations. I would also test unusual combinations to see whether it handles them sensibly instead of inventing an unsuitable recipe.

Finally, I would measure its response time and GPU memory usage on Colab. These tests will help me understand whether the model is practical for our project, not just whether its technical specifications look good.

6. Conclusion

Working on MiniChefGPT helps me connect what we learned in our course with a practical idea. Learning about GPT-2, TinyGPT, and Transformers gave me a foundation for understanding how language models generate text. Now, I want to apply that knowledge to a system that can help people with something they do in everyday life.

My first choice is Qwen3-4B-Instruct-2507 because of its instruction-following capabilities and open licence. However, the final decision should also depend on practical tests, especially recipe quality, generation speed, and whether it runs within the memory limits of a free Colab T4 GPU.

For me, the goal is not simply to use a large language model. It is to understand it, test its limitations, and use it to build something useful. With MiniChefGPT, I want to turn the ingredients people already have into simple meal ideas they can actually prepare.

References

Qwen Team. Qwen3-4B-Instruct-2507 Model Card. https://huggingface.co/Qwen/Qwen3-4B-Instruct-2507
Hugging Face. SmolLM3-3B Model Card. https://huggingface.co/HuggingFaceTB/SmolLM3-3B
Microsoft. Phi-4-mini-instruct Model Card. https://huggingface.co/microsoft/Phi-4-mini-instruct

Note: The model specifications and licences are based on the published model documentation. Speed and GPU memory use still need to be measured in our own Colab tests.

How Does a Computer Actually See an Image? My First Steps into Computer Vision

Umutesi Kelia — Tue, 13 Oct 2026 13:32:27 +0000

Have you ever looked at a picture and wondered how your brain recognizes what's inside it so quickly?

Imagine looking at a picture of a bus. You immediately notice its shape, colors, and windows, and your brain says, "That's a bus!"

But what happens when we give that same picture to a computer?

Does a computer actually see a bus, or does it see something completely different from what we see?

That question got me curious. I wanted to understand how a computer goes from processing numbers to identifying objects in an image.

I didn't want to just run an AI model, watch it draw boxes around objects, and say, "Wow, AI is amazing!" I wanted to understand what was happening behind the results.

So, I started exploring computer vision using Python, experimenting with image pixels, filters, classification, object detection, and segmentation.

And honestly, the more I learned, the more questions I had.

I discovered that an image, which looks so simple to us, is represented by numbers inside a computer. Wait... how can numbers represent a bus, a face, or even a tiny detail in a picture? And what happens when we change those numbers?

Then I started wondering how AI models recognize objects. How can a model identify a bus in one image but struggle with another because of lighting, different angles, or objects being partially hidden?

And here's another question that caught my attention: What's the difference between recognizing an object and identifying the exact pixels that belong to it? That's where I started exploring the difference between object detection and image segmentation.

I'm still learning, experimenting, and connecting these concepts. I don't want to know how to run a model; I want to understand why it works and what happens behind the scenes.

In this post, I'll share some of what I'm discovering as I explore how computers process images and learn to recognize what's inside them.

Sometimes, learning something new starts with one simple question you just can't stop thinking about.

Let's explore it together!

1. Wait, an image is just numbers?

One of the first things I explored was how images are represented in Python.

When we look at a picture, we see colors, people, objects, and backgrounds. But a computer represents a color image using numerical values called pixels.

Using NumPy, we can inspect those values:

pixel = img[100, 400]
print(pixel)

This gives us the RGB values of the pixel at row 100 and column 400.

RGB means Red, Green, and Blue. Each channel usually has a value between 0 and 255.

For example:

[255, 0, 0] # Red
[0, 255, 0] # Green
[0, 0, 255] # Blue

When I think about it, it is interesting that something we see as a complete picture can be represented by numbers that we can access and change using code.

I also explored how to extract a small part of an image:

patch = img[100:106, 100:106]

This selects a 6 × 6 section of the image.

My takeaway: Before trying to understand how AI recognizes an image, I need to understand what an image looks like from the computer's point of view. It starts with data.

2. What happens if we remove one color?

This was another interesting experiment because it showed me that I can change an image by modifying its pixel values.

no_red = img.copy()
no_red[:, :, 0] = 0

show(no_red, "No red")
plt.show()

Let me explain what is happening here.

First, img.copy() creates a copy of the original image. Then [:, :, 0] selects the red channel, and setting it to zero removes the red contribution from every pixel.

For example, a white pixel has the values [255, 255, 255]. After removing red, it becomes [0, 255, 255], which is cyan.

This helped me understand that the colors we see depend on the values stored in the different channels.

I like experiments like this because instead of only reading a definition, I can change something in the code and understand the effect by looking at the result.

3. Image filters: why do we need them?

I also explored image filters, including blur, sharpening, and edge detection.

At first, these might look like simple image effects, but they help us understand how image processing can emphasize or reduce certain features.

A filter often uses a small matrix called a kernel. The kernel moves across an image and calculates new pixel values using nearby pixels.

For example, this is a sharpening kernel:

sharpen = np.array([
[0, -1, 0],
[-1, 5, -1],
[0, -1, 0]
])

The values in this matrix affect how the output image is calculated. This particular kernel emphasizes differences between a pixel and its neighbors, which can make details appear sharper.

A blur filter works differently. It averages nearby pixel values, making the image smoother and reducing small details.

Edge detection helps highlight places where brightness changes, such as the boundaries between objects and their backgrounds.

What I find interesting is that we can use mathematical operations to make different features of an image easier to see.

My takeaway: Image processing is not magic. There are operations happening behind the output, and understanding those operations helps me understand the bigger picture of computer vision.

4. Image classification: how does a model guess what it sees?

Next, I explored image classification using a pretrained YOLO classification model.

classify(ASSETS / "zidane.jpg")

Classification means predicting what category an image belongs to. Depending on the model and its training classes, it might predict categories such as a person, an animal, or another object.

The model gives predictions with confidence scores, but something I want to remember is that a prediction is not automatically correct just because the model produced it.

We still need to look at the image and ask whether the prediction makes sense.

This also made me think about how much a model depends on the examples it learned from during training. If the category we want is not represented well in its training data, the prediction may not be what we expect.

I am beginning to see why learning about models also means learning about their limitations.

5. Object detection: what changes when we change confidence?

Object detection is different from classification. Instead of only predicting a category, a detection model can identify objects and draw bounding boxes around them.

One experiment I explored was changing the confidence threshold.

_ = detect(IMAGE_PATH, conf=0.1)

Then comparing it with:

_ = detect(IMAGE_PATH, conf=0.9)

The conf value sets the minimum confidence required for a detection to be kept.

With a lower threshold, the model can keep more predictions, including uncertain ones. With a higher threshold, it generally keeps fewer predictions, but it can also miss real objects.

This is where I started thinking beyond just getting an output.

What if we want a model to detect every possible object? What if false detections are a serious problem? Would we always choose a high confidence threshold?

I learned that the answer depends on what we are trying to achieve. There is a balance between detecting more objects and trusting the predictions we keep.

My takeaway: A model's output depends not only on the model itself, but also on the settings we choose and the problem we want to solve.

6. Object detection vs. image segmentation

I also explored image segmentation, which gave me another way to think about how AI understands images.

With object detection, a model draws a bounding box around an object. With segmentation, it can identify the pixels that belong to the object, giving us a more detailed outline.

For example, after running a segmentation model, we can inspect the masks:

r = segmenter(IMAGE_PATH, conf=0.4, verbose=False)[0]

if r.masks is not None:
for mask, c in zip(r.masks.data, r.boxes.cls):
print(r.names[int(c)], int(mask.sum()), "pixels")
else:
print("No segmentation masks were found.")

This code checks whether segmentation masks exist and counts the nonzero values in each mask. The counts represent the mask data at the model's output resolution, not necessarily exact pixel counts in the original image.

The difference is becoming clearer to me:

Classification: What category is in the image?

Object detection: What objects are present, and where are they?

Segmentation: Which pixels belong to each detected object?

These tasks may seem similar at first, but they answer different questions.

7. What happens when the image is not perfect?

Something else I want to explore is how well a model performs when an image changes.

Think about a picture taken in poor lighting, a blurry photo, or an image that has been rotated. As humans, we can sometimes recognize an object even when the image is not perfect. But will a model always recognize it?

One way to investigate this is to create a blurry version of an image:

from PIL import ImageFilter

blurry = original.filter(ImageFilter.GaussianBlur(8))

Then we can compare the model's predictions on the original image and the blurry version.

We can also experiment with darker images, lower resolutions, and different orientations.

I think this is an important part of learning AI because getting a model to work on one image does not mean it will perform equally well in every situation.

I want to understand not only when a model works, but also when it struggles and why.

What I am taking from this learning experience

The biggest thing I am learning is that understanding AI takes more than knowing which library to import or which function to call.

I need to understand the data going into the model, the operations being performed, the output coming back, and whether that output actually makes sense.

I am also learning to question results instead of accepting them immediately. If I change a value, what happens? If I change the image, does the prediction change? If the result looks wrong, what could be causing it?

These are the kinds of questions I want to keep asking as I continue learning.

I know I still have a lot to learn about computer vision and machine learning, but I am trying to build my understanding step by step rather than rushing through concepts without understanding them.

What is next for me?

I want to complete the hands-on exercises, compare the results, and get more comfortable experimenting with the code myself.

After that, I want to go deeper into how these models work internally and how they learn from data.

My goal is not just to use AI tools. I want to understand how they work well enough to eventually build things of my own.

I would love your feedback

Since I am still learning, I would really appreciate feedback from people with more experience in computer vision and AI.

What beginner-friendly experiments helped you understand computer vision better? Is there something in this blog that I should explain differently? And what would you recommend I learn next after understanding the basics of pixels, filters, classification, detection, and segmentation?

I am sharing this to document my learning and improve through feedback. If you are also learning AI, I hope we can learn from each other.

Thank you for reading!