> For the complete documentation index, see [llms.txt](https://docs.maiagent.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.maiagent.ai/tech/en/platform-development/architecture.md).

# Deployment Architecture

MaiAgent is a scalable generative AI platform that supports a wide range of application scenarios. To accommodate different business requirements and resource configurations, the platform offers two primary deployment modes: **all-in-one deployment** and **distributed deployment**.

This chapter explains the differences between these architectures, their applicable scenarios, and their respective advantages and disadvantages, and provides practical deployment references.

## All-in-One Deployment

### Architecture Overview

In all-in-one deployment mode, all core MaiAgent components—including the main service, task scheduling service, data storage, database, and frontend service—are installed and run on the same server. This mode features **centralized management** and simple deployment, making it suitable for rapid launches and test environments.

The MaiAgent platform can run without a GPU and can be deployed and operated smoothly in a standard CPU environment. However, on a machine with GPU resources, the platform can also be deployed in the same environment as the models to take full advantage of hardware acceleration. Two common architecture diagrams are provided below for reference.

### Architecture Diagrams

1. Deployment on a server with a GPU:

The MaiAgent platform and model service are installed on the same machine. The platform coordinates requests and controls traffic through an internal API, while the model uses the GPU for efficient inference. Hosting the platform and model service together eliminates the need to purchase a separate general-purpose server solely for running the platform, reducing overall hardware costs.

<figure><img src="https://3415477754-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNBTi475lqozGpB7xObpE%2Fuploads%2Fgit-blob-c44f0012dfa26a57f94b3502599ef95e0449b82b%2F%E6%88%AA%E5%9C%96%202025-09-07%20%E4%B8%8A%E5%8D%8810.45.02.png?alt=media" alt=""><figcaption></figcaption></figure>

2. Deployment on a server without a GPU:

When MaiAgent is deployed on a server without a GPU, it must connect through an API to a GPU server or cloud API inference service because a model service is still required. When the platform and model service are separated, they can scale independently. Computing capacity can be increased or decreased as needed, making the architecture more flexible and maintainable.

<figure><img src="https://3415477754-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNBTi475lqozGpB7xObpE%2Fuploads%2Fgit-blob-ae088ec75c4ed0ad2b74d027af6f5afdae86dff2%2F%E6%88%AA%E5%9C%96%202025-09-07%20%E4%B8%8A%E5%8D%8811.35.32.png?alt=media" alt=""><figcaption></figcaption></figure>

## Distributed Deployment

### Architecture Overview

In distributed deployment mode, MaiAgent’s core modules are separated into independent services and distributed across multiple servers. Each module can be scaled horizontally according to demand, enabling high availability and large-scale processing.

* **Cloud platform (Cloud PaaS) environment**\
  In public or private cloud environments, you can directly use platform-as-a-service (PaaS) capabilities such as Kubernetes, AWS ECS/EKS, GCP Cloud Run, and Azure App Service. These services provide container orchestration, load balancing, auto-scaling, and monitoring, allowing distributed modules to be deployed quickly and resources to be adjusted dynamically while reducing infrastructure operations overhead.
* **On-premises (On-Premise VM) environment**\
  Even in an on-premises VM environment, container platforms or application service frameworks can be deployed using virtual machines or bare-metal servers to provide distributed management and scaling capabilities similar to the cloud. Although cluster resources, monitoring, and redundancy mechanisms must be planned and managed internally, high availability and elastic scaling can still be achieved.

### Architecture Diagram

<figure><img src="https://3415477754-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNBTi475lqozGpB7xObpE%2Fuploads%2Fgit-blob-b75d99c8b7d76847ec9ff2bd2c967640c156f6b3%2F%E6%88%AA%E5%9C%96%202025-09-07%20%E4%B8%8A%E5%8D%8811.28.15.png?alt=media" alt=""><figcaption></figcaption></figure>

## Deployment Mode Comparison

<table><thead><tr><th width="133.58203125">Feature</th><th>All-in-One Deployment</th><th>Distributed Deployment</th></tr></thead><tbody><tr><td><strong>Architecture design</strong></td><td>All components are centralized on a single server/container</td><td>Components are separated into independent services distributed across multiple nodes</td></tr><tr><td><strong>Infrastructure cost</strong></td><td>Low; only one server is required</td><td>High; multiple servers or cloud resources are required</td></tr><tr><td><strong>Deployment cost</strong></td><td>Low</td><td>High; deployment is complex and requires a DevOps team</td></tr><tr><td><strong>Maintenance cost</strong></td><td>Low; centralized management</td><td>High; maintenance and monitoring span multiple servers and services</td></tr><tr><td><strong>Scalability</strong></td><td>None; limited by the resources of a single machine</td><td>Available; bottleneck modules can be scaled independently</td></tr><tr><td><strong>High availability</strong></td><td>None; a single point of failure interrupts the entire system</td><td>Available; failure of a single service does not affect the overall system</td></tr><tr><td><strong>Applicable scenarios</strong></td><td>PoCs, development and testing, and small-scale applications</td><td>Production deployments, large-scale applications, and multi-department use</td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.maiagent.ai/tech/en/platform-development/architecture.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.