We use deep learning where it earns its compute bill. Where it doesn't, a simpler model wins.
Neural networks are the right tool for images, audio, text and some sensor data. For a table of customer attributes they often aren't. We decide which you have with a baseline before anyone reserves a GPU.
Cloud endpointGPU or CPU inferenceEdge deviceon-device runtime
DatabricksSnowflakeAnthropic ClaudeOpenAI API
in short·15-second read
Neural networks are machine learning models built from layers of learned weights, used mainly for images, audio, language, sequences and other unstructured data.
Cohash designs, trains, fine-tunes and optimizes deep learning models in PyTorch, from LoRA fine-tunes of open-weight models to quantized models for edge devices. We compare every network against a simpler baseline and keep GPU spend under control with experiment tracking and budgets.
you probably need this if
GPU bills grow every month and nobody can tie them to an experiment.
A fine-tuned model was never compared with a simpler baseline.
The model is accurate but too slow or too large for the device it must run on.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Neural Networks, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · neural networks3 open
openGPU bills grow every month and nobody can tie them to an experiment.
recurringA fine-tuned model was never compared with a simpler baseline.
blockedThe model is accurate but too slow or too large for the device it must run on.
exposure
Architecture selectionFine-tuning open-weight modelsTraining infrastructureInference optimizationTime series and sensor modelsProtecting model weights
startrehearsehandover
Baseline
Experiment
Optimize
Deploy and monitor
we are here
ready to hand over
The team ships the smallest model that hits the target and can show the numbers behind…
On the gateway the model meets the latency budget, and the accuracy it gave up is…
Baseline and candidate model evaluation report
Training code and experiment tracking history
chapter 01 · where it hurts
Why teams reach out
GPU bills grow every month and nobody can tie them to an experiment.
A fine-tuned model was never compared with a simpler baseline.
The model is accurate but too slow or too large for the device it must run on.
chapter 02 · what we change
How we solve it
Architecture selection
Fine-tuning open-weight models
Training infrastructure
Inference optimization
Time series and sensor models
Protecting model weights
chapter 03 · how it runs
Our approach
Baseline
Experiment
Optimize
Deploy and monitor
chapter 04 · where you end up
What changes
The team ships the smallest model that hits the target and can show the numbers behind the choice.
On the gateway the model meets the latency budget, and the accuracy it gave up is measured.
Baseline and candidate model evaluation report
Training code and experiment tracking history
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
Convolutional networks, transformers or recurrent models chosen for the data and the latency budget, starting from pretrained weights whenever a suitable model exists.
Parameter-efficient fine-tuning such as LoRA, which trains small adapter matrices instead of every weight, so a domain-specific model fits on modest hardware.
Distributed training on Databricks or your cloud, with checkpointing so spot or preemptible GPUs can be used without losing a run, and experiment tracking for every job.
We quantize, distill, prune and export to ONNX, then measure accuracy loss against the original model. A speed gain shouldn't hide a drop in quality.
For vibration, audio and telemetry we try sequence models. We also test them against gradient-boosted trees on engineered features, and the trees often win.
Treat weights as sensitive assets. Keep them in a registry that workloads reach by workload identity, checksum or sign every version, and never copy them to a laptop.
capability 01 / 06in production
Architecture selection
Convolutional networks, transformers or recurrent models chosen for the data and the latency budget, starting from pretrained weights whenever a suitable model exists.
Parameter-efficient fine-tuning such as LoRA, which trains small adapter matrices instead of every weight, so a domain-specific model fits on modest hardware.
Distributed training on Databricks or your cloud, with checkpointing so spot or preemptible GPUs can be used without losing a run, and experiment tracking for every job.
For vibration, audio and telemetry we try sequence models. We also test them against gradient-boosted trees on engineered features, and the trees often win.
Treat weights as sensitive assets. Keep them in a registry that workloads reach by workload identity, checksum or sign every version, and never copy them to a laptop.
We pieced these together from Neural Networks situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Fine-tuning a 70B model to sort product reviews
composite · not a client story
Beforethe situation
A team with GPU budget wants to fine-tune a large open-weight model to sort product reviews into 30 categories. They have about 20,000 labeled reviews. Nobody has built a baseline.
What we dothe work
We begin with TF-IDF and logistic regression, then try a small fine-tuned encoder. Only if neither hits the target do we LoRA fine-tune a mid-size open-weight model. All three are compared on accuracy, latency and serving cost, and each candidate's license gets reviewed before anyone adopts it.
Afterwhere you end up
The team ships the smallest model that hits the target and can show the numbers behind the choice. If the big GPU run isn't needed, it doesn't happen.
case file 02
Bearing-fault model that must run on a gateway without a GPU
composite · not a client story
Beforethe situation
There's a PyTorch model that picks up bearing faults in vibration data. On a workstation GPU it runs fine. It has to run on an industrial gateway instead, with an ARM CPU and not much memory, and inference has to keep up with the sensor's sample rate.
What we dothe work
We export to ONNX and benchmark latency under ONNX Runtime on the actual gateway. Next comes int8 quantization, then a smaller architecture if needed, with accuracy re-checked on held-out fault data after each step. The artifact we pick is versioned together with its benchmark results.
Afterwhere you end up
On the gateway the model meets the latency budget, and the accuracy it gave up is measured. The next change gets compared against benchmarks stored with the model.
How a deep learning model is trained, compressed and served
Training jobs start from pretrained weights and run on GPU clusters with checkpointing and tracked budgets. The chosen model is compressed, registered under workload-identity access and deployed to cloud endpoints or edge devices.
01 · Inputs
Training dataimages · audio · text · telemetry → GPU training jobs · training set
Pretrained weightsopen-weight models · backbones → GPU training jobs · fine-tune
02 · Training
GPU training jobsPyTorch · LoRA · distributed → Checkpoints · save state→ Experiment tracking · metrics→ Compression · chosen model
Experiment trackingruns · metrics · GPU budget
Checkpointsspot-safe resume
03 · Optimization
Compressionquantize · distill · ONNX → Model registry · register
We don't start a step until the last one has produced something you can check.
step 01
Baseline
A non-neural baseline and a pretrained model, each scored on the same held-out data.
step 02
Experiment
Architectures and training settings tried under a fixed GPU budget, with every run tracked.
step 03
Optimize
The chosen model compressed and tested on the hardware it will run on.
step 04
Deploy and monitor
Serving, monitoring and a retraining plan, with the registry recording which weights are live.
you keep
What you're left with
We write these for your Neural Networks setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
design01
Baseline and candidate model evaluation report
yours to keep
code02
Training code and experiment tracking history
yours to keep
design03
Optimized model artifacts with accuracy and latency benchmarks
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
Deep learning engineer
Machine learning engineer (PyTorch)
GPU training infrastructure engineer
MLOps engineer
Data scientist
due diligence · neural networks
Questions to ask any partner, including us.
Put these to anyone bidding on your Neural Networks work. The ones who've done it answer differently from the ones who've read about it.
Q1
Which simpler model did you compare against, and by how much did the network win?
On tabular data, gradient-boosted trees often beat deep learning. If the network isn't clearly ahead, you'd be paying to run something harder for nothing.
Q2
How will you cap GPU spend while experimenting?
Training runs quietly overshoot budgets. Ask how spend limits are set, how experiments are tracked and whether idle clusters shut down automatically.
Q3
What license does each pretrained model carry, and does it cover our use?
Open-weight licenses differ a lot. Some limit commercial use, user counts or fields of use, and that has to be settled before a product depends on the model.
Q4
How much accuracy do we lose after quantization?
Quantizing cuts latency and memory, but rare classes usually take the hit. Measure it on your own hardware and your hardest cases.
Q5
Who can download our trained weights, and would we know if they leaked?
If weights trained on your data get out, the data can go with them. Ask for registry access controls, signed versions and download logs at the very least.
01Do we need our own GPUs?
Usually not. Cloud GPUs on demand, or through Databricks, cover most training. We'd only look at owning hardware with a steady, heavy training load or strict data residency rules.
02Should we fine-tune a model or just prompt a hosted one?
Try prompting first. Fine-tune when you need consistent output on one narrow task at high volume, or lower latency or cost than a large hosted model gives you. Or when the model has to run entirely inside your environment.
03Can we use open-weight models commercially?
Often, but licenses differ. Some open-weight models use permissive licenses such as Apache 2.0, while others add use restrictions or conditions. We review the license for each model before it's adopted.
04How do we protect a model we trained?
Keep weights in a registry and give access only to the training and serving workloads that need them. Sign or checksum each version and log every download. If weights trained on your data get out, that data can leak with them.
05Can you make an existing model faster or cheaper to serve?
Often. Export to ONNX, quantization, request batching and distillation into a smaller model are the usual options. We benchmark each on your hardware and test set, then pick the one with an accuracy cost you can accept.
related
Often paired with
Projects on Neural Networks usually end up touching one of these, so they're worth a look.
