> initializing_profile.py... Done.

Jonathan Wrede

ML & Platform Engineer

Dagster | dbt | Kubernetes | Python | FastAPI

Ich baue produktionsreife ML-Systeme und Dateninfrastruktur für IoT-Flotten - von Kapazitätsalgorithmen über Analytics-Warehouses bis zum Fleet-Monitoring für 100.000+ Geräte.

I build production-grade ML systems and data infrastructure for IoT fleets - capacity prediction algorithms, analytics warehouses, and fleet monitoring for 100,000+ devices.

KontaktGet in touch LebenslaufResume LinkedIn

IoT

dbt

IMPACT

Messbare Wirkung Measurable Impact

100k+

IoT-Thermostate überwacht

IoT thermostats monitored

~400

Kundenprojekte mit aktiver Batterieprognose

customer sites with active battery prediction

95+

dbt-Modelle im Analytics-Warehouse

dbt models in analytics warehouse

61-99%

Speicherreduktion bei SNNI (Thesis)

Memory reduction for SNNI (thesis)

Eingesetzter Stack Production Stack

Ingest

Python / IoT APIs / TimescaleDB

Transform

dbt Core / Polars / SQL

Orchestrate

Dagster / Docker / Cron

Deploy

Kubernetes / Helm / ArgoCD

Observe

Grafana / Prometheus

Ausgewählte Projekterfahrung Selected Project Experience

GEBÄUDETECHNIK / IoTBUILDING TECH / IoT

IoT Analytics-PlattformIoT Analytics Platform

ELT / dbt / Dagster / ArgoCD

Zentrales Analytics-Warehouse für 100.000+ IoT-Thermostate - von der rohen Gerätetelemetrie zu getesteten dbt-Modellen, Dagster-Orchestrierung und Grafana-Dashboards auf Kubernetes. Central analytics warehouse for 100,000+ IoT thermostats - from raw device telemetry to tested dbt models, Dagster orchestration, and Grafana dashboards on Kubernetes.

dbt|Dagster|Grafana|ArgoCD|K8s

MLOps / IoT

Batterie-Intelligenz-SystemBattery Intelligence System

Python Library / Algorithmen / Fleet

ML-gestützte Kapazitäts- und Laufzeitvorhersage für 100.000+ IoT-Geräte - als produktionsreife Python-Bibliothek mit Konfidenzintervallen und hardwarespezifischen Defaults. ML-powered capacity and runtime prediction for 100,000+ IoT devices - shipped as a production Python library with confidence intervals and per-hardware defaults.

Python|Polars|pydantic|Dagster|Docker

PLATFORM / OPS

Batterie-Operations-DashboardBattery Operations Dashboard

FastAPI / Alpine.js / Docker

Internes Ops-Tool für Batterietestmanagement, Kapazitätsmessung und automatisiertes Alerting - FastAPI-Backend, Alpine.js-Frontend, 3-Service Docker-Compose-Setup. Internal ops tool for battery test management, capacity measurement, and automated alerting - FastAPI backend, Alpine.js frontend, 3-service Docker Compose setup.

FastAPI|Alpine.js|Plotly|Docker

AI SECURITY

Secure Neural Network Inference

M.Sc.-Thesis · In Arbeit · 2026 M.Sc. Thesis · In Progress · 2026

Speicher-Profiling und Optimierung für 4 SNNI-Systeme auf BERT und ViT - 61-99 % Speicherreduktion, analytische Modelle und ein Deployability-Framework. Memory profiling and optimization across 4 SNNI systems on BERT and ViT - 61-99% memory reduction, analytical models, and a deployability framework.

Python|PyTorch|HE / CKKS|MPC In ArbeitIn progress

ErfahrungExperience

Jan 2025 - HeutePresent

Machine Learning Engineer | Vilisto

Batterie-Vorhersage-Algorithmen, IoT-Datenplattform (dbt + Dagster + ArgoCD) und Fleet-Monitoring für 100.000+ Geräte. Battery prediction algorithms, IoT data platform (dbt + Dagster + ArgoCD), and fleet monitoring for 100,000+ devices.

Jan 2023 - Dec 2024

Big Data Consultant | Saracus

Cloud Data Warehouses (Snowflake / BigQuery / Azure Synapse), Python-ETL-Pipelines und Streamlit-Apps mit OAuth SSO für Enterprise-Kunden. Cloud data warehouses (Snowflake / BigQuery / Azure Synapse), Python ETL pipelines, and Streamlit apps with OAuth SSO for enterprise clients.

Sep 2021 - Oct 2022

Working Student - Data Scientist | Vilisto

