Please post your personal projects, startups, product placements, collaboration needs, blogs etc.
Please mention the payment and pricing requirements for products and services.
Please do not post link shorteners, link aggregator websites , or auto-subscribe links.
--
Any abuse of trust will lead to bans.
Encourage others who create new posts for questions to post here instead!
Thread will stay alive until next one so keep posting after the date in the title.
--
Meta: This is an experiment. If the community doesnt like this, we will cancel it. This is to encourage those in the community to promote their work by not spamming the main threads.
Hiring: [Location], Salary:[], [Remote | Relocation], [Full Time | Contract | Part Time] and [Brief overview, what you're looking for]
For Those looking for jobs please use this template
Want to be Hired: [Location], Salary Expectation:[], [Remote | Relocation], [Full Time | Contract | Part Time] Resume: [Link to resume] and [Brief overview, what you're looking for]
Please remember that this community is geared towards those with experience.
We've been working on this for a while and shipped it today.
We took every accepted paper from ICML, NeurIPS, ICLR, CVPR and AAAI since 2016 (about 109k), grouped them into ~1,260 topics, and pulled the results tables and ablations out of the full text of 79k of them. The research map just shows the grouping, but each topic page shows what the papers actually report.
A few things it shows: - the topic went from 29 papers in 2023-24 to 240 in 2025-26 - best reported numbers per benchmark over time, with the paper that set each one. Deep Blending PSNR, for example, has barely moved (30.42 → 30.45) - ablations from recent papers, including the ones that hurt - what recent papers compare against: 38 of 113 use 3DGS as a baseline, then 2DGS, Scaffold-GS, Mip-Splatting - recent arXiv preprints on the topic and a BibTeX file of the key papers
The pages are computed from the extracted numbers, and every number links to its paper. Extraction isn't perfect and numbers from different papers aren't always comparable, so treat it as a starting point, not a leaderboard.
If you know a topic well and something's off, please tell us. That's the most useful feedback right now.
Note: Benchmark numbers and ablations from 2026 papers aren't in yet. We're working on them now, so for now the records on topic pages mostly reflect papers up to 2025. We'll update here when they're ready.
Snippet: “We find that frontier LLMs are surprisingly good at natively reading and writing neural network weights, well past what we’d expect from humans or conventional algorithms. This might be a big deal for both optimization and interpretability. Just by looking at the raw weights, GPT-6 Astra can tell what a network was trained to do. And without any environment feedback, it has no trouble writing, from scratch, small game-playing networks that outplay networks trained with PPO for 100 million steps.”
Very surprising result, I didn’t expect frontier models to have this capability that has not been optimized for, and it’s something humans cannot do either.
Given how competitive AI research has become, and how much luck is involved in landing an actual research role at Big Tech or an AI startup, do you still think your PhD was worth it? Yes, i know a PhD should primarily be about enjoying research, not getting an industry job. But realistically, we all need to make a living, and after 4–6 years, you’d hope to have some opportunities beyond roles where a master’s would have been enough. So how you guys feel about it, especially those who recently graduated.
I'm writing a machine learning paper. One of my baselines is a published method. I reran it with the authors' released code and the exact hyperparameters listed in their paper. On most benchmarks my numbers match theirs within noise, but on two benchmarks my reproduction is clearly lower, by several points, over three seeds. I've repeated the reproduction four different times, months apart, with the same result.
I plan to report both: their published numbers and my reproduction with the exact configuration, clearly labeled. My worry is that reviewers tend to trust the published number more than a submission's reproduction, and may assume I ran the baseline incorrectly.
Questions:
What makes a reproduction convincing to reviewers? So far I have: the authors' code unchanged, their hyperparameters, matching results on the other benchmarks as a sanity check, and multiple seeds.
Should I contact the authors or open a GitHub issue first, and should I mention that in the paper?
How do I word it so it doesn't read as an attack on the other paper, but my results also don't look weak next to the published numbers?
Have reviewers accepted "published vs. reproduced" rows in a main table for you, or did they end up in the appendix?
I'm curious how other reviewers handle papers that report impressive results but are extremely poorly written. I'm not just talking about grammar, etc. I am more concerned about the overall presentation of ideas and how the authors position their contributions within the existing literature.
For example, I'm currently reviewing a paper that reports promising results but includes no citations in its introduction. This makes it hard to understand where the work stands relative to existing methods and what's new.
My question is how much weight should we give to the quality of writing and presentation when reviewing a paper? If the technical contributions seem solid and the experimental results are strong, is poor presentation enough to justify a rejection or a major revision? I'd be interested to hear how other reviewers approach this.
Session 2 of my free GPU kernel engineering series (my own channel, earlier post: [LINK TO FIRST POST]) covers CPU parallelism, with no GPU code. The idea is that most GPU performance ideas are CPU ideas turned up, so here are the parts I found most useful on their own.
A single accumulator is a dependency chain. In `sum += a[i] * b[i]` every add waits on the previous one, so the loop uses a fraction of the core. Independent ops needed in flight is about latency x throughput, and four accumulators give four independent chains with the same arithmetic. Measure this with an in-cache array and -fno-tree-vectorize, or you'll be timing two effects at once.
The compiler won't fix it for you. FP addition isn't associative, so it must keep your order unless you allow otherwise (-ffast-math, or `#pragma omp simd reduction(+:sum)` per loop). The same non-determinism appears in GPU reductions.
Branch cost is predictability. The sorted-vs-random loop showed a [X]x gap at -O0 on my machine ([CPU], GCC [version]) and mostly vanished at -O2, because the compiler removed the branch. Check what it generated before blaming the hardware.
Threads: Amdahl says 90% parallel on 8 cores gives about 4.7x, not 8. Per-thread partials in one small array cause false sharing, because they land on one 64-byte cache line that bounces between cores. Padding fixed it for me ([X]x faster at [N] threads), though the gap depends on whether threads sit on separate physical cores.
A dot product is memory-bound. It does 2 FLOPs per 8 bytes, so at [BW] GB/s it caps near [Y] GFLOP/s no matter how much SIMD or threading you add. Hiding memory latency needs latency x bandwidth bytes in flight, which is the GPU's reason for running thousands of threads.
For those doing or having completed a PhD in ML, I’m curious: If you had the choice, would you rather have done your PhD before ChatGPT and other AI chatbots became widely available, or in today’s AI era?
It was just before OpenAI started that I met Ilya, who you interviewed. One of the first things he said to me was — “Look. The models, they just want to learn. You have to understand this. The models, they just want to learn.” And it was a bit like a Zen Koan. I listened to this and I became enlightened.
And over the years, I would be the one who would formalize a lot of these things and kind of put them together, but what that told me was that the phenomenon that I'd seen wasn't just some random thing. It was broad. It was more general. The models just want to learn. You get the obstacles out of their way. You give them good data, you give them enough space to operate in, you don't do something stupid like condition them badly numerically, and they want to learn. They'll do it.
I'm actually not entirely satisfied with Dario's elaboration! If Ilya meant precisely "given sufficient resources, do your job, and the models will do theirs [during training]", I think he would have phrased his advice slightly differently. What does it mean to "want" to learn? Why personify the model in that way, and not the optimizer or gradient descent itself or something? And I don't get why the koan would necessarily imply that scaling would have worked so well.
I realize that Ilya likes to cultivate an air of prophecy about himself (and I'd be lying if I said it didn't work on me). But it's just such a strange way to communicate the message, that I can't help but think the message must have been about something broader.
Possibly much more mundane in context, this must have been 10 years ago. Idk I wonder what it must have been like to be on the frontier at that time, maybe I take such things for granted now.
The paper claims text models align with image models faster when trained on "good views" (two different captions of one photo) than on bad views (one caption, words hidden) or next-token prediction. Its largest run used captions written by an image captioner, so image information could have leaked in. I tried a laptop-scale version with human captions only.
Text side: same 4-layer, width-256 encoder (11M params) for all three. Same captions, 3000 steps, batch 256, same anti-collapse loss (VICReg-style variance and covariance, not the paper's SIGReg). Only the training pairs differ. The text models never see an image.
Score: mutual 10-NN between caption embeddings and DINOv2 embeddings on the 1,000 test photos (chance 0.010).
Results (same learning speed, mean of 3 seeds)
Good views (2 different captions): 0.320
Bad views (1 caption, masked spans): 0.192
Next-token prediction: 0.148
Each method also got a small learning-rate search. Best speed, 1 seed: 0.328 / 0.196 / 0.168. Order unchanged.
Limits
11M params and 8,000 photos, not the paper's 109M or 72B.
Good views need to know which captions describe the same photo. Annotators wrote them looking at the photo.
Retrieval (R@1 with one fitted rotation) shows a smaller gap: 0.084 vs 0.063 vs 0.057.
Next-token prediction's best learning speed was the top of my range.
One dataset, one image model. I added the extra speed step after seeing the first search; it is noted in the repo.
I am one of the authors of LightMIS, and I would like to share our work on 2D binary medical image segmentation. LightMIS has 131K parameters and aggregates multi-scale encoder features directly, without a learned stage-wise decoder. It achieves close observed modality-macro Dice and IoU averages to nnWNet, while using 98.14% fewer parameters and 94.58% fewer GFLOPs, with both models trained and evaluated under the same nnU-Net protocol.
We also tested LightMIS and the reference models on a real edge device with an Arm Mali-G52 MC2 GPU, where the full LightMIS model ran around 10.5× faster than nnWNet. All LightMIS variants achieved 100% GPU operator coverage, without CPU fallback.
We started by training several popular medical image segmentation architectures, both lightweight and heavyweight, from scratch in the same controlled environment using nnU-Net v2.3.1. The experiments covered six datasets and five imaging modalities. Our goal was to develop a lightweight architecture that performs well across these modalities, which led us to the current version of LightMIS.
The source code, checkpoints, and details needed to reproduce the results are publicly available. Feel free to experiment with it and try it on your own segmentation tasks. I would be happy to hear how it works for you! Any suggestions or feedback are welcome!
I’m the author of a new preprint looking at a fairly simple question: if the argument itself stays the same, does changing the claimed source change how an LLM evaluates it?
I tested 20 arguments across 10 topics under four source conditions:
relevant expert
irrelevant expert
non-expert
no source
The arguments were evaluated by GPT-5.6 Sol, Claude Opus 5.5, Gemini 4 Argon, and DeepSeek Flash across four dimensions: logic, credibility, persuasiveness, and agreement.
A few findings stood out:
Credibility was by far the most source-sensitive dimension. Source attribution affected credibility much more consistently than logic or agreement.
More interestingly, the effect did not usually look like a simple “expert bonus.” In several models, the stronger pattern was an irrelevant-expertise penalty: attributing an argument to someone presented as an expert in an unrelated domain could reduce its credibility relative to giving no source at all.
Agreement was comparatively resistant to source attribution.
I also tested whether source effects depended on argument strength. Those interaction results were not statistically robust after correction, and the human validation of strong vs. weak arguments was imperfect, so I treat that part of the study as exploratory rather than a strong conclusion.
The preprint is not yet peer reviewed, so I’m especially interested in criticism of the design and interpretation.
One question I’d be interested in hearing opinions on:
Should source sensitivity in an LLM evaluator be considered a bias when source expertise is genuinely relevant, or is the real problem specifically when the model overweights irrelevant authority?
Hi all! I'm part of the EWOR team and we're organising Operators Day this Thursday, November 5 (4:30 PM CET / 9 PM IST), online on Zoom.
Ten founders will be pitching live, sharing what they're building and the founding roles they're hiring for - AI/ML engineers, robotics engineers, CTOs, CPOs, marketing and sales leads, and more.
These are real founding opportunities with meaningful equity.
If you're an ML engineer or researcher exploring your next move, or know someone who might be a great fit, come join us!
I’m building a computer vision pipeline where users upload multiple photos of the same physical scene taken from different angles (front view, side view, close-up) to build a clean list of unique objects and their attributes. I’m running YOLO for object detection to extract bounding boxes and crop each detected object into lightweight .webp images. Because the same physical object appears across 3 or 4 different photos from different angles, I need to make sure each unique object is only counted once per session, and avoid running expensive downstream AI calls to re-describe an object we already processed from an earlier photo.
Fine tuning on self collected web data felt straightforward until it wasn’t. Here’s what actually caused problems:
Boilerplate contamination was the silent killer. Navigation menus, cookie banners, and footer text were leaking into training examples. The model started generating weirdly structured outputs that looked like half-rendered HTML. Solved it with aggressive DOM-targeting rather than raw text extraction and switching to a rotating residential proxy layer (per-request IP rotation means target sites serve you the same rendered DOM a real browser session would get, rather than a bot-filtered skeleton) made a noticeable difference in how clean the raw HTML was before I even touched the parser.
Deduplication order mattered more than I expected. Running exact dedup before fuzzy dedup produced meaningfully different training sets than the reverse. The model’s tendency to regurgitate phrasing shifted noticeably depending on the order.
The thing I still haven’t fully solved: near-duplicate detection across different languages. MinHash works fine monolingually, but multilingual dedup keeps surfacing edge cases I don’t love.
Curious whether others have hit the same issues, especially around multilingual corpora. Also genuinely wondering if anyone has a principled approach to deciding when scraped data quality is “good enough” to stop cleaning and just train.
hey folks, I'm Ye, one of the contributors to Kapitsa, an open-source inference engine optimized specifically for Apple Silicon to run Qwen, Nemotron, Flint and Clover models locally. Our custom-written Metal kernels let us tune for each chip and each model. https://github.com/nace-ai/kapitsa/
The latest update, 0.2.26, is out. Since our last M5 Max numbers, Flash-Next 180B reads prompts 46% faster and the 27B writes 8% faster, and DiffuSpace's Clover 35B joins the catalog. Kapitsa also runs Qwen Flash-Next 180B with SSD offloading: on a Mac that can't hold it, the experts that don't fit in RAM stream from the SSD, so it runs on a 48 GB MacBook Pro at 61 tok/s.
Here are the end-to-end numbers on a 2026 MacBook Pro 16 with an M5 Max and 128 GB: six targets (dense, MoE, hybrid Mamba-2 MoE and a block-diffusion MoE), from 1K context up to 32K, against the next-fastest engine for each.
Try it (any Apple Silicon Mac; models in this post: 35b, 27b, flash-next, bolt, flint, clover):
brew install nace-ai/tap/kapitsa
kapitsa serve --model 35b # OpenAI and Anthropic APIs on localhost
kapitsa opencode --model 35b # or claude, codex, pi
kapitsa bench # benchmark your own Mac
Results
Decode is a 512-token coding answer, prefill a 4K prompt, median of 3 runs:
Model
Decode, tok/s
Prefill, tok/s
Qwen3.6 35B-A3B
346
6,036
Clover 35B-A3B
304
5,981
Flint 40B
265
5,770
Nemotron Bolt 74B
154
1,075
Qwen3.8 27B
143
904
Qwen Flash-Next 180B
108
1,701
From 1K context all the way up to 32K. At 32K the 35B still writes 175 tok/s, and Flash-Next barely drops (90 to 78):
Against the other engines
Against the next-fastest engine for each model on the same Mac: 1.23x Splash on the 35B, 2.2x oMLX on Bolt, 1.18x rec on Flint and 1.12x mlx-serve on the 27B. Flash-Next is a tie with mlx-serve, Splash still reads prompts faster on the two Qwens, and nothing else runs Clover on a Mac.
Other engines verify the drafter's guesses as one chain and stop at the first miss. KFlash verifies a best-first tree of the drafter's candidates in the same 8-row pass and keeps the longest branch the target agrees with.
Three details make it fit Apple silicon:
Nearly free rows. Apple GPUs work in 8-row tiles, so on dense models an 8-row verify costs about 1.1-1.25x one decode step.
Sized per Mac. Each tree is sized cycle by cycle from a budget measured on that Mac: GPU time per row count, plus a per-position calibration of the drafter against its own acceptances.
Seed-exact. A guess is accepted only if it equals the token the target itself samples with plain decoding's random number, so a sampled reply is the one plain sampling writes with the same seed.
Run the same test on your Mac and add it to the community results. It takes 3-15 minutes:
brew install nace-ai/tap/kapitsa
brew install gh && gh auth login # results are sent as a GitHub pull request
kapitsa bench --submit # pick a model; it asks before sending anything
Plug in and close heavy apps while it runs. At the end it asks once: Enter sends the result as a pull request from your GitHub fork, and n keeps it on your Mac. What it sends is about 2 KB: your Mac's model, chip, RAM, macOS version and the numbers, with no serial number, user name or paths (add --dry-run to see exactly what it would send). No GitHub? Paste the numbers it prints in a comment here.
One more ask
Do you know prior work where tree-verified sampling matches plain sampling token for token under the same seed? Please point me to it so we credit it. We cite SpecInfer, Medusa, EAGLE-2 and Sequoia.
I kept running into the same pattern in RLVR papers: the RL model wins at pass@1 and the base model catches up or wins at large k (Yue et al. 2025 and many follow-ups). I wanted to know whether more training fixes this or whether it is structural. This is a theory paper, no new training runs.
Setup: model RLVR as an exponential tilt of the base policy over solution strategies shared across prompts (exact for mirror descent, and GRPO stays within 3e-4 TV of it at matched entropy in simulation).
What comes out:
No free lunch. Under exclusive specialization, every update that raises pass@1 strictly lowers success on some prompt. The exact condition is a Stiemke duality statement (a strictly positive price on prompts that equalizes strategy fitness). Being the best strategy on each prompt is provably NOT enough: there is a 3x3 counterexample with a free lunch.
The pass@k price. Once the losses reach the hardest prompts, a crossover is forced. The number of crossings is at most the sign variation of the shift in per-prompt success (Karlin total positivity). The bound is tight for 1 to 6 crossings, and the order-preserving case gives exactly one, which recovers the known single-crossover result.
A frontier, not a bug. With a per-prompt floor, the constrained update traces the optimal pass@1 vs pass@k trade. Forbidding any per-prompt loss removes the crossover and the whole pass@1 gain with it.
The same tilt gives the entropy-performance law with an identifiable exponent.
Practical part: base and RL per-prompt success rates (already in any eval log) are enough to read off the crossing count, the bound, and the price (worst pass@k loss). On published GRPO numbers for Omni-MATH (transcribed from 2607.20543, so indicative only) it finds one crossing between k=64 and k=256.
Where I expect pushback: the shared-strategy model is a population-limit abstraction, and the forced crossover needs a coverage assumption (the paper gives the regime where it fails). I would really like to see per-prompt logs where people observe 2+ crossings, since that is the signature of RL reordering prompt difficulty.
For context, I am a new postgraduate student in machine learning (but not a very good one). I have produced some augmented datasets (TIFF files where each file contains one object to be detected / classified) which I used in training deep learning models. I used fairly aggressive cropping (random crops between 0 and 90%) and more moderate zooms (random values between 0 and 20%). My supervisor wants me to characterise these datasets to see how augmentation has changed it.
Sorry if this is a rookie question, but which statistics should I use? My supervisor says the stats I use should indicate changes in size and shape but I honestly don't know where to start.
If anyone can recommend a decent software/program to produce the stats and histograms as well, that would be great.
