Uncategorized

Running powerful AI on your smartphone isn’t just a hardware problem — it’s a model architecture problem. Most state-of-the-art vision encoders are enormous, and when you trim them down to fit on an edge device, they lose the capabilities that made them useful in the first place. Worse, specialized models tend to excel at one type of task — image classification, say, or scene segmentation — but fall apart when you ask them to do something outside their lane. Meta’s AI research teams are now proposing a different path. They introduced the Efficient Universal Perception Encoder (EUPE): a compact vision encoder that handles diverse vision tasks simultaneously without needing to be large. The Core Problem: Specialists vs. Generalists To understand why EUPE matters, it helps to understand how vision encoders work and why specialization is a problem. A vision encoder is the part of a computer vision model that converts raw image pixels into a compact representation — a set of feature vectors — that downstream tasks (like classification, segmentation, or answering questions about an image) can use. Think of it as the ‘eyes’ of an AI pipeline. Modern foundation vision encoders are trained with specific objectives, which gives them an edge in particular domains. For example: CLIP and SigLIP 2 are trained on text-image pairs. They’re strong at image understanding and vision-language modeling, but their performance on dense prediction tasks (which require spatially precise, pixel-level features) often falls below expectations. DINOv2 and its successor DINOv3 are self-supervised models that learn exceptional structural and geometric descriptors, making them strong at dense prediction tasks like semantic segmentation and depth estimation. But they lack satisfactory vision-language capabilities. SAM (Segment Anything Model) achieves impressive zero-shot segmentation through training on massive segmentation datasets, but again falls short on vision-language tasks. For an edge device — a smartphone or AR headset — that needs to handle all of these task types simultaneously, the typical solution is to deploy multiple encoders at once. That quickly becomes compute-prohibitive. The alternative is accepting that a single encoder will underperform in several domains. Previous Attempts: Why Agglomerative Methods Fell Short on Efficient Backbones Researchers have tried to combine the strengths of multiple specialist encoders through a family of methods called agglomerative multi-teacher distillation. The basic idea: train a single student encoder to simultaneously mimic several teacher models, each of which is a domain expert. AM-RADIO and its follow-up RADIOv2.5 are perhaps the most well-known examples of this approach. They showed that agglomerative distillation can work well for large encoders — models with more than 300 million parameters. But the EUPE research demonstrates a clear limitation: when you apply the same recipe to efficient backbones, the results degrade substantially. RADIOv2.5-B, the ViT-B-scale variant, has significant gaps compared to domain experts on dense prediction and VLM tasks. Another agglomerative method, DUNE, merges 2D vision and 3D perception teachers through heterogeneous co-distillation, but similarly struggles at the efficient backbone scale. The root cause, the research team argue, is capacity. Efficient encoders simply don’t have enough representational capacity to directly absorb diverse feature representations from multiple specialist teachers and unify them into a universal representation. Trying to do so in one step produces a model that is mediocre across the board. https://arxiv.org/pdf/2603.22387 EUPE’s Answer: Scale Up First, Then Scale Down The key insight behind EUPE is a principle named ‘first scaling up and then scaling down.‘ Instead of distilling directly from multiple domain-expert teachers into a small student, EUPE introduces an intermediate model: a large proxy teacher with enough capacity to unify the knowledge from all the domain experts. This proxy teacher then transfers its unified, universal knowledge to the efficient student through distillation. The full pipeline has three stages: Stage 1 — Multi-Teacher Distillation into the Proxy Model. Multiple large foundation encoders serve as teachers simultaneously, processing label-free images at their native resolutions. Each teacher outputs a class token and a set of patch tokens. The proxy model — a 1.9B parameter model trained with 4 register tokens — is trained to mimic all teachers at once. The selected teachers are: PEcore-G (1.9B parameters), selected as the domain expert for zero-shot image classification and retrieval PElang-G (1.7B parameters), which the research team found is crucial for vision-language modeling, particularly OCR performance DINOv3-H+ (840M parameters), selected as the domain expert for dense prediction To stabilize training, teacher outputs are normalized by subtracting the per-coordinate mean and dividing by the standard deviation, computed once over 500 iterations before training begins and kept fixed thereafter. This is deliberately simpler than the complex PHI-S normalization used in RADIOv2.5, and avoids the cross-GPU memory overhead of computing normalization statistics on-the-fly. Stage 2 — Fixed-Resolution Distillation into the Efficient Student. With the proxy model now serving as a single universal teacher, the target efficient encoder is trained at a fixed resolution of 256×256. This fixed resolution makes training computationally efficient, allowing a longer learning schedule: 390,000 iterations with a batch size of 8,192, cosine learning rate schedule, a base learning rate of 2e-5, and weight decay of 1e-4. Standard data augmentation applies: random resized cropping, horizontal flipping, color jittering, Gaussian blur, and random solarization. For the distillation loss, the class token loss uses cosine similarity, while the patch token loss combines cosine similarity (weight α=0.9) and smooth L1 loss (weight β=0.1). Adapter head modules — 2-layer MLPs — are appended to the student to match each teacher’s feature dimension. If student and teacher patch token spatial dimensions differ, 2D bicubic interpolation is applied to align them. Stage 3 — Multi-Resolution Finetuning. Starting from the Stage 2 checkpoint, the student undergoes a shorter finetuning phase using an image pyramid of three scales: 256, 384, and 512. The student and the proxy teacher independently and randomly select one scale per iteration — so they may process the same image at different resolutions. This forces the student to learn representations that generalize across spatial granularities, accommodating downstream tasks that operate at various resolutions. This stage runs for 100,000 iterations at

