Ollama, llama.cpp ці vLLM: які лакальны LLM-сервер выбраць

Для аднаго распрацоўшчыка на ноўтбуку запускайце Ollama: яна ўсталёўваецца за некалькі хвілін, спампоўвае мадэлі па назве і загружае іх па патрабаванні. Для невялікай каманды, Mac, сервера без GPU або спажывецкай відэакарты бярыце llama-server з llama.cpp: ён абслугоўвае GGUF-мадэлі і дае яўны кантроль над паралельнымі слотамі, API-ключамі і метрыкамі Prometheus. Для production-трафіку на GPU ўзроўню дата-цэнтра запускайце vLLM, у якога continuous batching і PagedAttention трымаюць высокую прапускную здольнасць па меры росту канкурэнтнасці. Усе тры серверы прапануюць OpenAI-сумяшчальны API, таму можна пачаць з аднаго і перайсці на іншы, змяніўшы base URL і назву мадэлі.

Для чаго аптымізаваны кожны сервер

Ollama аптымізавана пад час да першага адказу. Яна працуе як дэсктопная праграма або фонавы сэрвіс, спампоўвае мадэлі па назве, загружае мадэль пры першым запыце і выгружае яе пасля перыяду прастою, па змаўчанні праз пяць хвілін, паводле FAQ Ollama. Некалькі зменных асяроддзя OLLAMA_* замяняюць тонкую наладу планавальніка, і ў гэтай прастаце ўвесь сэнс.

llama.cpp аптымізаваны пад пераносімасць. Гэта рухавік інферэнсу на C/C++ на аснове бібліятэкі ggml з бэкендамі Metal для Apple Silicon, CUDA, HIP для AMD, Vulkan, SYCL і аптымізаванымі шляхамі для CPU з AVX, AVX2, AVX-512, AMX і ARM NEON. Калі мадэль не змяшчаецца ў VRAM, ён можа трымаць частку слаёў на GPU, а астатнія ў сістэмнай памяці. Яго HTTP-сервер llama-server зводзіцца да аднаго бінарніка, GGUF-файла і набору флагаў. У хуткім старце README праекта цяпер паказана адзіная каманда llama serve, а дакументацыя llama-server і Docker-вобразы па-ранейшаму пастаўляюць выканальны файл llama-server, які выкарыстоўваецца ў гэтым артыкуле.

vLLM аптымізаваны пад прапускную здольнасць на паскаральніках. У яго README пералічаны PagedAttention для кіравання KV-кэшам, continuous batching, chunked prefill, prefix caching, абслугоўванне некалькіх LoRA, тэнзарны і канвеерны паралелізм і доўгі спіс фарматаў квантызацыі. Ён падтрымлівае GPU NVIDIA, AMD і Intel, працэсары x86, ARM і PowerPC, а іншыя паскаральнікі падключаюцца праз апаратныя плагіны.

Коратка: Ollama і llama.cpp пасуюць сціпламу жалезу і некалькім адначасовым карыстальнікам, а vLLM апраўдвае больш складаную наладу, калі шмат запытаў прыходзіць адначасова. Апаратны бок выбару, у тым ліку аб'ём памяці для вагаў і KV-кэша, разабраны ў дапаможніку па жалезе для лакальных LLM.

Адзін OpenAI-кліент, тры base URL

Усе тры серверы рэалізуюць /v1/chat/completions, /v1/completions, /v1/embeddings, /v1/models і /v1/responses. Старонка сумяшчальнасці Ollama з OpenAI удакладняе, што Responses падтрымліваецца толькі без захавання стану. llama-server дадаткова прапануе Anthropic-сумяшчальны /v1/messages, а vLLM побач з маршрутамі OpenAI пералічвае Anthropic Messages, транскрыпцыю аўдыя і pooling API.

Трымайце выбар сервера ў канфігурацыі, каб код кліента не мяняўся:

import os
from openai import OpenAI

# Ollama:       http://127.0.0.1:11434/v1
# llama-server: http://127.0.0.1:8080/v1
# vLLM:         http://127.0.0.1:8000/v1
client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ.get("LLM_API_KEY", "not-used"),
)

