Cactus Compute Mirage: The 22 MB Vision Model for On-Device AI

TL;DR

Cactus Compute Mirage is a 22 MB vision language model built for on device image understanding. In a single pass it combines scene description, object detection, OCR, image segmentation, spatial reasoning and structured form extraction, and returns machine readable JSON that applications, robots and language models can act on directly.

ELI5 Introduction

Imagine a tiny artificial intelligence that can look at a photograph and answer several useful questions at once. It can say what is in the picture, find objects and draw boxes around them, read words on signs or packages, outline individual objects, explain how objects relate to one another, and even fill in a simple form based on what it sees. Mirage does all of this while running directly on a phone, smartwatch, robot or other device rather than relying on a distant data center.

Think of Mirage as a compact visual assistant. You show it an image, and it gives you an organized report: a description of the scene, a list of objects with their locations and attributes, text detected in the image, outlines that separate objects from their background, relationships between objects, and answers to specific questions or form fields.

The important idea is structured vision. Instead of simply saying, “There is a stop sign,” Mirage can identify the sign, locate it, describe its color and shape, recognize the word printed on it, connect it to its pole and return that information in a format an app can immediately use. That matters because real world AI products need more than a caption. A warehouse robot may need to identify a package, read its label and decide where to place it. A field inspection app may need to detect equipment, read a serial number and flag a missing safety item. A wearable may need to understand a scene while preserving battery life and user privacy.

Detailed Analysis

What Is Cactus Compute Mirage?

Cactus Compute Mirage is a small vision language model, or VLM, built for image understanding and structured extraction on consumer hardware. It has 51.3 million parameters and occupies about 22 MB when deployed with Cactus Quants, the company’s 2 bit quantization approach. Mirage is not a conventional image classifier that assigns one label to an entire photo. It is a multimodal perception system that returns a structured record containing scene information, objects, text, masks, relationships, events and reasoning.

The model can run locally in a browser, through a Python interface, or through native application integrations. Cactus positions it alongside Needle, its text generation model, and Whistle, its speech recognition model, as part of a broader portfolio of compact foundation models for edge devices.

Mirage combines several computer vision tasks in one model, and the capabilities are not isolated modules. They are produced in a single forward pass, which reduces the complexity of building multi model vision pipelines.

Why On Device Vision AI Matters

The market for AI is moving beyond large cloud hosted models toward systems that can operate directly on devices. This shift is driven by several practical needs: privacy, latency, offline reliability, bandwidth constraints and the growing number of intelligent endpoints. On device AI means the model runs where the data is created. A phone can analyze a photo without uploading it. A wearable can interpret its surroundings without a constant network connection. A robot can respond to its environment without waiting for a remote server. Mirage is explicitly designed for these environments.

On the privacy dimension, images often contain sensitive information: faces, documents, locations, medical details, proprietary equipment or customer environments. When vision inference happens locally, raw images do not need to leave the device merely to be understood. This does not eliminate every privacy obligation. Developers still need clear consent, secure storage, access controls and responsible retention policies. However, local inference can materially reduce exposure by keeping image data on the device during analysis.

On latency and reliability, cloud inference introduces network round trips. In environments with poor connectivity, such as factories, warehouses, vehicles, rural sites or disaster zones, that dependency can become a product limitation. Mirage’s reported end to end inference time is 74 milliseconds on a Samsung Galaxy S26 NPU and 107 milliseconds on its CPU. Those figures make it suitable for interactive use cases where a user needs immediate visual feedback.

On cost and scalability, cloud vision costs tend to scale with usage. Every image analyzed, stored or transmitted can create infrastructure expense. Local inference shifts much of the compute burden to hardware that customers already own. That does not mean edge AI comes at zero cost. Developers must still optimize models, manage updates, handle device fragmentation and design fallback behavior. But for high volume visual workflows, on device inference can reduce recurring cloud costs and improve unit economics.

How Mirage Works

