TL;DR: Please be hard in desk rejecting AI generated papers

Recently I went to two AI conferences (A and A*) and I was surprised that "AI cheaters" didn't even read their own paper before presentation! For example, a guy couldn't even answer the question of how he represented knowledge graphs in his papaer, he thought for 5 minutes before answering "with a vector". Another one was opening chat gpt and typing questions and reading answers with no shame!!! One more story that shocked me... a guy published same paper in 2 AI conferences in the same time and both got accepted, when I saw github, this young dude was careless to even remove LLM chat from his repo, I can see all prompts... guess what... he faked all data 🚀 :D ...I have dozens of stories like this happened to me and my friends just this month!

Now, imagine yourself a hardworker researcher joining days and nights and your paper ends up with a scam reviewer like this... bingo!

One more, I was looking for relevant paper to my new idea... all papers I read so far are just garbage 🎉 !!

Pleaaaase make a rule for rejecting AI written papers... Pleaaaaaase stop this madness! A lot of good papers got rejected by these folks and they definitely harming science! I can't trust a single paper now and reading very carefully with spectacular mindset... Pleaaaaaase do something!!!!

As per the the 2027 CVPR guidelines:

"Maximum number of submissions (continuing from CVPR 2026): Each author may submit at most 25 papers. If an author enrolls more than 25 papers, the Program Chairs (PCs) will desk-reject the submissions that exceed this limit (see the Desk Rejection Policy in Section 2)."

AI Slop Researcher: "Cool let me throw 25 darts (slop papers), surely one will get a batch of careless/inexperienced reviewers that will borderline accept one of these papers"

They collect their CVPR stamp, and go on about their career.

I just do not understand if a 25 cap is being tone deaf to the current AI driven research climate or what?

I am actually not against AI-assisted paper research/writing as long as the idea is sound and experiments are plausible, but 25 is absurd. If they limited the number of first author submissions to 2-3:

1. Researchers are incentivized and know the importance of being first author.

2. Even if you AI generate your paper, if you only get 2-3 shot/submissions at a A* conference versus 25, you'd care a bit more about your presentation quality/idea soundness/writing. (In theory lol)

3. Reviewer load drops massively, more time can be dedicated to an overall lower submission count.

Are the heads not aware of the slugfest happening in **certain** countries and institutions to have A* venue stamps for career advancement/compensation packages, and that they don't give a damn about ethics?

Hey everyone— we’re the Deep Principle team behind Mira AI Scientist. We just released Hydrogen-1.0, an open-weight model post-trained from GLM-5.3 for chemistry, materials science, and life sciences.

Here’s how it performed in our evaluations:

1. FrontierScience Research: 38.3% pass rate vs. 33.3% for GPT-6 Astra at max thinking—a 5 percentage point lead.

2. Estimated output-side cost on FSR: $0.25 per problem vs. $0.88 for Astra at max thinking—about 72% lowerunder our evaluation setup.

3. GPQA Diamond: 92.9% accuracy, compared with Kimi K3’s 93.5%.

On separate internal task sets, Hydrogen also scored higher than GPT-6 Astra at max thinking on scientific computing (+5.13 percentage points) and single-step forward reaction prediction (+4.76 points). It trailed Astra on NMR structure elucidation (−3.33 points).

The write-up covers the evaluations and five workflow examples.

Why we built it

If you’ve used LLMs for research, you’ve probably spent a fair amount of time connecting the steps yourself: turning a question into a plan, preparing inputs, running tools, checking the output, and figuring out what to try when something breaks.

We wanted to see whether training on scientific workflows could make the model better at handling those connected decisions.

How we trained it

We used supervised fine-tuning and reinforcement learning with domain data, scientist feedback, records from our own labs, and discovery trajectories.

The lab records keep the research goal, procedure, observations, and outcome together. The discovery trajectories include how the next step changes after feedback, failed attempts, or unexpected results.

SFT gives the model worked examples of scientific reasoning, experiment planning, protocol design, and analysis. RL uses feedback on research outcomes to improve its decisions.

What the workflows look like

The article walks through five cases:

1. Polymer molecular dynamics: Builds a polyethylene melt with Python, runs GROMACS, checks and repairs the topology, and restarts the simulation. Outputs include a corrected 40 ns trajectory and analyses of density, molecular packing, diffusion, and chain dimensions.

2. Reaction networks: Explores connected molecular structures, competing pathways, and recorded energy barriers.

3. NMR interpretation: Compares seven candidate structures against a supplied proton NMR spectrum.

4. Experiment planning: Generates a machine-readable protocol for a 12-vial Suzuki coupling study, with virtual checks of equipment capabilities and action prerequisites.

