Models & constraints

Each model alias is described in /v1/info with its modalities, capabilities, licensing, backend routing chain, and behaviour constraints — the latter being client-relevant quirks that the rust-api enforces before forwarding to the upstream.

curl -s -H "Authorization: Bearer $BEARER" \
  https://dgx.spass.fun/v1/info \
  | jq '.models[] | {alias, family, context_window, tools, constraints}'

Model summary

The min_max_tokens column is the floor that rust-api silently applies when your request specifies a smaller value. Reasoning models need ≥ 200 to leave room for hidden reasoning tokens before any visible content; OpenAI-via- OpenRouter refuses values below 16. Floored values are reported in the response header spass-applied: max_tokens_floored=N.

constraints schema

Every entry in /v1/info exposes a constraints object:

{
  "min_max_tokens": 200,
  "accepts_image_url": false,
  "typical_response_seconds": 8
}

• min_max_tokens — silent auto-floor for max_tokens. null means no floor.
• accepts_image_url — false for all models today, so an image_url.url with an http(s):// URL is always rejected with HTTP 400 and code: image_url_not_supported. Inline as base64 data URI.
• typical_response_seconds — rough cold-inference latency hint for client-side timeout configuration. Cache hits are sub-second and not reflected here.

Per-model notes

How the local backends behave

(llama-4-scout was retired on 2026-07-14 with Portfolio v2, ADR 0029.)

The local backends run vLLM with LMCache active. Cold first-token latency is dominated by the queue + the (often warm) prefix scan; a typical short Q&A is 5-8 s end-to-end through the tunnel, while repeated requests sharing a prefix collapse to 30-40 ms via LMCache.

Local aliases come in two flavours. The T1 default (e.g. qwen3-8-27b) routes local-first with a cloud fallback: if the local backend is down (/readyz reflects this in status/degraded_reasons), LiteLLM transparently routes the next call to the cloud provider without changing the model field. The T0 -local variant has no fallback by design — a down lane returns HTTP 5xx, which is the guarantee that no prompt leaves the house.

Local vision: qwen3-8-27b

Qwen 3.8 27B (dense, hybrid linear attention), served on the reclaimed spark2 GB10 in NVFP4 with 262 K context. Accepts image input — verified on 2026-08-22 against a scanned PDF without a text layer (docs/MODELLVERGLEICH-LOKAL-2026-08-22.md). Earlier revisions of this page and of /v1/info claimed "text-only serving"; that was wrong and made the gateway drop images for this lane.

Local flagship: qwen3-6-35b-a3b

Alibaba Qwen 3.6, an MoE (3B active / 35B total) served locally on the Station (4x A100, TP=4, FP8). Multimodal text+vision, 262 K native context, Apache-2.0 license. The T1 default routes Station-FP8 primary → OpenRouter (cloud-2) fallback. Five caller-addressable variants exist in the allowlist:

• qwen3-6-35b-a3b — T1 quality-default (Station primary + cloud-2 fallback)
• qwen3-6-35b-a3b-local — T0 force-local strict (DSGVO, no cloud fallback)
• qwen3-6-35b-a3b-fp8 — T2 quant-explicit (Station only)
• qwen3-6-35b-a3b-cloud-1 — T3 Ollama Cloud
• qwen3-6-35b-a3b-cloud-2 — T3 OpenRouter

(qwen3-6-35b-a3b-cloud, a synth-billed Ollama→OpenRouter aggregator, is also addressable.) See /v1/info for the full backend chain.

Reasoning: gpt-5.5-pro, gemini-3.1-pro, flagship

These hide a "thinking" pass before producing any visible content. With small max_tokens you get an empty content field and finish_reason: length. The rust-api silently floors to 200; if you need long answers, set max_tokens explicitly (e.g. 1500 for an essay-length reply).

gemini-3.1-pro is the only flagship in this set that accepts audio and video input via OpenRouter. See /v1/info for the modalities field.

Image generation: nano-banana, gpt-image, image-gen

nano-banana (Google Gemini 3.1 Flash Image) is fast (~15 s) and cheap. gpt-image (OpenAI GPT-5.4 + GPT-Image-2) is much slower (100-180 s) and ~5× more expensive but renders text-in-image and follows complex instructions better.

The composite alias image-gen runs nano-banana first and falls back to gpt-image only on hard failures, giving you the best of both.

Output is delivered as base64-encoded image data inside an OpenAI-style chat completion — the bytes live in choices[0].message.images[0].image_url.url as a data:image/...;base64,... string. Set client timeout ≥ 240 s when calling gpt-image directly.

Vision input — base64 only

All cloud providers refuse server-side URL-fetches; the local vLLM doesn't either. Inline images as base64 data URIs:

B64=$(base64 -w 0 photo.jpg)
curl ... -d "{
  \"model\": \"qwen3-vl-30b-instruct\",
  \"messages\": [{
    \"role\": \"user\",
    \"content\": [
      {\"type\": \"text\", \"text\": \"What is in this image?\"},
      {\"type\": \"image_url\", \"image_url\": {\"url\": \"data:image/jpeg;base64,$B64\"}}
    ]
  }]
}"

Sending an https://... URL gets you HTTP 400 with code: image_url_not_supported and a param pointing at the offending field.

Backend status

The backends array in /v1/info lists each routing destination with status:

• available — actively used by LiteLLM.
• deprecated — known to be retired (e.g. NVIDIA NIM endpoints).
• unconfigured — supported in principle, missing API-key or config.
• planned — in scope but not wired up yet.

Only available backends are reachable at runtime; the rest are catalog metadata for transparency.