reply = client.chat.completions.create(
    model=os.environ["LLM_MODEL"],
    messages=[{"role": "user", "content": "Explain HTTP 429 in two sentences."}],
    temperature=0.2,
)
print(reply.choices[0].message.content)

OpenAI SDK патрабуе радок ключа, таму перадавайце заглушку, калі ў сервера ключа няма. Ollama лакальна ігнаруе ключ, а llama-server і vLLM правяраюць яго, толькі калі іх запушчана з ключом.

Серверы разыходзяцца ў полі model. Ollama чакае тэг са сваёй бібліятэкі, напрыклад qwen3:8b. vLLM чакае назву рэпазіторыя Hugging Face або значэнне --served-model-name. llama-server з адной мадэллю абслугоўвае тое, што загрузіў, флаг --alias задае назву, якую вяртае /v1/models, а ў рэжыме router назва выбірае мадэль.

Сумяшчальнасць заканчваецца на межах спецыфікацыі OpenAI. vLLM прымае дадатковыя параметры накшталт top_k праз extra_body і па змаўчанні ўжывае generation_config.json мадэлі, што можа змяніць стандартныя значэнні сэмплінгу, калі не перадаць --generation-config vllm. Шаблоны чата і токенізатары таксама могуць адрознівацца ў GGUF-канвертацыі і зыходнага чэкпойнта, таму перад пераключэннем праганіце адзін і той жа набор ацэнкі на абодвух серверах, як апісана ў дапаможніку па ацэнцы AI-агентаў.

Фарматы мадэляў і адкуль бяруцца вагі

Тры серверы чытаюць розныя файлы, і гэта часта вырашае пытанне раней за прадукцыйнасць.

Ollama спампоўвае мадэлі са сваёй бібліятэкі па назве, запускае GGUF-рэпазіторыі з Hugging Face камандай ollama run hf.co/{user}/{repo}:{quant} і імпартуе лакальныя GGUF-файлы або каталогі Safetensors праз Modelfile, у якім радок FROM паказвае на вагі. Пры імпарце яна не квантызуе GGUF-файлы, таму спачатку квантызуйце іх інструментамі llama.cpp.

llama.cpp чытае GGUF. Чэкпойнт Hugging Face канвертуюць скрыптам convert_hf_to_gguf.py і квантызуюць або спампоўваюць гатовы GGUF праз -hf user/repo:quant. README пералічвае цэлалікавую квантызацыю ад 1,5 да 8 біт. Мадэлям з зрокам патрэбны яшчэ файл праектара, які -hf спампоўвае аўтаматычна.

vLLM чытае рэпазіторыі мадэляў Hugging Face з вагамі Safetensors, а таксама квантызаваныя чэкпойнты GPTQ, AWQ, FP8, INT8, INT4 і compressed-tensors. Дакументацыя называе падтрымку GGUF вельмі эксперыментальнай, і гэтая падтрымка пераехала ў знешні плагін vllm-gguf-plugin.

# Ollama: a library model, or a GGUF repository on Hugging Face
ollama pull qwen3:8b
ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0

# llama.cpp: download a GGUF and serve it
llama-server -hf ggml-org/Qwen3.5-0.8B-GGUF --port 8080

# vLLM: serve a Hugging Face repository
vllm serve Qwen/Qwen3-0.6B --host 127.0.0.1 --port 8000

Канкурэнтнасць, батчынг і памяць KV-кэша

Канкурэнтнасць каштуе памяці. Кожная актыўная паслядоўнасць захоўвае ключы і значэнні ўвагі для кожнага токена свайго кантэксту, таму памяць расце разам з колькасцю адначасовых паслядоўнасцей, памножанай на іх даўжыню, і ўсё гэта звыш вагаў. Для стандартнага трансформера карысная такая ацэнка:

KV bytes per token = 2 × layers × kv_heads × head_dim × bytes_per_value
Qwen3-8B, 16-bit cache: 2 × 36 × 8 × 128 × 2 = 147,456 bytes = 144 KiB
One 32,768-token sequence: 144 KiB × 32,768 = 4.5 GiB

