MiniCPM-V reads images, while MiniCPM-o adds speech
MiniCPM-V turns images, documents, and video into material you can ask questions about. The repository also houses MiniCPM-o, the related model family that handles speech input and output. Choose the branch of the family before choosing an inference engine. A developer building document search needs a different path from someone building an assistant that watches a camera while talking, even though both arrive at the same repository and see the same headline.
Our checkout occupied 589.7 MB across 427 files and roughly 37,355 source lines. The current English README links separate guides for the vision and speech families, with Chinese documentation also available. It announces MiniCPM-V 4.7 in a smaller dense variant and a larger mixture-of-experts variant. That choice deserves attention: a model that activates only some experts still needs access to the others. The guide explicitly explains why weight storage remains a constraint for local deployment.
What happened when we ran it
Our sandbox installed commit 71e0a84 in 9 seconds, adding 35 packages and occupying 38 MB on disk. The build succeeded in 1 second. The October 13, 2026 run used Python 3.12 on Debian through the ghcr.io/astral-sh/uv:python3.12-bookworm image, with 3 CPUs, 8 GB of RAM, no secrets, and no elevated privileges. These results show a successful repository setup path, with very little time spent in its build step.
Tests were skipped because the lab found no test script or target. Pip-audit reported 0 known vulnerabilities. The scan found 0 CI workflow files, no Dockerfile, and no tests directory. A skipped suite supplies no passing-test evidence. The measurement block also contains no image-answer accuracy, model-loading result, generation throughput, or video latency. The project's published evaluation charts can't fill those gaps in our run, and the small installed environment isn't a measured memory requirement for inference.
Model assets and video decoding remain separate work
The current vision guide loads a processor and model from Hugging Face, then sends images through a chat template before generation. Its Python route names Transformers, PyTorch, and video-decoding packages. You must choose a model asset and runtime that fit the target machine. Local inference needn't use a hosted answer API, but getting those assets onto a disconnected device is still deployment work. Cache the model you intend to ship and record its revision alongside your application.
The 35 packages and 38 MB from our install are a baseline for the path the lab executed. Don't budget the entire model deployment from that figure. The guide separately documents several quantized weight formats and routes through server frameworks or local engines. Quantization reduces the precision of stored weights to save resources, with output behavior still requiring evaluation. A successful Python environment tells you very little about whether a particular model and engine fit your laptop or phone.
Ollama support depends on the particular model revision
Issue 1149's projector-loading report names MiniCPM-V 4.7, rather than an older member of the family. A user on Ollama 0.40.3 reports that the model fails to load because the bundled backend doesn't recognize its projector type. Their report says text-only prompts fail too, since the projector loads with the model. This is a concrete reason to check the exact engine and model pairing before adopting the advertised Ollama route.
Our 1-second build doesn't resolve that compatibility report. The Python guide describes another boundary: video decoding can fail when torchcodec and the installed CUDA stack don't match. It documents PyAV as an alternative and a route for selecting a matching CUDA wheel. Those are upstream instructions, not errors observed in our sandbox. For an existing workstation, first check its supported runtime against the model guide instead of assuming the newest package combination is the simplest route.
Phone deployment uses other repositories and still needs evaluation
The MiniCPM-V 4.7 guide sends mobile developers to a separate applications repository and links the optimized expert-scheduling runtime. That matters when weighing the local-device pitch. The main repository alone doesn't supply every piece of a phone application, and the storage and loading strategy is part of the runtime choice. The Intel OpenVINO section also leaves its example notebook link marked TBD, so that advertised path doesn't yet have the promised direct example there.
With 0 CI workflow files found in the measured checkout and no runnable test target, I would bring my own representative document set to an evaluation. Include a scanned page with small text, a chart whose labels matter, and an image where the requested detail is absent. Check whether answers preserve the details and admit uncertainty. These are proposed adoption checks. Nothing in the lab results establishes how MiniCPM-V answers them, and the hardware pitch shouldn't substitute for seeing your own documents handled correctly.
October activity outweighs the old GitHub release tag
The last push was October 13, 2026. GitHub showed 26,690 stars and 62 open issues and PRs. The latest GitHub release endpoint returned the May 27, 2025 tag 20250527, but the README announces MiniCPM-V 4.7 on October 12, 2026, and recent pull requests update its documentation. Together with current compatibility reports, that shows ongoing development. The old release endpoint is a poor shortcut for deciding whether this project is maintained.
Qwen3-VL and InternVL are sensible comparison candidates for the same image-and-document workload. Their own model sizes and deployment routes need evaluation on your documents too. MiniCPM-V's 9-second repository install makes a trial easy to start when local vision processing matters and you can choose the runtime deliberately. Take the exact document your application depends on, load it with the model revision and engine you plan to ship, and use that result to decide whether to adopt it.