Skip to main content
Glama
nisaral

DIO Predictive Inference Orchestrator

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
DIO_SLO_MSNoAdmission budget in milliseconds.5000
DIO_ADMISSION_MODENoAdmission mode: empirical, rank_only, or absolute (diagnostic).empirical
DIO_CACHE_BONUS_MSNoSession/prefix affinity bonus in milliseconds.200
DIO_ENGINE_METRICSNoWhether to scrape vLLM /metrics.true
DIO_KV_CACHE_COST_MSNoKV cache cost coefficient (c_kv) multiplied by KV utilization.800
DIO_ENGINE_QUEUE_COST_MSNoEngine queue cost coefficient (c_q) multiplied by waiting requests.50
DIO_ENGINE_PREFIX_HIT_BONUS_MSNoPrefix hit bonus coefficient (c_p) multiplied by prefix-hit rate.150

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
dio_get_modelsB

Query DIO gateway for available LLM models, active backends, and cluster health.

dio_predict_latencyA

Get latency and cost predictions before sending requests. Predicts queue delay, execution latency, and optimal backend using DIO's dual-timescale NLMS filter.

dio_route_promptC

Route a prompt through DIO's intelligent NLMS scheduler to the optimal backend and return the completion.

dio_cluster_statusA

Get live telemetry from the DIO cluster, including learned worker slopes, KV-cache pressure, and admission goodput statistics.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.6/5.0

Scored across 4 tools

Disambiguation4/5

The tools have mostly distinct purposes: listing models, predicting latency, routing prompts, and checking cluster telemetry. Minor overlap exists between dio_get_models and dio_cluster_status since both mention health, but their descriptions clarify that one is model/backend inventory and the other is deep operational telemetry.

Naming Consistency4/5

Three tools follow a clear verb_noun pattern (get_models, predict_latency, route_prompt), while dio_cluster_status deviates by omitting the verb. The shared 'dio_' prefix and overall readability keep the set mostly consistent.

Tool Count5/5

With 4 tools, the server is well-scoped for an inference orchestrator. Each tool covers a distinct, necessary capability (discover, predict, route, monitor) without unnecessary bloat.

Completeness4/5

The core workflow of checking available models, predicting latency, routing a prompt, and inspecting cluster health is fully covered. Minor gaps exist such as detailed per-model information or explicit policy management, but these are not critical for the server's stated purpose.

Maintenance

ActivityActive
ResponsivenessResponsive