ML-Modelle zur Präsenzerkennung (Python, scikit-learn), PostgreSQL/TimescaleDB-Pipelines, Vue.js-Frontend und internes Labeling-Tool. Presence-detection ML models (Python, scikit-learn), PostgreSQL/TimescaleDB pipelines, Vue.js frontend, and internal labeling tool.

AusbildungEducation

M.Sc. Computer Science - AI / ML / Statistics

Universität Münster | Thesis: Speicheroptimierung für Secure Neural Network Inference in Transformern University of Münster | Thesis: Optimizing memory footprints for secure neural network inference in transformers

BUILDING TECH / IoT IoT Analytics-PlattformIoT Analytics Platform

KontextContext

ELT-Plattform für IoT-Telemetrie von 100.000+ Thermostaten. Kernproblem: Rohdaten leben in einer transaktionalen Zeitreihendatenbank - nicht für analytische Abfragen geeignet. Ziel war ein von der Produktion getrenntes Analytics-Warehouse mit getesteten Transformationen und nachvollziehbarer Lineage. ELT platform for IoT telemetry from 100,000+ thermostats. Core problem: raw data lives in a transactional time-series database - unsuitable for analytical queries. Goal was an analytics warehouse fully separate from production, with tested transformations and traceable data lineage.

ArchitekturArchitecture

IoT Sources

EL Job (PII-safe)

Timescale raw

dbt

Models + Tests

Dagster

Grafana

Kubernetes + Helm ArgoCD Sqitch migrations

dbt-Modellschichten (95+ Modelle)dbt Model Layers (95+ models)

Staging

stg_valve_movement_daily

stg_last_updates_per_day

stg_battery_fleet_daily

stg_thermostat_hierarchy

+ 4 more…

Mart

device_states_per_day

battery_algorithm_eval

online_ratios_by_firmware

hardware_fw_distributions

+ many more…

UmsetzungImplementation

ELT statt ETL: Daten werden roh geladen und im Warehouse transformiert. PII wird im Ingestion-Layer entfernt, bevor Daten das Analytics-Schema erreichen. 12-stündliche und tägliche Dagster-Assets mit automatischer Backfill-Unterstützung. ELT over ETL: data is loaded raw and transformed inside the warehouse. PII is stripped in the ingestion layer before data reaches the analytics schema. 12-hourly and daily Dagster assets with automatic backfill support.
Zwei-Schicht dbt-Architektur: Staging-Modelle sind 1:1 mit Rohdatenquellen (nur Casting, Renaming, Deduplication) - keine Business-Logik. Mart-Modelle enthalten Aggregationen und Joins. Chunked Upserts für historische Backfills ohne Speicherprobleme. Two-layer dbt architecture: staging models are 1:1 with raw sources (only casting, renaming, deduplication) - no business logic. Mart models own aggregations and joins. Chunked upserts for historical backfills without memory issues.
Sqitch verwaltet das Raw-Schema (EL-Zielschema), dbt verwaltet sein eigenes Analytics-Schema - keine Migrationskonflikte zwischen beiden Tools. ArgoCD GitOps: Staging-App trackt den main-Branch automatisch, Prod-App wird manuell promotet. Sqitch owns the raw schema (EL target), dbt owns its own analytics schema - no migration conflicts between the two tools. ArgoCD GitOps: staging app auto-syncs to main branch, prod app is manually promoted.
Dagster Software-Defined Assets mit explizitem Abhängigkeitsgraph: die Orchestrierung ergibt sich aus den deklarierten Asset-Dependencies, nicht aus manuell definierten DAGs. Ermöglicht automatisches Erkennen veralteter Assets bei Schema-Änderungen. Dagster software-defined assets with explicit dependency graph: orchestration is derived from declared asset dependencies, not manually wired DAGs. Enables automatic detection of stale assets when schemas change.

DesignentscheidungenDesign Decisions

ELT statt ETL ermöglicht das Neuausführen von Transformationen ohne erneuten Extract. Die strikte Staging/Mart-Trennung verhindert, dass Rohdaten-Strukturen direkt in Applikationscode durchsickern. Sqitch und dbt besitzen separate Schemas, damit dbt-Migrationen niemals Rohdaten-Tabellen berühren. ELT over ETL allows re-running transformations without re-extracting. The strict staging/mart split prevents raw data structures from leaking into application code. Sqitch and dbt own separate schemas so dbt migrations never touch raw data tables.

dbt Dagster PostgreSQL / TimescaleDB Grafana Prometheus ArgoCD Kubernetes Helm Python Sqitch

MLOps / IoT Batterie-Intelligenz-SystemBattery Intelligence System

KontextContext

