# 1. Одновременная работа с Ollama

---

### Максимальное количество пользователей и зависимые факторы

Прямого жесткого ограничения на "максимальное количество пользователей" в Ollama нет. Вместо этого, реальное количество одновременных сессий определяется следующими ключевыми факторами:

| Фактор | Влияние |
|---|---|
| **Видеопамять (VRAM)** | Это самый главный ограничитель. Каждый параллельный запрос к модели требует дополнительной VRAM. Как только VRAM заканчивается, новые запросы не могут быть обработаны параллельно. |
| **Параметр `OLLAMA_NUM_PARALLEL`** | Эта переменная окружения напрямую указывает, сколько запросов ОДНА модель может обрабатывать одновременно. Требуемая память масштабируется пропорционально этому значению, умноженному на размер контекста модели. |
| **Сложность и размер модели** | Более крупные модели (например, с 70B параметров) потребляют значительно больше VRAM, чем маленькие (например, 7B), что напрямую сокращает возможное число параллельных сессий. |
| **Объем системной памяти (RAM)** | Если модель не помещается полностью в VRAM, часть ее слоев переносится в системную RAM. Это значительно замедляет обработку, но позволяет работать с моделями, превышающими объем VRAM. |
| **Производительность CPU** | Хотя GPU выполняет основную работу, CPU все равно участвует в обработке, и его производительность может стать узким местом при очень большом количестве одновременных легких запросов. |

**Пример:** На GPU `RTX 3090` с 24 ГБ VRAM, для модели размером 8B, можно комфортно обслуживать около 20 одновременных пользователей.

---

### Максимальное значение `OLLAMA_NUM_PARALLEL`

Теоретического или программного "максимума" для `OLLAMA_NUM_PARALLEL` не существует. Вы можете установить это значение хоть в 100, но **практический предел всегда упирается в доступную VRAM**.

Установка слишком высокого значения `OLLAMA_NUM_PARALLEL` приведет к ошибкам нехватки памяти, когда реальные запросы начнут поступать, и сервер не сможет выделить требуемый объем VRAM. Поэтому рекомендуется увеличивать это значение постепенно, тестируя нагрузку.

---

### Что происходит при превышении лимита `OLLAMA_NUM_PARALLEL`?

Если количество одновременных запросов от пользователей превышает значение `OLLAMA_NUM_PARALLEL`, Ollama не "падает" и не теряет запросы. Происходит следующее:

1.  **Запросы в очереди:** Все запросы, которые поступают сверх лимита `OLLAMA_NUM_PARALLEL`, помещаются в очередь.
2.  **Обработка по принципу FIFO:** Эта очередь работает по принципу "первый пришел — первый обслужен" (First-In, First-Out). Как только один из параллельных слотов освобождается, Ollama берет следующий запрос из очереди и начинает его обработку.
3.  **Лимит очереди:** Сама очередь тоже имеет лимит, который задается переменной `OLLAMA_MAX_QUEUE` (по умолчанию 512). Если и эта очередь переполняется, новые запросы будут отклонены с ошибкой `503 Server Overloaded`, что сигнализирует клиенту о перегрузке сервера.

Таким образом, система спроектирована быть отказоустойчивой: она обрабатывает столько, сколько может, а остальных вежливо просит подождать в очереди.

# 2. API Ollama

Ollama предоставляет два основных способа взаимодействия через API:
1.  **API, совместимый с OpenAI (рекомендуемый)**: Имитирует структуру OpenAI API, что позволяет использовать огромное количество существующих инструментов "из коробки".
2.  **Нативный API Ollama**: Прямой, более простой API для базовых взаимодействий.

Для большинства задач, включая интеграцию с внешними инструментами, **настоятельно рекомендуется использовать API, совместимый с OpenAI**.

---

## 1. API, совместимый с OpenAI

Этот режим специально создан для того, чтобы любые приложения, написанные для работы с OpenAI, могли без изменений кода работать с вашим локальным сервером Ollama.

*   **Базовый URL:** `http://<адрес_вашего_сервера>:11434/v1`
*   **Ключ API (API Key):** Не требуется. Библиотеки могут требовать указать его, но Ollama игнорирует любое переданное значение.

### Ключевой эндпоинт: `POST /v1/chat/completions`

Это полный аналог эндпоинта OpenAI для чатов.

**Пример запроса (`curl`):**
```bash
curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -d '{
  "model": "llama3",
  "messages": [
    {
      "role": "user",
      "content": "Почему небо голубое?"
    }
  ]
}'
```
Структура ответа (формат OpenAI):

Ответ полностью соответствует формату OpenAI, используя массив choices для вывода.

```JSON
{
  "id": "chatcmpl-123",
  "object": "chat.completion",
  "created": 1716218112,
  "model": "llama3",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Небо кажется голубым из-за явления, называемого рэлеевским рассеянием..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 10,
    "completion_tokens": 150,
    "total_tokens": 160
  }
}
```

## 2. Нативный API Ollama
Ollama также имеет свой собственный, более простой API. Он может быть полезен для быстрых скриптов или специфических задач.

| Метод | Эндпоинт | Описание |
|---|---|---|
| `POST` | `/api/chat` | Основной эндпоинт для чата (нативный формат). |
| `POST` | `/api/generate` | Генерация текста из одного промпта. |
| `GET` | `/api/tags` | Получение списка локальных моделей. |
| `POST` | `/api/pull` | Скачивание модели из репозитория. |
| `DELETE` | `/api/delete` | Удаление локальной модели. |

# 3. Расширение прокси для работы нескольких Codex

---

## Что даёт настройка Ollama (без изменений в прокси)

| Переменная | Назначение |
|---|---|
| `OLLAMA_NUM_PARALLEL` | Количество одновременно обрабатываемых запросов одной моделью. |
| `OLLAMA_MAX_QUEUE` | Размер очереди ожидания (по умолчанию 512). Превышение → ошибка 503. |
| `OLLAMA_KEEP_ALIVE` | Время удержания модели в памяти после последнего запроса. |

Если эти параметры выставлены, Ollama справляется с несколькими клиентами: запросы сверх `NUM_PARALLEL` встают в очередь, а после освобождения слота обрабатываются. Прокси в этом случае выступает просто как прозрачный шлюз.

---

## Как можно улучшить прокси

Для **контроля доступа**, **изоляции клиентов** и **предотвращения злоупотреблений** в прокси можно добавить следующие механизмы:

### 1. Аутентификация по API-ключам
- Идентифицировать каждого клиента по уникальному токену
- Отклонять запросы без валидного ключа

### 2. Rate limiting на клиента
- Ограничивать количество запросов в секунду для каждого клиента

### 3. Ограничение используемых моделей
- Разрешать клиенту только определённый список моделей
- Проверять поле `model` в теле запроса

### 4. Детальное логирование
- Логировать имя клиента, метод, путь, статус, длительность запроса