RU /EN
Start a project
Product engineering · ML · Systems

From zero — to a working product.

I take on complex software and ML products end to end: from the product problem and architecture through backend, inference, native application and production infrastructure. One engineer owns the technical outcome instead of a chain of disconnected vendors.

  • macOS · iOS · Linux · GPU
  • Swift · Rust · Python · Kotlin
  • MLX · CUDA · vLLM · Core ML
Start a project Telegram ↗

Selected projects

01 / 05
01

KRT Studio

Production product

A single self-hosted AI studio: image, video and audio generation and editing on your own GPUs, in one interface.

The KRT Studio main screen: sessions on the left, a grid of results from four models in the centre, the AI helper on the right expanding a short request into a detailed prompt, generation parameters below and the VRAM indicator in the top bar
One interface across every modality. On the right, the AI Director: “Pomeranian with glasses” is expanded into a full prompt by a local Qwen3.5-4B. In the centre, the same request across four models, every frame labelled. Parameters and VRAM headroom stay in view.
Why it exists
Open models live in dozens of separate web UIs: each with its own launcher, its own parameters, its own result history. KRT Studio brings them into one working tool on your own hardware, with no cloud APIs. A new model is added to the existing studio instead of standing up yet another UI.
What I built
The entire product, solo: architecture, a FastAPI backend, a custom worker protocol and supervisor, a VRAM-aware model runtime, the React frontend, a built-in image editor with 12 tools, and the mass-generation queue.
Engineering detail
Every model declares its own capabilities and limits — steps, guidance, resolutions, LoRA — and the interface shows only the controls that apply to the selected one. Storage and database are chosen by config: S3, MinIO or a local disk; PostgreSQL or SQLite. The AI Director talks to any OpenAI-compatible endpoint, so there is no vendor lock-in anywhere in the chain.
Outcome
40+ open models in one studio: images, image editing, video, music, TTS and sound effects. Shared sessions and projects, carrying a result between the image, video and audio workflows, batch generation and side-by-side comparison.
  • 40+ models
  • image · video · audio · TTS
  • 12 editor tools
  • VRAM-aware runtime
Frontend React 19 · TypeScript · Zustand · Fabric.js · Tailwind · Vite
Backend Python · FastAPI · asyncio · SSE · PyTorch (CUDA 12.8)
Infra worker supervisor · PostgreSQL / SQLite · S3 / MinIO / local disk

A real batch run

The first run produced 6 600 images across 11 models. The set then grew to 17 models — the whole array was generated through KRT Studio, and the long batch jobs ran without restarting the process. The result is published as an open dataset and an interactive comparison: pick a prompt and put the models side by side.

600
prompts
17
models
10 200
images
~72 h
of generation in total
The KRT Studio batch generation window with per-model and per-prompt progress
One run out of the set. The batch runs in the background: progress per model and per prompt, and the window can be closed.
02

Recompose

Native application

A native macOS OCR app that rebuilds the document, not just the text inside it.

88
tests over the pipeline
64
experts in the MoE decoder
Top-6
token routing
Why it exists
Ordinary OCR gives you a stream of text: tables fall apart, diagrams are lost, and the structure has to be rebuilt by hand. Recompose gives the document back: tables stay tables, headings stay headings, and diagrams are carried over as cut-outs.
What I built
The full Unlimited-OCR inference stack in Swift and MLX: SAM Vision Encoder, a CLIP-like Vision Encoder, Vision Fusion and an MoE decoder. Plus document assembly, export, and two surfaces — CLI and GUI.
Engineering detail
An MoE decoder with 64 experts and Top-6 routing, running entirely on a native Metal runtime. No Python ships with the app: the model runs inside it, not alongside it.
Outcome
Export to DOCX, a reconstructed PDF and a searchable PDF. An image of a document becomes a genuinely editable file. 88 tests.
  • 88 tests
  • 64 MoE experts · Top-6
  • text · tables · diagrams
  • no Python runtime
Stack Swift · MLX · Metal · Unlimited-OCR · DOCX / PDF
03

turna

Infrastructure

A TURN/STUN server in Rust, built for a closed video-calling system that needed a networking stack under its own control rather than external infrastructure.

Client behind NAT
STUN binding RFC 5389
TURN allocation lifecycle RFC 5766 · 8656
turna Rust
Production path
  • relay over UDP and TCP
  • batched I/O: recvmmsg / sendmmsg
  • long-term credentials, JWT, limits
  • session migration, graceful drain
