Get more performance from your real-time perception and intelligence stack, with an agent that actually understands your target compute and knows how much performance headroom is remaining.
Orin & Thor
Supported platforms today. More coming soon.
The steps below let RunLocal optimize your proprietary stack while minimizing IP sharing. For open-source models, just share the repository and target HW/SW versions.
Your coding agent uses the RunLocal Skill to locally prepare a Request Package from your internal model stack. You review it, then your agent uploads it to the RunLocal Platform.
No weights or training data are uploaded; full source code is not required. See the docs for details.
Our agentic ML compiler explores implementation changes for supported workloads on your target compute platform. We evaluate candidate performance and numerical accuracy using RunLocal’s infrastructure.
It experiments with inference optimizations, including custom kernels, quantization, operator fusion, and scheduling. It doesn’t perform distillation or broader model architecture changes (currently).
Optimized code, results, and insights are uploaded to the RunLocal Platform as a Deliverable Package. Your coding agent downloads it and integrates the changes locally. You then validate the results locally.
The problem RunLocal solves
Device access and profiling help an agent understand how an existing implementation runs. On their own, they do not establish how an untested change will affect performance, what causes a bottleneck, or how much performance headroom remains.
RunLocal connects workload facts, a custom MLIR compiler and hardware models calibrated on real devices. The same chain links a proposed change to its resource costs, its predicted effect and the evidence needed to test it. Skip to our secret sauce
An agent can identify a hotspot and suggest plausible optimizations, without a reliable basis for ranking which changes will help most.
Choosing between them requires predicting how compiler choices affect interacting hardware mechanisms across the workload. A change can relieve one bottleneck while making another more important, and testing every possibility on-device takes too long.
More device runs can leave the root cause of a slowdown unclear and the next optimization little better informed.
Different bottlenecks can produce similar timings. Changing several things at once can hide which caused an improvement, so the agent needs experiments that isolate the relevant causal effects within a limited device budget.
An agent can stop with performance headroom left, or keep searching where little remains, because recent results have plateaued.
A plateau describes the results found so far. Estimating the remaining opportunity requires performance bounds grounded in the workload and device, with assumptions and uncertainty made clear.
The cost to your real-time intelligence stack
You're leaving performance on the table, without a clear sense of how much is remaining, and taking longer to hit your performance targets.
Improve performance, reduce costs, and plan your next move with more confidence.
Run your stack faster on the same compute
Fit larger models on the same compute
Do more without hiring more rare ML compiler talent
Meet performance targets with cheaper compute
Better estimate whether models will fit your compute
Better estimate performance headroom before committing
When standard compilers and libraries don’t deliver the performance you need
Workloads whose shapes or execution paths vary at runtime, such as sparse LiDAR perception with changing occupied-voxel counts.
Multiple models sharing hardware or feeding into one another, where coordinating execution and data movement can reduce overall latency.
Custom and emerging model operations that need more than standard library kernels.
Our secret sauce
RunLocal connects workload facts, a custom MLIR compiler and hardware models calibrated on real devices. The same chain links a proposed change to its resource costs, its predicted effect and the evidence needed to test it.
RunLocalOur Hardware Reasoning Engine models instructions, memory access, resource contention and dependencies together. We calibrate supported models against benchmarks from real devices to help identify what limits execution and predict the effect of changing it. The model distinguishes how long hardware resources stay busy, when results become available and when storage can be reused. These differences determine which operations can overlap and which must wait, helping us predict when removing one bottleneck will expose another.
Our MLIR dialects represent computation, data movement, dependencies and scheduling. Workload facts—such as known shapes, layouts and ordering—guide which transformations are valid. For supported compiler paths, we connect these representations to generated code. Our reasoning engine uses this information to predict the combined hardware effects of optimization candidates, compare expected runtimes and identify likely constraints before device testing. Each prediction is connected to a specific implementation.
Our reasoning engine derives a lower runtime bound from the computation, data movement and dependencies a workload requires. It considers instruction throughput, memory traffic and the longest chain of dependent work under stated hardware and numerical assumptions. The gap to measured performance bounds the remaining opportunity within that scope. We can also relax individual constraints in the model to predict which bottleneck would come next and which changes could bring execution closer to the limit.
When benchmarks leave device behavior uncertain, we compare how competing explanations would respond to additional tests. Controlled changes to dependency depth, memory footprint or concurrency can reveal differences hidden by similar total runtimes. We select tests where the explanations predict different timings or hardware-counter responses, then compare those predictions with device measurements. This focuses device time on reducing uncertainty in the hardware model, so the agent can compare optimization candidates with better information.
Our Hardware Knowledge Base retains benchmarks across instruction types, memory patterns and concurrency, together with calibrated device behavior. Each measurement keeps its program identity and test conditions, so we can assess revised models without repeating the original device runs. We use benchmarks excluded from calibration to assess predictive accuracy for the tested device and workload conditions. New workloads combine this knowledge with their own instructions and dependencies, reusing the work of measuring and explaining the device across optimization projects.
Help customers get more from your silicon. Bring their models onto your platform faster, broaden your model zoo, and improve the software behind it.
Book A Call (opens in a new tab)Port and optimize customer models faster without hiring more support engineers.
Add and maintain support for more models without hiring a large internal optimization team.
Use insights from RunLocal to improve your compiler, libraries, and developer tools.
See how you use RunLocal, and read the docs for more detail.
The challenge is helping the agent decide which implementation changes to try, understand their combined effects, and know how much performance remains. RunLocal adds compiler control, calibrated hardware models, reusable experiment knowledge and infrastructure for running and validating the search. See our secret sauce.
Building it means maintaining compiler integrations, hardware calibrations, reliable device experiments and correctness checks across models, devices and SDK versions. RunLocal provides that system and the hardware knowledge already collected, so your team can focus on its autonomy/perception stack.
We’re also building reusable compiler rules and experiment knowledge across projects, extending the coverage an individual team would otherwise need to develop itself.
For supported workloads, our own MLIR-based compiler provides an alternative path when the standard vendor compilation path restricts useful changes. On Qualcomm, it can produce QNN graphs directly while retaining Qualcomm’s backend and runtime. On NVIDIA, we can generate custom kernels for selected parts of a workload and retain TensorRT where it is useful. The choice depends on the workload and the performance opportunity.
Compiler-level changes include custom kernels, operator fusion, memory layouts, data movement, precision choices and execution scheduling. We consider the full inference workload, including interactions between operations and models. Distillation and broader model architecture changes are outside the current scope.
No. The Request Package describes your stack without requiring weights, training data, or full source code. See the docs.
A Deliverable Package on the RunLocal platform: optimized code or a binary, a performance report, and integration instructions. Your coding agent downloads and integrates it locally. You validate correctness and performance on your target compute.
A subscription gives your team access to RunLocal for a fixed recurring fee. Optimization requests are priced separately. For each request, we agree on performance targets, provide a fixed quote, and estimate the timeline. You only pay for that optimization if the agreed targets are met.
Start by booking a call to discuss your stack and target compute. We can then align on a 1-week pilot to prove RunLocal's optimization capability before you commit to something longer-term.
Tell us about your stack and target hardware. We’ll discuss where RunLocal could help and whether a 1-week pilot is a good fit.
BACKED BY
