Sharon Zhou's Finetuning LLMs course: 95 minutes on deciding when to fine-tune

You might expect a fine-tuning course to put training code in front of you straight away. DeepLearning.AI’s Finetuning Large Language Models does something else. It spends almost 30 minutes on two lessons, “Why finetune” and “Where finetuning fits in”, before it gets to any training. The whole course runs only about 1 hour 35 minutes.

There is a reason for that order. Picture a client who asks not “how do we fine-tune?” but “should we fine-tune?” Get the second question wrong and your team can lose several weeks on a problem that a good prompt would have solved.

Who teaches it, and what does the course contain?

The instructor is Sharon Zhou, now Vice President of AI at AMD. When the course came out in 2023 she was co-founder and CEO of Lamini, and the course was made with Lamini.

It is an intermediate-level short course with 9 videos, 6 code examples and 1 graded quiz. Some pages give a slightly shorter running time of 1 hour 25 minutes.

After the introduction, the lessons follow the order of a real project: Why finetune (about 14 minutes), Where finetuning fits in (15), Instruction finetuning (9), Data preparation (10), Training process (16), Evaluation and iteration (11), Considerations for getting started (4) and a conclusion (1). You need to know Python and understand a deep learning framework such as PyTorch.

The course page says the course is free for a limited time while the new learning platform is in beta, so check the access terms on the official page.

First idea: fine-tuning teaches a model how to answer before it teaches it anything new

According to the official description, fine-tuning helps a model learn style and format, and it can also add new knowledge. One of the course’s goals is to show how fine-tuning differs from prompt engineering, when to use each, and when to use both.

OpenAI’s guide to model optimisation goes further. It says prompt engineering may already be enough to get good results for your use case, and that fine-tuning takes time.

So if a client complains that the model “sounds wrong” or “drifts off format”, rewrite the prompt and add examples first. You don’t need a GPU yet.

Second idea: fine-tuning is a cost problem

OpenAI names two cases where fine-tuning clearly helps. The first is when output must keep a consistent format. The second is when you want a smaller, cheaper, faster model to do one job very well, where using a large model would not be economical.

A fine-tuned model also needs shorter prompts, with fewer examples and less context, so it saves tokens at scale.

When Anthropic opened fine-tuning for Claude 3 Haiku in July 2024, it gave the same reasons: cutting production costs by using Haiku in place of Sonnet or Opus, and training the model for a company’s highly specific workflows.

Try a hypothetical calculation. A ticket classification system puts about 2,000 tokens of examples into every prompt and handles 100,000 calls a day. The examples alone come to 200 million tokens a day.

Now suppose that after fine-tuning, each prompt needs only about 200 tokens of examples. The examples then come to 20 million tokens a day: 180 million fewer, a 90% cut. Set that saving against the work of preparing data, training and re-evaluating, and you have a concrete figure to bring to the client meeting.

Third idea: data and evaluation matter more than training

Add up the lesson times and Data preparation plus Evaluation and iteration run longer than Training process. That split matches real work. You can buy training time. A clean dataset and a metric the client agrees with have to be built on site, with the client.

The practical advice is to build an evaluation set in the first week, while you are still running on prompts. Then, if you do need to fine-tune, you already have a baseline to compare against. If you don’t, that evaluation set is still the most valuable thing you leave the client.

Which mistakes send fine-tuning projects off course?

The most common mistake is fine-tuning to fix a badly written prompt. If the prompt lacks clear instructions or examples, more training only hides the problem, and it takes far longer than fixing the prompt.

The second is training without a baseline. Without an evaluation set run against the prompt-based version, you cannot show that the new model is better, and the client is left deciding on gut feeling.

The third is forgetting to recalculate costs after training. If the reason for fine-tuning was to cut tokens or move to a smaller model, put the before and after figures side by side. If the saving is negligible, the prompt is still the right choice.

How to study it, and what to put on your CV

The course suits people who have already shipped at least one prompt-based LLM application into real use. Watch the first two lessons, read OpenAI’s guide alongside them, and only then open the training notebooks. If you are not yet comfortable with PyTorch, learn it first: the course lists it as a prerequisite.

When you read FDE job descriptions, look for phrases such as “fine-tuning”, “evaluation” or “cost optimization”. On a CV, a line like “compared prompting and fine-tuning on a self-built evaluation set and chose the cheaper option that still met the quality bar” carries far more weight than one that just says “fine-tuned a model”.

By the end of the course you will know how to fine-tune. In client work, though, the more useful skill is explaining with numbers why a client should fine-tune, or why they don’t need to yet.