Колькасць слаёў, колькасць KV-галоў і памернасць галавы бяруцца з config.json мадэлі. Чатыром такім паслядоўнасцям патрэбна 18 GiB кэша яшчэ да ўліку вагаў. Мадэлям са sliding-window або гібрыднымі слаямі ўвагі патрэбна менш, таму для іх формула дае верхнюю мяжу.

Ollama

OLLAMA_NUM_PARALLEL задае, колькі запытаў кожная загружаная мадэль апрацоўвае адначасова, і FAQ указвае значэнне па змаўчанні 1. OLLAMA_MAX_LOADED_MODELS па змаўчанні роўна колькасці GPU, памножанай на тры, або тром пры інферэнсе на CPU. OLLAMA_MAX_QUEUE па змаўчанні дапускае 512 запытаў у чарзе, пасля чаго сервер адказвае памылкай 503. FAQ таксама папярэджвае, што патрэбная памяць расце як OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH. Стандартную даўжыню кантэксту розныя старонкі дакументацыі апісваюць па-рознаму, і яна залежыць ад даступнай VRAM, таму задавайце яе яўна і правярайце ў слупку CONTEXT вываду ollama ps.

OLLAMA_HOST=127.0.0.1:11434 \
OLLAMA_NUM_PARALLEL=4 \
OLLAMA_CONTEXT_LENGTH=16384 \
OLLAMA_KEEP_ALIVE=30m \
ollama serve

llama-server

llama-server дзеліць працу на слоты. Кожны слот трымае адзін дыялог, -np задае колькасць слотаў, а значэнне па змаўчанні -1 азначае аўтаматычны выбар. Continuous batching уключаны па змаўчанні, таму новыя запыты далучаюцца да бягучага батча паміж крокамі дэкадавання. Калі колькасць слотаў выбрана аўтаматычна, усе слоты дзеляць адзін агульны KV-буфер. Калі -np зададзены ўручную, агульны буфер па змаўчанні выключаны і -c дзеліцца паміж слотамі: -c 32768 -np 4 дае кожнаму дыялогу 8192 токены. Праверце вынік праз GET /slots, які паказвае n_ctx кожнага слота.

Выгрузка на GPU задаецца флагам -ngl, які прымае лік, auto (па змаўчанні) або all. Калі мадэль не змяшчаецца, слаі, што засталіся на CPU, упіраюцца ў прапускную здольнасць сістэмнай памяці, таму часткова выгружаная мадэль працуе, але звычайна генеруе токены павольней.

llama-server -m /models/qwen3-8b-q4_k_m.gguf \
  --host 127.0.0.1 --port 8080 \
  -c 32768 -np 4 -ngl all \
  --api-key-file /etc/llama/api-keys.txt \
  --metrics

vLLM

Continuous batching у vLLM прымае новыя паслядоўнасці на кожнай ітэрацыі дэкадавання, пакуль ёсць вольныя блокі KV-кэша, а PagedAttention вылучае гэты кэш блокамі фіксаванага памеру па меры росту паслядоўнасцей і не рэзервуе максімальную даўжыню загадзя. Пры старце vLLM займае долю памяці GPU, зададзеную --gpu-memory-utilization, і ператварае рэшту пасля вагаў і працоўнай памяці актывацый у блокі KV-кэша. Калі пад нагрузкай блокі заканчваюцца, ён выцясняе частку запытаў і пералічвае іх, як толькі месца вызваліцца. Гэта відаць па метрыцы vllm:num_preemptions і па хваставой затрымцы.

Асноўныя рычагі: --max-model-len для самага доўгага дапушчальнага кантэксту, --max-num-seqs для максімальнай колькасці паслядоўнасцей за ітэрацыю, --max-num-batched-tokens, --gpu-memory-utilization і --tensor-parallel-size для падзелу адной мадэлі паміж некалькімі GPU. Знізіць --max-model-len да таго, што сапраўды патрэбна праграме, звычайна самы танны спосаб змясціць больш адначасовых запытаў.

