How to Self-Host Mistral's Timestral Time-Series Forecasting Models on Your Own Cloud

Key Points

• Self-hosting Timestral is legal and practical: Mistral published open weights for all four variants (5M, 28M, 123M, 209M) under a Modified MIT license on October 15, 2026, with the inference code under Apache 2.0 (Mistral, Hugging Face). The one real gate is a revenue cap, which I cover below.
• Timestral is tiny by LLM standards. The largest model is 209M parameters, about 837 MB in fp32, and Mistral says it does not need a GPU at inference - a 209M forecast runs in 140 ms on a standard 8-thread server CPU (Mistral). This is the opposite of the GPU-cluster problem everyone braces for.
• Self-host when the series itself is the sensitive asset (revenue, energy load, patient vitals, factory telemetry, trading signals), when you forecast thousands of series on a schedule, or when residency rules forbid a third-party endpoint. Below a few hundred forecasts a day, a hosted endpoint wins once you count your own time.
• The production shape is boring on purpose: an inference container, a readiness probe gated on weights loaded, a startupProbe sized to the real model load, autoscaling on concurrency rather than CPU%, and scale-to-zero on non-production. None of it is Timestral-specific.
• Qovery builds, deploys, and operates that service inside your own AWS, GCP, Azure, Scaleway account or your existing Kubernetes cluster, so the weights and the time-series never leave your account and the cloud bill plus any Savings Plans or committed-use discounts stay in your name.

Forecasting models are now small enough that there is no technical excuse to ship your most sensitive operational data to someone else's endpoint. Mistral's Timestral tops the three main public forecasting benchmarks with a 209M-parameter model that runs on a CPU. If your demand curves, energy loads, or trading signals are the crown jewels, the whole thing fits on a box you already own. Here is how I would run it in production.

What is Timestral, and can you actually self-host it?

Timestral is Mistral's family of time-series foundation models: you pass a numeric history plus optional covariates and get back a horizon of future values with probabilistic prediction intervals, not generated text. You can self-host it today because Mistral published downloadable weights for every variant under a Modified MIT license when it launched on October 15, 2026 (Mistral).

A time-series foundation model is a different animal from a chat LLM. The input is a numeric series plus optional covariates; the output is a forecast horizon with quantiles. Because it is pretrained across many domains, it forecasts zero-shot: you point it at a new series and get a forecast without training a per-series model first. Timestral supports multivariate targets, past-only covariates, known-future covariates, and categorical covariates, with a context window of up to 32,768 time steps (Hugging Face model card).

There are four variants, and all of them are open weights:

Three access modes exist, and you should pick deliberately. There is Mistral's hosted service plus Mistral Forge for fine-tuning; there are the open weights you run yourself from the GitHub repo; and there are the cloud marketplaces (AWS Bedrock, Google Vertex AI Model Garden, Azure AI Foundry) where Mistral's chat models are listed, though at the time of writing Timestral forecasting is distributed as open weights rather than as a marketplace forecasting endpoint. For self-hosting, only the open-weights path matters, and that path is wide open.

The license is the gate, not a footnote. The weights carry a Modified MIT license whose one real teeth is a revenue cap: "You are not authorized to exercise any rights under this license if the global consolidated monthly revenue of your company (or that of your employer) exceeds $20 million ... for the preceding month" (Timestral LICENSE). Above that line you contact [email protected] for a commercial license. The inference code itself is Apache 2.0. Read the license before you deploy, and re-read it at every upgrade, because this is a new family and terms can move between releases. Pin a specific Hugging Face revision instead of tracking main.

If you ever land on a model whose weights are not usable for your case, the self-hostable forecasting field is healthy: Amazon Chronos and Chronos-Bolt and Lag-Llama are Apache 2.0, Google TimesFM is Apache 2.0 for most releases (TimesFM 3.0 weights are production-licensed only inside BigQuery), and Salesforce Moirai 2.0 ships non-commercial (Spheron deployment guide). Everything in the rest of this article applies to those models verbatim, so swap the model name and keep going.

Why would you self-host a forecasting model instead of calling the hosted API?

Self-host when the data is the sensitive part, when forecast volume is high and predictable, or when residency rules forbid a third-party endpoint. For everything else a hosted endpoint ships faster, and pretending otherwise wastes a quarter of engineering time.