This is today’s edition of The Download, our weekday newsletter that provides a daily dose of what’s going on in the world of technology. The one piece of data that could actually shed light on your job and AI  Within Silicon Valley’s orbit, an AI-fueled jobs apocalypse is spoken about as a given. Now even economists who have downplayed the threat are coming around to the idea.   Alex Imas, based at the University of Chicago, is one of them. He believes that any plan to address AI’s impact will depend on collecting one vital piece of data: price elasticity.  Imas argues that “we need a Manhattan Project” for this. Read the full story to find out why.  —James O’Donnell  This article is from The Algorithm, our weekly newsletter giving you the inside track on all things AI. Sign up to receive it in your inbox every Monday.  Four things we’d need to put data centers in space  In January, Elon Musk’s SpaceX applied to launch up to 1 million data centers into Earth’s orbit. The goal? To fully unleash the potential of AI—without triggering an environmental crisis on Earth.  SpaceX is among a growing list of tech firms pursuing orbital computing infrastructure. But can their plans really work? Here are four must-haves for making space-based data centers a reality.  —Tereza Pultarova  This story is part of MIT Technology Review Explains, our series untangling the complex, messy world of technology to help you understand what’s coming next. You can read more from the series here.  The must-reads  I’ve combed the internet to find you today’s most fun/important/scary/fascinating stories about technology.  1 Trump has again proposed major cuts to US science and tech spending He wants to slash nearly every science-focused agency. (Ars Technica) + If Trump gets his way, the US could face a costly brain drain. (NYT $)  + Top research talent is already fleeing the country. (Guardian)  + Basic science deserves our boldest investment. (MIT Technology Review)  2 Sam Altman lobbied against AI regulations he publicly welcomed  A bombshell report reveals many OpenAI insiders don’t trust him. (The New Yorker $) + Some have called him a sociopath. (Futurism) + OpenAI’s CFO fears it won’t be IPO-ready this year. (The Information $)  + A war over AI regulation is brewing in the US. (MIT Technology Review)  3 NASA’s Artemis II has broken humanity’s all-time distance record The astronauts have flown farther than any humans before them. (BBC) + Their mission includes MIT-developed technology. (Axios)  4 Chinese tech firms are selling intel “exposing” US forces It comes from combining AI with open-source data.. (WP $) + AI is turning the Iran conflict into theater. (MIT Technology Review)  5 War is pushing countries to ditch hyperscalers Driven by Iran naming tech giants as military targets. (Rest of World) + No one wants a data center in their backyard. (MIT Technology Review)  6 OpenAI, Anthropic, and Google have united against China’s AI copying They’re sharing information on “adversarial distillation” (Bloomberg $)  7 Anduril and Impulse Space are working on Trump’s “Golden Dome” They’re developing space-based missile tracking for the project. (Gizmodo)   8 OpenAI has urged California to probe Elon Musk’s “anti-competitive behavior.” It accuses Musk of trying to “take control of the future of AGI.” (Reuters $) + And claims he coordinated attacks with Mark Zuckerberg. (CNBC) + A former Tesla president has revealed how he survived working for Musk. (WP $)  9 DeepSeek’s new AI model will run on Huawei chips It’s expected to launch in the next few weeks. (The Information $)  10 Memes have nuked our culture Internet “brain rot” has escaped our phones to take over everything. (NYT $)  Quote of the day  “I must say, it was actually quite nice.”   —Astronaut Victor Glover tells President Donald Trump what it was like when Artemis II was out of communication with the rest of humanity, The New York Times reports.  One More Thing  PABLO ALBARENGA Inside the controversial tree farms powering Apple’s carbon-neutral goal   In 2020, Apple set a goal to become net zero by the end of the decade. To hit that target, the company is offsetting its emissions by planting millions of eucalyptus trees in Brazil.  Apple is betting that the strategy will lead to a greener future. But critics warn that the industrial tree farms will do more harm than good.  Find out why the plans have sparked a backlash.  —Gregory Barber  We can still have nice things  A place for comfort, fun and distraction to brighten up your day. (Got any ideas? Drop me a line.)  + Japan’s automated bike garage is a cyclist’s dream come true.  + This deep dive into bird behavior reveals the secrets of their dining habits. (Big thanks to reader Terry Gordon for the find!) + The first photo from the Artemis astronauts vividly captures the glow of our atmosphere. + There’s a new contender for the world’s most gorgeous website: RobertDeNiro.com. 

