Open-Weight Models for Portuguese Business Use: Llama or Qwen?

Open-Weight Models for Portuguese Business Use: Llama or Qwen?

Open-weight models for Portuguese business use, such as the Llama and Qwen families, are a good fit when the task is well bounded, a mistake is cheap or reviewable, and there is a concrete reason to move off an API: control over data, predictable cost, or running in your own environment. They should not be treated as drop-in replacements just because the weights are free to download. The only safe way to decide is to test the model on your own tasks, with your own texts, and an evaluation standard defined beforehand.

Key takeaways

• An open-weight model is not free to run: the bill includes infrastructure, maintenance, ongoing evaluation and people.
• Quality in Portuguese varies by model, by size and by type of task. Generic benchmarks do not replace a test with your own cases.
• Classification, extraction and summarization are usually better candidates than long conversations that involve reasoning and sensitive actions.
• Always compare against the API you use today, with the same set of cases, the same criteria and blind review.
• Decide in advance what would make you keep the API, switch partially or drop the test. That keeps enthusiasm out of the decision.

What "open" means and why it changes the decision

When people say open models, they usually mean models whose weights are available for download. You can run them on your own infrastructure or with an inference provider of your choice. That gives you control over where data travels, over the model version (it does not change without notice) and over fine-tuning. In exchange, you take on the work an API hides: serving the model, sizing capacity, monitoring, updating and evaluating.

Another point that is often forgotten is the license. Each family and each version has its own terms, and not every model called open allows any commercial use without conditions. Before you spend time testing, read the license of the specific version you plan to use, and ask for a legal review if it will sit inside a product you sell to third parties.

There is also a practical distinction: running the model on your own machine or cloud is different from consuming an open model through a third-party provider. In the second case, your data leaves the company just as it would for a closed API, and the privacy advantage disappears. For whoever reviews data protection, that difference matters. The article on LGPD and artificial intelligence details what the company needs to record in each case.

When Llama or Qwen usually fit

Using open-weight models tends to make sense when at least one of these signals is present and the task is easy to verify:

• The data is sensitive and internal policy requires it to stay on controlled infrastructure.
• Call volume is high and repetitive, so the per-request cost of an API weighs more than the cost of operating a model.
• The task is narrow: classifying messages by topic, extracting fields from a document, normalizing records, summarizing tickets.
• You need stable behavior for a long time, without a vendor changing or retiring the version.
• A technical team can operate the service, or a partner can do it with clear responsibilities.

In these cases, an open-weight model can be a real candidate. Note that the list talks about narrow tasks. The more a flow requires following long instructions, using tools, holding extended context and handling ambiguity, the larger the gap tends to be compared with the frontier models offered through APIs.

When it is better to keep the API

Keeping the API is usually the right call in these situations:

• The task requires multi-step reasoning, interpretation of ambiguous context or reliable tool use.
• Volume is low or irregular, and your own infrastructure would sit idle most of the time.
• Nobody is available to operate, monitor and update the service after the pilot.
• Errors are costly and you depend on a quality level the test could not demonstrate.
• The only reason to switch is "saving money", without an honest calculation of total cost.

A middle path is to use both. A smaller open model handles triage and extraction, while a more capable API takes the hard cases. That split only works if there is a clear routing rule and a record of which model answered each case. For a comparison of models on a different task, the piece on Kimi K2.5 and Claude Opus 4.5 for coding applies the same testing logic to code.

How to build a Portuguese test set

The most common mistake is testing with polished questions written by the technical team. The real Portuguese your company deals with is different: WhatsApp messages with abbreviations, transcribed audio with errors, regional slang, internal product names, industry acronyms, emails with signatures and pasted history. If the test set does not contain that, the result is not worth much.

Build the set like this:

• Collect real cases of the task, with personal data removed or masked according to company policy.
• Include easy, common and hard cases, including confusing, incomplete and out-of-scope messages.
• Include cases where the correct answer is to refuse, ask for more information or hand off to a person.
• Record the expected result for each case, written by someone who knows the process, not by the model.
• Hold back a portion of the cases that nobody uses to tune prompts. It is reserved for the final measurement.

If the task has variations in tone and formality, such as customer support versus supplier communication, represent both. Models can do well in formal Portuguese and worse in colloquial language, or the other way around.