• Data gravity. A series of sales, energy load, patient vitals, factory telemetry, or trading signals is often the most sensitive operational data a company owns. The blocker is rarely model quality; it is the egress. Enterprise inference run on-premise or at the edge has climbed sharply as privacy pressure mounts, and data privacy and security is now the single most cited barrier to LLM adoption in enterprise surveys (Kong 2025 API & AI report).
• Volume economics. Forecasting is scheduled and batched: per SKU, per sensor, per store, hourly or nightly. Thousands of series per run turn per-request pricing into a line item nobody budgeted.
• Latency and locality. Inference running next to your warehouse, lakehouse, or edge gateway removes a cross-region round trip per series. A 10,000-series batch finishes in minutes, not hours.
• Residency and compliance. GDPR, HIPAA, and DORA frequently require processing inside a named region in an account you control. A third-party endpoint is a data-processing agreement and a trust boundary you now have to defend.
• Model stability. Pinned weights do not change under you. A hosted endpoint can deprecate or silently update a version between two nightly runs, and a forecasting regression is invisible for days.

The honest counter-case: if you forecast a few dozen series a few times a day, use Mistral's hosted service or a Bedrock/Vertex/Foundry chat endpoint for your adjacent needs and move on. Self-hosting is an operational cost you take on for a specific reason.

Modal, RunPod, and Hugging Face Inference Endpoints are genuinely good if you want zero cluster. Qovery's distinct position is different: your own cloud account, your own Kubernetes, your own cloud bill, without hiring a platform team.

What GPU and instance size do you need to run Timestral in production?

For Timestral, the honest answer is none - a CPU is enough for most workloads. Mistral states the model "does not need a GPU at inference," and on a standard 8-thread server CPU a one-day-ahead forecast from three weeks of 15-minute history takes 10 ms with the 5M model and 140 ms with the 209M model (Mistral). That is roughly 7 forecasts per second per core-group on the largest model, on hardware you are not paying a GPU premium for.

Here is the VRAM arithmetic anyway, because people ask and because it proves the point. Memory is roughly params x bytes-per-param + overhead. For the 209M model: 209M x 2 bytes at bf16 is 418 MB, or 837 MB at fp32 (the exact figure on the card). Add 30-50% for activations and batch headroom and you are still comfortably under 2 GB. That fits in the RAM of any laptop and in the VRAM of the smallest GPU anyone sells. There is no LLM-style KV-cache blowup here.

So the GPU question is really a throughput question: do you want to push millions of forecasts through a synchronous endpoint with the lowest possible latency? If yes, one mid-range GPU is plenty.

NVIDIA VRAM for reference: T4 16 GB, L4 24 GB, A10G 24 GB, L40S 48 GB (NVIDIA datasheets). Any of them is massive overkill on memory; you would pick one for compute throughput, not to fit the model. Or a GPU node pool in your existing Kubernetes cluster if you already run one. For a deeper per-cloud GPU price breakdown, I wrote up the full method in GPU pricing comparison across AWS, GCP, Azure and Scaleway.

Two practical levers: use spot or preemptible nodes for nightly batch (AWS spot runs up to ~90% below on-demand, AWS Spot) and on-demand for the synchronous endpoint. Quantization barely matters on a model this small; skip it unless you are squeezing onto an edge device.

How do you package Timestral as a deployable inference service?

Wrap the model in a small HTTP service, preload the weights at container start so the first request is not the slow one, and expose POST /forecast plus a /healthz that returns 200 only after the weights finish loading. FastAPI is enough for most teams; reach for NVIDIA Triton or TorchServe only when you need their batching.

Baking weights into the image makes startup fast and reproducible but gives you a multi-GB image; pulling from S3, GCS, Azure Blob, or Scaleway Object Storage keeps the image small and turns a model-revision swap into a config change at the cost of a slower cold pull. For a sub-1 GB model like Timestral, I bake them in and move on.

A Dockerfile sketch, CPU variant:

FROM python:3.12-slim
RUN pip install --no-cache-dir "git+https://github.com/mistralai/timestral.git@<pinned-sha>" fastapi uvicorn
RUN useradd -m app
USER app
COPY serve.py /app/serve.py
# warm the weights at build so they ship in the image layer
RUN python -c "from timestral import TimestralForecaster as T; T.from_pretrained('mistralai/Timestral-209M')"
CMD ["uvicorn", "serve:app", "--host", "0.0.0.0", "--port", "8000"]

The handler shape, with health gated on a module-level model object:

model = None  # None until loaded
@app.on_event("startup")
def _load():
    global model
    model = TimestralForecaster.from_pretrained("mistralai/Timestral-209M")

@app.get("/healthz")
def healthz(): return ("ok", 200) if model else ("loading", 503)

@app.post("/forecast")
def forecast(req: Req):  # {series, horizon, quantiles, covariates}
    return model.forecast(req.series, prediction_length=req.horizon, quantiles=req.quantiles)