Preview: behind Cargo features
  • DTLS · QUIC · WebTransport · TLS/TCP
  • io_uring · AF_XDP
  • clustering: gossip, hash ring
  • RFC 6062: less exercised
gRPC control plane turnactl Prometheus OpenTelemetry state: in-memory / Tarantool
Feature maturity is documented in a guarantees table — including what the server does not promise.
Why it exists
When a direct peer-to-peer connection is impossible, the call goes through a relay. The project needed a relay it could deploy and control itself — with its own limits, its own access policy, and no dependency on someone else's service.
What I built
The protocol layer, the architecture and the operational surface — solo: from packet parsing to a Helm chart, a gRPC control plane and a CLI.
Engineering detail
STUN binding and the full TURN allocation lifecycle per RFC 5389, 5766 and 8656, relaying over UDP and TCP. Batched UDP I/O: SO_REUSEPORT workers with recvmmsg/sendmmsg and per-batch arena buffers. The STUN and TURN parsers are continuously fuzzed, and every unsafe block is inventoried and confined to the transport and relay datapaths.
Outcome
Production GA 0.3.0 under Apache 2.0: Prometheus and OpenTelemetry, a gRPC control plane and the turnactl CLI, graceful drain, config and limit restore after a restart, Docker and Helm. A maturity matrix in the repository keeps the production path separate from preview features.
  • Rust
  • RFC 5389 · 5766 · 8656
  • continuously fuzzed parsers
  • Production GA 0.3.0
Core Rust · STUN / TURN · UDP · TCP · Tokio
Ops gRPC · Prometheus · OpenTelemetry · Tarantool · Docker · Helm
04

Dictum

Native application

A local voice AI utility for macOS: dictation, transcription, interviews and text processing, with no cloud requirement.

Microphone the user
System audio the other party
Core Audio Process Taps Aggregate Device IOProc realtime ring buffer
Speaker labels by construction no diarization model needed
Two tracks are recorded separately, so who is speaking is known exactly — no model, no dependency on room acoustics.
Why it exists
Voice input and meeting transcription usually mean sending audio to someone else's server. Dictum does the same work on the device: recognition and text processing run locally, and a cloud model is connected only if the user actually wants one.
What I built
GigaAM v3 through my own MLX port, a local Qwen for text processing, and an OpenAI-compatible API as an option. The system side: global hotkeys, the Accessibility API, system audio capture via Core Audio Process Taps and an Aggregate Device, a realtime ring buffer, custom chunking, SQLite.
Engineering detail
The microphone is the user; system audio is the other party. The sources are separated at the system level, so interview mode needs no separate diarization model: speaker attribution falls out of the capture architecture rather than another model's output.
Outcome
Dictation into any app, meeting transcription with speakers separated, and text processing — all on the device.
  • GigaAM v3 · MLX
  • Core Audio Process Taps
  • no diarization model
  • runs without the cloud
Stack Swift · MLX · Core Audio · Accessibility API · SQLite
05

ACE-Step Studio

Native application

The native macOS take on the KRT Studio music workflow — a separate lightweight product for Apple Silicon.

~7.7 s
for 30 seconds of music, M1 Max
~3.9×
faster than realtime
25 GB → ~400 MB
VAE buffers after the tiled decoder
Prompt
Tokenizer bit-exact
Qwen3 3.39×10⁻⁵
Conditioning
DiT 4.35×10⁻⁵
VAE 25 GB → ~400 MB
Audio
notes under stages — deviation from the reference implementation
At the VAE stage a straightforward decode needed around 25 GB of buffers; a tiled decoder cut that to ~400 MB — which is what makes generation possible on an ordinary Mac.
Why it exists
KRT Studio is a full self-hosted platform for your own GPU fleet. Not everyone needs a server: ACE-Step Studio takes the music workflow out of it and packages it into an app that runs entirely on a single Mac.
What I built
The full native pipeline in Swift and MLX: Prompt → Tokenizer → Qwen3 → Conditioning → DiT → VAE → Audio. The port, the runtime and the app.
Engineering detail
Step-by-step parity against the reference implementation: tokenizer bit-exact, Qwen3 at 3.39×10⁻⁵, DiT at 4.35×10⁻⁵, tokenizer indices matching 50 of 50. A tiled decoder cut the VAE buffer cache from 25 GB to ~400 MB.
Outcome
~7.7 s for 30 seconds of music on an M1 Max — about ~3.9× faster than realtime, locally and with no server.
  • ~7.7 s / 30 s audio
  • ~3.9× realtime
  • 25 GB → ~400 MB
  • Swift + MLX