export VLLM_API_KEY="$(openssl rand -hex 32)"
vllm serve Qwen/Qwen3-8B \
  --host 127.0.0.1 --port 8000 \
  --max-model-len 32768 \
  --max-num-seqs 64 \
  --gpu-memory-utilization 0.90

Структураваны вывад і выклік інструментаў

Усе тры серверы ўмеюць абмяжоўваць вывад JSON-схемай праз поле OpenAI response_format, таму такі запыт пераносіцца паміж імі без змен:

schema = {
    "type": "object",
    "properties": {
        "severity": {"type": "string", "enum": ["low", "medium", "high"]},
        "summary": {"type": "string"},
    },
    "required": ["severity", "summary"],
    "additionalProperties": False,
}

reply = client.chat.completions.create(
    model=os.environ["LLM_MODEL"],
    messages=[{"role": "user", "content": "Triage this log line: disk /var is 97% full"}],
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "triage", "schema": schema},
    },
)

Натыўны API Ollama таксама прымае "json" або схему ў полі format, а дакументацыя раіць паўтараць схему ў промпце. llama-server пераўтварае JSON-схемы ў свой фармат граматык GBNF і прымае гатовую граматыку для іншых формаў вываду. vLLM падтрымлівае response_format і аб'ект structured_outputs у extra_body з ключамі json, regex, choice, grammar і structural_tag. Старыя параметры guided_* выдалены ў v0.12.0, як адзначае старонка vLLM пра structured outputs. Абмежаванае дэкадаванне гарантуе сінтаксіс, але не праўдзівасць, а адказ, абрэзаны праз max_tokens, усё роўна будзе несапраўдным JSON, таму правярайце кожны вынік па схеме ва ўласным кодзе.

Выклік інструментаў працуе ва ўсіх трох серверах, але наладжваецца па-рознаму:

• Ollama прымае tools у /api/chat і /v1/chat/completions, уключна з паралельнымі выклікамі, для мадэляў, чые шаблоны падтрымліваюць інструменты.
• llama-server падтрымлівае інструменты ў стылі OpenAI праз Jinja-шаблоны чата, якія ўключаны па змаўчанні. Нататкі llama.cpp пра function calling пералічваюць натыўныя апрацоўшчыкі для некалькіх сямействаў мадэляў і ўніверсальны рэзервовы апрацоўшчык, які выдаткоўвае больш токенаў. Паралельныя выклікі выключаны, пакуль запыт не перадасць "parallel_tool_calls": true.
• vLLM патрабуе --enable-auto-tool-choice і --tool-call-parser, які адпавядае сямейству мадэлі, напрыклад hermes для Qwen2.5 або llama3_json для Llama 3.1 і 3.2. Старонка vLLM пра tool calling тлумачыць, што іменаваныя функцыі і tool_choice="required" выкарыстоўваюць structured outputs, а рэжым auto не гарантуе, што аргументы карэктна разбяруцца.

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --host 127.0.0.1 --port 8000 \
  --enable-auto-tool-choice --tool-call-parser hermes

Лічыце аргументы інструментаў недаверным уводам. Іх выбірае мадэль, а тэкст унутры знойдзенага дакумента можа паўплываць на гэты выбар, як тлумачыць дапаможнік па prompt injection і бяспецы MCP.

Запуск у Docker з доступам да GPU

На Linux з GPU NVIDIA спачатку ўсталюйце NVIDIA Container Toolkit, каб працаваў --gpus. Каманды ніжэй паўтараюць задакументаваныя вобразы і флагі кожнага праекта з адной зменай: кожны порт публікуецца толькі на 127.0.0.1. Дакументацыя Docker пра публікацыю партоў паказвае, што парты без адраса хоста публікуюцца на ўсіх адрасах хоста, а нататкі Docker пра файрвол дадаюць, што трафік апублікаваных партоў перанакіроўваецца раней, чым яго ўбачаць правілы ufw.

# Ollama with NVIDIA GPUs
docker run -d --name ollama --gpus=all \
  -v ollama:/root/.ollama \
  -p 127.0.0.1:11434:11434 \
  ollama/ollama

