Open Models From the Research Behind Gemini
Gemma is Google's family of open-weight models, built from the same research and technology as Gemini. That lineage is the point: capability developed for a frontier model, released in sizes you can actually run and inspect. The family spans a wide range, from models small enough for a single consumer GPU to mid-size models that handle serious production work — all sharing one interface, so moving between them is a configuration change rather than a rewrite. On DEVUP AI they are reachable through the standard OpenAI-compatible endpoint with one API key, billed in Algerian Dinar.

Gemma occupies a position most model families do not: open weights from an organisation that also ships a closed frontier model. The family is built from the same research and technology as Gemini, which means the techniques proven at frontier scale arrive in sizes that fit on hardware you can afford — and in weights you can download, inspect, and fine-tune rather than only call.
Breadth is the family's practical strength. It spans small models suitable for edge deployment and local development through to mid-size models that carry production traffic, and the whole range shares an interface. A prototype that starts on a small model and turns out to need more moves up by changing one field. That continuity is worth more in a real project than any single benchmark, because it removes the cost of being wrong about sizing at the start.
Open weights change what is possible beyond the API. Fine-tuning on your own data, running the model inside your own infrastructure for a workload that cannot leave it, and inspecting behaviour directly rather than inferring it — none of those are available on a closed model at any price. For teams with a narrow, stable task and enough examples, adapting an open model is frequently the shorter path to good results than prompting a larger one.
On DEVUP AI, Gemma models are called through the same OpenAI-compatible endpoint as the rest of the catalogue: one API key, one base URL, and a model identifier. Capabilities, context limits, and recommended settings differ between models in the family, so check the individual model page before switching a production path.
Available Gemma Models
Deploy and access all published models in this family with unified DZD pricing and zero foreign card requirement.
| Model | Context | DZD in / 1M tokens | DZD out / 1M tokens | Actions |
|---|---|---|---|---|
| gemma-4-E4B-itgoogle/gemma-4-E4B-it | — | 7 | 35 | View model |
| gemma-4-31B-it-Ultragoogle/gemma-4-31B-it-Ultra | 131K Tokens | 94.5 | 266 | View model |
| gemma-3-4b-itgoogle/gemma-3-4b-it | 131K Tokens | 17.5 | 35 | View model |
| gemma-3-27b-itgoogle/gemma-3-27b-it | 131K Tokens | 28 | 56 | View model |
| gemma-3-12b-itgoogle/gemma-3-12b-it | 131K Tokens | 17.5 | 52.5 | View model |
| gemma-4-31B-it-turbogoogle/gemma-4-31B-it-turbo | 262K Tokens | 42 | 129.5 | View model |
| embeddinggemma-300mgoogle/embeddinggemma-300m | 2K Tokens | 0.6533 | — | View model |
| gemma-4-31B-itgoogle/gemma-4-31B-it | 256K Tokens | 45.5 | 133 | View model |
| gemma-4-26B-A4B-itgoogle/gemma-4-26B-A4B-it | 262K Tokens | 24.5 | 119 | View model |
Call any Gemma model
Every model on this page uses the same API key and standard OpenAI-compatible endpoint. The example below uses the featured model google/gemma-4-31B-it-turbo.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DEVUP_API_KEY"],
base_url="https://api.devupai.com/v1",
)
response = client.chat.completions.create(
model="google/gemma-4-31B-it-turbo",
messages=[
{"role": "user", "content": "Hello world!"}
],
max_tokens=1024,
)
print(response.choices[0].message.content)import DevupAI from "devupai";
const client = new DevupAI({
apiKey: process.env.DEVUP_API_KEY,
});
async function main() {
const response = await client.chat.completions.create({
model: "google/gemma-4-31B-it-turbo",
messages: [{ role: "user", content: "Hello world!" }],
max_tokens: 1024,
});
console.log(response.choices[0].message.content);
}
main();curl -X POST "https://api.devupai.com/v1/chat/completions" \
-H "Authorization: Bearer $DEVUP_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "google/gemma-4-31B-it-turbo",
"messages": [
{ "role": "user", "content": "Hello world!" }
],
"max_tokens": 1024
}'Frequently Asked Questions
Match the size to the task rather than starting at the top. Smaller models handle classification, routing, extraction, and formatting at volume, where latency and cost per call decide whether a design is workable. Larger models suit general assistance, code, and analysis. Because the family shares an interface, testing a smaller model on your workload costs one changed field — and the result is better evidence than any benchmark table.
Three things a closed model cannot offer at any price: you can fine-tune on your own data, you can run the model inside infrastructure that your data is not permitted to leave, and you can inspect its behaviour directly. If none of those matter to your project, the open weights are a nice property rather than a deciding one — and you can use the model through the API exactly as you would any other.
When the task is narrow, its definition is stable, and you run it constantly. Prompting adapts a model without training it, and it costs input tokens on every single call — a long system prompt repeated across a million requests is a permanent tax. Fine-tuning moves that instruction into the weights. It is the wrong answer for anything whose definition changes often, or where you have too few examples to train on.
Support varies by model within the family rather than applying to all of them. Check the individual model page before building around it — assuming a capability that a specific model does not have produces a failure at the point where someone looks at the output, not at the point where the request is sent.
Not for the core call. Every model in the family uses the same OpenAI-compatible chat completions endpoint, so switching is a change to the model field. What does vary is context limits, input types, and recommended sampling settings — those live on the individual model pages and are worth reading before moving a production path.
They come from the same research and technology, and they occupy different positions. Gemini models are closed and reached only through an API. Gemma models are open weight — downloadable, inspectable, and fine-tunable. The relationship means techniques developed at frontier scale reach the open family; it does not mean the two are interchangeable, and the individual model pages are where the real capability differences live.