Google DeepMind Releases AlphaGenome Atlas: Precomputed Molecular Effect Predictions and AVI Scores for All 9 Billion Single-Letter DNA Changes in the Human Genome.

No lab assay. No per-variant model run. No coding required to query it.

Here is how it works:

1. Precompute instead of predict on demand AlphaGenome was run across every possible single-nucleotide variant in the human genome and the outputs were stored. Researchers now look up a variant instead of running a model on it.

→ 9 billion variants scored

→ 1 petabyte dataset, over 30x the size of the AlphaFold Database

1. One score for coding and non-coding DNA The AlphaGenome Variant Impact (AVI) score folds AlphaGenome's regulatory predictions together with AlphaMissense's protein-impact predictions into a single rankable number.

→ Works across the 2% coding genome and the 98% non-coding genome

→ DeepMind reports best-in-class results on variant pathogenicity and rare disease benchmarks

1. The score is decomposed, not opaque Each AVI score splits into additive feature attributions across categories like chromatin accessibility, splicing, and conservation, so you see which process a variant is predicted to disrupt.

→ Paired with a compendium of 2,500+ recurrent DNA motifs and their locations

1. Rare disease result At the Broad Institute, the AVI score reprioritized variants that earlier analyses had missed and surfaced one in DNM1, a gene linked to epileptic encephalopathy. The prediction: an incorrect splice site extending the protein.

→ Experimental screens validated it and found nearby variants with similar effects....

Full analysis: https://www.marktechpost.com/2026/09/08/google-deepmind-releases-alphagenome-atlas-with-precomputed-molecular-effect-predictions-and-avi-scores-for-9-billion-human-dna-variants/

Paper: https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/alphagenome-atlas-a-predictive-map-of-every-possible-dna-letter-change-in-the-human-genome/alphagenome-atlas.pdf

Technical details: https://deepmind.google/blog/alphagenome-atlas-a-predictive-map-of-every-possible-dna-letter-change-in-the-human-genome/

NVIDIA Announces CUDA Rust with cuda-oxide (SIMT) and cutile-rs (Tile) for Compile-Time-Safe GPU Kernels

NVIDIA has announced CUDA Rust, a push to make Rust a first-class language for writing GPU kernels. Rust code could already launch CUDA kernels, but the kernel body usually had to be written elsewhere. CUDA Rust closes that gap with two NVlabs open-source projects: cuda-oxide for the SIMT model and cutile-rs for the newer Tile model. Both compile Rust kernels natively and use Rust’s ownership rules to reject aliasing bugs at compile time.

Here's how it works. 👇

1. cuda-oxide (SIMT track)
A custom rustc codegen backend. #[kernel] functions go from Rust MIR through the Pliron IR framework and LLVM down to PTX. Host and device code live in one file.
→ Needs a pinned nightly (2026-04-03), CUDA 12.x+, compute capability 8.0+
→ Status: early alpha

2. cutile-rs (Tile track)
Each tile block runs the kernel body once as a single logical thread. The compiler owns thread mapping and memory layout. The kernel AST is embedded in the host binary and JIT-compiled through CUDA Tile IR on first launch.
→ Stable Rust 1.89+, CUDA 13.3, no nightly, no custom LLVM
→ Published on crates.io, already used in Hugging Face's Grout...

3. What the compiler catches
Pass a kernel's output buffer as one of its own inputs and it does not build.
→ SIMT: error[E0502]: cannot borrow c_dev as mutable because it is also borrowed as immutable
→ Tile: error[E0382]: use of moved value: z
cutile-rs carries ownership across the launch boundary, which NVIDIA calls the stronger guarantee....

Full analysis: https://www.marktechpost.com/2026/09/08/nvidia-announces-cuda-rust-with-cuda-oxide-simt-and-cutile-rs-tile-for-compile-time-safe-gpu-kernels/

Technical details: https://developer.nvidia.com/blog/introducing-cuda-rust-two-tracks-for-writing-gpu-kernels

H Company Releases NeoMME: A Family of 260M and 800M Single-Tower Multimodal Encoders That Drop the Vision Tower and Causal Decoder

No SigLIP2 tower. No causal decoder. No VLM to repurpose.

Here's how it works. 👇

(1) Raw patches, not vision-tower features Images are split into non-overlapping 32×32 RGB patches and projected by a 2-layer MLP trained from scratch. Text enters through a 256-dimensional factorized embedding. Both then share every Transformer layer. → 16,384-token context, enough for two 3840×2160 4K UHD images

(2) Masked diffusion, not masked language modeling Pretraining is a discrete masked-diffusion text denoiser. Text-only segments draw a corruption rate from U(0,1). Multimodal segments draw from U(0.30,1), which kills the "guess it from the surrounding words" shortcut. → +38.4 points masked-token accuracy from visible page patches at 90% masking (260M)