Step-by-step test plan

This is a simple outline for comparing an open-weight model with your current API. It follows the logic of our method: map, limit, pilot and hand over.

• Map: describe the task, who does it today, what the current quality is and what happens when there is an error. Record the baseline with the current API.
• Define criteria: choose a few criteria that matter to the business, such as content correctness, fidelity to the data provided, appropriate tone, valid output format and rate of correct handoff to a human.
• Limit: define what data the model can see and what actions it can take. At the start, let it only suggest, without executing anything.
• Run both sides: run the same set of cases on the open model and on the API, with equivalent instructions. Give each one the chance to have its prompt tuned, so you do not compare a polished prompt with a raw one.
• Evaluate blind: ask people from the process to rate the answers without knowing which model produced each one. If you use another model as a judge, validate it against human review, as described in LLM as a judge.
• Measure operations: watch response time, stability under load, format failures and resource consumption, in addition to quality.
• Pilot: if the result is promising, run a real, limited flow with logs, human review and an agreed metric. The guide on how to measure an AI automation pilot helps define the decision gates.
• Hand over and decide: deliver the operation with documentation and owners, and decide whether to expand, adjust or stop.

Public evaluation guides, such as Anthropic's material on evals for agents and OpenAI's evals guide, reinforce the same idea: evaluation needs to be continuous and based on real tasks, not a one-off check.

Illustrative scenario: message triage at a distributor

Imagine a distributor that receives customer messages on WhatsApp and wants to classify them by topic (duplicate invoice, order status, exchange, sales question) and extract the order number before routing to the right team. Today this is done through an API. The reason to consider an open-weight model is to keep the messages inside the company's infrastructure.

The team gathers a set of real messages, masks names and phone numbers, and defines the expected result for each one. It runs the open model and the current API. The results show that topic classification comes out very similar in both, but order number extraction fails more often on the open model when the message comes from transcribed audio with errors. A reasonable decision would be to use the open model for classification, keep the difficult extraction on the API or in a deterministic rule, and send low-confidence cases to a person.

Note what the scenario does not do: it does not declare a winner or a loser. It separates tasks, measures each one and decides flow by flow. On the support side, it is also worth reading about what to automate and what to keep human in AI customer support.

Cost, security and operations: what goes into the calculation

The cost comparison needs to include more than the price per call. Consider the infrastructure needed to serve the model at the latency you want, the team's time to maintain and update it, the cost of re-evaluating with every new version and the cost of failures. The FinOps Foundation works with the idea of unit economics, which helps: calculate the cost per task completed at acceptable quality, not per request.

On security, running the model locally does not remove application risks. Prompt injection, data leakage through poorly assembled context and unintended actions remain possible. The OWASP Top 10 for LLM applications is a good checklist for any model choice. If the flow involves personal data, record the purpose, the legal basis and who has access, and follow the guidance of Brazil's data protection authority, the ANPD.

Finally, define limits: what the model can read, which tools it can call, when it needs human approval and how logs are stored. This applies to any model, and for models less tested in your context it applies even more.

Frequently asked questions

Do Llama or Qwen understand Portuguese well? In general, they understand and generate useful Portuguese, but quality varies by version, size and task. Smaller models tend to make more mistakes with nuance, slang and long instructions. That is why a test with real messages from your company is more reliable than any ranking.

Is an open-weight model cheaper than an API? It depends on volume, infrastructure and who operates it. For high volumes and repetitive tasks, it can pay off. For low or irregular use, running your own usually costs more than the API, and the calculation should include the team's time.

Does running the model in-house solve LGPD? Not by itself. Keeping data on controlled infrastructure reduces exposure to third parties, but you still need to define purpose, legal basis, minimization, access control and records. If you use an external provider to serve the open model, the data leaves the company in the same way.

Can I use an open-weight model and an API at the same time? Yes, and it is often the most sensible setup. An open model handles narrow, repetitive tasks, and the API handles the cases that need more reasoning. For this to work, you need a clear routing rule, a record of which model answered and periodic review of the results.

Sources

• Anthropic: Demystifying evals for AI agents
• OpenAI: Evals guide
• OWASP Top 10 for LLM Applications
• ANPD: Autoridade Nacional de Proteção de Dados