Local Hosting for Time Series Foundation Models

Local hosting for time series foundation models is a different problem from local hosting for chat models.

The local LLM ecosystem has converged around a relatively clean user experience: download a quantized model, load it in a desktop app or runtime, send text tokens, receive text tokens. That abstraction works because many local LLMs share the same broad inference contract. They differ in architecture details, tokenizer quirks, context length, chat template, and quantization quality, but they still look like causal language models at the serving boundary.

TSFMs do not have that level of standardization yet. Some tokenize values and generate forecasts autoregressively. Some patch the input and predict quantiles directly. Some require JAX, some run through PyTorch, some depend on GluonTS-style data structures, and some combine a numerical forecaster with a text-conditioning path. They can all be hosted locally, but they do not all want the same host.

That is the central operational lesson from running TSFMs in practice: local hosting is not one recipe. It is a model-family adapter problem.

#What local hosting means

"Local" can mean at least four things.

The first is a laptop experiment: install the model package, load a checkpoint from Hugging Face, run a forecast on one CSV. This is the right entry point for researchers, analysts, and teams validating whether a model family is worth deeper evaluation.

The second is a desktop or workstation workflow: keep the model on a local machine, point notebooks or internal tools at it, and avoid sending proprietary time series to a third-party API. This is common in finance, energy, manufacturing, and healthcare settings where the data itself is sensitive even when the model is open.

The third is a local network service: run a forecasting API inside a VPC, office network, lab cluster, or edge environment. The model is still "local" to the organization, but it now needs request validation, batching, observability, versioning, and a stable response schema.

The fourth is production GPU hosting: serve multiple model families behind one internal or external API, usually with autoscaling, warm pools, model routing, and a reliability target. This is where the local-serving story stops being about whether a model can load and becomes about whether the system can keep serving forecasts when requests arrive with different context lengths, horizons, frequencies, and output requirements.

Those four use cases should not be collapsed. A model that is easy to run in a notebook may still be awkward to host as a low-latency API. A model that is expensive on a laptop may be efficient when batched on an A10G or L4. A model that supports point forecasts cleanly may need extra calibration work before it is acceptable for probabilistic planning.

#Why TSFMs do not fit one serving shape

The current TSFM model zoo is architecturally diverse.

Chronos is closest to the language-model analogy. The original Chronos family tokenizes time-series values into a discrete vocabulary and trains T5-style models to model those tokens. That makes the conceptual bridge to local LLM hosting obvious, but it does not mean a Chronos checkpoint is automatically a GGUF chat model. The official amazon-science/chronos-forecasting repository exposes a forecasting pipeline, not a chat-completions interface.

Chronos-Bolt changes the serving profile. It is designed for much faster inference than the original token-sampling Chronos path by predicting forecasts more directly. That makes it attractive for local CPU and GPU use, but it also means the output contract is not "next token." It is forecast arrays, often quantiles, over a requested horizon.

TimesFM has its own runtime expectations. The public timesfm package supports PyTorch and PAX/JAX installation paths, and the usage examples configure backend, context length, horizon length, batch size, and checkpoint identity explicitly. That is normal for a research-grade forecasting package. It is not the same as dropping a quantized LLM into a desktop chat runner.

Moirai and Moirai-MoE add another shape. Salesforce's Uni2TS stack uses forecasting-specific data handling and GluonTS-style evaluation utilities. Moirai's any-variate and probabilistic design is exactly why it is interesting, but it also means a serving layer has to normalize multivariate inputs, target columns, forecast distributions, and quantile outputs.

Lag-Llama is probabilistic and autoregressive, but its ecosystem is not the same as a consumer local LLM app. TiRex is built around xLSTM-style forecasting and enhanced in-context learning. TinyTimeMixer is small enough for CPU and edge use, but the engineering question shifts from "can it fit?" to "does it provide the uncertainty and accuracy profile the application needs?"

Text-conditioned systems such as Migas 1.5 split the problem again. A local LLM may summarize events, extract facts, or generate scenario text, while a numerical forecaster produces the forecast. Hosting the system locally means hosting a pipeline, not just one model.

#The role of local LLM tools