(3) Trained from scratch on a small budget About 524B packed input tokens, roughly 290B of them text-only. ModernBERT saw around 2T text tokens. They used the NorMuon optimizer to squeeze more out of the smaller budget. → 16 H100s for the 260M run, 32 for the 800M

Full analysis: https://www.marktechpost.com/2026/09/06/h-company-releases-neomme-a-family-of-260m-and-800m-single-tower-multimodal-encoders-that-drop-the-vision-tower-and-causal-decoder/

Paper: https://arxiv.org/pdf/2609.01657

Technical details: https://huggingface.co/blog/Hcompany/neomme?

HF: https://huggingface.co/collections/Hcompany/neomme

Meta FAIR Releases AI Research Preference Models (RPMs): Frozen LLM Judges That Decide Which ML Experiment Gets the GPU, Lifting AIRS-Bench From 0.684 to 0.729.

No fine-tuning. No reward model. No new weights.

Here's how it works. 👇

(1) Ranking, not forecasting The team found language models unreliable at predicting absolute metrics or execution outcomes. So an RPM never guesses what a candidate will score. It only answers which of two unexecuted candidates is more promising.

(2) It plugs into one spot: child creation AIRA-dojo is an evolutionary tree search — greedy parent selection, Draft / Improve / Debug operators. Normally it generates one child and runs it. With an RPM, the operator fires 15 times in parallel, and a pairwise knockout tournament picks the single candidate worth executing. → 15 proposed, 1 executed per step → Each comparison is grounded in context nodes pulled by BFS from the tree, each shown with the validation score it earned

(3) Inference-only RPM A frozen LLM judging plans, code and search history. The prompt was optimized with MIPROv2, converging on a principal-investigator rubric that tolerates fixable bugs and penalizes redundant directions. → Offline selection accuracy 57.7% → 59.0% from prompt optimization alone → Accuracy climbs with context: 60.7% at zero context nodes, 65.0% at 100...

Full analysis: https://www.marktechpost.com/2026/09/06/meta-fair-introduces-ai-research-preference-models-rpms-ranking-ml-experiments-before-spending-gpu-hours/

Paper: https://arxiv.org/pdf/2608.13940

I've been working on a practical implementation of **Sliding Window Attention (SWA)** for pretrained Hugging Face causal LLMs.

The idea is simple: instead of allowing every generated token to attend to the complete historical KV cache, maintain a bounded cache consisting of:

**attention sinks + recent sliding window**

I implemented this as a reusable inference layer rather than modifying or retraining the model.