# llama-server, CUDA build
docker run -d --name llama --gpus all \
  -v /srv/models:/models:ro \
  -p 127.0.0.1:8080:8080 \
  ghcr.io/ggml-org/llama.cpp:server-cuda \
  -m /models/qwen3-8b-q4_k_m.gguf --host 0.0.0.0 --port 8080 -ngl all

# vLLM with NVIDIA GPUs
docker run -d --name vllm --runtime nvidia --gpus all --ipc=host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  --env "HF_TOKEN=$HF_TOKEN" \
  -p 127.0.0.1:8000:8000 \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen3-8B

Унутры кантэйнера сервер павінен слухаць 0.0.0.0, інакш апублікаваны порт да яго не дастане. Прыватным яго робіць 127.0.0.1 на баку хоста. У задакументаванай камандзе vLLM ёсць --ipc=host, бо PyTorch абменьваецца данымі паміж працэсамі праз агульную памяць, асабліва пры тэнзарна-паралельным інферэнсе. Для GPU AMD выкарыстоўвайце ollama/ollama:rocm з --device /dev/kfd --device /dev/dri, вобразы llama.cpp server-rocm або server-vulkan ці vllm/vllm-openai-rocm. У production фіксуйце тэгі або digest вобразаў замест latest.

Бяспека: лакальная прывязка і аўтэнтыфікацыя на праксі

Стаўцеся да порта інферэнсу як да порта базы даных. Любы, хто да яго дабярэцца, можа марнаваць ваш час GPU, чытаць усё, што вяртае мадэль, а ў некаторых канфігурацыях выклікаць адміністрацыйныя маршруты.

Пачніце з адраса прывязкі. Ollama па змаўчанні слухае 127.0.0.1:11434, а llama-server слухае 127.0.0.1:8080. vLLM паводзіць сябе інакш: калі --host не зададзены, яго launcher слухае ўсе інтэрфейсы, таму па-за кантэйнерам заўсёды перадавайце --host 127.0.0.1.

Далей праверце, што насамрэч абараняе ключ кожнага сервера:

• Лакальны API Ollama не мае налады API-ключа. Любы, хто дастае да порта, можа ім карыстацца, таму адкрывайце доступ толькі праз праксі з аўтэнтыфікацыяй.
• llama-server правярае --api-key або --api-key-file на сваім API, а /health наўмысна застаецца публічным. У README адзначана, што CORS па змаўчанні адлюстроўвае любы Origin, і для лакальных сетак рэкамендаваны --cors-origins.
• --api-key у vLLM пакрывае толькі некалькі прэфіксаў шляхоў, у тым ліку /v1. Кіраўніцтва vLLM па бяспецы пералічвае неабароненыя маршруты, напрыклад /invocations, які вядзе да тых жа функцый інферэнсу, а таксама /pause ці /abort_requests, і раіць зваротны праксі са спісам дазволеных эндпойнтаў.

Невялікі франтэнд на Nginx закрывае абедзве патрэбы. Ён завяршае TLS, правярае bearer-токен, прапускае толькі /v1/ і вяртае 404 на ўсё астатняе.

map $http_authorization $llm_client {
    default "";
    "Bearer REPLACE_WITH_A_LONG_RANDOM_TOKEN" "team";
}

server {
    listen 443 ssl;
    server_name llm.example.internal;
    ssl_certificate     /etc/nginx/tls/llm.crt;
    ssl_certificate_key /etc/nginx/tls/llm.key;
    client_max_body_size 10m;

    location /v1/ {
        if ($llm_client = "") { return 401; }
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_read_timeout 600s;
    }

    location / {
        return 404;
    }
}

proxy_buffering off дазваляе струменевым токенам даходзіць да кліента па меры генерацыі. Калі upstream-сервер мае ўласны ключ, задайце той самы токен, каб запыт у абыход праксі ўсё роўна не прайшоў. Для Ollama накіруйце proxy_pass на порт 11434 і дадайце proxy_set_header Host localhost:11434, як у прыкладзе з FAQ. Дадайце limit_req, калі адзін GPU дзеляць некалькі карыстальнікаў. На ноўтбуку распрацоўшчыка памятайце, што OLLAMA_ORIGINS=* дазваляе любой адкрытай вэб-старонцы звяртацца да лакальнага сервера праз ваш браўзер.

