Will Gemma 3n be built in Chrome?

[Jax]

I heard from I/O that Gemma 3n is a nano-size multimodal model, just like Gemini Nano.
So I was wondering that which one is more powerful? Will Gemma 3n be another choice for Chrome built-in AI?

[Kenji Baheux]

Hi Jax,

Great question! 

The following article provides more details about the relationship between Gemma and Gemini Nano, and what's next: https://developers.googleblog.com/en/introducing-gemma-3n/

In particular, this section is relevant (emphasis added):

"Gemma 3n is our first open model built on this groundbreaking, shared architecture, allowing developers to begin experimenting with this technology today in an early preview. The same advanced architecture also powers the next generation of Gemini Nano, which brings these capabilities to a broad range of features in Google apps and our on-device ecosystem, and will become available later this year. Gemma 3n enables you to start building on this foundation that will come to major platforms such as Android and Chrome."

If you have the opportunity, don't hesitate to experiment with Gemma 3n and let us know what you think since that will inform the next generation of Gemini Nano.

Kenji BAHEUX (my how-to)

Product Manager - Chrome

Google Japan

On Thu, May 22, 2025, 6:36 AM Jax <qianju...@gmail.com> wrote:

I heard from I/O that Gemma 3n is a nano-size multimodal model, just like Gemini Nano.
So I was wondering that which one is more powerful? Will Gemma 3n be another choice for Chrome built-in AI?

--
You received this message because you are subscribed to the Google Groups "Chrome Built-in AI Early Preview Program Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-ai-dev-previe...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ai-dev-preview-discuss/63d6d265-4d96-44dc-8854-738f78b071dbn%40chromium.org.

[Thomas Steiner]

Hi Jax,

Remain in the Early Preview Program and you'll hear it first if new model versions drop.

As a general rule, we see the model more as an implementation detail that shouldn't matter to the developer, with the baseline assumption that the browser just chooses the best model and fine tunings for the task at hand automatically. That's why we specified the API interfaces, but not the model details.

For example, our friends over at Microsoft have made available the built-in APIs for testing, but powered by the Phi-4 model: https://blogs.windows.com/msedgedev/2025/05/19/introducing-the-prompt-and-writing-assistance-apis/. 

Cheers,

Tom

Thomas Steiner, PhD—Developer Relations Engineer (blog.tomayac.com, toot.cafe/@tomayac)

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891

----- BEGIN PGP SIGNATURE -----

Version: GnuPG v2.4.3 (GNU/Linux)

iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck

0fjumBl3DCharaCTersAttH3b0ttom.xKcd.cOm/1181.

----- END PGP SIGNATURE -----

On Thu, May 22, 2025, 06:36 Jax <qianju...@gmail.com> wrote:

I heard from I/O that Gemma 3n is a nano-size multimodal model, just like Gemini Nano.
So I was wondering that which one is more powerful? Will Gemma 3n be another choice for Chrome built-in AI?

--

[Jax]

Thanks, Kenji and Tom, thank you for bring those exciting news!

I do have strong interests in Gemma 3n, and already try to use it with MediaPipe (Met 'Array buffer allocation failed' error, though).
And Gemma 3n will inform the next Gemini Nano! Wow!

Also glad to see more vendors are supporting built-in API. Powerful Web made easier!

[Dan Brickley]

On Thu, 22 May 2025 at 16:12, 'Kenji Baheux' via Chrome Built-in AI Early Preview Program Discussions <chrome-ai-dev-...@chromium.org> wrote:

Hi Jax,

Great question! 

The following article provides more details about the relationship between Gemma and Gemini Nano, and what's next: https://developers.googleblog.com/en/introducing-gemma-3n/

In particular, this section is relevant (emphasis added):

"Gemma 3n is our first open model built on this groundbreaking, shared architecture, allowing developers to begin experimenting with this technology today in an early preview. The same advanced architecture also powers the next generation of Gemini Nano, which brings these capabilities to a broad range of features in Google apps and our on-device ecosystem, and will become available later this year. Gemma 3n enables you to start building on this foundation that will come to major platforms such as Android and Chrome."

This is really cool! Gemma seems important in its own right here though, too. For a web project there is also value in having the AI component be an open weights model with more potential for local customisation, evaluation of capabilities, and for discussions in the web standards community about having this piece of the infrastructure be more easily swappable. Would using Gemma allow the Prompt API and related functionality to be part of the Chromium opensource browser, as well as Chrome? As Tom mentions later in the thread, there's a "baseline assumption that the browser just chooses the best model and fine tunings for the task at hand automatically", and that "our friends over at Microsoft have made available the built-in APIs for testing, but powered by the Phi-4 model". While it makes sense for there to be sensible defaults, can we expect to see these choices being made by users and user organizations rather than browser teams? Is this possible yet without hacking at the browser codebase level?

cheers,

Dan

 

If you have the opportunity, don't hesitate to experiment with Gemma 3n and let us know what you think since that will inform the next generation of Gemini Nano.

Kenji BAHEUX (my how-to)

Product Manager - Chrome

Google Japan

On Thu, May 22, 2025, 6:36 AM Jax <qianju...@gmail.com> wrote:

I heard from I/O that Gemma 3n is a nano-size multimodal model, just like Gemini Nano.
So I was wondering that which one is more powerful? Will Gemma 3n be another choice for Chrome built-in AI?

--
You received this message because you are subscribed to the Google Groups "Chrome Built-in AI Early Preview Program Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-ai-dev-previe...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ai-dev-preview-discuss/63d6d265-4d96-44dc-8854-738f78b071dbn%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "Chrome Built-in AI Early Preview Program Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-ai-dev-previe...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ai-dev-preview-discuss/CADWWn7X7Y9%3DJdhK_y2eoABf9GcTGS9w5SKSCskGi32LKx9cteg%40mail.gmail.com.

