You’ve already built the harder thing.

Repeatable training, tracked experiments, audit trails, versioned datasets. Adding LLM features doesn’t replace any of it. It adds a few new objects to the same systems. The course is about which to keep, which to add, and how to extend a model platform without rebuilding it.

Free. Six modules. By Valohai.

Your platform

Training

Experiments

Audit trails

Datasets

New objects

Prompts

Providers

Cost per call

What stays the same

Most of what your ML team already does transfers to LLM features.

The discipline doesn’t change. The objects it tracks expand.

Lineage transfers.

You version datasets, track which model version produced which artifact, and audit which run shipped to production. LLM features need the same, with a few new objects in the graph: the prompt, the LLM provider version it ran on, and the retrieval inputs that fed the call. The shape doesn't change. The catalog gets longer.

Experiment tracking transfers.

You log hyperparameters, dataset hashes, and metric trajectories for training runs. LLM features track prompts, provider versions, and per-call cost on each evaluation. The platform doesn't change. What it tracks just expands.

Reproducibility transfers.

Locked dataset versions, pinned environments, deterministic builds. The same discipline applies to running an evaluation suite against a versioned prompt and a pinned LLM provider version, week over week, with a comparable result.

What’s new

Three new objects you’ll need to track that your model platform doesn’t yet.

These are the additions. Not a rebuild.

The prompt.

A prompt is a versioned artifact, like a dataset. It needs a hash, an author, a commit history, a comparison view across versions. Most ML platforms have nowhere to put this. Module 2 covers prompt versioning as engineering.

The provider.

Each LLM call goes to a specific provider, on a specific model version, at a specific cost. None of this fits cleanly into your training experiment tracker, but all of it needs to be tracked. Module 6 covers the routing layer.

Per-call cost.

Training cost was a yearly conversation. LLM call cost is a daily one. Cost per request, per feature, per provider, over time. The chart your platform doesn’t yet draw. The course shows how to build it.

Six modules. Three of them are the ones your team will spend the most time on.

Understanding LLMs for product development. When to reach for an LLM, when traditional ML, rules, or a database query is the better tool.
Prompt engineering fundamentals. Structured prompts, few-shot patterns, structured outputs, the iteration loop.
Context management. (Heaviest reading for ML teams.) Static context, RAG, fine-tuning, agents, chaining. Six strategies in order of cost.
Building LLM-powered features. Validation layers, retries, provider fallbacks, when an agent helps and when it hurts.
Evaluating LLM outputs. (The longest module.) Eval sets, layered evaluation, regression suites that block PRs.
Going to production. (Where the new infrastructure lives.) Cost tracking, model routing, prompt caching, quality drift, the weekly improvement rhythm.

Taught by Petteri.

Petteri is Head of Product at Valohai. Before joining, he led LLM implementations inside enterprise products, where shipping carefully wasn’t optional. The course is the playbook from those teams, plus what he sees across Valohai’s customer base now.

“The same problems keep showing up in the same order across teams. After enough of that, the lessons are worth writing down. This course is those lessons.”

By the end of the course, you’ll have:

An extension to your model platform that covers prompts, providers, and per-call cost as first-class objects.
A regression evaluation pattern that fits inside your existing CI and reproducibility practices.
A cost monitoring layer that tracks LLM spend at the same fidelity you already track training spend.
A framework for deciding when an LLM, a specialized model, or a database query is the right answer.