Everything in this series so far calls a hosted API. But Google also publishes Gemma, open-weight models from the same research lineage as Gemini, and they run happily on a developer laptop or a modest VPS. No API key, no per-token billing, no content leaving your machine.
That’s not a free lunch: local models are a capability tier below hosted frontier models. The interesting question is which WordPress workflows fit inside that tier, and there are more of them than you’d guess.
Setup: Ollama in five minutes
Ollama is the least-friction way to run Gemma locally. Install it (one command on Linux/macOS, an installer on Windows), then:
ollama pull gemma3:4b
ollama run gemma3:4b "Suggest five tags for a post about WordPress performance tuning."
Model size guidance, honestly: the small (1B-class) variants are fast on anything but noticeably limited: fine for classification, weak for prose. The 4B-class is the sweet spot for content tasks on ordinary hardware (8GB RAM). The 12B–27B class approaches genuinely good output but wants a real GPU or an Apple Silicon machine with memory to spare. Start with 4B; move up only if quality actually fails your task.
Ollama serves an HTTP API on localhost:11434, including an OpenAI-compatible endpoint, which means every tool that speaks that de-facto standard works with your local Gemma out of the box.
Calling it from PHP
Same pattern as the whole series, different URL, no key:
function gemma_generate( string $prompt ): string|WP_Error {
$response = wp_remote_post( 'http://localhost:11434/api/generate', [
'timeout' => 120, // local inference is slower than hosted APIs
'headers' => [ 'Content-Type' => 'application/json' ],
'body' => wp_json_encode( [
'model' => 'gemma3:4b',
'prompt' => $prompt,
'stream' => false,
'options' => [ 'temperature' => 0.3 ],
] ),
] );
if ( is_wp_error( $response ) ) {
return $response;
}
$data = json_decode( wp_remote_retrieve_body( $response ), true );
return $data['response'] ?? '';
}
If you architected your plugin with all AI calls behind one client function (as this series has nagged you to), pointing your development environment at local Gemma is a configuration change, not a refactor.
Where local genuinely wins
Development and testing. This is the underrated one. Building an AI plugin means hundreds of test generations. Against the hosted API that’s rate limits, quota anxiety, and a bill for testing error paths. Against local Gemma it’s free and offline: build against Gemma, integration-test against Gemini before release.
Privacy-constrained content. Client sites with contracts or compliance rules about data leaving infrastructure; internal knowledge bases; anything under NDA. “The model runs on the same server as WordPress” collapses a data-processing conversation that would otherwise involve lawyers.
High-volume, low-stakes batch work. Tagging ten thousand archive posts, drafting meta descriptions, first-pass categorization. Per-token pricing makes rerunning a large batch a decision; local inference makes it a for loop you leave running overnight. The failure mode is quality, so spot-check a sample before trusting a full run.
Latency-tolerant background jobs. A cron job enriching content at 3 a.m. doesn’t care that local inference took nine seconds instead of two.
Where hosted Gemini stays the right call
Equally important to say plainly:
- Anything interactive: users won’t wait for laptop-class inference, and your production web server almost certainly shouldn’t be running a model next to PHP-FPM.
- Tasks needing frontier capability: long-context reasoning, subtle editorial judgment, reliable complex structured output. The gap is real; pretending otherwise produces bad features.
- Multimodal and tool-heavy workflows: image understanding, function calling, and schema-constrained output are dramatically more dependable on the hosted API.
- Anything where you’d have to build your own scaling, monitoring, and failover to serve it: you’d be re-implementing Google’s infrastructure with worse economics.
The hybrid pattern
The setup I keep landing on for WordPress work: local Gemma for development and for private/batch enrichment; hosted Gemini Flash for interactive features; escalation to Pro for the hard cases (the cascade from the previous post). One client abstraction, three backends, each doing what it’s economically and technically best at.
A closing note on why this matters beyond economics: running a model locally (watching it load into memory, feeling the latency, seeing where a 4B model’s judgment frays at the edges) builds intuition about what these systems actually are that no amount of polished API responses provides. It makes you better at using the hosted models too. Pull one down this weekend and point a test WordPress install at it; the whole experiment costs an hour.
Next in the series: pointing Gemini at security work, with AI-assisted malware triage for WordPress files, from someone who cleans infected sites for a living.
Also in this Gemini × WordPress series: Gemini Flash vs Pro for Content Pipelines.
This post is part of the Gemini and WordPress developer guide, which lists every post in the series.