Proxy_for_codex/Instruction_parallel_codex.md

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):

curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -d '{
  "model": "llama3",
  "messages": [
    {
      "role": "user",
      "content": "Почему небо голубое?"
    }
  ]
}'

Структура ответа (формат OpenAI):

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

{
  "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. Детальное логирование

• Логировать имя клиента, метод, путь, статус, длительность запроса