Загрузить файлы в «/»

Описание работы Ollama с параллельными запросами
This commit is contained in:
2026-03-25 20:07:56 +03:00
parent 7ec80c48b9
commit afc1c537b9

View File

@@ -0,0 +1,145 @@
# 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 на клиента
- Ограничивать количество запросов в секунду для каждого клиента
- При превышении лимита возвращать ошибку `429 Too Many Requests`
### 3. Ограничение используемых моделей
- Разрешать клиенту только определённый список моделей
- Проверять поле `model` в теле запроса
### 4. Детальное логирование
- Логировать имя клиента, метод, путь, статус, длительность запроса