Research
Technical research
How to Rewrite Apache Spark UDFs for GPU Acceleration with AI Agents
13 Oct 2026
Open the thinkingAI research
From CUDA to MLX: How K-Search Brings Decades of Kernel Expertise to Apple Silicon
THE CONTEXTEvidence for
Evidence for
Transferring an optimisation between hardware architectures.
Research status: Publisher research announcement; read the original methods and evidence. The status supplied by the source is shown here; examine the method and scope in the original work.
How this was reviewed: Article-level review.
Berkeley and IBM researchers describe adapting a kernel-search approach from CUDA to Apple's MLX environment. Their system combines hardware constraints, generated candidates and measurements on real devices. The reported results vary by kernel: one attention comparison does not beat its native baseline, while another workload improves substantially against a community implementation. The article offers a research approach to transferring optimisation knowledge, with the comparison context remaining essential.
This blog describes research linked to a preprint; peer-review status is not established here. Its comparisons use particular kernels, baselines and hardware, with mixed relative results. They do not establish that a complete application will be cheaper, faster or more accurate on every Apple device or client workload.
OUR EDITORIAL CONNECTION
Portable ideas need local proof
Clients increasingly ask whether useful AI can operate closer to their own data. This belongs here because Page & Process investigates the practical environment behind an attractive promise. Hardware-aware research can inform that exploration, while a bespoke project still needs its own evidence about response time, correctness, cost and the kinds of information it handles.
The buyer question we would begin with
Can this capability run usefully in our environment, with an honest account of its limitations?
Look closer at
Transferring an optimisation between hardware architectures.
An optimisation discovered for one architecture raises a different question on another device. These layers separate an understandable capability from its implementation assumptions, then define what would have to transfer and what the project should measure for itself.
The PageWhat someone encounters.
A bespoke document-assistance workspace would show where processing occurs and when a task exceeds the supported local capability. The interface would preserve a usable manual route, make longer processing visible and explain any proposed external transfer before it happens. Instead of promoting a single benchmark number, the page would describe the client's actual supported tasks and the devices on which those tasks have been evaluated, using examples drawn from the intended workflow.
The ProcessWhat happens behind it.
Engineering would record the reference computation and supported hardware before exploring an optimisation. Candidate kernels would run in a constrained test environment with explicit correctness checks and a budget for search effort. The selected result would be kept with its configuration and evidence, rather than relying on a generated explanation. Production responsibility would include device compatibility, thermal behaviour, data handling and a fallback when the optimised path is unsuitable.
The ResearchWhat we need to understand.
We would first establish whether customers need local processing and which tasks justify it, rather than assume a particular chip solves the problem. Representative records would reveal size, structure and confidentiality constraints. A prototype study would compare response usefulness and acceptable waiting across the available devices. The research question is whether local capability meaningfully improves the user's workflow after accounting for support effort and cases that need a different execution path.
The TestHow we would find out.
The proposed local path would run the client's approved task set on named representative devices, with the same inputs and settings recorded for each comparison. Output checks must agree with the reference computation within its documented tolerance. Timings would include setup and memory movement, and repeated runs would expose thermal or resource instability. A task outside the supported range must fail clearly or use an authorised fallback, rather than silently degrade its result.
Choose the environment.
Check the capability there.
Show us the workload and hardware your service must actually use. We can compare the proposed implementation with its current baseline, inspect what transfers and record the conditions where a performance direction stops helping.