Gradient Ascend

Gradient Ascend · ZurichCustom deep learning for companies and research laboratories

Neural networks designed for your data.

We design deep learning architectures for a specific problem and dataset, deploy them into your systems, and show you why they decide what they decide. We work alongside your team until the model runs in production, so you don't need to build an ML department first.

Describe your problem How a project runs ↓
Contour lines of an objective with a path of gradient-ascent steps climbing to the optimum θ₀ θ* f(θ) = const. η∇f(θ)
Fig. 1 — Gradient ascent: each step follows the slope uphill, θ ← θ + η∇f(θ), until it reaches the optimum θ*. Our name, and a fair summary of how we work.

§1Approach

Why not just fine-tune a pretrained model?

Often you should, and we will tell you when. General-purpose models are trained on general-purpose data. When the signal you care about sits in a narrow vibration band, a rare cell morphology or years of sparse process logs, a network whose structure reflects that data tends to need less compute, fewer labelled examples, and is far easier to explain.

So we start from the data: its modalities, sampling rates, symmetries and noise. Then we design the architecture around it and benchmark it honestly against strong pretrained baselines.

Diagram: three data sources, each with its own encoder, joined by a cross-attention fusion block that feeds two outputs Data Encoders, one per source Fusion Outputs Vibration signal 48 kHz · 3 axes Dilated 1-D conv receptive field ≈ 1 s Thermal images 320×240 · 9 fps Small CNN shared across frames Process log tabular · sparse Embeddings + MLP missing-value aware Cross-attention fusion aligned in time Fault class 7 classes Uncertainty calibrated designed for this data
Fig. 2 — Illustrative: an architecture whose structure follows its data. Each source gets an encoder suited to its sampling rate and structure, and the sources are fused where they actually interact.

§2How a project runs

From your question to a model your team runs.

  1. 01

    Problem and data

    We start with your question and your data. We audit what you have, define success in numbers, and agree how it will be measured.

    You receive: a problem definition, a data audit, an evaluation protocol.

  2. 02

    Architecture

    We design and train candidate architectures that match the structure of your data, and compare them against strong baselines, pretrained models included.

    You receive: the trained model, a benchmark report, reproducible training code.

  3. 03

    Deployment

    We put the model into your environment, whether cloud, on-premise or edge hardware, with monitoring for drift and performance.

    You receive: a production service or package, monitoring, a runbook.

  4. 04

    Interpretability and handover

    We show which inputs drive each decision, test the model where it is most likely to fail, and train your team to run it. We stay involved until it is operational.

    You receive: an interpretability report, a failure analysis, training for your team.

§3Interpretability

You should be able to ask a model why.

A prediction you can't explain is hard to act on, hard to defend to a regulator, and hard to debug when the world changes. Every model we deliver comes with the analysis to answer three questions:

  • Which parts of this input led to this prediction?
  • What has the model learned to look for, internally?
  • Where is it likely to be wrong, and how would we notice?
Left: an input signal with a strip showing which time ranges drove the prediction. Right: a bar chart of contribution by input feature. Input signal Attribution over time 0 s 2 s burst at 2.1–2.4 kHz Contribution by feature Vibration, 2.1–2.4 kHz 0.46 Bearing temperature 0.21 Spindle speed 0.12 Tool age 0.07 Ambient humidity 0.02 Prediction: bearing fault, p = 0.93
Fig. 3 — Illustrative: why a model flagged a bearing fault. Left, the input signal and how much each time range contributed. Right, the same decision broken down by input feature.

§4Who we work with

Teams with a hard problem and no deep learning group.

Companies

Engineering, manufacturing, finance and healthcare teams whose data off-the-shelf models handle poorly. You bring the domain knowledge; we bring the architecture, the deployment and the explanation, and leave your team able to run it.

Research laboratories

Labs with new instruments or unusual datasets that need models built around their measurements, with methods documented well enough to publish and results that hold up to review.

§5Problems we take on

Data that general-purpose models handle poorly.

FieldProblemTypical data
Industrial engineeringDetect faults in rotating machinery before they cause downtimeVibration signals, thermal images, maintenance logs
Life sciencesClassify cell states and structures from new microscopy setupsHigh-resolution images with few labelled examples
Physical sciencesFast surrogate models that stand in for slow simulationsSimulation outputs and experimental measurements
Finance and insuranceRisk scores that can be explained, decision by decisionClaims, transaction and account histories

§6Company

Founded by researchers who wanted their models used.

Based in
Zurich, Switzerland
Founded
2024
Team
12 people, with master's degrees and PhDs in mathematics, physics and bioinformatics
Investors
investors@gradient-ascend.com
Hiring
3 open roles, hybrid or remote

§7Contact

Ascend with us.

Tell us what you want to predict, detect or understand, and what data you have. A few sentences are enough.

Send an enquiry