Pangram builds AI detectors to tell human writing from machine writing
Pangram was founded about three years ago, not long after ChatGPT's launch upended what it meant to write, and to know whether a human had written something. The company's mission was narrow and urgent: build AI detectors good enough to tell human text from machine text, at a moment when that line was disappearing fast.
Under the hood, a Pangram detector isn't so different from the models it's trying to catch. "These are just, like, very similar to large language models in the way they work," says Bradley Emi, Pangram's CTO and co-founder. "They're transformer, deep learning-based architectures that we fine-tune ourselves to be able to do a really good job of differentiating human and AI text." And like any large language model, that meant one thing above all: Pangram needed a lot of compute, and a lot of data, to train them.
At the time, the company was three people. There was no infrastructure team, no ML-ops function, no one whose job it was to keep GPUs fed and healthy.
The problem: managing their own GPU cluster was eating up engineering time
Before Lightning, Pangram ran its training jobs on a cluster of AWS servers the team had assembled and configured themselves, using Slurm, a scheduling tool academic labs have relied on for decades to line up jobs across shared machines. "That was just super unwieldy to manage," Bradley recalls.
The friction wasn't dramatic, it was death by a thousand small cuts. Every time the team needed more compute, they had to file a quota request and wait. The network file system they'd wired up to move data between machines kept breaking, lagging, quietly corrupting their pipeline. "AWS just really isn't set up very well for startups," Bradley says. "There are so many different settings and different options and configurations that you just don't need, or even need to think about. Getting to the solution you want is so unnecessarily complicated."
For a three person team trying to out-build models that were themselves evolving weekly, every hour spent setting up their infra was an hour not spent on the actual problem.
Switching to Lightning AI's Studios for on-demand GPU access
Bradley had used PyTorch Lightning at a previous job, and that familiarity led him to Lightning AI's Studios, a cloud-based ML training environment that gives teams on-demand or reserved GPU clusters without having to build any of the underlying infrastructure themselves. The team started on Lightning's Pro plan, then moved onto a startup-friendly plan as the company grew.
"It was a super easy way to onboard, get started, get the compute that we needed," Bradley says, "and honestly, also just bypass a lot of the work that a full-on ML infra training team usually provides."
As Pangram's models grew, so did what they asked of their compute. The team started out training on a single A10G GPU. Today, they train on clusters of 8xH100s, and lease dozens of GPUs from Lightning on a reservation basis, a scale-up that happened without anyone at Pangram becoming, by trade, an infrastructure engineer.
Scaling from 3 to 25 people without an infrastructure team
Three years later, Pangram has grown to 25 people, about half of them working directly in Lightning day to day. The workflow is straightforward to describe and relentless in practice: gather and synthesize training data, ship it to the cluster, train for three or four days, then run it through rounds of evaluation, sign-off, and QA before a new detector goes live.
As Pangram's heaviest training work scaled onto dedicated GPU capacity, the team built its own system for moving datasets between environments, an artifact system backed by S3, to keep pace with a workflow that had always just worked inside Lightning.
Some of Pangram's heaviest runs today move through a dedicated Lightning AI data center, while Studios continues to handle data preparation and give the team on-demand overflow capacity whenever they need to burst beyond it. Evaluation and QA happen across both environments before new detectors ship to Pangram's own serving infrastructure. Team members also spin up quick Streamlit demos or Claude-built web apps within Lightning Studios to share results with each other, the kind of informal show-and-tell that a fast-moving research team relies on.
The results: 2-3 engineering years and 50-60% in compute costs saved
The engineering time that freed up adds up fast, "In a parallel universe in which we didn't have Lightning, we probably would have had to just hire an ML engineer for the last 3 years to be full-time managing our infra," he says. "I'd say it's probably saved us 2-3 engineering years."
The savings show up in the compute bill, too. By moving heavy training workloads onto dedicated GPU capacity rather than buying equivalent power on AWS, Bradley estimates Pangram is saving 50-60% on compute costs, a meaningful number for a startup that has to make every dollar of runway count. "We're very price sensitive on GPUs," he says. "For startups, it's so important. You don't just have all this cash sitting around."
Bradley also points to the responsiveness of the people behind the platform. "The support from the team has been top 1% in terms of all of our vendors," he says of Lightning’s team. "Everyone's super responsive and always very helpful." For a lean team without the luxury of waiting days for answers, that kind of support has mattered as much as the compute itself.
Letting engineers focus on AI detection instead of infrastructure
All of this has led to Pangram’s recent milestone. In July 2026, Pangram raised $9 million in a round led by Menlo Ventures, bringing the company's total funding to nearly $13 million. The round coincided with the launch of Pangram 4, the company's most accurate text detector to date, and Pangram Image, a new tool for detecting AI-generated images, now in research preview.
The teams moving fastest aren't necessarily the ones with the most engineers. They're the ones who've figured out how to spend their engineers' time on the actual problem. Pangram went from 3 people to 25 without ever building an infrastructure function, freeing that time for years of work that went straight into better models instead.
"We're constantly running new experiments," Bradley says. "I think one of the benefits of being a startup is that we can experiment really rapidly." That's the quieter lesson underneath the story of a company built to detect machines: the fastest way to compete with fast-moving AI is to remove everything standing between an idea and the next experiment.