Unlike static, rules-based systems, AI agents can learn, adapt, and optimize processes dynamically. As they interact with data, systems, people, and other agents in real time, AI agents can execute entire workflows autonomously. But unlocking their potential requires redesigning processes around agents rather than bolting them onto fragmented legacy workflows using traditional optimization methods. Companies must become agent first. DOWNLOAD THE ARTICLE In an agent-first enterprise, AI systems operate processes while humans set goals, define policy constraints, and handle exceptions. “You need to shift the operating model to humans as governors and agents as operators,” says Scott Rodgers, global chief architect and U.S. CTO of the Deloitte Microsoft Technology Practice. The agent-first imperative With technology budgets for AI expected to increase more than 70% over the next two years, AI agents, powered by generative AI, are poised to fundamentally transform organizations and achieve results beyond traditional automation. These initiatives have the potential to produce significant performance gains, while shifting humans toward higher value work. AI is advancing so quickly that static approaches to task automation will likely only produce incremental gains. Because legacy processes aren’t built for autonomous systems, AI agents require machine-readable process definitions, explicit policy constraints, and structured data flows, according to Rodgers. Further complicating matters, many organizations don’t understand the full economic drivers of their business, such as cost to serve and per-transaction costs. As a result, they have trouble prioritizing agents that can create the most value and instead focus on flashy pilots. To achieve structural change, executives should think differently. Companies must instead orchestrate outcomes faster than competitors. “The real risk isn’t that AI won’t work—it’s that competitors will redesign their operating models while you’re still piloting agents and copilots,” says Rodgers. “Nonlinear gains come when companies create agent-centric workflows with human governance and adaptive orchestration.” Routine and repetitive tasks are increasingly handled automatically, freeing employees to focus on higher value, creative, and strategic work. This shift improves operational efficiency, fosters stronger collaboration, and generates faster decision-making—helping organizations modernize the workplace without sacrificing enterprise security. Download the article. This content was produced by Insights, the custom content arm of MIT Technology Review. It was not written by MIT Technology Review’s editorial staff. It was researched, designed, and written by human writers, editors, analysts, and illustrators. This includes the writing of surveys and collection of data for surveys. AI tools that may have been used were limited to secondary production processes that passed thorough human review.