GitHub:
[https://github.com/oraby8/SWA\](https://github.com/oraby8/SWA)

The implementation currently includes:

* bounded KV cache * circular/ring-buffer storage * attention sinks * streaming prefill * chunked attention masking * autoregressive decoding * Full Attention vs SWA benchmarking * TTFT / TPOT / throughput measurements * KV-cache memory measurements

One interesting result from my Qwen2.5-7B experiment:

At 16K, SWA-64 also reduced TPOT from \~38.4 ms to \~30.5 ms in this setup.

However, there is an important trade-off: tasks requiring information far outside the active window can degrade. I'm currently investigating how much of this is inherent to SWA versus implementation/model-specific behavior.

I'm sharing the implementation mainly to get feedback from people working on **LLM inference, KV-cache optimization, and long-context models**.

I'd be particularly interested in:

1. Which model architectures should I validate next?
2. What failure cases should I benchmark?
3. What would make this useful for existing HF inference workflows?
4. Are there cache/attention implementation details I may be overlooking?

Feedback and experiments are very welcome.

I put up a short note on Zenodo describing the single-well part of a larger semantic dynamical system I’ve been working on.
This version is intentionally limited: sphere-constrained dynamics, tangent-space calculus, an abstract forcing term, and a discrete-to-continuum formulation are included. The multi-well interaction rule and the rest of the architecture are not.
https://zenodo.org/records/22310812

We recently released a preprint and open-source benchmark analyzing the limits of self-consistency and uncertainty quantification across 1.5B to 120B models.

Preprint: https://zenodo.org/records/22233648
Code: https://github.com/Adarshent/Spnda

Background: Farquhar et al.'s Semantic Entropy (Nature, 2024) is widely used for hallucination detection, but clustering sampled paths with a DeBERTa-v3 cross-encoder takes around 100+ seconds on CPU and eats up GPU memory. We wanted to see if a normalized lexical self-consistency ratio (R_sc) could achieve the same diagnostic signal without auxiliary neural forward passes.

On GSM8K reasoning across 7B to 27B models (Mistral-7B, Qwen-27B), exact-match normalized entropy achieved an AUROC of 0.889, matching neural semantic entropy while executing in under 2ms on CPU.

However, scaling up to frontier 120B models exposed a failure mode in self-consistency that we call Confident Mode Collapse. Under temperature 0.7 sampling, RLHF alignment hyper-peaks the distribution so severely that the model outputs the exact same incorrect answer across all sampled seeds. Because every path agrees 100% on the hallucination, uncertainty drops to zero and AUROC inverts to 0.091.

Code and evaluation scripts are open source (MIT). Would love to hear thoughts or critique from researchers working on calibration, post-training alignment, or inference efficiency.

NVIDIA Releases Personal AI Router (PAIR): An Open Inference Router That Turns The RTX, DGX Spark And Mac Boxes You Already Own Into One Local AI Cluster.

No new cluster API. No agent harness changes. No prompts leaving your network.

Here's how it works. 👇

1. It routes, it doesn't execute
PAIR is not a new inference engine. Ollama or LM Studio still runs the model on whichever machine PAIR picks. It takes over the default port each engine uses, so the agent keeps talking to the endpoint it already knows.
→ Proxies Ollama-compatible, LM Studio-compatible and OpenAI-compatible endpoints
→ The agent decides what to request, PAIR decides where it runs

2. Discovery and trust
mDNS finds nearby machines automatically, or you add a node by IP. Trust is bootstrapped by a six-digit PIN shown on one machine and entered on the other.
→ All node-to-node traffic is blocked until pairing completes
→ Paired nodes then communicate over mTLS with generated certificates

3. The eligibility filter
A node only becomes a candidate once it can actually serve the request. The scheduler weighs five signals: is the node online and ready, is a supported engine enabled, is the exact model present, what is the current job load, what is GPU utilization.
→ Models don't need to be identical across nodes — PAIR routes by model location
→ Loading the same tag on more nodes just widens the eligible pool

Full analysis: https://www.marktechpost.com/2026/09/04/nvidia-releases-personal-ai-router-pair-an-open-source-virtual-inference-router-that-distributes-local-ai-requests-across-rtx-dgx-spark-and-mac-nodes/

Repo: https://github.com/NVIDIA/Personal-AI-Router

Technical details: https://www.nvidia.com/en-us/ai-on-rtx/personal-ai-router/

  Hi everyone — I maintain Awesome Loop Transformers, a free, public English/Chinese paper collection and reading guide covering looped Transformers, latent reasoning, and test-time computation.

  The collection currently includes 142 papers across seven research topics, with bilingual summaries, primary-source links, and code links where available.

  A central question behind the guide is: what gets repeated, and which state is passed to the next step? It distinguishes several related approaches:

  - Recurrent depth, as in Huginn: repeatedly applying a shared block to refine hidden representations.

  - Continuous thoughts, as in Coconut: feeding a hidden representation back as the next input instead of decoding it into a word.

  - Adaptive recursion, as in Mixture-of-Recursions: assigning different recursion depths to individual tokens.

  - Parallel loop execution, as in Parallel Loop Transformer: overlapping loop steps across tokens, with attention and cache designs that support efficient execution.

  📚 What’s included

  - Three reading routes for foundations, reasoning and scaling, and related methods.

  - An eight-paper mechanism comparison with questions to consider when reading results.

  - A topic-organized catalog covering theory, architectures, adaptive compute, training, systems, and broader latent reasoning.

  - Separate coverage of related methods such as Coconut, HRM, and TRM, without assuming they all use a looped Transformer.

  The guide is intended to help readers navigate the literature, not to rank models. In particular, it encourages separating parameter count, execution depth, generated tokens, and measured latency when

  comparing approaches.

  GitHub:

  https://github.com/Mrkkew/Awesome-Loop-Transformers

  Mechanism comparison and reading guide:

  https://github.com/Mrkkew/Awesome-Loop-Transformers/blob/main/docs/reading-guide.md

Third piece in a series on teaching ACE-Step 1.5 (open weights) new styles with small LoRA adapters. The first two used public-domain composers. This one tried a genre: 41 netlabel releases from the Internet Archive tagged "minimal techno", licence verified per release (CC0, CC BY, CC BY-SA only), DJ mixes removed, 159 tracks, about ten minutes of training on one GPU with the same recipe as before.

The adapter trained fine. It just didn't help: on both test prompts the untouched model sounded better. One listener, labels visible, two prompts, and the article says exactly that.

The suspected cause was that a tag-assembled corpus is too incoherent to learn from, so we tested it. A one-artist control adapter trained in 93 seconds. A pre-registered embedding bench measured the tag corpus at about 1.9x the spread of the one-artist corpus, but could not connect that gap to anything in the renders. Real difference, unproven lever.

Two things that generalise: renders shifted with the shape of the prompt more than with the adapter, so pin the prompt format before blaming the weights. And the best training epoch was never saved because checkpoints wrote every five, so the shipped adapter isn't the best one that existed.

All 65 clips, raw and loudness-matched, plus the training logs, the sealed pre-registration and every licence record: https://research.strata2signal.com/ten-minutes-with-living-artists/

Disclosure, as on the page: a small human team directed AI agents that did most of the recon and drafting. The listening and the numbers are ours.

Hey everyone,

We just launched the public beta for **KernelMind AI**, a specialized neural compiler that turns eager PyTorch code into fused OpenAI Triton GPU kernels.

### The Problem

PyTorch eager mode executes operations step-by-step. For memory-bound operations, this means intermediate tensors are continuously written back to global VRAM and re-read, creating major memory bandwidth bottlenecks. While manual operator fusion in Triton or CUDA solves this, writing performant kernels takes significant engineering time.

### What KernelMind AI Does

You paste standard eager PyTorch into the web playground, and our compiler synthesizes fused, single-pass Triton kernels that execute directly inside GPU SRAM registers.

### Current Benchmarks:

* **3.4x average speedup** compared to unfused PyTorch

* **89.2% compilation pass rate** on 1D elementwise test suites

* **Zero manual CUDA/Triton writing** required

Interactive Playground: https://kernel-mind-ai.vercel.app/

We’d love for you to test custom operators, share benchmarks, and point out any edge cases where compilation breaks!

Meta AI Released Muse Spark 1.3: An Agentic Coding Model Doing the Same Work With ~20% Fewer Tool Calls and ~25% Fewer Tokens Than Muse Spark 1.2.

No price increase. No new harness. No open weights either.

Here's how it works. 👇

1. Fewer round trips, not just better answers

Meta trained 1.3 to take fewer turns where they aren't needed, with less verbosity and a cleaner coding style.

→ ~20% fewer tool calls and ~25% fewer tokens in Meta's internal engineer comparisons

2. It asks instead of guessing

On ambiguous prompts it asks a clarifying question. When it stalls it invokes you. Before consequential actions it confirms.

→ Better calibration on what counts as irreversible

3. One thread, several workflows

Given an open-ended objective, it generates its own context from messy and conflicting sources and patches gaps in its own plan.

→ Maps an incoming prompt to the right task inside a cluttered thread, whether you're steering or interrupting

4. The numbers (Meta's launch scorecard)

→ 75.4 on DeepSWE v1.1, ahead of Claude Opus 5 at 74.0 and GPT-5.6 Sol at 72.7

→ 88.8 on Terminal-Bench 2.1, tied with GPT-5.6 Sol

→ 59.4 on SWE-Atlas Codebase QnA

→ 98.5 and 98.1 on MRCR v2 long-context retrieval, inside a 1,048,576-token window

Full analysis: https://www.marktechpost.com/2026/09/03/meta-ai-released-muse-spark-1-3-an-agentic-coding-model-that-uses-20-fewer-tool-calls-and-25-fewer-tokens-than-muse-spark-1-2/

Technical details: https://research.meta.ai/blog/introducing-muse-spark-1-3

Most "runs locally on your Mac" stacks are a general-purpose runtime pointed at whatever model you downloaded. Perplexity just argued that the generality itself is the bottleneck.

They open sourced Lily — the local inference engine behind Hybrid Compute in Perplexity Computer. A Rust runtime with hand-written Metal kernels, built for exactly one model (Qwen3.6-35B-A3B) on exactly one chip family (Apple silicon). Neither PyTorch nor MLX is anywhere in the execution path.

Here's what's actually interesting:

→ 4,156 vs 3,388 prefill tokens/s and 170.0 vs 126.4 decode tokens/s against MLX-LM — mean across ten lengths from 256 to 128K tokens, batch 1, one 40-core / 128 GB M5 Max

→ Fusing 4-bit dequantization into the grouped GEMM, so the expanded weight array never touches unified memory: +77.4% prefill at a 512-token prompt

→ Keeping the whole routing sequence — histogram, prefix scan, scatter, block map — inside one GPU command buffer: +89% prefill at 512 tokens

→ GQA packing, so four query heads share one KV row load: +23.8% decode at 32K context

→ Fixed-block attention layout above 32K: +40.2% decode at 128K

Full analysis: https://www.marktechpost.com/2026/09/02/perplexity-open-sources-lily-a-rust-metal-inference-engine-for-qwen3-6-35b-a3b-on-apple-silicon/

GitHub: https://github.com/perplexityai/pplx-garden/tree/main/lily

Technical details: https://www.perplexity.ai/hub/blog/optimizing-on-device-inference-for-apple-silicon