Маніторынг і праверкі працаздольнасці

Пачніце з гатоўнасці. /health у llama-server вяртае 503, пакуль мадэль загружаецца, і 200, калі яна гатовая, а vLLM таксама прапануе /health. Выкарыстоўвайце іх для health check кантэйнераў і проб балансавальніка, але не як доказ таго, што якасць генерацыі ў парадку.

vLLM па змаўчанні аддае метрыкі Prometheus на /metrics. Старонка vLLM пра метрыкі пералічвае vllm:num_requests_running, vllm:num_requests_waiting, vllm:kv_cache_usage_perc, гістаграмы часу да першага токена, затрымкі паміж токенамі і поўнай затрымкі запыту, а таксама лічыльнік выцясненняў. llama-server аддае /metrics толькі пры запуску з --metrics, у тым ліку llamacpp:requests_processing, llamacpp:requests_deferred, llamacpp:prompt_tokens_seconds і llamacpp:predicted_tokens_seconds, а GET /slots паказвае стан кожнага слота.

scrape_configs:
  - job_name: vllm
    static_configs:
      - targets: ["127.0.0.1:8000"]
  - job_name: llama-server
    static_configs:
      - targets: ["127.0.0.1:8080"]

Задакументаваны API Ollama не мае эндпойнта Prometheus. Выкарыстоўвайце GET /api/ps, каб бачыць загружаныя мадэлі, іх спажыванне VRAM, даўжыню кантэксту і час выгрузкі, і чытайце палі з таймінгамі ў кожным адказе. Працягласці пазначаны ў нанасекундах, таму хуткасць генерацыі роўная eval_count / eval_duration × 10^9 токенаў у секунду:

curl -s http://127.0.0.1:11434/api/generate \
  -d '{"model": "qwen3:8b", "prompt": "Say ready.", "stream": false}' |
  jq '{tokens: .eval_count, tokens_per_second: (.eval_count / .eval_duration * 1e9)}'

Наладжвайце алерты на сігналы таго, што карыстальнікі чакаюць: чарга waiting або deferred, якая не спадае да нуля, выкарыстанне KV-кэша каля 1, рост лічыльніка выцясненняў і павелічэнне часу да першага токена на p95. Метрыкі сервера апісваюць ёмістасць. Яны не скажуць, які промпт, выклік інструмента ці крок пошуку запаволіў запыт, таму звязвайце іх з трасіроўкай запытаў, як апісана ў дапаможніку па назіральнасці AI-агентаў.

Параўнанне ў адной табліцы

	Ollama	llama.cpp llama-server	vLLM
Аптымізаваны для	Хуткага ўсталявання і кіравання мадэлямі	Пераносімасці на CPU, Apple Silicon і спажывецкія GPU	Прапускной здольнасці на GPU дата-цэнтраў
Фарматы мадэляў	Мадэлі з бібліятэкі, GGUF, імпарт Safetensors	GGUF	Safetensors з Hugging Face, GPTQ, AWQ, FP8 і іншыя; GGUF эксперыментальна
Адрас па змаўчанні	127.0.0.1:11434	127.0.0.1:8080	Усе інтэрфейсы, порт 8000
Убудаваны API-ключ	Няма	--api-key, --api-key-file	--api-key або VLLM_API_KEY, абмежаваныя прэфіксы шляхоў
Канкурэнтнасць	OLLAMA_NUM_PARALLEL на мадэль, па змаўчанні 1	Слоты (-np) з continuous batching	Continuous batching з PagedAttention
Структураваны вывад	format, response_format	response_format, JSON-схема, GBNF	response_format, structured_outputs
Выклік інструментаў	tools у натыўных і OpenAI-маршрутах	Jinja-шаблоны, натыўныя або ўніверсальныя апрацоўшчыкі	--enable-auto-tool-choice з парсерам
Метрыкі	/api/ps і таймінгі адказаў	/metrics з --metrics, /slots	/metrics па змаўчанні
Лепш за ўсё падыходзіць	Аднаму распрацоўшчыку, прататыпам	Невялікім камандам, сціпламу або змешанаму жалезу	Шматлікім адначасовым карыстальнікам, production SLO

