Edge AI chipmaker SiMa.ai raises $150m at a $1.45bn valuation
Investors are backing chips that run AI on robots and cameras rather than in the cloud, which rewards learners who can make models small and fast.
SiMa.ai, a startup that makes chips and software for running AI directly on robots, drones, cameras and other devices, has raised a $150 million Series C round at a $1.45 billion valuation, according to a report by TechCrunch on 28 September 2026. The round was co-led by Fidelity Management & Research Company and Amplify, with Alter Venture Partners, Dell Technologies Capital and StepStone Group also taking part.
The new valuation is up from $960 million at the company's Series B in July 2025, and SiMa.ai has now raised more than $500 million in total. The company was founded in 2018 by Krishna Rangasayee, a former chief operating officer of chipmaker Groq.
TechCrunch reports that SiMa.ai's chips are designed to be energy efficient and to remove the need to send data back and forth to the cloud. The company pitches low latency and lower prices than Nvidia's GPUs, and the report places the raise in the context of growing demand for physical AI and humanoid robots. The article did not give details of customers, revenue or specific products.
Why it matters
Most of the attention on AI hardware goes to data centre GPUs, but a large share of future AI will run on devices that cannot wait for a round trip to the cloud. A robot arm, a drone or a factory camera has to decide in milliseconds, often on a battery, and sometimes without a network at all. Investors backing a specialist edge chip company at a higher valuation suggests they expect that market to grow alongside physical AI. For learners, it signals demand for people who can make models small, fast and efficient enough to fit on this kind of silicon.
Most of the attention on AI hardware goes to data centre GPUs, but a large share of future AI will run on devices that cannot wait for a round trip to the cloud.
Where the model runs
Cloud: on a remote server. Edge: on or next to the device, such as a robot or camera.
Latency
Cloud adds a network round trip to every decision. Edge removes it.
Connectivity
Cloud stops when the network drops. Edge keeps working offline.
Constraints
Cloud has large memory and power. Edge must fit tight memory, compute and power budgets.
What you can learn from this
- Edge inference moves the model to the data. In cloud inference, a device sends its sensor data to a server, the server runs the model, and the answer travels back. Edge inference runs the model on or next to the device instead. This cuts latency because there is no network round trip, keeps working when the connection drops, and keeps raw data such as video on site, which helps with privacy and bandwidth costs. The price is that the model must fit the device's limited memory, compute and power budget.
- Why specialised accelerators beat general chips on efficiency. A neural network spends most of its time multiplying and adding large grids of numbers. A general-purpose CPU handles this one instruction at a time, and a GPU spreads it across thousands of flexible cores, but both carry circuitry the task does not need. A dedicated machine learning accelerator arranges many multiply-accumulate units in fixed patterns and keeps data close to them, so less energy is spent moving numbers around. Since moving data costs far more energy than doing arithmetic on it, this design is where most of the efficiency gain comes from.
- Quantisation makes models fit. Models are usually trained with 32-bit or 16-bit floating point numbers, but many edge chips run fastest on 8-bit or even 4-bit integers. Quantisation maps each weight and activation onto that smaller range, shrinking memory use and speeding up arithmetic. Done carefully, often with a small calibration dataset, accuracy drops only slightly. Done carelessly, small objects stop being detected or rare classes vanish, which is why testing after quantisation matters.
- Latency budgets drive the design of physical AI. A system that controls movement has a hard deadline for each decision, set by how fast the world around it changes. Engineers break that budget into pieces: capturing the sensor frame, preprocessing it, running the model, and acting on the result. If the model alone takes longer than the budget, no amount of cloud capacity helps. This is why robotics teams care about worst-case latency, not just average speed.
- The software stack decides whether hardware gets used. A chip is only useful if developers can get their models onto it. That requires a compiler that turns a trained model into instructions for the chip, plus tools for quantisation, profiling and debugging. Many promising chips have struggled because moving from a familiar GPU workflow was too painful. When evaluating any accelerator, the quality of its toolchain is as important as its peak performance figures.
We teach this in the AI Tutor
How to use this in practice
- Measure a model's latency on your own laptop. Install PyTorch and load a small image model such as MobileNetV3 from torchvision. Time 100 forward passes on a single image at batch size one and record the average and the slowest run. Discard the first few runs, because the first passes include warm-up work that a deployed device would do only once. Done is two numbers in milliseconds and a sentence on whether they would meet a 30 frames per second budget of about 33 ms.
- Quantise the same model and compare. Export the model to ONNX and use ONNX Runtime's dynamic or static quantisation tools to produce an 8-bit version. Rerun your timing script and check the file size. Keep the input image and batch size identical so the comparison is fair. Done is a small table showing size, average latency and slowest latency for the original and quantised models.
- Check what accuracy you lost. Run both versions over a few hundred labelled images from a public dataset such as a subset of ImageNet or CIFAR-10. Count how often the top prediction matches the label, and note any classes where the quantised model is noticeably worse than the original. Done is an accuracy figure for each model and a note on whether the drop is acceptable for your use.
- Write a latency budget for a device you know. Pick a real system, such as a doorbell camera or a delivery robot, and split its reaction time into capture, preprocessing, inference and action. Assign each stage a number of milliseconds and justify it, then compare the inference slice with the timings you measured earlier. Done is a one-page budget that tells you how fast the model must be before you choose any hardware.
Sources
Our reporting is an original summary. Full coverage is at the links above.
How do you score in Artificial Intelligence?
A few minutes of questions, then a report on where you stand and what to learn next.