Platform

One control plane for GPUs, jobs, and models.

An OpenAI-compatible API gateway across every service, an MCP server exposing live hardware telemetry, Kubernetes-based orchestration with tiered scheduling, and usage metered to the second. Built for engineering teams running real workloads.

Talk to an engineer Explore solutions

gateway

$ tara connect --env prod
→ gateway: api.tara.example · region: jp
$ curl https://api.tara.example/v1/chat/completions \
    -H "Authorization: Bearer sk-tara-••••••" \
    -d '{"model":"qwen3.8-max","messages":[{"role":"user","content":"Hello"}]}'
{
  "id": "chatcmpl-example",
  "model": "qwen3.8-max",
  "usage": {"prompt_tokens": 4, "completion_tokens": 32}
}

Illustrative syntax only — no real endpoints or credentials.

API gateway

One OpenAI-compatible endpoint across every service.

All Tara Cloud services — dedicated deployments, shared endpoints, and resold frontier models — sit behind a single OpenAI-compatible API gateway. One key, one schema, one place to govern access.

Single entry point

A unified /v1 interface across open-weight, dedicated, and frontier model services — no per-service SDKs or endpoints to stitch together.

Key management

Issue, rotate, and revoke API keys per team or workload. Keys are scoped to services, models, and environments — revoked keys stop working immediately.

Rate limits

Per-key and per-project rate limits with burst handling, applied consistently across every service behind the gateway.

chat/completions — OpenAI-compatible

curl https://api.tara.example/v1/chat/completions \
  -H "Authorization: Bearer sk-tara-••••••" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.8-max",
    "messages": [{"role": "user", "content": "Summarize our incident"}]
  }'

Illustrative syntax only — no real endpoints or credentials.

MCP server

Hardware telemetry, exposed over MCP.

An MCP server exposes live hardware telemetry from every node in the fleet — BMC sensors, GPU metrics, and node inventory — so your monitoring, alerting, and automation can read the platform programmatically.

BMC sensors

Temperature, power draw, fan speed, and node health from the baseboard management controller — refreshed continuously.

GPU metrics

Per-GPU utilization, memory pressure, and thermal state — the signals that actually matter for scheduling and capacity planning.

Node inventory

Model, capacity, firmware, location, and lifecycle status for every node — machine-readable and always current.

MCP resources — placeholder syntax

tara://nodes/{id}/bmc        # sensors: temp, power, fan, health
tara://nodes/{id}/inventory  # node model, capacity, status
tara://gpus/{id}/metrics     # utilization, memory, thermals
 
GET tara://nodes/{id}/bmc
{
  "health": "ok",
  "temperature_c": 32.1,
  "power_w": 412,
  "fan_rpm": 5400
}

Placeholder resource syntax — no real endpoints are exposed here.

Orchestration

Kubernetes-native job submission.

Bring containerized jobs and the platform schedules them across a fleet of GPU nodes — with tiered scheduling that matches cost to criticality.

Containerized jobs

Submit standard container images — training, inference, batch — and the platform handles placement, dependencies, and cleanup.

Flexible tiers

Interruptible capacity on flexible tiers with deeper discounts — ideal for batch research and interruptible (preemptible) pipelines.

Priority tier

A production tier with reserved scheduling for jobs that must not be preempted — backed by contractual high-availability SLAs.

job spec — tier selection

kubectl apply -f train.yaml
 
# train.yaml (illustrative)
apiVersion: tara.sh/v1
kind: GPUJob
metadata:
  name: finetune-llm
spec:
  gpus: 8
  tier: flexible      # flexible | priority
  image: registry.tara.example/finetune:latest

Metering & governance

Per-GPU-second metering, budgets, and audit.

Usage is metered to the second and available in real time — so you can set and enforce budgets via API and prove what happened after the fact.

Per-GPU-second metering

Every job is metered in GPU-seconds, with a live usage view in the financing dashboard and itemized billing exports.

Spending-limit API

Set and enforce spending limits per project or team with a single API call — including hard-stop enforcement.

Audit log streaming

Control-plane and data-plane events stream continuously to your SIEM for retention, forensics, and compliance review.

spending limits & audit stream

# enforce a monthly limit per project (illustrative)
PUT /v1/spending-limits
{
  "scope": "project:prod",
  "hard_stop": true
}
 
# audit events → your SIEM
audit.tara.example/stream → https://siem.example/ingest

Illustrative syntax only — no real endpoints or credentials.

Put the platform to work.

Get hands-on with the gateway, the MCP server, and Kubernetes orchestration — our engineers will walk you through a live environment.

Talk to an engineer