VECTIQ
← Vectiq Product Platforms

Vectiq MLOps - Model Lifecycle Platform

Training a model is the easy part; keeping it correct after deployment is where most projects stall. Vectiq MLOps covers the whole loop on one platform: versioned datasets, training jobs tracked in MLflow, a registry that refuses to promote a model below its quality bar, inference endpoints with API keys and canary releases, and monitoring that measures drift and accuracy on live traffic and can trigger retraining. The preprocessing is saved inside the model, so the endpoint transforms inputs exactly as training did. It runs on Docker Compose on a single server or on Kubernetes with one deployment per endpoint, and a hosted GPU tier for larger models is being built as a separate service.

Launch app ↗
EnterpriseBanking & FinanceAgricultureSmart City & Transport
Vectiq MLOps - Model Lifecycle Platform

Technical capabilities

01

Versioned Datasets & Connectors

Upload CSV or Parquet, or pull a table from Iceberg, S3 Parquet, PostgreSQL or MySQL. Every pull becomes an immutable dataset version with its source snapshot recorded, and schema changes are flagged.

02

Training That Keeps Its Preprocessing

Jobs run on Celery workers with live logs. Imputation, encoding and scaling are fitted on the training split only and saved with the estimator, tracked in MLflow; Optuna search is optional.

03

Registry with Quality Gates

A version reaches production only if it clears the accuracy, R² or mIoU threshold for its task. One production version per model, an optional second reviewer, and a model card generated for every version.

04

Endpoints, Canary & Shadow

Deploy a version behind an API key with its own rate limit. Send a share of traffic to a new version, mirror requests to a shadow version without affecting replies, or roll back in one call.

05

Drift & Accuracy Monitoring

Each deployment gets a baseline from its training data; live inputs are compared with PSI. Ground-truth feedback turns into accuracy reports, and alert rules notify Slack, email, webhooks or the in-app inbox.

06

Retraining Loop

A retrain policy fires on drift, falling accuracy or a schedule. The challenger is scored on the same holdout as the champion; if it is worse the run stops and records why, otherwise it goes to canary and approval.

07

Feature Store

Validated ingestion into an online store on Redis and an offline store on Parquet, point-in-time lookups for training sets, and endpoints that fetch features by entity id instead of asking the caller for them.

08

Access, Audit & SDK

Project roles, personal access tokens, a Python SDK and CLI, scoped API clients for partners, and an activity log of who changed what. The dashboard is in Vietnamese and English.

Processing pipeline

01

Data Sources

CSV / Iceberg / SQL

02

Datasets

MinIO / versioned

03

Training

Celery / MLflow

04

Model Registry

Quality gate

05

Inference

API key / canary

06

Monitoring

PSI drift / alerts

Deployment scenarios

Enterprise Data Teams

From a Spreadsheet to an API

Churn, demand or lead scoring usually starts as a notebook nobody can run twice. On the platform the same model becomes a versioned dataset, a tracked training run and an endpoint the sales system calls with an API key, with the schema documented for whoever integrates it.

  • Pull training data straight from the warehouse or Lakehouse
  • scikit-learn, XGBoost and LightGBM algorithms with parameter checks
  • Single and batch prediction APIs with an input schema
  • Scheduled batch scoring written to Parquet, CSV or a data mart
  • Bring a model trained elsewhere as skops or ONNX; the platform re-evaluates it
Tabular MLBatch ScoringONNXLakehouse
Banking & Finance

Models You Can Explain to an Auditor

In a regulated business the question is not only whether a model is accurate but who approved it, on what data, and what it did last month. Every promotion is traceable, the person who requests it cannot approve it, and the model card travels with the version.

  • Two-person approval for production promotion
  • Model cards with lineage, metrics and feature importance
  • SHAP explanations per prediction when enabled
  • Inference logs kept by monthly partition with retention
  • Activity log queryable by user, action and time
GovernanceModel CardSHAPAudit
Data Scientists & Partners

Notebook In, Shared API Out

Data scientists keep working in notebooks; the platform takes over at the point where work usually gets lost. A notebook session gets a short-lived token, the SDK uploads data and imports models, and a partner receives one API client scoped to exactly the endpoints and feature groups they need.

  • JupyterHub workspaces signed in with platform accounts
  • Python SDK and CLI over the same API as the dashboard
  • Partner API clients with scopes, quotas and expiry
  • OpenAPI document generated per endpoint for integrators
  • Feature groups appended to Iceberg tables for the Lakehouse
JupyterHubSDKPATAPI Clients
Vectiq MLOps Geo

The Model Layer Behind Our Map Products

The Geo module, Vectiq MLOps Geo, does not run its own ML stack; it calls this platform over HTTP. Building statistics per H3 cell become feature groups, labelled image chips become datasets for a segmentation model, and drift is watched per region instead of only globally.

  • H3 cells as feature-store entities, looked up by coordinates
  • U-Net segmentation trained on Sentinel-2 chips, exported to ONNX
  • Batch inference over satellite scenes into map layers
  • Drift and alerts per region, not only per endpoint
H3Sentinel-2U-NetRegion Drift

Tech stack

FastAPICeleryMLflowPostgreSQLRedisMinIOscikit-learnXGBoostOptunaONNX RuntimeNext.jsKubernetes

Related projects