Gaps in toolchain support
Limited operator support, shape and precision restrictions, and inefficient hardware mappings.
Agentic model porting for
edge compute platforms
Port your AI stack for target hardware faster and with less hassle, and get better performance with an agent that actually understands the hardware.
Orin & Thor
More platforms coming soon
How it works
Optimize your proprietary stack with minimal IP sharing. For open-source models, share the repository and target hardware/software versions.
Prepare & submit
Locally prepare a Request Package with your model’s ops, shapes, and target hardware. Upload it to your account on the RunLocal Platform.
No weights, training data, or full source code required.
RunLocal optimizes
RunLocal’s agent optimizes it on our infrastructure and device farm: graph rewrites, custom kernels and fusion, quantization, and compiler flags.
It does not currently distill models or change architectures.
Apply & validate
Pull optimized code, artifacts, and reusable hardware insights from the RunLocal Platform. Integrate and validate the changes locally in your stack.
The business value
Port models faster, improve performance, choose hardware confidently, guide future model research, and do more with your existing team.
Port models in days instead of weeks
Reach the market sooner and reduce supply chain risk.
Where it’s most useful
When model requirements and hardware constraints need closer attention
Dynamic workloads
Models with input-dependent computation, such as LiDAR with changing occupied voxel counts.
Complex pipelines
Multiple models sharing compute and memory, with dependencies in execution and data movement.
The problem RunLocal solves
A coding agent with device access isn’t enough
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
01
Struggles to rank promising changes
An agent can identify a hotspot and suggest plausible optimizations, without a reliable basis for ranking which changes will help most.
Why this happens
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.
02
Can collect more measurements without resolving the cause
More device runs can leave the root cause of a slowdown unclear and the next optimization little better informed.
Why this happens
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.
03
Can stall without knowing what remains
An agent can stop with performance headroom left, or keep searching where little remains, because recent results have plateaued.
Why this happens
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
Worse performance. Slower optimization cycles. Less confidence.
You're leaving performance on the table, without a clear sense of how much is remaining, and taking longer to hit your performance targets.
Our secret sauce
An agent that actually understands your target compute
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.
Agent
Tests & ProfilesResults
Device
ChangesPredictions
RunLocalBenchmarks
Custom MLIR Compiler
Hardware Reasoning Engine
Hardware Knowledge Base
Execution
Calibration
Causal effects of a change
01
Causal and Predictive Hardware Modeling
Our 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.
Combined hardware effects
02
Custom MLIR Compiler
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.
Remaining performance headroom
03
Performance Bounds and Remaining Headroom
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.
Removing unsupported explanations
04
Targeted Experiments for Uncertain Predictions
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.
Shared calibration, different workloads
05
Reusable Benchmark Data and Hardware Knowledge
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.
For silicon vendors
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)Resolve customer requests faster
Port and optimize customer models faster without hiring more support engineers.
Grow your model zoo faster
Add and maintain support for more models without hiring a large internal optimization team.
Improve your software stack
Use insights from RunLocal to improve your compiler, libraries, and developer tools.
FAQ
How do we use RunLocal?
See how you use RunLocal.
What makes your agent so good?
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.
Why shouldn't my team build this?
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.
Is RunLocal an alternative to TensorRT or QAIRT?
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.
What kinds of optimizations does your agent make?
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.
Do we need to share weights, training data, or full source code?
No. The Request Package describes your stack without requiring weights, training data, or full source code.
How do we receive your optimizations?
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.
How does pricing work?
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.
Can we try before we buy?
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.
Get more from your edge compute
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