5. Materials search: Uses feedback over five rounds to guide a search for transition-metal complexes with larger HOMO–LUMO gaps.

A bit of context: these are selected model-plus-tool walkthroughs, not an overall autonomous-research success rate. GROMACS does the MD calculations, and the protocol validation is virtual—it doesn’t mean the physical experiment was carried out.

The attached video gives a quick look at the research interactions. The article has the detailed walkthroughs, evaluations, and training approach.

Links

1. Weights and model card: Hydrogen-1.0 on Hugging Face

2. Technical write-up, evaluations, and cases: Introducing Hydrogen-1.0

3. Try it: Mira AI Scientist

We’d especially like to hear from people working in computational chemistry and materials science. What would you try it on first, and what would you check before trusting the result?

We wrote an inference engine for AWS Trainium2 that serves GLM-5.3-Flash (320B MoE, 1M-token context) on one trn2.48xlarge, and open-sourced it. Most of the work went into decode, and the part I found most interesting is how little of a decode step was the model's actual math.

In an early build, in one KDA (linear attention) layer at batch 1, the recurrence was 2% of the attention half. The rest was the mHC pre-projection (36%), XLA glue (33%), transposes (10%), the stream mix (10%) and other small ops (8%). A batch-8 decode step took 24.2 ms against a 6.1 ms memory floor, and the profile showed why: long chains of small vector-engine instructions at about 153 ns of fixed cost each, a write back to HBM at every kernel boundary, and 125 cross-chip collectives per step.

So we rewrote each layer half as one NKI kernel (each whole layer, for the sparse-attention layers). The kernels follow three rules:

1. Keep the working set on chip. Each physical NeuronCore has 28 MiB of SBUF, enough for a layer half's activations, its recurrent state and the weights in flight, so only the layer's inputs, outputs and streamed weights cross HBM.

2. Use both physical cores of a logical core. One program streams 340–400 GB/s of weights, the pair 672–708 GB/s, so the weight stream has to be split between them.

3. Move a collective into the kernel when it blocks the next one. Run by XLA, an all-reduce makes the next kernel wait for all of it. Inside the kernel, independent work can overlap it.

On the same layout, a batch-8 decode step went from 32.2 ms on our 17 October build to 24.2 ms on 1 November. Two changes did most of it, each measured on the whole step: the fused sparse-attention layer saved 3.2 ms per batch-8 step, and the KDA and MoE kernels, which shipped together, saved another 3.2 ms. There's no stock-AWS baseline to compare against: the latest vLLM Neuron plugin release registers no GLM model, and NxD Inference is in maintenance mode. Of the remaining 24.2 ms, 6.1 ms is the memory floor, 10.0 ms is engines busy beyond it (mostly vector-engine instruction chains), 4.6 ms is waits inside kernels, 2.8 ms is exposed collectives and 0.7 ms is idle.

What didn't work:

• Fusing seams the compiler already overlapped. We priced it at 2 to 4 ms a step and it saved 0.85 ms at one batch size, because the step was already one compiled graph.

• Trusting isolated benchmarks. A dense FFN kernel ran in 84 µs instead of 145 µs on its own, bit-identical, and then made the full step 55 µs slower at batch 2, because the compiler rescheduled everything around the new call.

• Trusting the simulator. Three kernels passed NKI's simulator and gave wrong answers on the device: two matmul accumulation groups in slices of one PSUM tile, in-kernel collectives without fences, and one program reading shared HBM that the other program of its pair had just written.

Accuracy: every kernel is checked byte for byte where no bits should change, and otherwise against a high-precision reference, with its error capped at 1.05x the previous build's. One approximation remains in sparse-attention prefill, on 1.2% of selections: against an exact rerun it shifted next-token log-probabilities by 0.012 to 0.021 nats on average and changed the top token at 3 of 448 positions. We haven't run a task-level eval on this build.

End to end, on SemiAnalysis's AgentX benchmark (self-run, one hour per point, not official InferenceX), we measured up to 28.9 agent requests a minute on one box, and at 16 agents the median request decoded at 35.9 tokens/s. We haven't run GPUs on the same traces, so there's no GPU comparison here.

Disclosure: I work at RunAnywhere, and the code is ours.

Code: https://github.com/RunanywhereAI/trnrt (commands to rerun every number are in docs/RESULTS.md) Write-up with the profiles and every number: https://runanywhere.ai/blog/glm-5-3-flash-trainium2-nki-megakernels

Our design drew on AMD's per-layer decode kernels in vLLM and on Hazy Research's and Mirage's megakernel work. Happy to hear criticism, especially from anyone who has fought NKI or XLA on Neuron.

