Llama 4 gives open models a serious shot at enterprise workloads

Meta’s Llama project has moved beyond the role of “open alternative.” With Llama 4, released in April 2025 and now widely available across cloud platforms, Meta is offering a mix many engineering teams have wanted for years: open weights, native multimodality, and model sizes large enough for serious work, without forcing everything through one vendor API.

That changes the buying decision.

For teams building internal copilots, multimodal search, document-heavy assistants, or code tooling, Llama 4 is now one of the few model families that can plausibly cover the whole range. You can self-host it, buy it as a managed service from the major clouds, or do some of both. That flexibility matters as much as benchmark scores.

The lineup is simple enough:

• Llama 4 Scout: 17B active parameters, 109B total, up to 10 million tokens of context
• Llama 4 Maverick: 17B active, 400B total, up to 1 million tokens
• Llama 4 Behemoth: not released yet, but Meta positions it as a 288B active / 2T total teacher model for distillation and high-end reasoning

All three use a mixture-of-experts architecture, and all are multimodal across text, images, and video.

Open weights still matter

That’s easy to underrate now that every major cloud has a long menu of foundation models. But open weights still solve a specific set of problems that closed APIs don’t.

They give teams control over:

• where inference runs
• how data is retained
• whether fine-tuning is allowed
• how far they can push cost optimization
• what safety and policy stack sits around the model

That’s procurement, governance, and latency. Not ideology.

In healthcare, finance, defense, or any company sitting on a lot of internal code and internal documents, “just send it to a hosted API” often gets killed in review. Llama’s availability across AWS, Azure, Google Cloud, Hugging Face, and partners such as Databricks, Groq, Dell, Nvidia, and Snowflake makes it easier to keep the benefits of open weights without taking on the full pain of self-hosting.

Meta also kept its familiar licensing catch. Apps with more than 700 million monthly active users face restrictions. For most companies, that won’t matter. For very large consumer platforms, it still does.

MoE changes the operating model

The biggest architectural shift in Llama 4 is the move to MoE, or Mixture-of-Experts.

Instead of running the full model on every token, a gating network routes each token to a subset of experts. That’s why Scout can be 109B total parameters but only 17B active at inference time. Maverick pushes the same idea much further at 400B total with the same 17B active.

Meta is chasing higher capacity without paying dense-model compute costs on every token.

That’s a sensible move. It also comes with operational baggage.

MoE models are efficient when the serving stack is built for them. If it isn’t, routing overhead and expert imbalance eat into the gains. Tokens don’t spread out neatly. Some experts run hot. Throughput gets uneven. Multi-GPU inference becomes more sensitive to interconnect speed and runtime tuning than many teams expect.

If you plan to run these models yourself, the software stack matters almost as much as the model:

• DeepSpeed-MoE
• Tutel
• TensorRT-LLM with MoE support
• inference engines that can handle aggressive KV cache management, such as vLLM

Hardware matters too. MoE behaves better with high-bandwidth links such as NVLink or InfiniBand. On cheaper GPU setups with weaker interconnects, performance can get ugly fast.

That’s where open models turn into a systems problem.

The 10 million token question

The wildest spec in the Llama 4 family is Scout’s 10 million token context window. Maverick’s 1 million tokens is already huge. Scout goes much further.

That opens up real use cases:

• codebase-wide refactoring
• tracing behavior across months of logs and incident notes
• multi-document legal or compliance review
• combining diagrams, screenshots, tickets, and text in one session
• persistent project memory for long-lived agents

Useful, yes. But dumping massive amounts of context into a prompt is still expensive, awkward to operate, and often a sign of lazy system design.

Attention cost is still a problem. No serious deployment runs naive full attention at those lengths and calls it done. In practice, long-context systems depend on techniques such as streaming attention, chunking, sparse attention, and KV cache offloading. Even then, latency and cost can climb fast.