The install and the from_pretrained / forecast(..., prediction_length=...) calls are straight from the model card. A few preprocessing gotchas that quietly ruin forecasts in production:

• Scaling: feed the series in the units the model expects and keep scaling consistent between training backtests and live calls.
• Context truncation: respect the 32,768-step limit; silently dropping the oldest history changes the forecast.
• Missing values and irregular timestamps: decide your gap-filling policy explicitly.
• Frequency alignment and timezone drift: a daylight-saving shift looks exactly like a demand anomaly.

Pin everything - model revision, Python deps, torch version, inference server version. Unpinned stacks are the number-one cause of "it worked last week." And expose a bulk route that accepts N series in one call. One series per HTTP request is how teams accidentally multiply their bill by 10.

How do you run and scale it on Kubernetes without becoming a Kubernetes team?

The production shape is a Deployment with a readiness probe gated on weights loaded, a startupProbe sized to the real model load time, an HPA driven by concurrency or queue depth rather than CPU%, and scale-to-zero on non-production. On GPU, add a node pool with explicit nvidia.com/gpu limits. None of that is Timestral-specific, which is exactly why you should not hand-roll it.

• GPU node pool mechanics (only if you go GPU): the NVIDIA device plugin or GPU Operator, an accelerator nodeSelector, taints and tolerations so only GPU workloads land on the expensive nodes, and resource limits so one pod does not claim the whole card.
• Probes done right: readiness true only after load; a startupProbe sized to measured load time plus node provisioning. New GPU nodes on managed Kubernetes routinely take several minutes to join and pull images, so size the SLO for that and your pager stays quiet.
• Autoscaling for inference: HPA on in-flight-request or concurrency metrics beats CPU%, because inference pods pin CPU unpredictably. Use KEDA for queue-driven nightly batch.
• Two deliberate paths: a synchronous forecast API for product features on on-demand nodes, and a Kubernetes CronJob batch run writing forecasts to the warehouse on spot nodes.
• Cost control as a default, not a cleanup task: scale non-production to zero, auto-stop preview and staging, and keep GPU node pools out of dev clusters entirely.

This is where Qovery fits. Qovery builds the container, provisions and upgrades the cluster, manages the node pool, and gives every service git-push deployments, per-pull-request preview environments, environment auto-stop, per-environment RBAC, and databases backed by managed cloud services - inside your own AWS, GCP, Azure, Scaleway account or your existing Kubernetes cluster, so the weights and the series never leave it and the cloud bill stays in your name.

What does self-hosted Timestral actually cost compared to the hosted API?

Because Timestral runs on a CPU, the baseline is cheap: a compute-optimized node (AWS c7i, GCP c3, Azure Fsv2, Scaleway COP) plus a managed Kubernetes control-plane fee of about $0.10 per cluster-hour, roughly $73 a month on EKS, GKE Standard, and AKS Standard (EKS pricing, GKE pricing). AKS offers a free control-plane tier, and GKE includes one zonal cluster free per billing account. For the full line-by-line control-plane breakdown I did the math in the true cost of managed vs on-premise Kubernetes.

If you do choose a GPU for maximum throughput, here are real on-demand list prices and the 730-hour monthly math.

*Assumptions: 10,000 series forecast once nightly = ~300,000 forecasts/month, 209M model, 96-step horizon, single region, published list prices, 730 hours/month. Scaleway's L4-1-24G lists at about EUR 0.79/hr (Scaleway pricing).

Two things fall out of that table. First, the nightly spot-batch pattern is roughly a tenth of an always-on GPU node - a GPU idling 24/7 for a job that runs 20 minutes a night is pure waste. Second, the bring-your-own-cloud point: in a model where the workload runs in your account, any existing Savings Plans or committed-use discounts (up to ~72% on multi-year commitments, AWS Savings Plans) apply to this workload too. That is not true of a third-party endpoint, where you pay full retail forever.

Say the quiet part: at a few dozen forecasts a day, the hosted option wins on total cost once you count your own time. The flip comes somewhere in the low thousands of forecasts a day, which is exactly where scheduled enterprise forecasting lives.

What are the most common mistakes when self-hosting a forecasting model?

Self-hosted forecasting fails on operations, not on the model. The recurring ones:

