PyTorch & TensorFlow
When LLMs aren't the right tool — and there are still plenty of cases where they aren't — we reach for PyTorch or TensorFlow. Time-series forecasting, computer vision at edge-device latency budgets, recommendation systems trained on private signals, predictive maintenance models that need to generalise across thousands of devices. PyTorch is our default for new model work (the research ecosystem moves there first, the API is more pleasant) but we work with TensorFlow when a client's existing ML pipelines are already built on it. Both run cleanly through SageMaker, Vertex AI, or our own infrastructure depending on the client's cloud.
What you get
Real examples
Predictive maintenance for industrial equipment
Illustrative scenario: an Australian manufacturer needs to predict equipment failure 72 hours in advance from sensor data. PyTorch LSTM trained on historical failure events, deployed via TorchServe behind a real-time inference API. ~85% precision on the held-out test set; 72-hour prediction window in production.
Computer vision at edge latency budgets
Illustrative scenario: a manufacturer's inline quality inspection needs sub-100ms inference at the line. Trained custom YOLO variant in PyTorch, exported to ONNX, deployed on an edge device running TensorRT. Catches defects at line speed with no cloud round-trip.
Migrating TensorFlow 1 models to modern infrastructure
Illustrative scenario: a client has TF1 models running in a fragile production pipeline. We migrate to TF2 (or PyTorch where it makes sense), retrain with their full updated dataset, redeploy on SageMaker with versioning + monitoring. The legacy maintenance burden goes away.
Common questions
When do you NOT use an LLM and reach for PyTorch / TensorFlow instead?
Five scenarios. Time-series forecasting (LLMs are bad at this). Strict latency budgets under 100ms. Models that need to run on edge devices without cloud connectivity. Cases where training data is small but specific (a tuned classifier on 5K labels often beats an LLM with prompt engineering). Recommendation systems with private signal data. In all five, building a focused model is cheaper, faster, and more accurate.
PyTorch or TensorFlow?
PyTorch for new model development — the research ecosystem is there, the API is cleaner, the debugging story is better. TensorFlow when the client's existing infrastructure runs on it and migration cost outweighs the benefit. Both produce production-ready models when paired with the right deployment infrastructure.
How do you avoid LLM-flavoured hype-chasing on custom ML projects?
Brutally. The first question is always: 'Is there an LLM that already solves this acceptably?' If yes, use it. If no, then we scope a custom model. We've turned away a few engagements where the client wanted custom ML but an off-the-shelf LLM would have solved it for 10× less.
Do you handle the data engineering too?
Usually yes. Training data prep is half the work of any custom ML project — feature engineering, label quality, train/val/test splits, drift detection. We typically pair the modelling work with the data infrastructure work since they're inseparable in practice.
What about model serving and monitoring?
Default to SageMaker or Vertex AI for hosted clients, TorchServe + custom monitoring for self-hosted. Monitoring includes accuracy drift, latency, throughput, and feature distribution shift — all of which need to be in place before launch, not bolted on after the first incident.
Ready to get started?
Tell us about your project and we'll tell you honestly how we can help.
Get in Touch