IoT-Thermostate steuern Heizkörperventile per Motor. Ventilbewegungsschritte und Klemmenspannung sind die einzigen verfügbaren Signale zur Batterieeinschätzung - kein direkter Stromsensor. Die Herausforderung: genaue Kapazitäts- und Laufzeitschätzung aus indirekten, verrauschten Signalen über ~400 Deployments mit unterschiedlichen Hardware-Generationen. IoT thermostats actuate radiator valves via a motor. Valve movement step counts and terminal voltage are the only signals available for battery estimation - no direct current sensor. The challenge: accurate capacity and runtime estimation from indirect, noisy signals across ~400 deployments with different hardware generations.

System-ArchitekturSystem Architecture

Valve + Voltage

datavil
library

Algorithms

thermostat-
supervisor

PostgreSQL

100k+ devices

datavil - Core Algorithms

Capacity
Estimation

Faulty Day
Detection

p5 / p95
Intervals

Runtime
Prediction

GitLab CI/CD private PyPI · v0.10.3 Docker

UmsetzungImplementation

Ventilbewegung als Energieproxy: jeder Motorschritt hat einen bekannten mAh-Verbrauch pro Hardware-Version. Coulomb-Konvertierung summiert diese Schrittkosten über die Zeit. Geräte ohne gemessene Kapazität erhalten hardwarespezifische Fallback-Defaults. Valve movement as energy proxy: each motor step has a known mAh cost per hardware version. Coulomb conversion accumulates these step costs over time. Devices without measured capacity fall back to per-hardware-version defaults.
Fehlerhafter-Tag-Erkennung mit zwei Schwellwert-Typen: Spannungsabfall-Threshold UND Aktivitätsanomalie. Einzelne Tagesausreißer (Fenster < 6h) erhalten eine geringere Strafe als mehrtägige Fehlersegmente, um kurzes Sensorjauschen nicht überzubestrafen. Faulty day detection uses two threshold types: voltage drop AND activity anomaly. Single-day dips (window < 6h) receive a lighter penalty than sustained multi-day segments, to avoid over-penalizing brief sensor noise.
Konfidenzintervalle: empirische Verteilung gemessener Kapazitäten je Hardware-Version bildet einen Prior. Fehlende Tage addieren eine Kapazitätsstrafe. p5/p95 werden aus dieser Verteilung abgeleitet - das Ergebnis ist ein Laufzeitintervall, keine Punktschätzung. Confidence intervals: empirical distribution of measured capacities per hardware version forms a prior. Missing days add a capacity penalty term. p5/p95 are derived from this distribution - the output is a runtime interval, not a point estimate.
Bibliotheks-Design: reine Funktionen ohne DB-Zugriffe oder Seiteneffekte in datavil. Polars DataFrames mit pandera-Schemas an Funktionsgrenzen erzwingen korrekte Spaltentypen vor jeder Berechnung. beartype ergänzt pyright-Statikanalyse mit Runtime-Checks. Library design: pure functions only - no DB access or side effects inside datavil. Polars DataFrames with pandera schemas at function boundaries enforce correct column types before any computation. beartype adds runtime checks on top of pyright static analysis.
Release-Pipeline: commitizen parst Conventional-Commit-Messages und bumpt semver automatisch (fix - patch, feat - minor, breaking - major), aktualisiert CHANGELOG.md, setzt Git-Tag und triggert den GitLab-CI-Publish-Job ins private PyPI-Registry. Release pipeline: commitizen parses conventional commit messages to auto-bump semver (fix - patch, feat - minor, breaking - major), updates CHANGELOG.md, sets a git tag, and triggers the GitLab CI publish job to the private PyPI registry.

DesignentscheidungenDesign Decisions

Die Trennung von Algorithmus-Bibliothek (datavil) und Scheduler (thermostat-supervisor) hält Domänenlogik ohne Datenbankzugriff testbar. Reine Funktionen mit strikter Schema-Validierung bedeuten: Algorithmusfehler tauchen in Unit-Tests auf, nicht in Produktions-Cron-Runs. Die Bibliothek wird als versioniertes PyPI-Paket ausgeliefert, damit andere Services dieselben Algorithmen konsumieren können ohne Code-Duplikation. Separating the algorithm library (datavil) from the scheduler (thermostat-supervisor) keeps domain logic testable without a database. Pure functions with strict schema validation mean algorithm bugs surface in unit tests, not in production cron runs. Shipping the library as a versioned PyPI package lets other services consume the same algorithms without duplicating code.

Python Polars pydantic beartype pandera Docker GitLab CI/CD uv PostgreSQL

PLATFORM / OPS Batterie-Operations-DashboardBattery Operations Dashboard