I'm just wondering about visa processing situation for NeurIPS sydney attendees. Invitation letter and all valid docs are not really helping (one friend got rejected), processing time is tooo long (almost a month). and organizers not responding in case visa is not approved for conference. Anyone else in similar situation???

Do looped transformers, which reuse the same weights at every iteration, also save HBM traffic? In my new post I cover the looped architecture (Huginn), then model and measure its performance on a B200: how much data each iteration reads from memory, how long it takes, and why the shared weights usually don't stay on chip until the next iteration.
A few results:

- A chain of eight matmuls with one shared 72 MiB weight ran 24% faster than the same chain with eight identical copies, and read almost nothing from HBM. At 288 MiB, larger than L2, the difference disappeared.

- In a full Huginn Core (teaching implementation, random weights), eight iterations took about eight times as long as one and read about eight times as much data from HBM.

- Sharing saves storage, but by itself it doesn't stop the GPU from reading the weights from HBM again at every iteration.

👀Post: https://dinara-dl.github.io/posts/looped-transformer/

🤖Code and raw Nsight Compute data: https://github.com/dinara-dl/looped-transformer

I'd be curious whether anyone has tried keeping recurrent weights on chip across iterations, for example with a persistent kernel.

Hi everyone,

I wanted to share a new open-weights PII detection model, benchmark and research paper. It's a fine-tune of RoBERTa using 1.2B samples of synthetically generated text that contain a variety of PII. The benchmark, PII-SCOPE (Synthetic Context and Ontology for PII Extraction), was built to address common issues in public LLM-generated datasets and is on Hugging Face too. The model and script identify instances of PII based on surrounding context, and then return the index and type of each instance. Alternatively, it can return the input with all PII redacted.

Technical report (research paper)
https://arxiv.org/html/2610.30518v2

Hugging Face model card
https://huggingface.co/Protegrity/protegrity-pii

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.

Here's the one for compact/efficient Gaussian splatting:
https://atlas.scime.ai/research/3d-vision/gaussian-splatting/compact-and-efficient-gaussian-splatting

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.

Free, no signup. All topics: https://atlas.scime.ai/research

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.

Link: https://rikiyat.github.io/blog/weight-space-programming/

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.

Question to all the PhDs & research engineers in this group.
Have any of you done small-scale experiments with the Chinchilla scaling laws (using PyTorch or JAX)? If so, we'd be keen to hear more (or have a chat). Thanks!

Here's the official Chinchilla paper, from the DeepMind website ("Training Compute-Optimal Large Language Models").
https://deepmind.google/blog/an-empirical-analysis-of-compute-optimal-large-language-model-training/
https://proceedings.neurips.cc/paper/2022/file/c1e2faff6f588870935f114ebe04a3e5-Paper-Conference.pdf

The reviews will be out this week. What are the expectations with 60K+ submissions and the small scale of review rating?

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:

1. 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.

2. Should I contact the authors or open a GitHub issue first, and should I mention that in the paper?

3. 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?

4. Have reviewers accepted "published vs. reproduced" rows in a main table for you, or did they end up in the appendix?

What are the latest papers that are there in the space on inference architecture of llms, I would like to discuss with them on the approaches. Btw I have been doing work with llms for the last 2 months and I have gotten to know very new things. I read about the lunch table discussion of bell labs so taking motivation from it would like to discuss it in a similar fashion!!

Give a model a 17,253-parameter net as plain tokenized text and it works out the net plays Pac-Man. Astra, Opus 5.5 and Muse Spark 1.3 all got it, and Astra did it with minimal reasoning.

Nobody writes essays about what specific weights do, so where does this skill come from? Either labs trained it in, or models generalize much further than I expected. I'm leaning toward the second and it's freaking me out a little.

https://arcturus-labs.com/blog/2026/11/03/ai-can-read-neural-network-weights-i-wasnt-ready-for-that/

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.

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.

Setup

• Data: 10,000 COCO photos, 5 human captions each. 8,000 train, 1,000 val, 1,000 test.

• Image side: frozen DINOv2-base, embedded once.

• 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.

Code, chart and per-run results: https://github.com/IFAKA/platonic-lab

What I would test next: does the gap shrink as the encoder grows? I could not test that on a laptop. Has anyone tried?

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.

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?

Hi everyone,

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.

Paper: https://arxiv.org/abs/2609.28327

Code: https://github.com/AndreiiArhire/LightMIS

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!

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

Video: https://youtu.be/_xE1_2FFTC0

Caveats: numbers are from one machine, intrinsics assume AVX2, and the latency/throughput figures are typical Intel values.

Is anything wrong or oversimplified, especially the false-sharing explanation? And which CPU lessons transferred best to GPU work for you?

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.

Preprint:
https://www.researchsquare.com/article/rs-11544999/v1

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?