-
-
MechaDetect
-
Web design
-
Authentic image test result
-
AIGC image test result
-
Our model architecture
Inspiration
As AI-generated images become increasingly widespread, online platforms face a growing challenge: reliably detecting AI-generated content (AIGC) at scale.
Traditionally, detection models are run on the server side. As platforms grow and moderation demands increase, the computational resources required for detection must scale alongside them. We wanted to explore a different approach: running AIGC detection directly on the user's device.
By moving inference to the edge, the workload can be distributed across users' local hardware rather than concentrated in data centres. This approach also offers several advantages:
- Improved privacy: Images never need to leave the user's device during detection, providing stronger privacy assurances at a time when public trust in AI systems remains limited.
- Reduced server-side compute: Platforms can perform large-scale moderation without proportionally increasing their inference infrastructure.
- Lower infrastructure pressure: Reducing reliance on centralised compute can help lessen some of the physical and environmental constraints associated with the continued expansion of data centres.
MechaDetect is a family of models that prove accurate AIGC detection can be performed locally without sacrificing accuracy or user experience. They have class-leading performance at just 25.1M and 89.4M parameters respectively for the MechaDetect Quark and Atom families.
What It Does
For our project demonstration, we have created a website that uses WebGPU and WebAssembly to run AIGC detection entirely on the user's device using our models.
The server performs zero compute for AIGC inference. Instead, the model runs locally in the browser and typically completes inference in under 500 ms even on relatively low-end hardware, while maintaining strong detection accuracy.
This demonstrates that AIGC detection can be moved from centralised servers to user devices while remaining fast, practical, and accurate.
How We Built It
MechaDetect is based on a DINOv3 Vision Transformer and was trained using approximately 87.8k samples.
Our training pipeline consisted of several stages.
Stage 1 — Initial Training
For the first stage, we trained the teacher model for one epoch.
During this stage:
- The ViT backbone(DINOv3 ViT-H+/16) was frozen.
- Only the classification layers were trained.
- Images were kept clean, with no additional transformations applied.
This allowed the model to first learn the basic distinction between AI-generated and non-AI-generated images.
Stage 2 — Robustness Training
For the second stage, we trained using the dataset with the backbone unfrozen.
We introduce transformation pairs, allowing the model to learn that transformed versions of the same image should retain the same classification. Training combined classification on the original and transformed views with prediction consistency and feature consistency losses. A confidence-gated exponential moving average provided an additional consistency target.
This helped improve robustness against common image transformations such as compression, resizing, and other modifications that images may undergo after being uploaded or shared online.
Teacher–Student Distillation
The resulting teacher model contains approximately 872.6 Million parameters.
While this larger model provides strong performance on desktop-class machines, it is far too computationally expensive for practical inference on devices such as phones. We therefore used knowledge distillation to transfer its behaviour into a significantly smaller 25.1-million-parameter(ViT-S/16) and 89.4-million-parameter(ViT-B/16) student models.
The Atom and Quark family of models are designed to fit various deployment targets on the edge.
Adversarial Transformation Training
After distillation, we performed additional adversarial transformation training focused on the model's weaker cases.
The goal was to reduce performance differences between different image domains and improve robustness when inputs had been transformed or degraded.
Challenges We Ran Into
1. Building a Representative Dataset
One of our first major challenges was dataset curation.
Early versions of the model achieved more than 95% recall on AIGC images, but less than 70% recall on non-AIGC images. We eventually discovered that our original dataset did not contain enough variety in its human-created images.
For example, the model frequently classified the following as AI-generated:
- 3D renders produced using software such as Blender or CAD tools
- Screenshots from video games
- Images taken using webcams
- Images from lower-quality phone cameras
A major reason for this behaviour was that much of our original human-image dataset consisted of photographs taken using professional cameras. As a result, the model sometimes learned to interpret noise, compression artefacts, and characteristics of lower-quality cameras as indicators of AI generation.
Finding suitable datasets was also difficult. Many datasets published after 2020 do not explicitly label whether images are AI-generated or human-created, particularly datasets containing uncommon scenarios and edge cases.
This experience showed us how strongly model performance depends on the diversity and quality of the dataset.
2. Limited and Unreliable Compute
Our second major challenge was infrastructure.
Because we chose a relatively complex architecture and training pipeline, we required a significant amount of GPU compute, more than our desktop-class gaming PCs could provide.
The GPU cluster we originally built and intended to use became unoperational, forcing us to rent compute from third-party platforms such as Vast.ai.
Working through rented and sandboxed environments introduced several difficulties:
- Limited direct access to the underlying hardware
- Network and firewall restrictions
- Difficulties accessing some remote instances
- GPU configurations that occasionally differed from what had been advertised
- Reduced reliability during long training runs
These issues significantly slowed our iteration speed and made experimentation more difficult.
3. Learning While Building
Most of our team entered university as hobbyists or technology enthusiasts rather than experienced machine-learning researchers.
As a result, understanding some of the technical concepts involved in model training, optimisation, and infrastructure was itself a major challenge.
While we were able to understand many concepts at a high level, relying on AI agents for lower-level implementation frequently created new problems.
For example, AI agents sometimes struggled with:
- Accessing and configuring remote training instances
- Optimising training parameters for efficiency
- Maintaining compatibility between different environments
- Producing code that was easy to understand and debug
- Following an existing technical plan without unexpectedly changing direction
Although this occasionally led us down dead ends, the experience ultimately taught us how important it is to understand the systems we are building rather than relying entirely on abstraction.
Accomplishments We're Proud Of
Considering that our team started with relatively little experience in this field, we are extremely proud that we were able to produce a working family of models.
Our largest teacher model achieves performance that is close to perfect in the demo eval set, while our smaller student models perform almost as well, and in some cases, better, with a fraction of the footprint.
We are particularly proud that our models retains almost all of its accuracy even after common image transformations are applied, with only a 0.13 and 0.16 drop from clean to transformed image detection AUROC for Atom Super and Quark Super respectively.
Most importantly, we were able to demonstrate that a relatively small model can perform practical AIGC detection directly inside a browser without requiring server-side inference.
What We Learned
Novel Does Not Always Mean Better
One of the first lessons we learned was that trying something new does not necessarily make something innovative—or effective.
During early experiments, we used a ViT derived from a more general-purpose vision-language model(Gemma 4 31B). Despite achieving surprisingly good results, it was ultimately unable to match models designed more specifically for visual representation learning, such as DINOv3.
This reminded us that choosing an architecture suited to the problem is often more important than simply choosing something larger or more novel.
More Compute Is Not a Substitute for Better Data
Before entering the hackathon, some of us assumed that strong results could largely be achieved by scaling model parameters and computational resources.
While additional parameters and compute are certainly valuable, we learned that performance is ultimately constrained by factors such as:
- Dataset quality
- Dataset diversity
- Training methodology
- Experimental design
- Experience interpreting model behaviour
More compute can be useful, but it cannot automatically compensate for weak data or poor training decisions. More is not better, but those who are better require more.
Foundational Knowledge Matters
Our third major lesson was the importance of understanding the tools and systems we work with.
As future computing and data science students, we realised that relying too heavily on AI agents and abstraction can increase development speed in the short term, but gaps in technical understanding eventually become bottlenecks.
AI tools are extremely useful for accelerating development, but they are most effective when the person using them understands the underlying code, models, and infrastructure well enough to evaluate their decisions.
What's Next for MechaDetect
Because of the hackathon's rules and the limitations of our own resources, this version of MechaDetect relies primarily on commercially available and open datasets.
For future versions, we would like to curate our own datasets and conduct more controlled experiments to understand exactly which types of training data improve the model and which types reduce its accuracy.
We are also interested in exploring alternative model architectures.
Although this project taught us that architecture and training techniques should not be treated as silver bullets for weaknesses in data or methodology, there is still significant potential to explore models designed for even more constrained hardware.
One long-term goal would be to investigate whether AIGC detection could eventually run on extremely resource-constrained edge devices, such as microcontrollers.
MechaDetect began as an experiment in moving AI detection from the cloud to the edge. Going forward, we would like to explore just how far toward the edge that idea can be pushed.
Datasets used: https://huggingface.co/datasets/zye2/tj-data (full data disclosure and breakdown on github repo)
Log in or sign up for Devpost to join the conversation.