You're pledging to donate if the project hits its minimum goal and gets approved. If not, your funds will be returned.
$22,800 left to reach the funding goal.
I am 16 and I build language models from scratch. JARVIS is my 156-million-parameter model, trained with no pretrained weights. I designed it to save every generation, collects public web data, retrieves evidence, and tests architecture changes. I took it as far as one free Colab T4 GPU (15GB) allowed: 10 generations and 3,520 training steps. Then it ran out of memory.
My question is simple. When a small model looks like it improved, did it learn, or did retrieval, a tool or extra training time do the work? I have the system and a full experiment plan. I do not have the compute to run it.
I did all of this after leaving a 7–8 hour school day and a 3-hour commute for homeschooling in May 2026. In the months since, I finished Harvard’s CS50x, built JARVIS, reported security bugs to Google and Apple, and wrote two research papers. The rest of this page shows how, and what I will do with real compute.
My Goal is to find out if a small model improves more when its training is aimed at the mistakes it actually makes, compared with just training it longer.
I built a model with 12 layers, width 384, 7 experts and a 1,280-byte context. At 156M parameters, weights and optimizer state take about 2.5GB. As I understand it, the rest of the T4’s 15GB goes to activations, which grow with every layer, expert and extra byte of context, because my expert layer runs all experts on every token. When my architecture search tried bigger candidates, they ran out of memory. On a T4 I can test one small candidate at a time, in short runs. I cannot train a baseline and a candidate side by side, and I cannot repeat runs with different random seeds. Colab also disconnects, so I have rebuilt my state from saved checkpoints many times. This experiment needs all of those things.
My plan is
Freeze my Generation 10 model as the starting point, so it is never overwritten.
Test it on a fixed benchmark: arithmetic, science, reading, code, general knowledge, current facts and tool choice. Keep development, validation, regression and final-test sets separate.
For each failure, name the likely cause: missing knowledge, bad retrieval, reasoning, tool choice, unstable training, forgetting, or hardware limits.
Run targeted fixes under the same compute budget as the baseline.
Compare conditions in a 2×2×2 design: parameter update × retrieval × tools. This shows each part’s effect and how they interact. I plan at least 5 random seeds per condition.
Keep a change only if the target skill improves, older skills do not get worse, it fits the hardware, and the data trail is complete.
When I audited my first version (V6), I found two problems. Candidate models trained a few extra steps before being compared with the parent, which is unfair. And my data loader re-reads the whole corpus on every step. V7 fixes both before any experiment runs.
The code, paper and logs are public on GitHub: https://github.com/Aditya-0167/Jarvis-LLM .
Research paper: https://github.com/Aditya-0167/Jarvis-LLM/blob/main/RESEARCH%20PAPER%20JARVIS.pdf
Research paper detailed: https://github.com/Aditya-0167/Jarvis-LLM/blob/main/README-JARVIS_Research_Paper_full_repot.pdf
The experiment runs end to end with frozen benchmarks and fixed budgets, and I publish a clear answer. Yes, no and mixed are all valid answers.
A positive result means targeted learning beats plain continued training on unseen items with retrieval and tools switched off, and older skills stay within a tolerance I set before the run.
I report paired confidence intervals across several random seeds, and I check my automatic scorer by hand on a sample. In an earlier study I found a false positive in my own scorer and fixed it.
Everything is published: benchmark, code, checkpoints, raw outputs and a written report.
My experiment needs a machine I control to break past my current 15GB VRAM ceiling. Each tier below is a complete, working setup utilizing massive hardware headroom.
$7,000 (minimum): MacBook Pro M5 Pro, 64GB unified memory
MacBook Pro M5 Pro, 64GB: about $5,792.80
Taxes: $1,000.
On Apple Silicon, system RAM and GPU VRAM share a single pool through a Unified Memory Architecture. Getting a 64GB pool gives my model over 4x the memory headroom of my current 15GB Colab T4 setup. This gives me the exact headspace I need to scale my context window past 1,280 bytes. I can hold dense activation graphs for multiple random seeds locally without hitting a single CUDA Out-of-Memory failure. I will port my training code straight to Apple’s Metal backend. A laptop runs slower per step than a desktop GPU, but that will not stop me. Putting more time into it is infinitely better than being completely locked out on the free tier.
$9,000+: MacBook Pro M5 Max, 128GB unified memory
MacBook Pro M5 Max, 128GB: about $9,000.
A 128GB unified memory allocation lets the integrated GPU use a massive continuous workspace. This footprint easily beats even a dedicated desktop RTX 5090’s 32GB VRAM limit. This massive memory frontier completely changes my architecture search options. It lets me scale JARVIS candidate mutations all the way up to 1 Billion parameters. I can finally test structural weight internalization at a scale my free T4 cannot run at all.
$13,000+: GPU workstation
If funding reaches $13,000, I will buy the RTX 5090 32GB ($11,374.95) instead of a laptop. It trains much faster and lets me run baseline and candidate experiments at the exact same time.
I need a 128gb (64*2) DDR5 memory kit ($3,686.33), a Samsung 990 pro 4TB NVMe drive ($842.59), and an AMD Ryzen 9 9950X CPU upgrade (about $621.41). I also need a larger power supply (about $400), heavy airflow cooling (about $300), cloud credits ($3,000), and budget for shipping, tax, and import duty (about $2,500). This brings the tier to about $22,725.28.
I already own a Ryzen 5 9600X, an MSI B850 motherboard, 32GB RAM, and a 1TB SSD. I will reuse what is compatible. Any money not spent stays on the same research, and I will publish exactly what I bought and what it produced.
It is just me, working next to my NIOS studies and family duties. Here is how a 16-year-old got here.
I always wanted to know how machines work. As a kid, I took everything apart—first motors, then an old computer. Back in traditional school, my days were packed. A 7–8 hour school day, extra tuition, and a grueling 3-hour daily commute left zero hours to actually build software. So, in May 2026, I took a massive bet on myself. I pulled out to do homeschooling through NIOS. My parents and relatives completely opposed the idea at first. It took me a full month of showing them stacks of research and technical printouts before they finally agreed to let me try
I saved up my allowance for six straight months just to buy parts and assemble my own PC. My old machine was too weak to even boot Windows 11. Right after that, I knocked out Harvard's CS50x in less than two months, wrapping up with a 95% score on June 1, 2026. That same month, I finished two intensive NASA courses: Open Science 101 and Fundamentals of Remote Sensing.
My schedule is pretty intense. I run around helping at our family shop and managing daily household duties during the daytime. My real study block starts late around 9 PM. I grind until my night's unit is totally finished, usually crashing around 1:00 or 1:30 AM to make sure I get enough sleep to stay healthy.
What I built after that, in about four months:
JARVIS. I built it across ten generations: model, checkpoints, lineage tracking and web data collection. I used AI assistants for code and editing, and I take responsibility for all of it. I wrote the V7 experiment plan and a manuscript that separates what I measured from what I only propose. A version is under review at the ARRSI 2026 workshop.
Prompt-injection research. I wrote and ran a 164-trial study on Gemini and found a false positive in my own scorer. Then I built a larger study with 360 cases, six open models and 29,280 outputs.
Security research. I trace deep code paths, find weaknesses, build PoCs, and test them in real environments. For Apple, I learned EXT4, built crafted disk images, and created a macOS crash harness to validate a filesystem vulnerability. Apple reproduced another vulnerability I reported and is fixing there systems and has a planned fix on target for a Fall 2026 release, and has prioritized all my reports for review. I also reported 51 security issues to Google, including multiple P1/P2 findings.
Other work. I launched an homeschooled helper app on Play Store, securing 37% conversion, +224% impressions, & +100% activation growth, and completed the Tata IAM virtual simulation.
Every one of these started with a problem I did not know how to solve, and I learned it by building it.
I don’t plan to fail, and I don’t stop. I have kept going every time something broke. JARVIS started on a free Colab GPU, crashed many times, ran out of memory, and still reached ten generations because I rebuilt it and kept going. This project will get the same effort.
The most likely thing that could slow it down is compute, because my free GPU is too small for the full experiment. That is exactly what this funding fixes. If a run still doesn’t work, I will not give up. I will find the cause, fix one thing at a time, and run it again until I have a clear answer.
Whatever the result, the work stays useful. I will publish the benchmark, the code, every checkpoint and the full results, so other people can build on them. I believe in this project, and I will keep working until it is done.
$0 in grants or donations. I applied to Emergent Ventures for this same hardware and have no decision yet.