Your agents
Your endpoint
Rent dedicated hardware.
Choose an endpoint for your model. Get dedicated hardware, your own URL and a key. The capacity is yours to use.
Backed by
Y Combinator
More tokens.Same hardware. Same quality.
Dedicated inference for open models, tuned to your workload. We optimize the serving stack to get more from your hardware while preserving model quality.
Paste this into your coding agent:
Connect your agent to browse, launch and stop endpoints. You sign in and approve access in your browser; connecting does not start a model or rent hardware.
Or add it yourself
- Your modelOriginal quality preserved
- Your workloadOptimized for real traffic
- The whole stackServing engine to assembly
- More throughputFrom the same hardware
Self-optimizing inference endpoints
Dedicated capacity.
A fixed rate. More room to run.
Choose a measured configuration or bring your model. Run on InfraOptimal-managed GPUs and pay for hardware time, not tokens.
Optimized endpoints
Start with a measured configuration.
Compare model, hardware, price and the workload behind each performance result.
Browse endpoints → Custom endpointBring your open model.
Choose a model, review the recommended hardware, then confirm the price and spending limit.
Choose a model →No token limits.
Send parallel work without a token quota. Run as many agents as your hardware can serve; dedicated capacity sets the pace.
Pay by capacity.
A fixed rate for the hardware you choose, for the time you use it. No per-token charges. Billing increments are shown before launch.
Keep improving.
We optimize for your traffic in the background, testing ways to get more throughput from the capacity you already rent.
Connect your agents.
Use your endpoint from an OpenAI-compatible client, or explore tools for parallel agent work.
How we optimize
Autonomous
performance optimization.
Your model and workload define the test. Agents propose changes, measure them on the target hardware, and retain only candidates that pass the required quality and performance checks.
Your model. Your traffic.
The original model is the reference. We characterize your workload: request sizes, concurrency and reusable context. That workload and the target hardware define the optimization problem.
Agents do the iteration.
Agents propose changes, profile bottlenecks and run experiments. They can search serving policies, model execution and low-level code within the scope allowed by the runtime.
Every result faces the same rules.
Candidate and baseline run under the same conditions. Repeated comparisons and held-out workloads decide which changes qualify. The measured result and its configuration are retained for the next iteration.
Where the speed comes from
Performance lives
across the stack.
Explore the software layers we work on and the hardware constraints they share. The model remains the reference; the implementation is what changes.
Fixed referenceYour original model + your workloadSoftware changes are tested against this contract.
Model execution / We optimize
Preserve the model. Improve its implementation.
The original model defines the computation. We explore how that computation is carried out: operator fusion, reusable work and model-specific algorithms, under the model's fixed behavior contract.
- What we optimize
- Computation graphs, operator combinations and reusable intermediate work.
- What stays fixed
- The original model remains the reference for every candidate.
Serving engine / We optimize
Make the engine fit the traffic.
Request scheduling, batching and cache management determine how much useful work the GPUs receive. We optimize these decisions together for your workload and target hardware.
- What we optimize
- Batch formation, request scheduling, KV-cache reuse and serving policies.
- What stays fixed
- The same model and service-level constraints govern each comparison.
Device placement / We optimize
Put work where it runs best.
How a model is divided across devices affects memory use, communication and throughput. We explore partitioning, replication and data movement for the available devices and their interconnect.
- What we optimize
- Tensor, pipeline and data parallelism; placement of computation and state.
- What stays fixed
- The target hardware and the permitted deployment scope stay explicit.
Kernel design / We optimize
Build the operations the model needs.
We optimize the work inside GPU kernels: fuse operations, choose tiles and layouts, reuse data and reduce unnecessary memory traffic. Each change is evaluated as part of the full serving workload.
- What we optimize
- Operator implementations, tiling, fusion and memory-access patterns.
- What stays fixed
- A faster isolated kernel must still improve the end-to-end workload.
Compiler & assembly / We optimize
Carry the optimization down to instructions.
Code generation, instruction selection and scheduling connect the model's operations to the device. We specialize these choices for the target instruction set, register budget and execution resources.
- What we optimize
- Compiler transformations, generated assembly and instruction scheduling.
- What stays fixed
- Changes remain subject to the same model-behavior and performance contract.
ISA & microarchitecture / Hardware target
Optimize for the machine that will run it.
The instruction set, compute units, memory hierarchy and interconnect constrain what is fast. We use those constraints to guide software changes and measure the result on the target hardware.
- How it guides the search
- Hardware-aware software choices, from serving policies down to assembly.
- The boundary
- The existing hardware is the target of optimization; chip design is outside this scope.
A decade at the hardware‑software boundary.
Backed by Y Combinator.
Kaden Cassidy
Top 20 in the Anthropic kernel optimization challenge. 600+ certification tests shipping in RISC-V International's ACT4 suite.
Parth Kocheta
Sped up petabyte-scale robotics infrastructure at Amazon. Visual-inertial odometry for autonomous drones at CMU's AirLab.