• No evaluation harness. Run rolling-origin backtesting with MASE, sMAPE, and pinball (quantile) loss against held-out windows and alert on degradation. Definitions and formulas are in Hyndman & Athanasopoulos, Forecasting: Principles and Practice and the GluonTS evaluation docs. Without this, a regression is invisible until the business feels it.
• Cold start treated as downtime. Model load plus GPU node provisioning takes minutes and will page you unless probes and SLOs account for it.
• Paying for idle GPUs. 27% of cloud spend is wasted, and idle compute is the single largest driver at 35% of that waste (State of FinOps 2025). A nightly batch does not need a 24/7 node.
• Shipping the endpoint wide open. Forecast inputs leak revenue, demand, and capacity. Put authentication, per-environment RBAC, and network policy in front of it before anything else.
• License drift. Re-read the model card license at every upgrade. On a new family with a revenue cap, this genuinely changes who may deploy.
• No rollback path. Keep the previous pinned revision deployable behind a flag, because a bad forecast is silent for days.
• Confusing data drift with model drift. An upstream schema or frequency change looks exactly like a model problem until you instrument the inputs.

How do I deploy a self-hosted Timestral service from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent in plain language to deploy the inference container into your own cloud account. The agent proposes every action and you approve it, so nothing touches your infrastructure silently.

Install the skills for Claude Code, Cursor, Codex, OpenCode, and Gemini CLI:

curl -fsSL https://skill.qovery.com/install.sh | bash
# scope to one project instead of globally:
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the Qovery MCP Server to Claude Code (OAuth, read-only by default):

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242
# enable write access only when you want the agent to change infrastructure
# (also requires enabling write access in the Qovery Console):
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

What each skill does for this workload: qovery-onboard connects the cloud account, qovery-deploy ships the inference container, qovery-preview spins a per-pull-request environment to A/B a new model revision, qovery-optimize stops paying for idle nodes, qovery-troubleshoot diagnoses a pod that will not schedule, and qovery-terraform exports the setup as code. Skills deploy; the MCP Server operates what already exists. Full walkthrough in the AI agent quickstart and the Claude Code integration.

Are Mistral's Timestral weights open, and can I use them commercially?

Yes. All four variants (5M, 28M, 123M, 209M) ship open weights under a Modified MIT license, with the code under Apache 2.0 (Hugging Face). Commercial use is allowed unless your company's global consolidated revenue exceeded $20 million in the preceding month, in which case you need a commercial license from Mistral (LICENSE).

What GPU do I need to self-host a Timestral forecasting model?

None for most workloads. Mistral states Timestral does not need a GPU at inference, and the 209M model forecasts in 140 ms on an 8-thread CPU (Mistral). If you want maximum throughput on a synchronous endpoint, a single mid-range GPU such as an NVIDIA T4, L4, or A10G is more than enough, since the model needs under 2 GB of VRAM.

Can I run Timestral forecasting on CPU only?

Yes, and for scheduled batch forecasting it is usually the cheaper, simpler choice. A standard server CPU with 8 threads produces a 209M-model forecast in 140 ms and a 5M-model forecast in 10 ms (Mistral). Use a compute-optimized instance (AWS c7i, GCP c3, Azure Fsv2, Scaleway COP) and you avoid the GPU premium entirely.

Is self-hosting Timestral cheaper than the hosted API, and at what volume does it flip?

At low volume, no: the hosted option is cheaper once you count your own time. The flip comes in the low thousands of forecasts a day, where a CPU node at a fixed monthly cost beats per-forecast billing. A nightly spot-batch job is roughly a tenth the cost of an always-on GPU node (list prices).

How do I keep my time-series data inside my own cloud account and region?

Run the inference container in your own AWS, GCP, Azure, or Scaleway account and pin the Deployment to that region, so neither the weights nor the series ever cross an external boundary. Qovery deploys and operates exactly this setup in your account, which is what makes GDPR, HIPAA, and DORA residency requirements straightforward to satisfy.

Can I run Timestral on my existing Kubernetes cluster instead of a new one?

Yes. Timestral is a standard container with a sub-1 GB model, so it runs on any conformant cluster, with or without a GPU node pool. Qovery can deploy onto your existing cluster (BYOK) rather than provisioning a new one.

What are the best open-weight alternatives if I need self-hostable forecasting today?

Amazon Chronos / Chronos-Bolt and Lag-Llama are Apache 2.0, and Google TimesFM is Apache 2.0 for most releases (Spheron guide). Watch the fine print: TimesFM 3.0 weights are production-licensed only inside BigQuery, and Salesforce Moirai 2.0 is non-commercial. The deployment pattern in this article applies to all of them.

Forecasting models crossed a threshold this year: the best one on the public leaderboards is 209M parameters and runs on a CPU. That removes the last technical reason to hand your demand curves, energy loads, and patient vitals to someone else's endpoint. If you want that inference running in your own cloud account without hiring a platform team, Qovery builds, deploys, and operates it for you in minutes.