Fine-Tune Nemotron 3.5 Lightning With Personas to Learn Local Rules

NVIDIA has published a step-by-step recipe for teaching an open model the local rules of a country, not just its language. Posted on the NVIDIA Technical Blog on October 27, 2026 by Sophia Abbassi and Shashank Verma, the walkthrough post-trains Nemotron 3.5 Lightning on French public-service questions, using synthetic "residents" from the Nemotron-Personas-France dataset to generate conversations, LoRA to fine-tune, and a frozen test set to check the result against the base model. The point is useful beyond France: it is a template for adapting an open model to any locale or domain where the facts live in official documents.

We cover what the recipe does, what to copy from it, and what the post does not prove. The numbers and steps below come from NVIDIA's blog and the Nemotron repository.

The recipe at a glance

Why local rules are a different problem from local language

A general model can write fluent French and still be wrong about French administration. NVIDIA's example is a passport question from someone who can no longer travel for health reasons. The un-tuned model suggests applying by post and mailing the file to the public finances department. NVIDIA says that conflicts with official documentation: a government official must make a home visit, and mail submission is not an option.

After post-training, the model's answer says an agent can come to your home, that you need a medical certificate less than three months old, that part of the process can be started online through the ANTS site or at an equipped town hall, and that you should bring original documents and pay the tax stamp. NVIDIA notes it is also shorter and in the voice of a support agent.

Local facts can even vary within one country. NVIDIA's persona write-up gives a case: a resident of French Guiana pays a tax stamp of €43 for a passport, against €86 in mainland France. A model without that grounding would get that wrong for part of the population.

What personas add

A generic prompt like "a French adult who needs a passport" produces generic questions. A grounded persona has an age, a commune, a job and a household that follow French census data, plus written profiles of work and daily life. That changes what the person asks and how they ask it, and sometimes what the right answer is.

NVIDIA built Nemotron-Personas-France with the French startup Pleias, and Nemotron-Personas-Belgium with Pleias and the Belgian university KU Leuven. They belong to a data program that includes persona datasets for 12 countries. We covered the UK and Germany releases in our post on Nemotron-Personas for European public-sector open models.

A machine producing green tiles beside a few gray ones, illustrating how persona-seeded synthetic data multiplies scarce real examples for Nemotron fine-tuning

NVIDIA is careful about the limits. It advises using persona fields "only to vary how customers communicate rather than to guess the customer's needs or competence from protected or sensitive attributes," and excluding names and unnecessary demographic details from the final training data. Its own caveat: persona grounding is about coverage, "not a guarantee of fairness or proper representation."

Pleias uses three Nemotron-Personas datasets, including France and Belgium, in Lamina, a spine-care assistant from a Pleias partner. The personas turn a few real patient cases into varied training conversations and let Pleias test across patient profiles. That is a company's description of its own use, not an independent result.

The five steps

Step 1: Write a behavior contract and freeze a test set

Before generating anything, define what a good answer is. NVIDIA's contract for the French assistant covers six dimensions:

• Audience: French adults with varying technical levels.
• Task: identity-document and vehicle-registration procedures.
• Language: French, calm and respectful.
• Grounding: only the official procedure text supplied for each question; no invented fees, deadlines, documents or routes.
• Safety: never ask for passwords, bank details or software installs; say so when something cannot be confirmed, such as opening hours, and point to the mairie or service-public.gouv.fr.
• Output: a short direct answer, then the documents or steps that apply, then a pointer to the official source when something is missing.

For production, NVIDIA suggests a holdout set of 100 to 300 human-written or de-identified patterns with an expected behavior recorded for each. The sample cases include a local-fact question (the Guyane stamp price), an out-of-scope question (Saturday opening hours, where the right answer is to not invent hours) and a scam-call safety case.

Step 2: Generate synthetic conversations

Sample 2,000 personas spread across departments and occupations, then use the sdg/data_designer step to turn each into a customer message and an agent reply. A separate judge model checks each generated answer, by default through an NVIDIA-hosted API that needs NVIDIA_API_KEY.