There’s also a quality problem. Longer context means more chances for the model to latch onto junk, stale instructions, or malicious prompt content buried somewhere in the pile. Guardrails get weaker as the context gets messier. Prompt injection gets easier. So does agreement bias, where the model treats harmful or false context as authoritative because it’s present and recent.

A giant context window is best treated as a pressure valve, not a default operating mode.

For most enterprise systems, the better pattern still looks familiar:

• retrieve the right material with RAG
• rank for relevance
• track provenance
• summarize hierarchically
• keep memory structured instead of shoving everything into the prompt

Massive context helps when retrieval fails, when traceability matters, or when users genuinely need full source material in session. It doesn’t remove the need to design the system properly.

Native multimodality makes Llama 4 much more usable

Meta says the Llama 4 models natively handle text, images, and video. That matters.

A lot of enterprise information is not text. It’s diagrams, architecture screenshots, UI mockups, scanned PDFs, slide decks, support recordings, and screen captures from incidents. If your assistant only reads text, a big chunk of the project becomes preprocessing and glue code.

Multimodal support changes the kinds of tools teams can build:

• a support assistant that reads tickets plus screen recordings
• an internal engineering bot that interprets architecture diagrams and log excerpts together
• a QA workflow that checks UI screenshots against spec documents
• code review helpers that understand text, design mocks, and issue threads in one pass

The catch is infrastructure. Video and image pipelines get messy quickly. Frame extraction, sampling, normalization, and batching all become your problem if you self-host. GPU memory pressure goes up. Quantization such as FP8 or INT8 starts to look less like optimization and more like necessity.

If your use case includes long videos, you’ll almost certainly need smart frame selection. Feeding raw footage end to end is wasteful and often worse than pre-segmenting the important moments.

Tool use still depends on the surrounding stack

Meta has trained Llama models for tool use, including integrations such as Brave Search, Wolfram Alpha, and a Python interpreter. Useful. Also table stakes at this point.

The practical issue is the layer around the model. You still need function-calling schemas, strict output formatting, sandboxing, timeouts, allowlists, and audit logs. A model that can use tools is not a production-ready agent stack.

For senior engineers, that’s where much of the security risk sits. A web search connector can exfiltrate data. A Python sandbox can get expensive or dangerous if isolation is weak. A code assistant with shell access can wreck a developer environment if policy enforcement is sloppy.

Meta’s own safety tooling is helpful:

• Llama Guard
• CyberSecEval
• Llama Firewall
• Code Shield

Useful tools. Not enough by themselves.

Safety gets harder with open, multimodal, long-context models

This is the least glamorous part of the story, and one of the most important.

Open-weight models are attractive because you control them. That also means you own the failure modes. If you’re combining open weights, long context, images, video, and external tools, safety stops being a model-selection problem and becomes a runtime architecture problem.

You need defense in depth:

• input filtering
• policy checks before tool calls
• output moderation
• source attribution
• sandboxing
• logging
• rate limits
• human review for high-risk actions

Long context makes this harder. The more material you stuff into the window, the easier it is for harmful instructions or poisoned content to hide in plain sight.

Which model fits most teams?

For most organizations, Maverick looks like the practical choice.

Its 1 million token context is already excessive for many workloads, but still useful for serious document and code tasks. It should land in a better cost-latency range than Scout for assistants, coding tools, and multimodal enterprise chat.

Scout is more specialized. A 10 million token window is impressive, but it raises enough cost and engineering questions that you should only pay for it if you have a clear workload that benefits from it. Large compliance review, deep codebase analysis, massive incident reconstruction, maybe. General-purpose chat probably doesn’t justify it.

Behemoth, if it arrives as described, looks more like a distillation source than a deployment target. Most teams aren’t going to run a 2T-parameter teacher directly. They’ll want smaller, cheaper models that inherit some of its behavior.

Meta’s strongest move may be the breadth of the family rather than one flagship. A set of open-weight models that can be hosted almost anywhere and tuned for very different jobs is a strong position.

For teams that want ownership, multimodality, and room to optimize, Llama 4 belongs on the short list. Model selection is the easy part. The engineering starts after that.