{% extends "base.html" %} {% block title %}Settings — CoderAI{% endblock %} {% block content %}
Server configuration — restart CoderAI to apply changes
torch.cuda.empty_cache(). Turn this off on a GPU that drops off the bus (Xid 79) to stop the background thread from touching CUDA — host-RAM mitigation (gc / heap trim / idle eviction) still runs. Loads are always skipped regardless.
Upscaling and FPS interpolation run on in-process torch models by default (ESRGAN upscaler, RIFE/FILM interpolator) — no external tools. Enable these only to fall back to external tools when no model is configured.
--no-resume-jobs launch flag.
Run DeepSeek V4 through antirez's native ds4 / DwarfStar engine as a managed subprocess. When enabled, requests for a matching model name are proxied to ds4-server. First use clones + builds ds4 and downloads several GB of weights — this is slow and needs lots of RAM (96 GB+).
Run GLM-5.2 through JustVugg's pure-C colibri MoE engine. Unlike ds4, colibri ships no server — coderai drives the C engine binary directly over its stdin/stdout mux protocol (no colibri Python at runtime). First use clones + builds the engine (CUDA when available). The GLM-5.2 int4 container (~372 GB directory) is not downloaded automatically — point the model path at it (see the int4 g64 + int8-MTP container).
Run Kimi-K3 through FareedKhan-dev's portable-C kimi-k3-in-c engine. coderai patches in a resident serve loop and drives it over the same mux protocol as colibri. CPU-only (AVX2+FMA) and needs ~1.7 TB fast local storage (the ~1.56 TB checkpoint + a ~109 GB packed trunk from the repo's scripts/pack-trunk.sh). Nothing is downloaded automatically.
Run many large MoE families (DeepSeek, Kimi, Qwen, GLM, MiniMax) through ktransformers' CPU+GPU heterogeneous engine, served over SGLang's OpenAI API. coderai launches python -m sglang.launch_server as a managed subprocess and proxies to it. Requires SGLang + kt-kernel installed out of band (best on AMX/AVX-512 CPUs). Selected per model via an explicit backend: kt pin or the model id below — never by a broad name marker.
Serve an LLM (or VLM) through vLLM's OpenAI server with continuous batching — far higher aggregate throughput than serialized single-instance backends. coderai launches vllm.entrypoints.openai.api_server as a managed subprocess and proxies to it. vLLM pins its own torch/CUDA, so it runs in an isolated venv (CUDA-only). Selected per model via a backend: vllm pin or the model id below. Also serves Surya2 for OCR.
Other coderai installs on your network become engines of this one: this front polls each node's state, assigns models to it, pins a model to it by name on the Models page (Engine / card), and routes requests there by capability and load — the node's own front picks the card. A node needs only an API token created on its Tokens page. This section also lists the llama.cpp rpc-server processes this machine runs to lend its cards to a GGUF loaded on another node (per model: Cards on other machines). Reachability of everything is on the Cluster page; the full story is in docs/cluster.md.
/cluster/*; a head uses it for discovered nodes and for listed nodes with a blank token. Blank keeps the stored one, - clears it._coderai._tcp and lists the others on the Cluster page. Link-local: same subnet, container on the host network.rpc-server process per row (built by packaging/build-rpc-server.sh, from the same llama.cpp as the bundled llama-cpp-python — the protocol is versioned). Device = a ggml device name (CUDA0, Vulkan1 …, blank = default). Unauthenticated protocol: bind to a LAN or WireGuard address, never the internet.Burst inference to rented GPUs on RunPod — as Pods (coderai provisions, load-balances and autoscales them) or Serverless endpoints (RunPod autoscales). Uses no local VRAM: coderai proxies OpenAI requests to the remote GPU. Set the account key here, then tag a model in the Models list with backend: runpod and its per-model pod/serverless block. These are the account-wide settings shared by every RunPod model.
Images, video, embeddings, TTS, STT and the rest load their model in this process, so there is no per-model way to move them. Point a capability somewhere else and matching /v1 requests are forwarded there instead — to another coderai, or to a RunPod pod coderai provisions, scales and reaps for you. Per-model service_url still wins over anything set here. Chat and completions are not listed: those are per-model, on the model's own page.
Dedicated OCR engines (detection + recognition), not a vision LLM — faithful text with bounding boxes and layout, batched on GPU. Serve PaddleOCR, docTR or Surya, selectable per request. Endpoints: POST /v1/ocr, POST /v1/ocr/batch. Heavy deps install out of band (pip install -r requirements-ocr.txt or ./build.sh … --ocr); a missing engine returns HTTP 503.
Global defaults for shrinking an over-long chat history before generation so requests don't error out on context overflow. Per-model settings on the Models page override these. OFF by default.
CoderAI stands on the shoulders of remarkable open-source work. Heartfelt thanks to the developers whose engines and research make these capabilities possible.
…and the wider open-source ecosystem (PyTorch, Hugging Face Transformers/Diffusers, and many more) that CoderAI builds on.