Свой OpenAI-совместимый API-сервер на VPS

Один и тот же код приложения может ходить и в OpenAI, и в твою локальную модель — если сервер говорит на формате /v1/chat/completions. Собираем такой эндпоинт на своём VPS.

Зачем свой OpenAI-совместимый эндпоинт

Формат OpenAI стал де-факто стандартом: под него написаны SDK, LangChain, десятки готовых интерфейсов. Если поднять свой сервер с тем же контрактом, весь этот софт заработает без переделок — просто меняешь base_url.

• Независимость — данные и модель на твоём сервере.
• Экономия — нет платы за токены облака.
• Совместимость — существующий код не трогаем.

Для CPU-инференса небольших моделей отлично подходит быстрый сервер: связка AMD EPYC + NVMe у MAATRIX даёт высокую производительность на ядро, а это ровно то, что нужно llama.cpp без GPU.

Важно понимать, что «OpenAI-совместимый» — это про контракт HTTP, а не про модель. За одним и тем же эндпоинтом /v1/chat/completions может стоять что угодно: локальная Llama, Mistral, Qwen или проксируемое облако. Приложение этого не различает — оно шлёт список сообщений и получает ответ в знакомом формате. Именно поэтому такой сервер — это точка развязки: сегодня за ним CPU-модель для экономии, завтра GPU-инференс под нагрузку, а код клиента остаётся неизменным.

Вариант 1: llama.cpp (CPU-friendly)

llama.cpp запускает GGUF-модели и умеет отдавать OpenAI API. Собираем и стартуем сервер.

sudo apt update && sudo apt -y install build-essential cmake git
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && cmake -B build && cmake --build build -j

./build/bin/llama-server \
  -m ./models/model.gguf \
  --host 0.0.0.0 --port 8080 \
  -c 4096 --api-key sk-local

Эндпоинт /v1/chat/completions уже доступен на порту 8080. Флаг -c задаёт размер контекста, а --api-key включает проверку ключа — без него сервер примет любой запрос. Модели в формате GGUF качаются с HuggingFace; для CPU оптимален квант Q4_K_M — он вдвое легче оригинала и почти не теряет в качестве. llama.cpp хорош тем, что тянет тяжёлую математику на всех ядрах процессора, поэтому на многоядерном EPYC небольшие модели отвечают вполне бодро.

Вариант 2: Ollama

Ollama — самый простой путь: ставится одной строкой и сразу даёт OpenAI-совместимый API на порту 11434.

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3
ollama serve

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3","messages":[{"role":"user","content":"Привет"}]}'

Вариант 3: vLLM для GPU

Если есть видеокарта и нужен высокий throughput — vLLM отдаёт тот же формат и держит десятки параллельных запросов.

pip install vllm
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 --port 8000

Практичный приём — поставить перед всеми тремя бэкендами один агрегатор (LiteLLM) и дать приложению единственный адрес. Тогда CPU-модель, GPU-инференс и облачный фолбэк живут за одним ключом, а маршрутизация решается конфигом, а не кодом.

Подключаем клиент

Любой OpenAI SDK работает после смены base_url — код остаётся прежним.

from openai import OpenAI
client = OpenAI(base_url="http://SERVER_IP:8080/v1", api_key="sk-local")
r = client.chat.completions.create(model="model",
    messages=[{"role":"user","content":"Проверка"}])
print(r.choices[0].message.content)

Прод: TLS, ключ и systemd

Голый порт наружу выставлять нельзя. Прикрой сервер Nginx с TLS и проверкой ключа.

server {
  listen 443 ssl;
  server_name llm.example.com;
  location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Authorization $http_authorization;
  }
}

• Всегда задавай api-key — даже для внутреннего использования.
• Ограничь фаервол: ufw allow 443, порт модели наружу закрыт.
• Оформи в systemd, чтобы сервер поднимался после ребута.

Ещё один слой защиты — rate limiting на уровне Nginx. Даже с валидным ключом стоит ограничить число запросов в секунду, иначе один сбойный клиент или утёкший ключ способны положить инференс, заняв все воркеры. Директива limit_req_zone плюс скромный лимит на IP закрывают этот риск малой кровью и не мешают нормальной работе. А если сервис смотрит в интернет, полезно писать доступ в отдельный лог и периодически проверять, кто и как часто дёргает эндпоинт.

Частые вопросы