NVIDIA serves Nemotron 3.5 Lightning locally with vLLM for generation on a DGX Station; on a DGX Spark it recommends the hosted API. Preview eight records first and check them against the contract before running the full set, and start with 500 to 1,000 records on a Spark or any hosted API.

The one setting that breaks runs is enable_thinking: false. Lightning produces reasoning traces by default. The flag must live under providers, extra_body, chat_template_kwargs. Put it under inference_parameters and the run fails; leave it out and reasoning text leaks into your training data.

Then audit. The audit_and_split.py script drops rows with formatting problems, leftover reasoning or leaked persona names, and splits 90/10 by source UUID so the same persona never appears in both train and validation sets.

Step 3: LoRA fine-tune

NVIDIA starts from a validated LoRA recipe for Lightning on NeMo Automodel, and says to change only the data paths and training schedule at first, since the model and LoRA settings are tuned for this architecture. On a DGX Spark, set a local batch size of 1, a sequence length of 8192 and a 16 GB shared-memory size. Validation loss should fall before it flattens; if it is flat or rising from the start, check the data.

A fitted green collar around a cream core, a picture of a LoRA adapter wrapped around a frozen Nemotron base model

Step 4: Merge and serve

Keep the LoRA adapter for future iterations, merge it into the base checkpoint with the convert/merge_lora step, and serve both models with vLLM. On a DGX Station, run both with a GPU memory utilization of 0.45 so they fit side by side. On a Spark, serve one at a time.

Step 5: Evaluate against the base model

"A lower loss isn't enough to prove the post-trained model is better at the job," NVIDIA writes. Send the same frozen prompts to both models, write the answers to a side-by-side comparison file, and read them. NVIDIA recommends human review. Its evaluation plan has six slices, each with an acceptance criterion:

Read every answer for invented fees, deadlines or documents, and for replies that break character. Check each fact against official pages.

What this does and does not show

It shows a complete, reproducible workflow with open data, open models and a repository tagged at v0.2.0, with agent skills that can help a coding agent assemble the steps. That is genuinely useful, because most fine-tuning guides skip the unglamorous parts: the behavior contract, the audit filter, the by-persona split.

It does not show a measured improvement. The blog gives one before-and-after answer and an evaluation plan, but no scores, no sample sizes for a judged comparison, and no regression numbers for the Retention slice. The results table says only what your results "should be along the lines of." Treat the passport example as an illustration. Run your own frozen test set before trusting the adapted model.

Two other cautions follow from the design. First, the facts come from the procedure text you supply, so the quality ceiling is the quality of that text, and it can go stale when rules change. Second, a model fine-tuned on synthetic data written by another model inherits that generator's style and mistakes; the judge model and your human review are what catch them.

How it compares with other adaptation routes

Small models tuned on a company's own data have recently beaten frontier models on narrow tasks. Two cases we covered: Shopify's Sidekick post-trained on Nemotron 3.5 Lightning, which came with vendor claims we checked, and Coinbase's fine-tuned Qwen3.5 9B fraud agent. NVIDIA's French recipe sits in the same family, but starts from synthetic rather than production data, which makes it more accessible and less proven. For other language-specific efforts see NVIDIA's Indic pretraining pipeline.

What to do with it

1. Read the example folder in the repo before you buy hardware. The file layout (config, scripts, sources, eval) is the transferable part.
2. Swap in your own sources. The workflow only needs a persona dataset for your market, a document set with the true answers, and a behavior contract.
3. Build the frozen test set first, including out-of-scope and safety cases, and score the base model before you train.
4. If you only have a DGX Spark, plan for the hosted-API path for generation and the smaller training settings. Our DGX Spark price and memory post covers what that machine offers.
5. Re-run the evaluation each time the source rules change.

Related reading

• Nemotron 3.5 Lightning 30B-A3B open MoE
• Nemotron-Personas for UK, Germany and European public-sector models
• Shopify Sidekick on Nemotron 3.5 Lightning: claimed vs verified
• Coinbase's fine-tuned Qwen3.5 9B fraud agent
• NVIDIA Indic pretraining pipeline
• NVIDIA DGX Spark price and memory change

Sources: NVIDIA Technical Blog and the Nemotron GitHub repository.

Details are accurate as of October 27, 2026. Check the repository for current versions and settings.