Tools such as Ollama and LM Studio are still relevant. They are just not general TSFM serving layers.

Ollama's import documentation describes importing several supported Safetensors architectures, importing GGUF files, and quantizing compatible FP16/FP32 models through a Modelfile workflow. Hugging Face's Ollama integration is framed around running GGUF checkpoints directly from the Hub with commands such as ollama run hf.co/{username}/{repository}. Hugging Face's LM Studio integration similarly focuses on GGUF and MLX LLMs, and the LM Studio import docs describe importing external GGUF files into its expected model directory.

That is excellent for local LLM use. It is also the clue to the boundary: most TSFMs are not distributed as GGUF causal language models with a chat template. They usually ship as PyTorch, JAX, GluonTS, or model-specific Python packages with forecasting-specific input and output semantics.

The right local architecture is therefore often compositional:

Layer	Local tool that fits	Job
Text summarization	Ollama, LM Studio, llama.cpp, MLX, local OpenAI-compatible LLM server	Summarize events, analyst notes, logs, weather alerts, promotions, outages, or policy changes.
Time-series inference	Python service using the model's native package	Load TSFM checkpoints, validate numeric arrays, run forecasts, return point/quantile/sample outputs.
Forecast API	FastAPI, gRPC, internal service, notebook wrapper, or CLI	Normalize request and response shapes across model families.
Evaluation and routing	Local benchmark harness or production router	Select models by latency, calibration, horizon, covariate support, and accuracy.

This is not as simple as opening a model in a desktop chat UI. It is more useful. It preserves the strengths of both ecosystems: local LLMs handle language context, while TSFMs handle numerical forecasting.

#The adapter boundary

At TSFM.ai, we treat model family as a first-class serving boundary. The public API should not expose every internal quirk of Chronos, TimesFM, Moirai, TTM, or a text-conditioned stack. But the serving layer cannot pretend those quirks do not exist.

The adapter for each family has to answer the same questions:

• What input shape is valid: univariate, multivariate, grouped, covariate-aware, or text-conditioned?
• What context lengths are supported, and what happens when the user sends too much or too little history?
• What forecast horizons are efficient, and which ones require chunking or rolling calls?
• Does the model return point forecasts, quantiles, samples, or parameters of a distribution?
• How should missing values, irregular timestamps, time zones, and frequency inference be handled?
• Which device and precision modes are stable: CPU, Apple Silicon, CUDA FP32, FP16, bfloat16, INT8, or compiled graph?
• What metadata is required to make the result interpretable: scale, frequency, target column, quantile levels, confidence interval semantics, model version, and calibration status?

This adapter boundary is the difference between "we got a notebook to run" and "we can host this model reliably." It is also where many local experiments fail quietly. The model may load, but the request path may be wrong: context is padded incorrectly, the forecast horizon exceeds the tested regime, the output quantiles are interpreted as calibrated intervals, or a covariate is passed without respecting whether it is known in the future.

For an authoritative local hosting stack, the adapter is not optional glue. It is the product.

#CPU, desktop GPU, and production GPU

Hardware choice changes the deployment story.

CPU-only local hosting is real. The CPU-only energy load forecasting benchmark showed that several TSFMs can produce useful energy forecasts on consumer hardware. This matters for utilities, research labs, regulated teams, and edge deployments where a cloud GPU is not available or not allowed. Small models such as TTM, compact Chronos-Bolt variants, and other lightweight forecasters can be viable on commodity machines.

Desktop GPUs are the next step. A workstation with an NVIDIA consumer card can be enough for evaluation, small internal services, and nightly batch jobs. The limiting factors are usually VRAM, dependency compatibility, and request shape variability rather than raw FLOPs. A single large context request may fit, while a batch of many uneven series may fragment memory or waste compute on padding.

Production GPUs are a different operating mode. On real GPU infrastructure, the hardest work is not calling model.forward(). It is keeping utilization high while preserving latency and correctness. Forecasting requests arrive with different lengths, horizons, numbers of series, and output types. Batching needs to group compatible shapes. Model replicas need warm weights. Cold starts need to be controlled. Large models need predictable memory footprints. Observability needs to track both infrastructure metrics and forecast-specific metrics: context length distribution, horizon distribution, calibration drift, interval coverage, missing-value rate, and per-model error.