Mirage uses an architecture designed to extract maximum value from a small parameter count and a compact deployment footprint. At a high level, an image enters the model, passes through an encoder that creates visual features, and then feeds a decoder that produces structured output. Detection, OCR and segmentation components share image features rather than requiring entirely separate systems.

The model uses a shared encoder across tasks. That means the same underlying visual representation supports object detection, masks, OCR and the final description. This design reduces duplicated computation and allows different outputs to remain connected to the same visual evidence. For example, when Mirage identifies a stop sign, it can provide a bounding box, a segmentation mask, attributes such as color and shape, and a relationship to the pole supporting it. These outputs form a small scene graph rather than disconnected predictions.

Quantization reduces the numerical precision used to represent model weights. Instead of storing every parameter with high precision floating point values, a quantized model uses fewer bits per value. Mirage uses Cactus Quants, a 2 bit deployment scheme that allows the model to fit in approximately 22 MB. Most quantized matrices use 2 bits, while selected components such as token embeddings, routing matrices and certain floating point tensors retain higher precision. The practical implication is significant: a capable vision model becomes small enough to distribute with an application, run on constrained hardware and load quickly on consumer devices.

One of Mirage’s most important differentiators is its output format. Rather than returning only natural language, it can return JSON containing scene attributes, objects with names, boxes, scores and attributes, segmentation masks, OCR text with locations and confidence scores, relationships and events, reasoning traces and structured form fields. This makes Mirage useful as a perception layer for software systems. A mobile app, robot controller or automation workflow can consume the JSON directly rather than parsing unstructured text.

Key Use Cases

Smartphones are an obvious deployment target. Mirage can support photo search, accessibility features, document capture, shopping assistance, field service tools and camera based productivity workflows. For example, a maintenance technician could photograph a machine panel. Mirage could detect the equipment, read the label, identify warning indicators and return a structured record that a service application uses to create a work order.

Wearables and augmented reality devices impose severe constraints on memory, power and thermal capacity. A 22 MB vision model is more compatible with these constraints than a large cloud dependent vision system. Potential applications include navigation assistance for visually impaired users, object identification in augmented reality, no touch inspection in industrial settings, context aware notifications, and accessibility and scene interpretation. Because Mirage supports local inference, a wearable can provide useful visual understanding even when connectivity is limited.

Robotics and automation workflows need to perceive the environment quickly and reliably. Mirage can help a robot identify objects, understand spatial relationships, read labels and make simple decisions. A warehouse robot, for example, could identify a package, locate it in space, read a shipping label and determine whether it belongs in a particular bin. The structured output makes it easier to connect perception to action.

Field operations teams often need to capture evidence quickly. Mirage can support inspection workflows by detecting assets, reading identifiers, extracting visible information and filling structured forms. Consider a utility inspection. A technician photographs a meter, transformer or signage. Mirage can identify the asset, read visible text, detect visible defects or labels and populate a form. A human reviewer can then validate the result before it enters a system of record.

Applications involving home environments, personal photos, children, healthcare adjacent contexts or confidential documents benefit from a privacy first design. Local inference allows the application to provide useful intelligence without routinely transmitting raw visual data to a backend.

Market Context: Why Small Models Matter

The broader AI market is entering a phase where model usefulness is increasingly measured by deployment practicality, not only benchmark performance. Enterprises and consumer product teams need systems that work within real constraints: limited memory, intermittent connectivity, privacy requirements, battery limitations and cost pressure.

Cactus Compute’s positioning reflects this shift. Its portfolio includes compact models for mobile devices, wearables, AR glasses, smart homes, robotics, automotive systems, laptops, game consoles, TVs and microcontrollers. Mirage fits into a category that could be called deployment aware AI: models designed from the beginning for the environments where they will actually run.

This matters because many impressive AI demonstrations fail in production. A model may perform well in a research environment but become impractical when it must run repeatedly on a battery powered device, operate offline or return reliable structured data for a business workflow. Mirage addresses that gap by emphasizing a small footprint, local execution, structured output, multiple vision tasks in one model, compatibility with the broader Cactus ecosystem, and availability through Python and native interfaces.

