Почему ваш Ollama тормозит и как это исправить
Вы ставите Ollama, запускаете модель, а потом пытаетесь отправить второй запрос, пока первый еще думает. Результат? Очередь. Один агент работает, остальные ждут. Это как стоять в очереди за кофе, когда у вас срочное совещание. Медленно, неэффективно и бесит.
Проблема в архитектуре. Такие инструменты как Ollama или LM Studio отлично подходят для демо, но для продакшена, где нужны параллельные запросы от нескольких агентов, они не годятся. Нужен сервер инференса, который умеет обрабатывать много запросов одновременно.
Решение — vLLM. Это не просто еще один бэкенд для запуска моделей. Его движок PagedAttention умеет эффективно управлять видеопамятью (VRAM), что позволяет обрабатывать десятки параллельных запросов на одной карте. А если обернуть его в Docker, получаем изолированную, воспроизводимую среду.
Что строим: фабрика агентов на стероидах
Цель — система, где три агента работают одновременно, не мешая друг другу:
- Агент-кодер (Claude Code) — пишет код. Специализированная модель от Anthropic, заточенная под программирование. На 22.03.2026 актуальна версия Claude-Code-1.5 с контекстом 128K токенов.
- Агент-аналитик (GPT-OSS-120B) — проверяет код, ищет уязвимости, предлагает архитектурные решения. Модель с открытым исходным кодом, альтернатива GPT-4.
- Агент-оркестратор — простой Python-скрипт, который распределяет задачи между первыми двумя.
Все это крутится на одной машине с Linux, желательно с GPU типа NVIDIA RTX 6000 Ada или лучше. Если у вас нет такой карты, загляните в гайд про сборку станции для LLM. Или используйте облачный инстанс.
1Подготовка Linux: выкидываем лишнее
Если вы еще не на Linux, самое время перейти. Ubuntu 24.04 LTS или последний стабильный Debian — ваш выбор. Windows для такого — мучение.
Первое что делаем — чистим систему от телеметрии и ненужных сервисов. Особенно если у вас серверное железо NVIDIA. В статье "DGX OS умер, да здравствует Ubuntu" есть подробности. Кратко:
# Отключаем службы телеметрии NVIDIA (если есть)
sudo systemctl stop nvidia-telemetry
sudo systemctl disable nvidia-telemetry
# Обновляем систему и ставим необходимое
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget git python3-pip python3-venv2Docker и NVIDIA Container Toolkit: клетка для GPU
vLLM мы будем запускать в контейнерах. Это дает изоляцию и простоту развертывания. Но чтобы Docker видел GPU, нужен NVIDIA Container Toolkit.
# Устанавливаем Docker
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
# Устанавливаем NVIDIA Container Toolkit (актуально на 22.03.2026)
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/libnvidia-container/gpgkey | sudo apt-key add -
curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker
# Проверяем
docker run --rm --runtime=nvidia --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smiЕсли команда nvidia-smi в контейнере не работает, проверьте драйверы на хосте. Нужны драйверы NVIDIA версии 550 или новее. Команда nvidia-smi на хосте должна показывать вашу карту.
3Запускаем vLLM в Docker: сервис инференса
Теперь самое интересное. Берем официальный образ vLLM с Docker Hub. На 22.03.2026 актуальна версия vLLM 0.5.0 или новее, с поддержкой новейших моделей.
# Тянем образ
docker pull vllm/vllm-openai:latest
# Запускаем контейнер для модели Claude Code
# Важно: указываем правильное имя модели и выделяем часть GPU
docker run -d \
--gpus all \
--shm-size=10g \
-p 8000:8000 \
-v ~/.cache/huggingface:/root/.cache/huggingface \
vllm/vllm-openai:latest \
--model NousResearch/Hermes-3-Code-13B \
--served-model-name claude-code \
--max-model-len 8192 \
--tensor-parallel-size 1 \
--gpu-memory-utilization 0.5Что за флаги?
--shm-size=10g— увеличиваем shared memory, иначе большие модели не загрузятся.-p 8000:8000— выставляем порт. vLLM предоставляет OpenAI-совместимый API.-v ... /root/.cache/huggingface— монтируем кеш моделей, чтобы не качать заново при перезапуске.--gpu-memory-utilization 0.5— говорим vLLM использовать только 50% VRAM этой карты. Это чтобы на той же карте запустить вторую модель.
А где же Claude Code? Дело в том, что оригинальная модель Claude — проприетарная. Но в открытом доступе есть отличные альтернативы, обученные на кодексе. Например, NousResearch/Hermes-3-Code-13B (актуальна на 2026 год). Она отлично справляется с генерацией кода. Если хотите именно Claude, нужен доступ к API Anthropic, но это уже не 100% локально.
Запускаем второй контейнер для модели GPT-OSS-120B. Она больше, поэтому может потребоваться несколько GPU.
# Для большой модели на нескольких GPU
docker run -d \
--gpus all \
--shm-size=20g \
-p 8001:8000 \
-v ~/.cache/huggingface:/root/.cache/huggingface \
vllm/vllm-openai:latest \
--model openbmb/gpt-oss-120b \
--served-model-name gpt-oss \
--max-model-len 4096 \
--tensor-parallel-size 2 \
--gpu-memory-utilization 0.8Обратите внимание на --tensor-parallel-size 2. Это говорит vLLM разбить модель между двумя GPU. Если у вас одна карта с 48GB VRAM, можно попробовать поставить 1, но модель может не влезть. Тогда используйте квантование или выберите модель поменьше. Подробнее про запуск больших моделей — в статье про DeepSeek-V3.2 на vLLM.
4Пишем оркестратора: дирижер для агентов
Теперь у нас есть два сервера: http://localhost:8000/v1 (кодер) и http://localhost:8001/v1 (аналитик). Нужен скрипт, который будет принимать задачу, решать, какому агенту ее отправить, и собирать результат.
# orchestrator.py
import openai
from concurrent.futures import ThreadPoolExecutor
import time
# Клиенты для наших локальных моделей
client_coder = openai.OpenAI(
base_url="http://localhost:8000/v1",
api_key="no-key"
)
client_analyst = openai.OpenAI(
base_url="http://localhost:8001/v1",
api_key="no-key"
)
def ask_agent(client, model, prompt, system_prompt=None):
messages = []
if system_prompt:
messages.append({"role": "system", "content": system_prompt})
messages.append({"role": "user", "content": prompt})
response = client.chat.completions.create(
model=model,
messages=messages,
temperature=0.2,
max_tokens=2000
)
return response.choices[0].message.content
def code_and_review(task_description):
"""Параллельно генерируем код и анализируем его."""
code_prompt = f"Напиши код на Python для: {task_description}"
review_prompt = f"Проанализируй безопасность и качество кода для задачи: {task_description}"
with ThreadPoolExecutor(max_workers=2) as executor:
future_code = executor.submit(
ask_agent,
client_coder,
"claude-code",
code_prompt,
"Ты — опытный программист. Пиши чистый, эффективный код."
)
future_review = executor.submit(
ask_agent,
client_analyst,
"gpt-oss",
review_prompt,
"Ты — security аналитик. Ищи уязвимости, плохие практики, предлагай улучшения."
)
code = future_code.result()
review = future_review.result()
return {
"code": code,
"review": review,
"timestamp": time.time()
}
# Пример использования
if __name__ == "__main__":
task = "функция, которая читает JSON файл, проверяет валидность данных и записывает в SQLite"
result = code_and_review(task)
print("Сгенерированный код:")
print(result["code"])
print("\nАнализ:")
print(result["review"])
Вот и вся магия. ThreadPoolExecutor отправляет запросы к двум моделям одновременно. Пока одна генерирует код, вторая его анализирует (по описанию задачи). На выходе получаем результат в 2 раза быстрее, чем если бы делали это последовательно.
Где собака зарыта: нюансы и грабли
Теория гладкая, практика с ухабами. Вот что сломает вам шею, если не знать.
| Проблема | Причина | Решение |
|---|---|---|
| Модель не загружается, пишет про нехватку памяти | VRAM недостаточно, или неверно указан tensor-parallel-size | Уменьшите gpu-memory-utilization, попробуйте квантование (добавьте --quantization awq), убедитесь что драйверы свежие. |
| Запросы тормозят, хотя GPU не загружена | Упираемся в CPU или медленный диск. Модель с кеша медленно подгружается. | Используйте SSD NVMe для кеша моделей. Увеличьте --shm-size. Проверьте, не свопит ли система. |
| Второй контейнер не видит GPU | Docker занял все GPU первым контейнером. | Явно ограничьте GPU в каждом контейнере через --gpus 'device=0' и --gpus 'device=1'. |
| API возвращает ошибку 503 | vLLM перегружен очередью запросов. | Настройте --max-num-seqs и --batch-size. Увеличьте таймауты в клиенте. |
Самый частый вопрос: "Почему не использовать Kubernetes?" Можно. Но для одной машины это overkill. Docker Compose — максимум что нужно. Создайте docker-compose.yml, опишите два сервиса vLLM и оркестратор, и поднимите одной командой. Если масштабируетесь на кластер — тогда да, смотрите в сторону Kubernetes и таких решений как LLM-IDS на DGX.
Что дальше? Эволюция системы
Вы запустили двух агентов. Что делать теперь?
- Добавьте агента-тестировщика — модель поменьше, которая будет запускать сгенерированный код в изолированном окружении (Docker-in-Docker или отдельный контейнер).
- Внедрите очередь задач — RabbitMQ или Redis. Агенты будут брать задачи из очереди, а оркестратор только распределять.
- Настройте мониторинг — Grafana + Prometheus. Следите за загрузкой GPU, временем ответа vLLM, температурой карты. Перегрев — главный враг стабильности.
- Экспериментируйте с моделями — мир не стоит на месте. На 2026 год уже могут быть новые монстры типа DeepSeek-V3.2 или Llama 4. Загружайте их через vLLM и сравнивайте. Гайд по запуску свежих LLM на vLLM вам в помощь.
Главный секрет — не гнаться за количеством агентов. Лучше три быстрых и стабильных, чем десять, которые падают каждые полчаса. Начните с двух, отточите пайплайн, затем добавляйте новых.
Неочевидный совет: выделите под кеш моделей отдельный быстрый SSD, а еще лучше — RAM-диск. Чтение весов модели с диска — это бутылочное горлышко при холодном старте. Если у вас 192GB RAM, как в этой конфигурации, смонтируйте /dev/shm размером в 100GB и храните там самые часто используемые модели. Скорость загрузки увеличится в разы.
И помните: локальный AI — это не про экономию денег на API. Это про контроль, приватность и возможность пилить систему под свои нужды без оглядки на ToS облачных провайдеров. Когда ваш агент-кодогенератор работает в сотне метров от вас, а не в датацентре на другом континенте, вы спите спокойнее.