This is why TSFM serving often resembles a small model zoo rather than a single model endpoint. In our own serving work, the practical pattern is a common API over per-family adapters, with model routing above it. The router can send short CPU-friendly jobs to lightweight models, probabilistic jobs to models with native interval support, long-context jobs to architectures that benefit from more history, and text-conditioned jobs to a pipeline that includes a local or hosted language model.

#What changes when you host on GPUs

GPU hosting makes TSFMs faster, but it does not erase the model-family problem.

The first issue is shape management. LLM serving often optimizes around token counts and decode steps. TSFM serving optimizes around context length, horizon length, number of series, number of variables, and output representation. A batch of 1,000 series with 512 points each is a very different object from one multivariate series with many channels and a long horizon.

The second issue is output normalization. One model may return samples, another returns quantiles, another returns a point forecast, and another requires post-processing to produce calibrated intervals. A hosted API needs to make those differences explicit without forcing every downstream user to learn every model's internals.

The third issue is dependency isolation. A single machine may need PyTorch, JAX, GluonTS, CUDA-specific builds, model-specific repos, and different Python versions. That is manageable in notebooks. In production it argues for separate containers, explicit model manifests, and compatibility tests at deploy time.

The fourth issue is warm capacity. Loading a model into GPU memory is slow enough that a production system should avoid doing it on the critical path. Warm pools and preloaded replicas matter. So does deciding which models deserve GPU residency and which can run on CPU or be loaded lazily for offline jobs.

The fifth issue is calibration. Local hosting makes it easy to run a model. It does not make the model's intervals trustworthy for your domain. Probabilistic forecasts need empirical coverage checks, backtests, and often conformal calibration. The cost of a bad local forecast is still real even when the inference bill is zero.

#A practical local reference stack

For a team starting from scratch, the simplest robust stack looks like this:

1. Start with one model family and one task. For example: Chronos-Bolt for univariate probabilistic forecasting, TimesFM for long-context point forecasting, or Moirai for multivariate probabilistic experiments.
2. Build a local Python wrapper around the model's native package. Do not begin by forcing the model into an LLM runtime unless the model is actually distributed in a compatible format.
3. Define a stable request schema: timestamps, values, optional covariates, context length, horizon, frequency, quantile levels, and missing-value policy.
4. Define a stable response schema: forecast timestamps, point values, quantiles or samples, model identity, version, scale handling, and warnings.
5. Add a small benchmark harness with your own data. Measure accuracy, calibration, latency, memory, and failure modes before adding more models.
6. Add a second model family only after the adapter boundary is clean. The value of local hosting comes from comparison and routing, not from accumulating unmaintained notebooks.
7. If text context matters, host a local LLM separately and pass structured summaries into the forecasting path. Keep the information boundary explicit so future leakage is not smuggled into the forecast.

For production, add containerized model adapters, GPU warm pools, request batching, model routing, and forecast-specific observability. The GPU optimization guide, streaming inference architecture, and production forecast pipeline posts cover those layers in more detail.

#What a TSFM hosting standard would need

The local LLM ecosystem became useful because formats, runtimes, and APIs converged. TSFMs need a different standard, not a copy of the chat stack.

A useful TSFM serving standard would define:

• a canonical time-series tensor format with timestamps, frequencies, masks, targets, variables, and grouped series;
• a way to declare context and horizon limits;
• output semantics for point forecasts, quantiles, samples, and calibrated intervals;
• metadata for model family, training domain, known covariate support, future covariate support, and calibration status;
• adapter hooks for scaling, missing values, irregular sampling, and time-zone handling;
• benchmark manifests that pair latency, memory, accuracy, and calibration results with the exact serving configuration.

This is why "can I run it locally?" is the wrong final question. The better question is: can I host it locally with the right input contract, output semantics, hardware profile, and evaluation loop?

For current TSFMs, the answer is yes, but not through one universal local app. The practical path is native model packages behind a consistent forecasting adapter, with local LLM tooling used where language context genuinely helps. That architecture is less magical than a one-click runner. It is also much closer to what reliable forecasting systems need.