πͺ
RDTvlokip PRO
AI & ML interests
Recent Activity
Organizations
Straight answer to your question first: the absolute-threshold variant (Focal) is per-token with no global budget, depth is emergent, and on real text ~86% hit the R=4 ceiling anyway. That arm can't be cleanly matched, you're right.
But the percentile variant (Nomade) already is a fixed budget by construction. q=0.3 freezes the 30% least-uncertain active tokens every iteration, which gives a deterministic depth cascade (β30 / 21 / 15 / 34% to full depth) independent of the data. q is the passes-per-sequence knob you're asking for.
So the clean ablation falls straight out of that, exactly as you're framing it:
- Entropy arm: percentile q=0.3, freeze the lowest-entropy 30% each iteration.
- Random arm: freeze a random 30% each iteration.
Same q β identical depth distribution β identical pass budget. The only thing that differs is which tokens spend it. Any remaining gap is the selection signal, cleanly isolated, no confound from freeze count.
And it's a tiny change: swap the entropy-quantile mask for a random mask at the same fraction, same seed, same harness. That's article 4's core experiment now, matched-budget, selection is the only free variable.
Thanks you turned a vague "entropy vs random" into a properly controlled one. (Pending the hardware fix, but the design is locked.)
I can't finish validating them, because my PC won't stay on.
The last honest step was simple: rerun the three looped models on two more seeds, so I can report variance instead of a single lucky run. 8 runs, ~50 hours overnight. Routine.
Except mid-training, the whole machine freezes solid. Screen black, RAM still lit, power button dead, I have to cut mains power at the wall. No blue screen, no crash dump. Just a dead PC that's still powered.
The event logs tell the story: repeated NVIDIA driver errors (nvlddmkm 153, 4101) building up for days, even at idle, at 1am, with nothing running, then Kernel-Power 41 with no bugcheck. A 2017 GTX 1080 Ti fighting a 2026 driver that's known to be rough on Pascal cards.
Out of 8 planned runs, the machine survived exactly two. So the results stay exactly what I called them: preliminary, one seed. A crash is not a data point.
The frustrating part isn't the bug. It's that the science is clean and the code is ready, the only thing missing is a machine that survives a night.
The plan: roll back the driver, rent cloud GPUs (Lambda Labs) to finish the seeds, and long-term, build a rig that can actually sustain solo research. If you've beaten Kernel-Power 41 on a Pascal card or want to support the work. I'm genuinely open to it.
Solo ML runs on whatever hardware you can reach. Right now mine is a 2017 card that won't stay awake.
Full write-up π
π https://huggingface.co/blog/RDTvlokip/the-hardware-wall-kernel-power-41
Good catch. The ablation is clean and I hadn't run it. Maybe I'll add it to article 4 stochastic depth vs entropy halting, same harness, same protocol.
Hey, thanks for the feedback, everything you raise is already addressed in the article:
- **Confirmation bias / "8-prompt spectacular":**dedicated section "Didn't you first report much bigger gains?", the 8Γ80 results are explicitly disclosed and corrected to 50Γ200, both sets of numbers visible.
- Seed band: bolded disclaimer in the intro, repeated in limitations and conclusion: 1 seed, variance not controlled.
- Halting on the 50-prompt rerun: dedicated Q&A: "Your adaptive halting barely fires at generation time. So what did it actually do?"
Worth a read before commenting.
After proving last time that architecture is a threshold, not a lever, I got stubborn: could I change how the model learns? Four honest attempts, Lion, a sharper AdamW Ξ²2, multi-token prediction, LayerScale. Four failures. The bottleneck wasn't the learning rule either.
So I changed the shape of the computation instead: loop the same transformer blocks 4Γ, deeper reasoning, zero added parameters. It beat the baseline on perplexity, the first thing in the whole project to move that number. Then I added my own twist: let each token decide how deep to think, halting on its own entropy.
My first evaluation was spectacular. Coherence up 65%. Hallucinated names down 62%.
It was noise.
Eight prompts, one seed. I re-ran on 50 prompts Γ 200 tokens and watched the gains shrink to "modest" and on out-of-domain prompts, recurrence actually made things worse. No universal winner. And none of it is new: it's Adaptive Computation Time (2016), the Universal Transformer (2018), and LoopViT (2026), recombined and measured honestly.
The real lesson:
A number from 8 prompts is a rumor. The eval harness that kills your own best result is worth more than the result it kills. Cite your lineage. Stay preliminary until multiple seeds say otherwise.
The three models are live. The write-up is honest about every caveat π
π https://huggingface.co/blog/RDTvlokip/teaching-a-15m-french-llm-to-think-deeper
The runner-up at 0.39 is the tell. A 0.6 pick reads decisive until you see the model was one sample away from a completely different sentence. The chosen-prob view collapses that fork into a single number; the full distribution is where the hesitation actually lives. We agree there.
Your cross-turn rung is the one I underweighted, and you're right. In a single generation the worst case is a bad sentence. Across turns, the bug is in the gap, the state you assumed propagated versus what actually did. The failure isn't in any frame, it's in the cut between two.
To your real question, does any layer never lie? My honest answer: no single layer is fully honest, but the disagreement between two adjacent layers is. A clean rendered string over an exploded distribution. A confident chosen-prob over a runner-up that's nearly tied. Carried state that doesn't match assumed state. Every bug I've actually caught lived in a mismatch between two representations, never in one read alone.
So I've stopped looking for the truthful layer and started diffing adjacent ones. The signal isn't in any rung of the ladder, it's in the rungs not agreeing. The lie is always at a seam.
That's literally how I caught a decoding setting gaming my own metric: coherence looked great, but the model's self-perplexity on its own output had jumped. Neither number was "the truth." The gap between them was.
For me it's the per-token probabilities of the generation, not the tokens themselves.
When an eval looks clean but feels off, the text reads fine and the ids look fine, so the bug isn't what was generated, it's how confidently. I pull the prob of each chosen token. A model that's quietly broken (or being pushed by a bad sampling setting) shows it there first: long stretches of very low-confidence picks the surface text hides, or suspicious spikes where it's locked onto one path.
That's actually how I caught one of my decoding configs gaming a metric, coherence looked great, but the self-perplexity of the model on its own output had jumped. The rendered text was smooth, the model itself "disagreed" with what it had written. The confidence signal exposed it before any human read-through would have.
So my order is: rendered text β raw ids β per-token confidence. Each layer is less lossy than the one above it. Your truncated-JSON case is the same shape, the rendered transcript is the most lossy view of all, and the thing that actually fired lives one layer down.
What about you, when the id stream looks clean too, do you go to logits, or somewhere else entirely?
Diffing the real input_ids against what you think you sent is the move. That's literally how I found it, printed the actual ids, saw a 3 (my `) sitting at the end where I expected my last content token. Two tokens I never typed, exactly.
To your question: I log raw ids on every eval run now, not just when something looks off. Cheap insurance. The whole reason this bug survived so long is that the symptom (drift) and the trigger (<eos>) live in different representations, one in the decoded text, one in the id stream. If you only inspect the layer where the symptom shows up, you never see the cause. Logging both by default means the next invisible-token bug shows up in the diff before I waste a day blaming sampling.
The rule I took from it: never debug a generation issue from the decoded string alone. The string is lossy skip_special_tokens=True hides the exact thing that's breaking you.
Exactly. Once the architecture clears the threshold, it stops being the lever and we keep tuning it out of habit because it's the part we can see.
The one that surprised me most wasn't even a hyperparameter. It was a single trailing <eos> token on the prompt.
My model kept "drifting", prompt about one town, output about a completely different one. I spent ages blaming the # heading token, the sampling, the data. Turns out encode(add_special_tokens=True) was appending <eos> to the end of the prompt. The model, trained on packed documents, read that as "this document is finished" and helpfully started a brand new one. The was invisible in the decoded output, so I never saw the actual trigger.
Strip the trailing <eos>, and the "drift" was just... gone. No architecture, no retraining. One token.
Your deepcopy-in-the-hot-path story is the same shape, the bug hides in the layer nobody inspects because it "obviously can't be that simple." It always can.
After building it from scratch (custom crawler, BPE, LLaMA-style arch, 3-phase trainer), the model wrote perfect French but hallucinated facts and drifted off-topic. So I went hunting for the bottleneck, convinced it was the architecture.
It wasn't. It never is.
The wins came from boring places: a data pipeline that cut documents mid-sentence, two special tokens silently sabotaging generation, and one decoding hyperparameter that doubled coherence (38 β 76 tokens before drift). The flashy research, contrastive decoding, DoLa, gave the smallest gains. One of them was even a false negative caused by my own buggy eval harness.
The real lesson isn't about French LLMs:
Architecture is a threshold, not a lever. Once you clear it, the bottleneck is everywhere except the architecture. Measure first. Read your own data. Verify your code before you trust your conclusion.
The model was never the problem.
Full write-up here π
π https://huggingface.co/blog/RDTvlokip/what-i-learned-optimizing-a-15m-french
I'm at Station F at My booth with GOSIM Paris 2026 today & tomorrow.
Come meet me for a live in-person demo and a chat !
4 months building the dataset before even touching the model. Custom crawler, custom extractor, custom BPE tokenizer, everything from zero. Then the architecture β RoPE, RMSNorm, SwiGLU, Flash Attention. Then a 3-phase trainer. Then debugging a causal mask bug that made the model generate "Γ―sΓ―sΓ―s" for hours.
Then the power went out at epoch 10/18.
The checkpoint survived. The model learned form perfectly β grammar, markdown, structure. Substance? Still working on it. Honest conclusion.
Full write-up here π
π https://huggingface.co/blog/RDTvlokip/i-trained-my-own-french-llm-from-scratch
For years, robotics has been locked behind high prices and complex systems.
So we decided to change that.
Today, weβre open-sourcing Ark-Bot β a fully 3D-printed, 6-DOF robot arm that works seamlessly with our Python robotics library, Ark.
And yesβ¦ Itβs only Β£215.86 to build.
π§ ArkBot Specs π§
1οΈβ£ Reach: 1 meter
2οΈβ£ Weight: 2.6 kg
3οΈβ£ Payload: 1.8 kg πͺ
4οΈβ£ DOF: 6
5οΈβ£ Input Voltage: DC 12V
π€Fully 3D-printable & open-source
π€Integrated with Ark β no ROS required
πΉ Weβve also released a video showing the full assembly process β because robotics should be something everyone can learn, build, and improve on.
π©βπ With Ark-Bot, anyone β from students to AI researchers β can experiment with embodied AI, robot learning, and control algorithms on real hardware, affordably.
If you could control a 1-meter robot arm from your laptop for under Β£220β¦
π What would you build first?
πhttps://github.com/Robotics-Ark/ark_bot
π₯ https://www.youtube.com/watch?v=Kuk4pC0EaEw&feature=youtu.be