KontextContext

Internes Ops-Tool für Batterietestmanagement auf einer VM ohne Kubernetes-Overhead. Wichtige Design-Einschränkung: drei Prozesse mit sehr unterschiedlichen Anforderungen - zustandsloser API, Singleton-Scheduler (doppelte Ausführung würde Daten korrumpieren) und Polling-Loop mit In-Memory-Zustand - müssen koexistieren ohne sich gegenseitig zu beeinflussen. Internal ops tool for battery test management, deployed on a single VM without Kubernetes overhead. Key design constraint: three processes with very different requirements - stateless API, singleton scheduler (duplicate runs would corrupt data), and polling loop with in-memory state - need to coexist without interfering with each other.

Architektur (3-Service Docker Compose)Architecture (3-Service Docker Compose)

PostgreSQL +
External API

FastAPI :8000

nginx :8081

Alpine.js
+ Plotly

backend-cron

daily 00:10 UTC · auto-stop · capacity sync

backend-monitor

every 5 min · Teams alert · 1h cooldown

FastAPI Routers

/channels

list · hosts

/measurements

series (30m agg)

/patches

sync · batch insert

/external

customers · hexes

UmsetzungImplementation

3-Service Docker-Compose-Split: API (zustandslos, kann frei neustarten), backend-cron (Singleton - doppelte Ausführung würde Daten doppelt schreiben), backend-monitor (persistente Polling-Schleife mit In-Memory-Cooldown-State). Separate Container verhindern, dass diese Anforderungen kollidieren. 3-service Docker Compose split: API (stateless, can restart freely), backend-cron (singleton - duplicate runs would double-write data), backend-monitor (persistent polling loop with in-memory cooldown state). Separate containers prevent these requirements from colliding.
Messwerte werden auf 30-Minuten-Fenster aggregiert in der API-Schicht. Rohe Zeitreihen bleiben in PostgreSQL; Aggregation erfolgt zur Abfragezeit mit Zeitbereichs-Limit, um Antwortzeiten zu begrenzen. Measurements are aggregated to 30-minute windows in the API layer. Raw time series stay in PostgreSQL; aggregation happens at query time with a time-range limit to keep response times bounded.
Patch-System: Patches sind manuelle Korrekturen/Annotationen auf Messwerten. Der /patches/sync-Endpoint führt einen 3-Wege-Diff durch (erstellen fehlender, aktualisieren geänderter, löschen entfernter Patches) ohne vollständigen Re-Import. Patch system: patches are manual corrections/annotations on measurements. The /patches/sync endpoint performs a three-way diff - create missing, update changed, delete removed - without a full re-import.
Monitor nutzt eine In-Memory-Map mit Last-Seen-Timestamps pro Host. Beim Überschreiten des Schwellwerts wird ein Teams-Webhook gefeuert; der 1h-Cooldown pro Host verhindert Alert-Storms bei Netzwerkausfällen ganzer Segmente. Monitor uses an in-memory map of last-seen timestamps per host. When a threshold is exceeded a Teams webhook fires; the 1-hour per-host cooldown prevents alert storms when an entire network segment goes down.
Kein JavaScript-Build-Schritt: Alpine.js + Tailwind per CDN, Frontend sind reine statische Dateien hinter nginx. Keine Node.js-Toolchain nötig auf der Ziel-VM. No JavaScript build step: Alpine.js + Tailwind via CDN, frontend is plain static files behind nginx. No Node.js toolchain required on the target VM.

DesignentscheidungenDesign Decisions

Der Cron-Job ist ein separater Container statt eines Hintergrund-Threads im API-Prozess, damit er einzeln über die CLI debuggt werden kann ohne API oder Frontend zu berühren. Der Monitor speichert Cooldown-State in-process statt in der DB, da kurze Unterbrechungen beim Neustart akzeptabel sind und kein persistenter State-Store nötig ist. The cron job is a separate container rather than a background thread in the API process, so it can be invoked standalone via CLI without touching the API or frontend. The monitor stores cooldown state in-process rather than in the DB because brief resets on restart are acceptable and no persistent state store is needed.

FastAPI Alpine.js Plotly Tailwind CSS Docker Compose nginx Python PostgreSQL

AI SECURITY / RESEARCH Secure Neural Network Inference

M.Sc.-Thesis in Arbeit - Universität Münster · Abschluss geplant Oktober 2026 M.Sc. thesis in progress - University of Münster · Expected completion October 2026

ProblemstellungProblem

