Choose your platform

Before you build with AI, you have to choose the platform it's hosted on. Your choice impacts the speed, cost, scalability, and trustworthiness of your AI system. You can choose between:

• Client-side AI: Runs directly in the browser. This means data can stay private, on the user's device, and there's no network latency. However, to perform well, client-side AI needs highly specific, well-defined use cases.
• Server-side AI: Runs in the cloud. It's highly capable and scalable, but more expensive in terms of latency and cost.

Each option comes with trade-offs, and the right setup depends on your use case, team skills, and resources. For example, you may offer a summarization tool that runs locally so users can ask personal questions without needing to manage personally identifiable information (PII). However, a customer support agent could give more useful answers by using a cloud-based model that has access to a large database of resources.

In this module, you learn how to:

• Compare the trade-offs between client and server-side AI.
• Match your platform to your use case and team capabilities.
• Design hybrid systems, which offer AI on the client and server, to grow with your product.

Review the options

For deployment, think of AI platforms along two primary axes. You can choose:

• Where the model runs: Is it running client-side or server-side?
• Customizability: How much control do you have over the model's knowledge and capabilities? If you can control the model, meaning you can modify the model weights, you can customize its behavior to meet your specific requirements.

Client-side AI

Client-side AI runs in the browser, and computation happens locally on the user's device. You don't need to provide for inference-time compute, and data stays on the user's machine. This makes it fast, private, and suitable for lightweight, interactive experiences.

However, client-side models are usually quite small, which can constrain their capabilities and performance. They're best suited for highly specialized tasks, such as toxicity detection or sentiment analysis. Often, these are predictive AI tasks with a limited output space.

There are two primary options:

• Built-in AI: Browsers, such as Google Chrome and Microsoft Edge, are integrating AI models. These are accessible through JavaScript calls, with no setup or hosting required. Once the model is downloaded, it can be called by all websites that use it.
• Custom models: You can use client-side libraries, such as Transformers.js and MediaPipe, to integrate models into your application. This means you can control the model weights. However, that also means that every user of your website has to download your custom model. Even the smallest AI models are large in the context of a website.

Server-side AI

With server-side AI, your web application calls an API to send inputs to the AI model and receive its outputs. This setup supports larger, more complex models and is independent of user hardware.

The two categories for server-side AI are:

• Managed services: These are models hosted in data centers by a third-party, such as Gemini 3 and GPT-5. The model owner provides an API to access it. This means you can use state-of-the-art models with minimal setup. These are ideal for fast prototyping, open-ended conversation, and general-purpose reasoning. However, scaling on a managed service can be expensive.
• Self-hosted models: You can deploy open-weight models, such as Gemma or Llama, on your own infrastructure or in a managed container, such as Vertex AI or Hugging Face Inference. This approach means you can benefit from pre-training done by the model creator, but you maintain control over the model, fine-tuning data, and performance.

Choose an initial platform

Review the architectural characteristics of the AI platforms and analyze the trade-offs to decide on your initial setup.

Define your architectural requirements

With every decision, you have to make compromises. Take a look at the key characteristics that define the cost and value of your AI platform:

• Model power: How well the model performs across a wide range of users and tasks, without tuning. Often, this correlates with model size.
• Customizability: The extent to which you can fine-tune, modify, or control model behavior and architecture.
• Accuracy: The overall quality and reliability of the model's predictions or generations.
• Privacy: The degree to which user data stays local and under user control.
• Fixed cost: The recurring expense required to operate the AI system regardless of usage, incl. infrastructure provisioning and maintenance.
• Cost-per-request: The additional cost of each incoming request.
• Compatibility: How widely the approach works across browsers, devices, and environments without fallback logic.
• User convenience: Whether users need to take extra steps to use the AI system, like downloading a model.
• Developer convenience: How quick and easy it is to most developers to deploy, integrate, and maintain the model, without specialized AI expertise.

The following table provides an example of estimates for how well each platform performs for each criterion, where 1 is the lowest and 5 is the highest.

Analyze trade-offs

To illustrate the decision-making process, we'll add another feature to Example Shoppe, a mid-sized ecommerce platform. You're interested in saving costs in off-hours customer service, so you decide to build an AI-powered assistant to answer user questions about orders, returns, and products.

Analyze the scenario using two lenses: use case requirements and business or team constraints.

Now that you've prioritized your criteria, you can refer to the trade-off estimation table to determine what platform matches your highest-priority criteria:

It's clear from this breakdown that you should use server-side AI, and probably a managed service. This offers a versatile model for complex customer questions. It minimizes maintenance and development effort by offloading infrastructure, model quality, and uptime to the provider.

While customizability is limited, this is a worthwhile trade-off for a web development team with limited model engineering experience.

A retrieval-augmented generation (RAG) setup can help you to provide the relevant context to the model at inference time.

Hybrid AI

Mature AI systems rarely run on a single platform or with one model. Rather, they distribute AI workloads to optimize the trade-offs.

Spot opportunities for hybrid AI

Once you've launched, you should refine your requirements based on real-life data and feedback. In our example, Example Shoppe, you wait a few months to analyze the results and find the following:

• Around 80% of requests are repetitive ("Where is my order?", "How do I return this?"). Sending these requests to a managed service creates a lot of overhead and cost.
• Only 20% of requests require deeper reasoning and an open-ended, interactive conversation.

A lightweight local model could classify user inputs and answer routine queries, such as, "What is your return policy?" You can route complex, rare, or ambiguous questions to the server-side model.

By implementing both server-side and client-side AI, you can reduce costs and latency, while maintaining access to powerful reasoning when needed.

Distribute the workload

To build this hybrid system for Example Shoppe, you should start by defining the default system. In this case, it's best to start client-side. The application should route to server-side AI in two cases:

• Compatibility-based fallback: If the user's device or browser cannot handle the request, it should fall back to the server
• Capability-based escalation: If the request is too complex or open-ended for the client-side model, as defined by predetermined criteria, it should be escalated to a larger server-side model. You could use a model to classify the request as common, so you perform the task client-side, or uncommon, and you send the request to the server-side system. For example, if the client-side model determines that the question is related to an uncommon issue, such as getting a refund in a different currency.

Flexibility introduces more complexity

Distributing workloads between two platforms makes you more flexible, but it also adds complexity:

• Orchestration: Two execution environments mean more moving parts. You need logic for routing, retries, and fallbacks.
• Versioning: If you use the same model across platforms, it must stay compatible across both environments.
• Prompt engineering and context engineering: If you use different models on each platform, you need to perform prompt engineering for each.
• Monitoring: Logs and metrics are split and require extra unification effort.
• Security: You're maintaining two attack surfaces. Both local and cloud endpoints need hardening.

This is another trade-off for your consideration. If you have a small team or you're building a non-essential feature, you may not want to add this complexity.

Your takeaways

Expect your platform choice to evolve. Start from the use case, align with your team's experience and resources, and iterate as both your product and your AI maturity grow. Your task is to find the right mix of speed, privacy, and control for your users, then build with some flexibility. This way, you can adapt to changing requirements and benefit from future platform and model updates.

Resources

• As platform and model choice is interdependent, read more about model selection.
• Read how to go beyond cloud with hybrid and client-side AI

Check your understanding