Writing fast GPU code is one of the most grueling specializations in machine learning engineering. Researchers from RightNow AI want to automate it entirely. The RightNow AI research team has released AutoKernel, an open-source framework that applies an autonomous LLM agent loop to GPU kernel optimization for arbitrary PyTorch models. The approach is straightforward: give it any model before you go to bed, and wake up to faster Triton kernels — no GPU expertise required. https://arxiv.org/pdf/2603.21331 Why GPU Kernels Are So Hard to Optimize A GPU kernel is a function that runs in parallel across thousands of GPU cores. When you run a transformer model like LLaMA or GPT-2, the bulk of compute time is spent inside kernels for operations like matrix multiplication (matmul), softmax, layer normalization, and attention. These kernels live in libraries like cuBLAS and cuDNN, or get generated automatically by PyTorch’s compilation pipeline. The problem is that squeezing maximum performance out of these kernels requires reasoning simultaneously about arithmetic intensity, memory coalescing, register pressure, tile sizes, warp-level synchronization, and tensor core instruction selection — a combination of skills that takes years to develop. A single high-performance matmul kernel may involve 200+ lines of CUDA or Triton code with dozens of interdependent parameters. This expertise is scarce, and the manual tuning process scales poorly as model architectures evolve. The benchmark suite KernelBench, which evaluates frontier LLMs on 250 GPU kernel problems, found that even the best models matched PyTorch baseline performance in fewer than 20% of cases using one-shot generation. AutoKernel was built directly in response to that gap. The Loop: Edit, Benchmark, Keep or Revert AutoKernel’s core insight is that an expert kernel engineer’s workflow is itself a simple loop: write a candidate, benchmark it, keep improvements, discard regressions, repeat. The framework mechanizes this loop. An LLM agent modifies a single file — kernel.py — a fixed benchmark harness verifies correctness and measures throughput, and the result determines whether the change persists. Crucially, every experiment maps to a git commit. Kept experiments advance the branch; reverted experiments are erased cleanly with git reset. The entire history is browsable with standard git tools, and experiment results are logged to a plain tab-separated results.tsv file — dependency-free, human-readable, and trivially parseable by the agent. Each iteration takes approximately 90 seconds — 30 seconds for correctness checking, 30 seconds for performance benchmarking via Triton’s do_bench, and 30 seconds for agent reasoning and code modification. At roughly 40 experiments per hour, an overnight 10-hour run yields 300 to 400 experiments across multiple kernels. This design draws directly from Andrej Karpathy’s autoresearch project, which demonstrated that an AI agent running a keep/revert loop on LLM training code could discover 20 optimizations across 700 experiments in two days on a single GPU. AutoKernel transplants this loop to kernel code, with a different search space and a correctness-gated benchmark as the evaluation function instead of validation loss. The agent reads a 909-line instruction document called program.md, which encodes expert knowledge into a six-tier optimization playbook. The tiers progress from block size tuning (sweeping tile dimensions through powers of 2, adjusting num_warps and num_stages) through memory access patterns (coalesced loads, software prefetching, L2 swizzling), compute optimizations (TF32 accumulation, epilogue fusion), advanced techniques (split-K, persistent kernels, Triton autotune, warp specialization), architecture-specific strategies (TMA on Hopper, cp.async on Ampere, adjusted sizes for L4/RTX), and finally kernel-specific algorithms like online softmax for attention and Welford’s algorithm for normalization. The instruction document is intentionally comprehensive so the agent can run 10+ hours without getting stuck. https://arxiv.org/pdf/2603.21331 Profiling First, Optimizing Where It Matters Unlike prior work that treats kernel problems in isolation, AutoKernel starts from a complete PyTorch model. It uses torch.profiler with shape recording to capture per-kernel GPU time, then ranks optimization targets using Amdahl’s law — the mathematical principle that the overall speedup you can achieve is bounded by how much of the total runtime that component represents. A 1.5× speedup on a kernel consuming 60% of total runtime yields a 1.25× end-to-end gain. The same speedup on a kernel consuming 5% of runtime yields only 1.03×. The profiler detects GPU hardware from a database of known specifications covering both NVIDIA (H100, A100, L40S, L4, A10, RTX 4090/4080/3090/3080) and AMD (MI300X, MI325X, MI350X, MI355X) accelerators. For unknown GPUs, it estimates peak FP16 throughput from SM count, clock rate, and compute capability — making the system usable across a wider range of hardware than just the latest NVIDIA offerings. The orchestrator (orchestrate.py) transitions from one kernel to the next when any of four conditions are met: five consecutive reverts, 90% of GPU peak utilization reached, a two-hour elapsed time budget, or a 2× speedup already achieved on that kernel. This prevents the agent from spending excessive time on kernels with diminishing returns while higher-impact targets wait. Five-Stage Correctness Harness Performance without correctness is useless, and AutoKernel is particularly thorough on this front. Every candidate kernel passes through five validation stages before any speedup is recorded. Stage 1 runs a smoke test on a small input to catch compilation errors and shape mismatches in under a second. Stage 2 sweeps across 8 to 10 input configurations and three data types — FP16, BF16, and FP32 — to catch size-dependent bugs like boundary handling and tile remainder logic. Stage 3 tests numerical stability under adversarial inputs: for softmax, rows of large identical values; for matmul, extreme dynamic range; for normalization, near-zero variance. Stage 4 verifies determinism by running the same input three times and requiring bitwise identical outputs, which catches race conditions in parallel reductions and non-deterministic atomics. Stage 5 tests non-power-of-two dimensions like 1023, 4097, and 1537 to expose masking bugs and tile remainder errors. Tolerances are dtype-specific: FP16 uses atol = 10⁻², BF16 uses 2 × 10⁻², and FP32 uses 10⁻⁴. In the paper’s full evaluation across 34 configurations on an NVIDIA H100, all 34 passed correctness with zero failures across eager, compiled, and custom kernel outputs. Dual Backend: Triton and CUDA C++ AutoKernel supports both Triton and