> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orq.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# AI gateway vs config management

> Compare AI Gateway and Configuration Management integration patterns. Choose the right Orq.ai architecture for your LLM application deployment strategy.

There are two main ways of integrating **orq.ai** to your systems. Using the service as a **Gateway** or as a **Configuration Management** system.

## Gateway

The main way of using **orq.ai** as a AI Gateway would be its simple integration to existing systems. **orq.ai**'s deployment urls will be used to send requests to the LLM backends.

<img src="https://mintcdn.com/orqai/dw2ZHifUWLDAlqTf/images/docs/9f18c2a-Screenshot_2024-07-31_at_14.15.59.png?fit=max&auto=format&n=dw2ZHifUWLDAlqTf&q=85&s=62cf474f3994537defbe1e6709e6a583" alt="Architecture diagram showing a User connecting to Your App via an AI Gateway through orq.ai, which fans out to multiple AI providers including OpenAI, Azure, Cohere, Anthropic, and Groq." width="2266" height="1764" data-path="images/docs/9f18c2a-Screenshot_2024-07-31_at_14.15.59.png" />

There are multiple advantages to using **orq.ai** this way:

* It makes **managing multiple LLM providers simple**, as **orq.ai** becomes the interface to reach all LLM backend available. This makes your integration with multiple LLM transparent.
* You benefit from the native **retry mechanism and error management** we offer. If a call fails to one LLM provider, it is retried seamlessly. Moreover, prolonged failure can result into fallbacks to different providers. To learn more see [Retries and Fallbacks](/docs/proxy/retries).
* Logs & Monitoring is native to **orq.ai**, all calls will be logged and searchable in the panel, this way you keep trace of all your application's activity with LLM and can detect potential issues quickly.

One thing to keep in mind:

* This puts Orq.ai on the critical path of your applications and systems, making its availability and potential fallback path something to consider when designing a fault-tolerant system.

## Configuration Management

You can decide to use **orq.ai** only as configuration management for your various LLM backend.

<img src="https://mintcdn.com/orqai/H9mjdYaABF092Mk-/images/docs/06b9bcf-Screenshot_2024-07-31_at_14.17.14.png?fit=max&auto=format&n=H9mjdYaABF092Mk-&q=85&s=35c5699f510c609d243b5b248814605f" alt="Architecture diagram showing orq.ai providing Prompt & Model Configuration and Observability & Feedback to Your App, which calls AI providers directly for generation." width="2256" height="1628" data-path="images/docs/06b9bcf-Screenshot_2024-07-31_at_14.17.14.png" />

This has some advantages over using AI Gateway:

* You manage **the calls to LLM Models end-to-end**, this lets you keep control over the integration and manage its lifecycle, ensuring data stays within your infrastructure before reaching LLM backends.
* You still benefit from the configuration management on **orq.ai** side and can fetch at runtime the latest configuration from your Deployment.
* You still benefit from [Deployment Routing](/docs/deployments/creating#routing), ensuring your users reach the model you desire.
