Remember back in May when I introduced the gemma-skills repository? It's been rewarding to see how many of you have used my previous post to stream...
For further actions, you may consider blocking this person and/or reporting abuse
That moment where the agent caught you trying to audio-tune a vision-only model and pointed you at E2B instead is the feature that sells this for me. So I'm curious how the guardrail knows: is the model-to-capability map hard-coded into the skill, or does the agent read it off the model card at runtime? New checkpoints tend to show up faster than any static list gets updated, so if it's hard-coded, a fresh Gemma release with a new capability would quietly fall through until someone patches the skill. Which way did you build it?
Exactly! The skill file include specific guidelines, like using the Gemma 4 E2B through 31B models for vision SFT, and the E2B through 12B models for audio SFT. So if you explain exactly what you're trying to do, your agent can spot errors for you.
To maximize the value of these skills, we will continuously update it alongside every new Gemma release.
thanks for sharing!
the base→custom gap is where most agent pipelines stall too. curious what the memory footprint looks like on M2 - that’s usually where people give up and go back to APIs.
Local fine-tuning gets much more usable when the workflow is packaged as a repeatable path instead of a pile of notebook cells. The operational details matter: dataset shape, eval split, hardware limits, artifact naming, and rollback when a tuned model gets worse on the real task. That is where a trainer tool can save a lot of wasted runs.
The LiteRT-LM angle for IoT is where this gets genuinely interesting â not just because you can shrink the model, but because the fine-tuned model now has state that needs to survive alongside the device. When you fine-tune locally and deploy on an edge device, the model weights travel with the hardware, but the training metadata (what data shaped it, which epochs actually improved evaluation, what the failure modes were during SFT) usually gets left behind on the workstation.
That gap matters more than people think. A model that "knows" classical Korean translation but can't tell you why it knows it is a model you can't debug when it drifts. We ran into this building moteDB â an embedded multimodal database in Rust â where the storage layer lives on the same device as the inference engine. The fine-tuned weights, the training logs, the evaluation curves, and the raw training samples all coexist in one store. When the model degrades at month six on a Raspberry Pi, you can actually trace what happened instead of just re-running the whole pipeline.
Has anyone here tried persisting fine-tuning metadata alongside the deployed model? I'd be curious how you handle the "why does this model know what it knows" problem on devices that don't have cloud access.
Great article! The agent-led guardrail approach is really impressive — having the agent automatically catch model capability mismatches (like the audio-tuning on a vision-only model) saves a lot of debugging time. Looking forward to trying gemma-trainer with multimodal fine-tuning. Thanks for sharing!
Local fine-tuning is interesting because it moves some control back to the builder. The practical question is not only model quality, but the surrounding workflow: dataset hygiene, repeatable runs, evals, versioning, and knowing when fine-tuning is better than retrieval or prompting.
Follow me
yeah, so good for everyone
as problem and this problem a one platform fully one work space
One workspace for developers. Analyze, review, explain, test, and debug your code in one place.”
Assalamualaikum,
This looks really interesting, I’m still a beginner so some parts are new to me.
Just curious, where should someone like me start before learning this?