Implementation Strategies

Start with a narrow workflow

The most effective deployments begin with one clearly defined outcome. Avoid trying to build a general purpose visual assistant on day one. Choose a workflow where visual understanding removes a measurable bottleneck: reading labels in a logistics process, detecting missing safety equipment, identifying products on a shelf, extracting fields from documents, supporting accessibility in a mobile app, or helping a robot recognize and locate objects.

A narrow scope makes it easier to define success, collect evaluation data and improve the product iteratively. It also makes it possible to ship something real within a quarter rather than a year, which keeps stakeholders engaged and learning cycles short.

Design the output contract first

Because Mirage returns structured JSON, teams should define the required output before integrating the model. A useful output contract may include objects and confidence thresholds, required OCR fields, mask format, maximum objects or text lines, language requirements, decision options, and error and low confidence behavior.

Mirage allows developers to request selected sections and fields, set confidence thresholds, limit output size and choose mask formats. Using these controls can improve both performance and reliability. Treat the output contract as an API design exercise rather than an afterthought. If the downstream application cannot consume the model’s response cleanly, the pipeline will leak complexity into every feature that touches it.

Use confidence thresholds deliberately

Mirage provides detection scores and OCR confidence values. These should not be treated as perfect truth signals, but they are valuable for workflow design. A practical approach is to define confidence bands: high confidence results can be automated, medium confidence results can show a review prompt, and low confidence results can request a clearer image or escalate to a human. This approach prevents the model from becoming a silent source of errors in operational workflows.

Pair Mirage with a language model when needed

Mirage can pass its structured output to a text only language model. The language model does not see the original pixels; it reasons over Mirage’s observations. This separation can be useful when an application needs to answer a complex question, generate a report or guide a user through a workflow. However, it also creates a dependency: if Mirage omits an important visual detail, the downstream language model cannot recover it.

Cactus tested this approach with Qwen3 0.6B using 256 VQAv2 validation questions across 128 images. The company reported a score of 31.3 out of 100 on VQA consensus credit when using Mirage’s structured record and complete trace, compared with 22.2 when providing a record from another image. It also found that omitting the trace produced a score of 33.1, meaning the trace did not provide a reliable benefit in that experiment.

The strategic lesson is clear: structured perception can enable text based reasoning, but teams should evaluate the full pipeline rather than assume that adding a language model automatically improves accuracy.

Build human review into high stakes flows

For workflows involving compliance, safety, financial decisions, medical contexts or irreversible actions, AI should assist rather than replace accountable human judgment. A robust design includes clear confidence indicators, visual overlays for detected objects and text, easy correction controls, audit trails, escalation paths and regular quality monitoring.

No vision model should be treated as infallible. Mirage’s own documentation acknowledges that its outputs are predictions and that its reasoning trace may contain incorrect inferences. Object names come from the language model and are not restricted to a fixed class list, which increases flexibility but can introduce labeling errors. OCR can misread text, particularly in low quality images, unusual fonts or challenging lighting. A downstream language model can only reason from the information Mirage provides, so missing visual details remain unavailable to it. Real world performance also depends heavily on device hardware, image quality and workflow design. The appropriate posture is confident but disciplined. Use Mirage to accelerate perception and reduce manual work, while retaining validation mechanisms where errors carry operational or safety consequences.

Best Practices and Case Studies

Optimize for the actual device

Benchmarks on one device do not guarantee similar performance on another. Teams should test on representative hardware, operating system versions, camera conditions and real world lighting environments. Key variables include CPU versus NPU execution, available memory, thermal constraints, camera quality, image resolution, background app activity, battery state and network availability. Mirage’s reported performance on a Samsung Galaxy S26 is encouraging, but product teams should validate performance across their intended device population.

Reduce unnecessary output

Generating every available field increases compute and integration complexity. Mirage supports selective output, allowing developers to request only the sections and fields they need. For example, an application that only needs OCR and object boxes should not necessarily request full segmentation masks, scene descriptions and reasoning traces. Trimming output can improve speed and reduce downstream parsing complexity.

