Holo4-27B

Holo4-27B is Hcompany's dense 27B agentic model built for computer use. Released on 2026-09-28, it is designed to drive software the way a person does: clicking and typing through GUIs, writing and executing code, and calling MCP and API tools. It runs across desktop, web, Android, and code sandboxes, and Hcompany publishes weights in FP16, FP8, and GGUF formats alongside an OpenAI-compatible endpoint on the H Models API.

The distinguishing design choice is interface flexibility. Most agentic models specialize: GUI-trained models are useless when there is no screen, and tool-calling models stall in front of an application with no API. Holo4-27B was trained to pick whichever interface the task demands, which matters for real workflows where a single job spans a browser, a legacy desktop app, and a shell. It scores 61.7% on OSWorld 2.0, the benchmark Hcompany uses to measure generalist computer-use performance.

For local deployment, the dense 27B form factor is the pragmatic part. Every parameter is active on every token, so VRAM planning is straightforward and there is no expert-routing behavior to profile. It sits in the same weight class as Qwen3-VL-32B and Gemma 3 27B, but its training target is agentic control rather than general chat or document understanding.

Holo4-27B is a dense transformer with 27B parameters, paired with a vision encoder for screenshot and image input. Because it is dense rather than Mixture-of-Experts, all 27B parameters are read on every forward pass. That has two practical consequences:

• VRAM scales linearly with quantization. A 27B dense model at 4-bit lands near 16-17 GB of weights, at 8-bit near 28 GB, and at FP16 near 54 GB. There is no active-parameter discount.
• Throughput is predictable. Token generation speed depends on memory bandwidth divided by weight size, so a 4-bit build on a 24 GB card is roughly twice as fast as an 8-bit build on the same card.

Hcompany has not published a context length for Holo4-27B, and no training cutoff or license terms were specified at release. Treat context as an open question: verify the current config on the model card before you architect a long-horizon agent around it, and budget KV cache accordingly. For computer-use loops, where each step carries a screenshot plus an action history, KV cache grows faster than in plain chat, so headroom above the weight footprint matters.

The sibling model, Holo4-35B-A3B, is a Mixture-of-Experts variant with 3B active parameters. It is faster per token but needs the full 35B resident in memory. Holo4-27B trades that speed for a smaller total footprint and more consistent latency.

The model covers chat, code, vision, and function calling, and the useful work happens where those overlap.

• Browser and desktop automation. Reading a screenshot, locating a control, and emitting a click or keystroke. This is the core competency behind the OSWorld 2.0 result, and it is what makes Holo4-27B relevant for RPA-style tasks that previously required brittle selectors.
• Form and document workflows. Pulling values out of an image or PDF, then entering them into a web app or legacy desktop client. Vision input plus function calling means the model can read a scan and drive the destination system in one loop.
• Coding inside a sandbox. Writing a script, running it, reading the traceback, and revising. This is a narrower mode than a dedicated coding assistant, but it is the right one for agents that need to compute something mid-task rather than complete a repository.
• MCP and API orchestration. When a service exposes an MCP server or a REST endpoint, the model can call it directly instead of driving a UI, which is faster and far more reliable.
• Mobile flows. Android support extends the same agent loop to device-level tasks.

If you want a general-purpose chat model or a long-context document reasoner, this is not the sharpest tool. If you want an agent that operates software, it is built for exactly that.

GGUF weights are published, which means the standard local stack applies: llama.cpp, Ollama, and LM Studio for GGUF builds, and vLLM or SGLang for FP8 and FP16 on server-class GPUs.

Add 2-6 GB on top for KV cache and the vision encoder, more if you run long agent trajectories or high concurrency.

Q4_K_M is the right default. It fits a single 24 GB card with room for context, and the quality loss against FP16 is small enough that agentic action accuracy barely moves. Step up to Q5_K_M or Q6_K only if you have a 32 GB card and want the extra margin on vision-heavy tasks. FP8 is the better choice than Q8_0 if your runtime supports it, since it uses less memory for comparable quality. FP16 is for 80 GB accelerators or multi-GPU setups and is not worth the bandwidth cost on consumer hardware.

• RTX 4090 / 3090 (24 GB): Q4_K_M, the standard local configuration. Expect roughly 25-40 tokens/sec single-stream on the 4090 and 20-30 on the 3090.
• RTX 5090 (32 GB): Q5_K_M or Q6_K comfortably, FP8 if you keep context modest. Expect 45-70 tokens/sec at 4-bit.
• Dual RTX 3090 (48 GB): FP8 or Q8_0, useful if you need quality parity with the hosted endpoint.
• Apple M4 Max (64 GB or 128 GB unified): Q4_K_M through Q8_0 via Metal. Bandwidth-bound, so expect roughly 15-25 tokens/sec, with the 128 GB configuration able to hold FP16.
• Strix Halo / 128 GB unified memory PCs: Q4_K_M to Q8_0 with large context, slower per token than discrete GPUs.

For a 27B dense model on a consumer GPU, 24 GB is the practical floor and 32 GB is the comfortable target.

Ollama is the fastest way to get started, assuming the GGUF tag is published in the Holo4 collection:

1ollama run holo4:27b

Then point your agent loop at the local endpoint. For vision and function calling, confirm your runtime supports image input and tool-call parsing for this architecture before you build on it, since support varies between llama.cpp builds.

Holo4-27B vs Qwen3-VL-32B. Qwen3-VL-32B is the closest general-purpose alternative: dense, vision-capable, slightly larger, and stronger on document understanding and broad multimodal chat. Choose Qwen3-VL-32B if your workload is mostly reading and reasoning over images. Choose Holo4-27B if your workload is acting on screens, where its training on GUI trajectories and tool interfaces gives it a clear edge.

Holo4-27B vs Gemma 3 27B. Gemma 3 27B is a solid general chat and vision model with a permissive license and broad runtime support, and it is easier to deploy. It is not an agent model. If you need something to drive a browser or fill a form, Holo4-27B is the correct pick; if you need a conversational assistant with image input, Gemma 3 27B is lighter to operate and better documented.

Holo4-27B vs Holo4-35B-A3B. Same family, different tradeoff. The MoE model is faster per token but requires 35B of resident memory. On a single 24 GB card, the dense 27B at Q4_K_M is the only one of the two that fits.