[Kenji Baheux]

Hi Dan,

Thanks for your insightful questions! You've brought up an excellent point regarding the potential for user customization and the integration of open-source models like Gemma within the Chromium ecosystem.

While shared AI models might require some additional support from our team, it should be technically feasible for anyone to use and fine-tune an LLM, provided the terms of service permit it. Our main question is whether the current lack of easy sharing might make this less attractive for the majority of a product's users. 

• One assumption we have is that some products may command sufficient value and/or user time to rationalize the download of a fine tuned LLM. 
• Other products might not have the same profile, and for those we would need them to agree on building their fine tunings on top of a few preselected shared models to achieve decent cache hit rates. If we were to provide a shared Gemma model, would this be sufficient for most needs or are there other models to consider and why?

 

To better understand the scope and complexity of allowing more user and developer agency in model selection and fine-tuning, we're actively assessing opportunities. If you haven't already, I highly recommend completing one or more of the surveys available in this thread: https://groups.google.com/a/chromium.org/g/chrome-ai-dev-preview/c/4Yj02QbZzXI (I'm happy to repost the survey links if needed).

Furthermore, providing details about your specific use cases and operational context (e.g., managed device environments, large organizations with multiple sites across different origins) would significantly assist us in identifying top priorities and effective solutions.

Lastly, concerning fine-tuned models, if we were to adopt a set of best-in-class shared models and subsequently update these models to their latest versions, how would you handle the update lifecycle? For example, do you have the necessary infrastructure (perhaps internally, or through a cloud service) to smoothly refresh your LoRAs? What kind of lead time would be ideal? Would it be acceptable to optionally fallback to server side with an older version of the model while the LoRA are being refreshed?

Best,

[Cuyler Stuwe]

Some strong thoughts on this:

 

As a general rule, we see the model more as an implementation detail that shouldn't matter to the developer, with the baseline assumption that the browser just chooses the best model and fine tunings for the task at hand automatically. That's why we specified the API interfaces, but not the model details.

I strongly disagree with this assessment, and I think that committing to this approach is what will make the difference in preventing AI developers from adopting the local models for anything beyond demos and little toy applications.

To be clear: It's absolutely the right call to approach it this way from an API perspective. There should be no changes to the API unless there needs to be some new mode of input or output (e.g., if we were to start sending videos to the model and getting videos in response, etc.). 

However, with regard to meaningful AI application behavior, a different model is not merely an "implementation detail" (and intuitively, this is a little bit obvious if you ask yourself: "Why are we even bothering to build different models if we expect to see no substantial difference in behavior?").

As an AI developer, I run evaluations on a model-by-model basis. The applications I build at work using OpenAI and Anthropic's APIs are aimed at a specific dated snapshot of a model checkpoint. They are not aimed broadly at "whatever the latest rolling version of GPT/Claude is".

From the perspective of an AI applications developer, every single change to a model is potentially a breaking change. Model modifications are holistic rather than carefully scoped, and the effects of changes on downstream applications are not fully known to either the vendor or the developer.

Without being able to commit to releasing information about specific models (and pertinent information about those models), developers won't be able to build reliable, useful, sophisticated systems around them.

The probabilistic nature of LLMs already makes them a "moving target" from the perspective of those of us building applications around these systems; This is a double-edged sword, and we work around the downsides. But if you compound the issues by pushing hidden rolling updates as though it were a product for end-users (rather than as an API for developers), it should be unsurprising that it's too unpredictable for developers to adopt.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ai-dev-preview-discuss/CADWWn7WSgiHpfdoabxowZPFjF--uqj5YsQzBXWi_YM-3da_Tqg%40mail.gmail.com.

[Dan Brickley]

There is also a privacy/ fingerprinting angle. I am in favour of there being a good shared AI (inc MCP / tool use etc.) API for browser, webplatform and serverside use which is general across provider. But the fingerprintability issue will need careful discussion…

[Jacob Kinnaird]

 Have proof that I'm the reason for these huge advancements. 

[Scott Fortmann-Roe]

@Cuyler I think the model probably has to be an implementation detail for something like this.

If it isn't, I think you're either freezing the model quality in place indefinitely (if you can even get browser vendors to agree on one), or you're requiring the user to download multiple multi-gigabyte model files to allow you to select specific versions. Neither of those seem very practical.

Also I don't know if Chrome is doing this currently, but ideally they'll have a range of models for different machines. So a top-end MacBook has one model while a low end ChromeBook may have a lower quality one or it may even use a remote service (I do think the ability to specifiy local-only, remote-only, remote-or-local, might be a good thing to bake into the API at this point even though all models are currently local only).

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ai-dev-preview-discuss/CAFfrAFp6rimUGmowGJeHbza57bCrF-Hr13skyx2P6NrnLSSSCg%40mail.gmail.com.

[Thomas Steiner]

Part of the reason why we start with shipping task APIs like the Translator API (vs. exploratory APIs and early-stage APIs) before thinking of shipping the explorative Prompt API is that generally there are benchmarks for tasks like translation, for example, BLEU, METEOR, NIST, and others, so even if different browsers ship these APIs backed by different models, there's still a way to judge if the quality is "good" enough. This is acknowledgedly harder if there's no concrete task to benchmark, as we don't know what people will build with the Prompt API. This is also why we rely on feedback from this group so much. Thank you!

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ai-dev-preview-discuss/CAHqtauEYLyfCE1pokMYHkkevciqnHLR%3Dffmui5g_nW%3DiP_pw_Q%40mail.gmail.com.

--