Шлях выбару для распрацоўкі, каманды і production

Прайдзіце пытанні па чарзе і спыніцеся на першым адназначным адказе.

1. Мадэлі спрабуе адзін чалавек на ноўтбуку ці працоўнай станцыі? Выкарыстоўвайце Ollama. Рухайцеся далей, калі спатрэбяцца метрыкі, аўтэнтыфікацыя або кантроль на ўзроўні асобнага запыту.
2. Вы працуеце на Mac, серверы без GPU або спажывецкай відэакарце, у VRAM якой мадэль ледзь змяшчаецца ці не змяшчаецца зусім? Выкарыстоўвайце llama-server. Квантызацыя GGUF і частковая выгрузка дазваляюць яму працаваць там, дзе vLLM не зможа загрузіць мадэль.
3. Гэта невялікая каманда з некалькімі адначасовымі карыстальнікамі на адной машыне? Выкарыстоўвайце llama-server з -np, роўным пікавай канкурэнтнасці, API-ключом, --metrics і праксі. Ollama таксама падыдзе, калі ўсе карыстаюцца адной-дзвюма мадэлямі, а аўтэнтыфікацыю выконвае праксі.
4. Чакаецца стабільны канкурэнтны трафік, мэтавыя затрымкі, некалькі GPU або фарматы квантызацыі для GPU накшталт FP8 ці AWQ? Выкарыстоўвайце vLLM, прывязаны да localhost за шлюзам, з зафіксаванымі вобразамі і зборам метрык Prometheus з першага дня.

Шмат якія каманды ў выніку выкарыстоўваюць два серверы: Ollama або llama-server на машынах распрацоўшчыкаў, vLLM у staging і production і адзін і той жа код OpenAI-кліента паўсюль. Гэта працуе толькі тады, калі набор ацэнкі праганяецца на production-артэфакце, бо GGUF-квантызацыя і FP8-чэкпойнт адной мадэлі на практыцы паводзяць сябе як розныя мадэлі. Дапаможнік па архітэктуры production AI-агента апісвае шлюз, таймаўты, паўторы і рэзервовыя варыянты, якія павінны стаяць перад любым з гэтых сервераў.

Чэкліст разгортвання

• Выберыце сервер па шляху выбару і зафіксуйце дакладны файл мадэлі, квантызацыю і шаблон чата, якія будзеце абслугоўваць.
• Разлічыце памяць KV-кэша для пікавай канкурэнтнасці і максімальнага кантэксту, потым наладзьце OLLAMA_CONTEXT_LENGTH, -c і -np або --max-model-len і --max-num-seqs.
• Прывязвайце серверы да 127.0.0.1, яўна перадавайце --host 127.0.0.1 у vLLM і публікуйце парты Docker як 127.0.0.1:port:port.
• Вынесіце TLS, аўтэнтыфікацыю, спіс дазволеных эндпойнтаў і абмежаванне частаты запытаў у зваротны праксі. Ніколі не адкрывайце порт інферэнсу без аўтэнтыфікацыі.
• Задайце ключ у llama-server або vLLM як другі ўзровень абароны і не пакідайце яго ў гісторыі shell і слаях вобраза.
• Збірайце /metrics з llama-server і vLLM і апытвайце /api/ps Ollama праз прыватную сетку.
• Правядзіце нагрузачны тэст на ўласных промптах пры чаканай канкурэнтнасці і запішыце час да першага токена, токены ў секунду, даўжыню чаргі і памяць.
• Правярайце структураваны вывад па схеме ў кодзе і лічыце аргументы інструментаў недаверным уводам.
• Фіксуйце версіі і digest вобразаў і паўторна праганяйце набор ацэнкі пасля любой змены сервера, файла мадэлі, квантызацыі ці вобраза.