Sara Metwalli’s piece on Towards Data Science argues that modern AI is as much a hardware story as a software one: CPUs coordinate, GPUs supply the parallel throughput that training needs, TPUs specialize in tensor math, and NPUs run inference on phones at low power. I agree with her. What I’d add is that for WordPress work the AI hardware list mostly shrinks. Three of those four chips will never sit in your stack, and the one that does is the least glamorous.
The AI hardware list, quickly
CPUs have a few powerful cores and are built for flexibility, so they run the operating system, load data and coordinate other devices. GPUs have thousands of small cores, originally for pushing pixels, and matrix multiplications map onto that nicely, which is why the big models get trained on clusters of them. TPUs, Google’s chips, do a narrow set of tensor operations very well, and NPUs do one job, energy-efficient inference, on personal devices. That taxonomy is accurate, and it’s useful when a client asks for an AI feature, because it tells you where the compute lives. The answer is almost never your web server.
Your server is the CPU in the story
WordPress runs on PHP, and PHP runs on a CPU. A typical host has no GPU and meters CPU time, sometimes tightly on shared plans. So the server side of an AI feature is coordination work: assemble the prompt, call the model, store the result. Scale is the part people get wrong. Batch-generate alt text or product summaries for a media library with a few thousand items and you’ve built a queue on a CPU-metered box. The common failure is overlapping cron jobs eating the account. Use Action Scheduler or WP-Cron with small batches, and take a transient lock per batch so the same job never runs twice.
Where inference runs, and how to call it
Inference happens on the provider’s GPUs or TPUs, and both the latency and the per-request cost live there. Your job is to call it carefully. The pattern I use is a timeout, an error check and a cache, because the same product description doesn’t need a fresh completion on every page view. It’s the same shape most AI workflows in WordPress settle into eventually.
function bbioon_get_completion( $prompt ) {
$cache_key = 'bbioon_ai_' . md5( $prompt );
$cached = get_transient( $cache_key );
if ( false !== $cached ) {
return $cached;
}
$response = wp_remote_post(
'https://api.example-model.com/v1/generate',
array(
'timeout' => 15,
'headers' => array(
'Content-Type' => 'application/json',
'Authorization' => 'Bearer ' . BBIOON_AI_KEY, // define() outside the repo
),
'body' => wp_json_encode( array( 'prompt' => $prompt ) ),
)
);
if ( is_wp_error( $response ) || 200 !== wp_remote_retrieve_response_code( $response ) ) {
return ''; // fall back to the human-written text
}
$data = json_decode( wp_remote_retrieve_body( $response ), true );
$text = $data['text'] ?? '';
set_transient( $cache_key, $text, DAY_IN_SECONDS );
return $text;
}The wp_remote_post reference covers the arguments; the two worth caring about are the timeout, since model APIs are slower than the APIs you’re used to, and the fallback branch, which fires more often than you’d think. If you want an AI feature wired into a WordPress or WooCommerce site like this, with caching and fallbacks instead of a raw API call per request, that’s the kind of work I do. Describe the feature and I’ll scope where the compute should live.
The one chip on your side is the visitor’s
The NPU is the only chip in the story that ends up on your side, inside the visitor’s phone or laptop, and the browser reaches it through WebGPU. MDN describes WebGPU as giving JavaScript access to the system GPU for general-purpose compute, notes it requires HTTPS, and doesn’t consider it Baseline yet. Chrome shipped it in 113, and Firefox and Safari followed. For a store, that means something like product search over a small embedding index that runs entirely in the browser, with no API key shipped to visitors and no per-search bill.
Treat it as an enhancement. Keep the server search as a fallback, and remember the model file is real weight on the page. I’m not sure I’d bet anything checkout-adjacent on it yet, given the uneven browser support. Feature-detect navigator.gpu and lazy-load the model after the first interaction, so it stays off the critical path.
