When Do We Need On-Policy Distillation? Distilling on Offline Student Rollouts Is Often Better
Paper • 2610.11291 • Published • 10
ZeroGPU Explorers
community
AI & ML interests
None defined yet.
Recent Activity
View all activity
BK-Lee
authored a
paper about 9 hours ago
BK-Lee
authored a
paper 6 days ago
Post
152
We're super excited to introduce security-one: our open-weight model for security decisions.
Designed to:
✅ Run 24/7
✅ Assess signals across apps, agents and infra
✅ Return structured probabilities to guide routing
✅ Route suspicious events to stronger models/humans
superagent-ai/security-one-27b
Designed to:
✅ Run 24/7
✅ Assess signals across apps, agents and infra
✅ Return structured probabilities to guide routing
✅ Route suspicious events to stronger models/humans
superagent-ai/security-one-27b
- 1 reply
BK-Lee
authored a
paper 11 days ago
Post
3498
I made a 1.1M ModernBERT encoder play Doom in real time on a CPU
Some time ago, VAGO Solutions released SauerkrautLM-Doom-MultiVec-1.3M, a tiny model trained to play Doom Defend the Center scenario from 31k human gameplay examples.
My first thought: cool! I love both Doom and Small Language Models.
Then another idea: I bet I can do better :-)
What I did?
- evaluated the original model and found it's better than reported
- changed a bit the architecture
- generated SFT data with a scripted oracle
- SFT + PPO refinement on consumer hardware
Got a smaller, faster and killer model
Can even fit a floppy with int8 quantization 💾
Watch it play/read the article: anakin87/tiny-doom-defender
Some time ago, VAGO Solutions released SauerkrautLM-Doom-MultiVec-1.3M, a tiny model trained to play Doom Defend the Center scenario from 31k human gameplay examples.
My first thought: cool! I love both Doom and Small Language Models.
Then another idea: I bet I can do better :-)
What I did?
- evaluated the original model and found it's better than reported
- changed a bit the architecture
- generated SFT data with a scripted oracle
- SFT + PPO refinement on consumer hardware
Got a smaller, faster and killer model
Can even fit a floppy with int8 quantization 💾
Watch it play/read the article: anakin87/tiny-doom-defender
ZeroGPU clone fails during tensor packing with Errno 28 — 82.1 GB pack target
1
#185 opened about 1 month ago
by 
Thananon
All ZeroGPU Spaces stuck on "Starting" with clean logs — CPU and paid GPU unaffected
👍 2
4
#183 opened about 2 months ago
by 
luna0805
BramVanroy
posted an update 2 months ago
Post
2808
**I benchmarked HF buckets against https access for Common Crawl.**
Took me a while to get round to do this but I benchmarked access to Common Crawl via https vs hf buckets. Both experiments were run at night in Europe. I do not think other hardware problems were impacting the speeds since CPU processing time of the non-download pipeline components were highly similar (within 2% identical) and below only the WarcReader speeds of datatrove are used.
Experiment: selected 5 disjoint samples of 64 files each (randomly from the latest crawl; 20,499 docs/file). Those five batches were then processed by 32 single-core tasks with 4GB/core (five batches to calculate CIs). Paired experiment between using https and hf bucket.
- https: 40.0 [39.3-40.6] (seconds per WARC file)
- hf bucket: 172.0 [122.7-221.2]
That is a difference of about 4x in streaming speed. You'll see that https is also more stable (smaller CI).
I also ran raw throughput tests to the endpoints to measure rate limiting (64MiB transfer at 8/32/128/256 concurrent readers) and rate limiting seems not an issue for either: at any of those parallel reader numbers, their respective speeds stay about the same.
Note that, given CC scale, this is still a small test. Rate limiting may become more obvious when processing a full crawl. I do not know whether the https endpoint vs HF bucket will shut you out earlier with which limits.
Took me a while to get round to do this but I benchmarked access to Common Crawl via https vs hf buckets. Both experiments were run at night in Europe. I do not think other hardware problems were impacting the speeds since CPU processing time of the non-download pipeline components were highly similar (within 2% identical) and below only the WarcReader speeds of datatrove are used.
Experiment: selected 5 disjoint samples of 64 files each (randomly from the latest crawl; 20,499 docs/file). Those five batches were then processed by 32 single-core tasks with 4GB/core (five batches to calculate CIs). Paired experiment between using https and hf bucket.
- https: 40.0 [39.3-40.6] (seconds per WARC file)
- hf bucket: 172.0 [122.7-221.2]
That is a difference of about 4x in streaming speed. You'll see that https is also more stable (smaller CI).
I also ran raw throughput tests to the endpoints to measure rate limiting (64MiB transfer at 8/32/128/256 concurrent readers) and rate limiting seems not an issue for either: at any of those parallel reader numbers, their respective speeds stay about the same.
Note that, given CC scale, this is still a small test. Rate limiting may become more obvious when processing a full crawl. I do not know whether the https endpoint vs HF bucket will shut you out earlier with which limits.
gsarti
authored 5
papers 3 months ago
Beyond the Commitment Boundary: Probing Epiphenomenal Chain-of-Thought in Large Reasoning Models
Paper • 2606.13603 • Published
Distilling Formal Logic into Neural Spaces: A Kernel Alignment Approach for Signal Temporal Logic
Paper • 2603.05198 • Published
Bridging Logic and Learning: Decoding Temporal Logic Embeddings via Transformers
Paper • 2507.07808 • Published
Predicting Future Behaviors in Reasoning Models Enables Better Steering
Paper • 2606.11172 • Published • 1
Interpreto: An Explainability Library for Transformers
Paper • 2512.09730 • Published • 1
yuanshengni
authored 2
papers 3 months ago
szymanowiczs
authored 3
papers 4 months ago
BK-Lee
authored a
paper 4 months ago
BK-Lee
submitted a
paper to Daily Papers 4 months ago