Stack Swift · MLX · Metal · ACE-Step · Qwen3 · DiT · VAE

I don't start with the technology

First I work through the product problem and its constraints. Sometimes the right answer is a large ML model. Sometimes it is a plain algorithm with no ML at all. Architecture follows the outcome, not the other way around.

Recompose
Complex multimodal ML genuinely is required: you cannot rebuild a document’s structure from an image without a model.
timesense
An LLM is not just unnecessary here, it is harmful. Calendar automation needs determinism: the same phrase must produce the same event every single time. Dictionaries and regular expressions guarantee that; a model does not.
Dictum · interview mode
No separate diarization model needed: the microphone is the user, system audio is the other party. The sources are separated at the system level.

What I do

I fit best where no off-the-shelf solution exists, or where it is not enough.

Product Engineering

From a raw product idea to a working application: architecture, backend, native or web client, deployment and production.

Applied ML

Inference, fine-tuning, LoRA, RAG, embeddings and reranking, multimodal pipelines, and getting models into real products.

Native / Local AI

Porting Python and PyTorch models to a native runtime, MLX and Core ML, quantization, model conversion, inference without a cloud API.

Systems Engineering

Rust, distributed backend, network protocols, realtime systems, GPU infrastructure and high-performance services.

Open source and other work

GitHub kruatech Systems · native apps · tools Hugging Face kruatech Models · datasets · interactive demos
T2I Model Comparison

An open comparison of text-to-image models over a single prompt set: not a selection of good-looking frames but a full run with the result published

  • 600 prompts
  • 17 models
  • 10 200 images
Read more Dataset Comparison
gigaam-v3-mlx

Native GigaAM v3 inference for Swift and MLX on Apple Silicon — Russian speech recognition entirely on-device

Read more GitHub Hugging Face
timesense

A deterministic natural-language parser for dates, events and recurrence — no LLM, no ML. “every second Friday of the month at 6:30pm retro” → a structured event, an RFC 5545 rrule or a ready .ics file. Russian and English, zero dependencies, under 1 ms per phrase.

Read more PyPI GitHub
VaultGuard

An open-source password manager: a local KeePass (.kdbx) file with no server at all, or any Bitwarden / Vaultwarden-compatible server — your own or hosted. AutoFill, TOTP, biometrics, certificate pinning. Apache 2.0.

Beta · submitted for App Store review
Read more Support GitHub

How I work

  1. 01

    Work through the product problem

    I do not start by picking a framework or a model.

  2. 02

    Design the solution

    MVP scope, architecture, stack, model, constraints and what counts as done.

  3. 03

    Build it

    I take the key engineering parts myself: backend, ML, native runtime, infrastructure — whatever the project needs.

  4. 04

    Take it to production

    Testing, packaging, deployment, release, operation.

Engineering range

Native apps ·ML inference ·Fine-tuning / LoRA ·RAG ·Model conversion ·Realtime audio ·Networking ·Distributed backend ·GPU infrastructure ·Document reconstruction

About

Anton Krutilin. Working in commercial software since 2011, as an architect since 2019. Currently an architect in a stream at one of the country’s two largest banks; the stream’s architecture scope covers 60+ people. Alongside building products on my own, I work as an architect of large enterprise systems and make architectural decisions at that scale.

KRUATECH is an independent engineering studio. One engineer covers a large part of a product’s technical path: product architecture, backend, ML, native application and infrastructure. For a startup that means a lot of engineering without standing up a full technical team first.

Commercial
since 2011
Architecture
since 2019
Current scope
60+ people stream
Engineering
Product · ML · Systems
Code
Swift · Rust · Python

I also join a team

I am open to strong engineering and architecture roles where the work is not only aligning decisions, but also building the hard parts of the system myself.

Discuss a role →
  • Architecture
  • ML / Inference Systems
  • Product / Systems Engineering

Got a problem? Let’s take it apart.

Come with a finished spec, or just with a product idea. I will help work out what actually needs building, choose the architecture, and take it through to a working product.

Start a project
Telegram a@krutilin.pro GitHub Hugging Face
For hiring enquiries →