Secure Neural Network Inference (SNNI) ermöglicht private Inferenz - weder Clientdaten noch das Servermodell werden offengelegt. Der Speicherbedarf von Dutzenden bis Hunderten GB macht SNNI-Deployments praktisch unmöglich. Bisherige Evaluierungen ignorieren Speicher weitgehend. Secure Neural Network Inference (SNNI) enables private inference - neither client data nor the server model is revealed. Memory requirements of tens to hundreds of GB make SNNI deployments practically infeasible. Prior evaluations largely ignore memory.

SNNI-ProtokollSNNI Protocol

Client
(private input)

HE / MPC

Server
(private model)

Encrypted
result

4 SNNI-Systeme · 4 kryptographische Paradigmen

4 SNNI Systems · 4 Cryptographic Paradigms

HE / CKKS

MPC

Hybrid HE+MPC

SHARK

BERT-base ViT-Base/16 SNNI-Benchmark repo

BeiträgeContributions

HE/CKKS verschlüsselt den Client-Input homomorph: der Server wertet das Netz auf Ciphertext aus ohne zu entschlüsseln - hoher Rechenaufwand, aber keine Kommunikation während der Inferenz. MPC (Secret Sharing) verteilt Input und Gewichte über mehrere Parteien; günstigere Grundoperationen, aber hohe Kommunikationslast proportional zu Aktivierungsgrößen. HE/CKKS homomorphically encrypts the client input: the server evaluates the network on ciphertext without decrypting - high compute cost but no communication during inference. MPC (secret sharing) distributes input and weights across parties; cheaper base operations but high communication overhead proportional to activation sizes.
Speicher-Profiling der 4 Systeme auf BERT-base und ViT-Base/16: RSS-Tracking auf Layer-Ebene, um zu identifizieren wo Allokationen entstehen. Stock-Implementierungen: 3,3 GB bis über 192 GB Peak - großteils durch Puffer, die für die gesamte Inferenz pre-allokiert werden statt schichtweise freigegeben. Memory profiling of 4 systems on BERT-base and ViT-Base/16: layer-level RSS tracking to identify where allocations occur. Stock implementations: 3.3 GB to over 192 GB peak - largely due to buffers pre-allocated for the full inference pass rather than released layer-by-layer.
Waste Factors quantifizieren, wie viel mehr Speicher ein System allokiert als rechnerisch minimal nötig ist. Analytische Modelle leiten den Waste Factor aus Paradigma-Eigenschaften (Ciphertext-Expansion, Kommunikationspuffer, Protokoll-Overhead) ab - vorhersagbar ohne Profiling. Waste factors quantify how much more memory a system allocates than the theoretical minimum. Analytical models derive the waste factor from paradigm properties (ciphertext expansion, communication buffers, protocol overhead) - predictable without profiling.
Optimierungen (Layer-Fusion, In-Place-Operationen, schrittweise Puffer-Freigabe) reduzieren Peak-Speicher um 61-99 % und generalisieren über Paradigmen und Modellarchitekturen. Das Deployability-Framework mappt Hardware-Speicher-Budgets auf machbare System-/Modell-Kombinationen. Optimizations (layer fusion, in-place operations, incremental buffer release) reduce peak memory by 61-99% and generalize across paradigms and model architectures. The deployability framework maps hardware memory budgets to feasible system/model combinations.

Speicherreduktion (schematisch)

Memory Reduction (schematic)

Stock3.3 GB - 192 GB+

OptimiertOptimized 61-99% reduction

Python PyTorch HE / CKKS MPC BERT ViT Transformers

Messbare Wirkung Measurable Impact

Eingesetzter Stack Production Stack

Ausgewählte Projekterfahrung Selected Project Experience

IoT Analytics-PlattformIoT Analytics Platform

Batterie-Intelligenz-SystemBattery Intelligence System

Batterie-Operations-DashboardBattery Operations Dashboard

Secure Neural Network Inference

ErfahrungExperience

Machine Learning Engineer | Vilisto

Big Data Consultant | Saracus

Working Student - Data Scientist | Vilisto

M.Sc. Computer Science - AI / ML / Statistics

BUILDING TECH / IoT IoT Analytics-PlattformIoT Analytics Platform

KontextContext

UmsetzungImplementation

DesignentscheidungenDesign Decisions

MLOps / IoT Batterie-Intelligenz-SystemBattery Intelligence System

KontextContext

UmsetzungImplementation

DesignentscheidungenDesign Decisions

PLATFORM / OPS Batterie-Operations-DashboardBattery Operations Dashboard

KontextContext

UmsetzungImplementation

DesignentscheidungenDesign Decisions

AI SECURITY / RESEARCH Secure Neural Network Inference

ProblemstellungProblem

BeiträgeContributions

Rechtliche Hinweise