Use constrained decisions

When an application needs a decision, provide a limited set of choices rather than asking an open ended question. Mirage supports choices from supplied labels, bounded counts, short text fields and object linked answers. For instance, instead of asking, “What is wrong with this equipment?” an inspection app might ask Mirage to select from Normal, Minor defect, Major defect, or Unable to determine. This creates more predictable outputs and makes quality assurance easier.

Maintain an evaluation set

Every vision AI deployment needs a living evaluation set that reflects real operating conditions. It should include common cases, edge cases, poor lighting, motion blur, occlusion, unusual objects, multilingual text, adversarial or ambiguous scenes and failure examples. Teams should track accuracy, false positives, false negatives, latency, crash rates, user corrections and downstream business outcomes.

Protect user trust

Even when inference is local, users should understand what the application is doing. Clear communication builds trust and reduces misuse. Best practices include explaining when camera analysis is active, providing a visible indicator during inference, allowing users to delete captured images, avoiding data collection without a clear purpose, separating model updates from silent behavioral changes, and providing accessible alternatives for users who cannot use camera features.

Case example: field service inspection

A facilities maintenance company could deploy Mirage in a technician mobile app. When a technician photographs equipment, Mirage identifies the asset, reads its label, detects visible components and extracts fields such as serial number, model type or status indicator. The app can then prepopulate a service record. If confidence is low, the technician reviews and corrects the result. Over time, the company builds a labeled dataset from corrections, improving both model selection and workflow design. The business value comes from reduced manual data entry, faster documentation and more consistent inspection records.

Case example: retail shelf monitoring

A retail operations team could use Mirage to analyze shelf photographs. The model identifies products, reads labels, detects empty spaces and returns a structured record of shelf conditions. A store associate receives a prioritized task list rather than a vague image description. The system can flag missing items, misplaced products or unreadable labels for human review. The key is to treat Mirage as a perception layer, not a fully autonomous decision maker. A human or business rule engine makes the final operational decision.

Case example: accessibility and navigation

A navigation aid could use Mirage to describe surroundings, identify objects and detect text such as door signs, street names or transit information. Because Mirage supports multiple languages, including English, German, French, Spanish, Italian, Dutch and Polish, it can support multilingual user experiences. The application should avoid overstating certainty. Instead of claiming that an object is definitely a particular item, it can present the detected label, confidence and visual context, allowing the user to make an informed decision.

Case example: robotics and logistics

In a warehouse, Mirage can support object recognition, label reading and spatial reasoning. A robot can use detected boxes and masks to understand where objects are located, while OCR helps identify packages or inventory labels. The most effective architecture separates perception from action. Mirage provides structured observations. A planning or control system determines the appropriate response. This separation improves safety, testability and maintainability.

Conclusion

Cactus Compute Mirage signals an important direction for applied AI: intelligence does not need to live exclusively in the cloud, and vision models do not need to be enormous to be useful. By combining detection, OCR, segmentation, scene understanding and structured extraction in a 22 MB package, Mirage makes on device visual intelligence more practical for products that must be fast, private and reliable. Its strongest role is as a perception layer that converts images into structured information applications, robots and language models can act upon. Its approximately 22 MB footprint and 2 bit Cactus Quants deployment make it relevant for phones, wearables, robots and other edge environments, while structured JSON output is the central product advantage because it turns visual perception into usable application data.

For organizations building mobile, wearable, robotics or field operations products, the opportunity is not simply to add computer vision. It is to redesign workflows around structured perception, local execution and human centered automation. On device inference supports privacy, lower latency and offline operation, though it does not remove the need for strong governance and validation. Successful adoption depends less on model novelty and more on workflow design, evaluation, confidence handling and human oversight. Teams that begin with a focused use case, validate performance in real conditions and design clear escalation paths will be best positioned to turn compact vision AI into durable product advantage.