When Renting AI Costs More Than Owning It: The Qwen3.5-397B Enterprise Playbook

From Renting AI to Owning AI: The Value, Cost, and Implementation Path of Enterprise Private Models

Thomson Reuters recently launched its own large language model, Thomson, with a project investment of approximately $40 million, using Alibaba's Qwen3.5-397B-A17B as its foundation.

You might not have heard of Thomson Reuters, but you've certainly heard of Reuters; Thomson is the parent company of Reuters. So why would a large company specializing in legal, tax, and news information spend so much money to build its own model?

Actually, the reason isn't hard to find if you think about it. In recent years, AI has been gradually becoming the infrastructure for professional business processes in fields like law, sales, recruitment, and healthcare. OpenAI's user activity data also confirms this: since February 2026, the weekly active users of Codex in the legal industry have increased 108-fold, and in sales and recruitment, 41-fold.

As usage grows, problems arise: if core capabilities are always built on someone else's API, service fluctuations, price hikes, model upgrades, and changes in data boundaries are all enough to cause a company serious trouble.

So, many enterprises are starting to ask a question: which AI capabilities are worth controlling themselves, and which are more cost-effective to continue renting?

---

1. Why Enterprises Want to Move from Renting AI to Owning AI

In the past few years of rapid large model development, the vast majority of enterprises have accessed AI by calling model providers' APIs. The reason is simple: it's quick to start, and the results are usually good. Companies don't need to buy their own GPUs, maintain inference services, or understand model training. As long as they send the request and receive the result, the business can run.

However, as business scale grows and usage gradually increases, problems will slowly emerge.

1. Every Call Generates a Long-Term Cost

Enterprises don't use AI just to summarize a document occasionally; they deeply embed models into their business flows, such as contract review, invoice recognition, customer service ticket classification, supplier document review, code checking, and internal knowledge Q&A. Once these functions go live, they may generate calls daily, hourly, or even every minute.

In the short term, external APIs save infrastructure costs; in the long term, an enterprise may continuously pay inference fees for the same type of repetitive tasks. As business volume grows, so do the call volume and the bill. Therefore, many companies are starting to re-evaluate whether renting AI is a cost-effective deal.

If not renting, then building a private model must be considered. Of course, this doesn't mean building a private model is necessarily cheaper, because the enterprise also has to bear the costs of GPUs or cloud resources, inference services, data cleaning, model engineering, monitoring, upgrades, and security governance. What really needs to be compared is the total cost of ownership over a period of time, not simply the API unit price versus the local inference unit price.

2. The Enterprise Cannot Fully Control the Model

It's not that external models aren't good, but that enterprises can easily be constrained:

• When the model is upgraded or taken offline
• When a certain capability is adjusted
• How pricing, rate limiting, and service terms change
• Which region the service is deployed in
• How data is processed and stored
• Why the model suddenly changes its answering style
• Whether a specific professional capability can adapt to their business domain
• ...

These issues gradually impact legal, sales, HR, finance, healthcare, supply chain, and internal corporate code, eventually evolving into compliance, stability, and business continuity problems.

An enterprise's control over AI isn't just about 'whether it owns the model weights'; it can be broken down into at least four layers:

1. Data Control: e.g., whether data can leave the domain, how it is retained, who can access it
2. Application Control: whether Prompts, RAG, tool calls, approvals, and logs are controllable
3. Service Control: whether the model version, deployment region, SLA, and vendor are controllable
4. Weight Control: whether the model can be self-deployed, fine-tuned, distilled, and replaced

Open weights primarily enhance the fourth layer, which helps the enterprise gain some service control, but it does not automatically solve data governance, business process, and security audit issues. In actual business, enterprises don't need to choose strictly between 'renting everything' and 'developing from scratch'. A more realistic approach is to decide which capabilities need to be self-controlled based on business scale, data sensitivity, and the cost of errors.

3. An Enterprise's Most Valuable Industry Moat Cannot Just Be Placed in the Context

In the past two years, the first step for many enterprises integrating large models was to build a Q&A assistant: recall internal knowledge documents, splice them into a Prompt, and hand it to the large model for summarization. So, everyone studied document chunking, vector retrieval, and recall algorithms, hoping the model could answer questions in the business domain.

This is essentially doing RAG. RAG is useful, but it mainly solves the problem of 'giving the model materials to look at', not necessarily enabling the model to learn the 'enterprise's way of judgment'—which is, in fact, industry experience. These are the core competencies of an enterprise:

• Which risks must be escalated
• Which anomalies are just formatting issues
• Which clause is truly important in the current transaction
• Which materials, though relevant, cannot be used as a basis for conclusions
• Under what circumstances should it explicitly say 'uncertain'

If this experience always exists only in the context of individual requests and manual corrections, it is difficult to solidify into reusable enterprise capabilities.

However, not all industry knowledge needs to be stuffed into model weights. Dynamic regulations and product documentation are better placed in a version-controlled knowledge base for traceability and permission control; stable output styles are solidified through fine-tuning. As for strong rules like risk thresholds and approval processes, it's best to leave them to explicit business logic.

---

2. Why Qwen3.5-397B-A17B Can Serve as an Enterprise Foundation

Let's start with the conclusion: this model is not for individuals, or at least not suitable for most individuals to deploy directly; for enterprises, it's not a final product ready for launch either. It's more like a large, open, and further-processable model foundation.

And the reason it's suitable as a candidate foundation isn't just because of its large parameter scale, but because it achieves a relatively perfect balance between general capability, openness, adaptability, and inference efficiency.

1. 397B Total Parameters, 17B Activated: A Mixture of Experts Model

Qwen3.5-397B-A17B is a sparse Mixture of Experts (MoE) model with a total parameter scale of about 397 billion, but each forward computation only activates about 17 billion parameters.

Think of it as a large expert team: the entire team has about 397 billion parameters, but each time it processes a token, the routing mechanism selects only some experts to participate in the computation. This preserves the capacity of a larger model while reducing the computation per step.

For enterprises, this design is quite meaningful. Enterprise AI often isn't about occasionally processing a complex question, but continuously processing contracts, forms, tickets, code, and business documents. Single-inference efficiency affects concurrency, latency, and cost, and MoE can alleviate the single-computation pressure to some extent.

But there's a point that's easily misunderstood here: 17B refers to the activated parameters, not all the parameters required for deployment.

That is, the total model weights are still 397B. Enterprises still face issues like weight storage, VRAM distribution, expert routing, node communication, and long-context KV Cache. MoE reduces some computational pressure, not turning a 397B model into a 17B model.

2. Open Weights Mean the Enterprise Has Room for Modification

The biggest difference between open weights and models accessed via API isn't whether they can be downloaded, but whether the enterprise can control the model to a certain extent:

• Self-deploy and fix the model version
• Connect to internal tools and data systems
• Fine-tune or distill using enterprise cases
• Replace the foundation based on business evaluation results
• Choose where the model runs
• ...

But open weights do not equal full open source. Training data, complete training code, training recipes, and infrastructure may not be public. What the enterprise gets is a deployable and modifiable model foundation.

3. Multimodal + Long Context, Better at Handling Enterprise Documents

Enterprise documents are rarely clean plain text. In actual work, you often encounter:

• PDF contracts
• Scanned documents
• Excel spreadsheets
• Images and attachments
• Multiple cross-referenced files
• Lengthy regulations and historical records
• ...

Qwen3.5-397B-A17B is positioned as a native vision-language model and offers longer context capability. This makes it better at handling complex documents, forms, images, and other multi-modal materials.

4. General Capabilities Are Strong Enough

When an enterprise chooses a foundation model, the main consideration is whether it can plan and decompose a complex task to completion. The capabilities shown in Qwen's official materials include:

• Complex Instruction Execution: Understanding multi-step requirements and outputting in a specified format as much as possible. Legal, financial, and risk control tasks often require the model to simultaneously perform extraction, comparison, classification, citation, and summarization.
• Reasoning and Coding Ability: Handling math, logic, and program generation tasks, without needing to teach it basic reasoning, structured processing, and coding from scratch.
• Tool and Agent Ability: Supporting tool calls, planning, search, and multi-turn tasks, allowing it to be further connected to retrieval systems, databases, and internal business APIs.
• Vision and Document Understanding: Multimodal.
• Multilingual Processing: Official materials show that Qwen3.5 has expanded language and dialect coverage to 201, suitable for cross-language materials and multi-regional business.

While the above doesn't mean it surpasses GPT or Claude on all tasks, it at least provides a relatively complete skeleton of general capabilities: it can reason, code, process documents, and connect to tools. Enterprises can focus their training resources on legal clauses, tax rules, supplier standards, and internal processes, rather than retraining language, common sense, and basic reasoning.

This is the significance of Qwen3.5 as a foundation: It's not about completing specialization for the enterprise, but about changing 'training general capabilities from zero' into 'starting specialization from a starting point that already possesses general capabilities'

---

3. What an Enterprise Actually Gains by Owning Its Own Model

1. Potentially Lower Long-Term Costs for High-Frequency Tasks

When an enterprise processes a large number of stable tasks daily, it can evaluate whether private deployment or a smaller distilled model can reduce costs. For example:

• Reviewing a large number of documents daily
• Processing customer service tickets daily
• Extracting a large number of structured fields daily
• Continuously performing code checks and test generation
• Conducting initial screening of supplier documents

The characteristics of these tasks are high volume, relatively stable format, and infrequent requirement changes. If external models are called long-term, costs will continuously grow; if some capabilities are migrated to a private model, unit costs and resource control may be more stable.

Why say potentially? Because the enterprise still needs to pay for:

• GPUs or cloud resources
• Inference services and model engineering
• Data cleaning and training
• Monitoring, auditing, and security governance
• Model upgrades and fault handling
• Error rework and manual fallback

This investment only makes sense when the call volume is large enough, the scenario is stable enough, and the model capability can be reused long-term.

2. Saving Professional Staff Time

Often, what enterprises really want to save isn't token costs, but expert time. Taking supplier initial screening as an example, the model can automatically complete document reading, field extraction, rule comparison, and evidence location, generating an initial review result with supporting evidence, leaving only high-risk and undeterminable cases for expert review. This type of work has clear rules and high repeatability; handing it to the model can free up a significant amount of expert time, allowing experts to focus on more valuable work.

3. More Controllable Sensitive Data

Customer contracts, supplier quotes, undisclosed financial data, internal code, and case materials can all be sensitive enterprise data.

Private deployment doesn't automatically solve all security problems, but at least it allows the enterprise to independently decide:

• Where the data is placed
• Who can access the model
• What content can enter the context
• Whether customer data is allowed to enter training
• How model output is logged and audited
• How version upgrades are verified

For industries like legal, healthcare, finance, and government, this control itself is very valuable.

4. Turning Industry Experience into Long-Term Assets

What an enterprise should truly solidify isn't a specific model file, but a working mechanism that allows the model to become smarter with use.

For example, if we use AI for supplier document initial screening, a complete closed loop looks something like this:

The business staff uploads the documents → The system records who uploaded them, which model version was used, and what tools were called → The model provides an initial screening conclusion and basis → An expert reviews it, corrects it if something is wrong, or rejects it outright → This document and the expert's modification traces are desensitized, organized, and quality-checked → Turned into three things: training material, error case library, and evaluation test questions → Used to optimize RAG, fine-tune the model, or even distill it into a smaller model → After the new version goes live, continue collecting the next round of feedback, and the cycle repeats.

In this process, the outputs of each link have their own uses:

• Desensitized real business data can be used to continue training the model or serve as a knowledge base for RAG.
• The parts the expert corrected tell the model you were wrong here, missed something there, the wording was off—these can be processed into preference data.
• Those failure cases that went wrong are all collected into the regression test set to ensure the new version doesn't make the same mistakes.
• The expert's internal yardstick, like what counts as qualified, is written into executable scoring rules.
• Domain evaluation sets are used to horizontally compare which is better among different foundations, different prompts, different retrieval schemes, and different fine-tuned versions.
• Workflow and tool call records are solidified into reusable Agent processes.
• Permissions, audits, and version records ensure traceability when something goes wrong.

After such a round, data is no longer waste lying in logs but becomes a true model asset—usable for training, evaluation, and explaining model behavior. If you want to switch foundations someday, this set of assets can be quickly migrated over.

So, what the enterprise truly holds in its hands isn't a specific model at all, but three things that are much harder to replicate:

First, knowing what the most common problems in its business are Second, knowing what answer counts as correct Third, knowing how the model fits into the real workflow, with a human safety net

This is where data assets generate compound interest. The first time you use a model, you just complete a task; but every subsequent expert correction, every post-mortem of a failure, every version evaluation, makes the next version easier to train and easier to validate. So, a private model itself isn't that valuable; the truly valuable point is using the private model to accumulate the enterprise's own model assets.

---

4. How to Transform Qwen3.5 into Your Enterprise's Own Model

When an enterprise does AI, don't start by training a model. It's unrealistic and unnecessary. A more reliable path is to start from a specific task, build up layer by layer, step by step, just like engineering—first launch an MVP version, then iterate and optimize gradually:

• First, write prompts and connect tools, get the entire process running.
• Once it's running, if you find the knowledge is insufficient, then add RAG.
• After adding RAG, if you find the output style is unstable, then do LoRA fine-tuning.
• If that's still not enough, the task is genuinely complex, and the model needs to orchestrate multiple tools itself, then consider post-training or reinforcement learning.

That sounds a bit abstract. Let me give a concrete example. For the business scenario of supplier document initial screening, don't make the first version complicated.

As long as the model can output risks, evidence, and to-dos in a fixed format, and the tools for document parsing and enterprise lookup are connected, it's good enough to go live. After going live, monitor a few key metrics: amount of manual modification, false negative rate, evidence accuracy, cost per task. Don't touch model training before these metrics stabilize.

When problems arise, then prescribe the right remedy:

Doesn't know the latest rules? Connect RAG. Knows the rules but writes in a disorganized way? Use real cases corrected by experts to do LoRA fine-tuning. Really needs the model to decompose tasks and orchestrate tools by itself, and you already have stable scoring standards and an evaluation set? Then think about post-training.

A few more pieces of practical advice:

1. Format issues should be solved with structured output and field validation, don't rely on the model. 2. Dynamic regulations should be placed in the knowledge base, not in the model weights. 3. Risk thresholds and approval permissions should be written in explicit rules and business processes, don't let the model judge. 4. Fine-tuning can only make the model's style resemble a business professional, but it cannot make business decisions for them.

---

5. What Kind of Company Is Suitable for Evaluating 397B

If an enterprise wants to try 397B, it should first ask itself a few questions:

• Does it have a large number of repetitive knowledge-based tasks?
• Does it possess private data that external models cannot access?
• Does it have strict requirements for data leaving its domain?
• Is the call volume stable in the long term?
• Can the task results be clearly evaluated?
• Does it have algorithm, engineering, data, and operations teams?
• Can it bear the costs of distributed inference and model governance?

If you just want to build an internal chatbot, with very low call volume, no evaluation set, or no dedicated team, directly deploying 397B is very unnecessary and just adds an expensive infrastructure burden.

As for the deployment part, I think it can be viewed in stages:

1. Low call volume / rapid validation: Managed API
2. Data sensitive / stable call volume: Private deployment
3. Clear task / pursuit of unit cost: Large model distilling a small model
4. Strong data, expert, and evaluation capabilities: Continuous pre-training + post-training

Qwen3.5-397B-A17B can serve as a candidate foundation for enterprise evaluation, but the end state doesn't have to be an online service model; it can also serve as a teacher model, generating training data for smaller, cheaper business models.

---

6. How an Enterprise Project Should Be Implemented

Step 1: Choose the Task First, Not the Model

The first batch of tasks should ideally have these characteristics:

• High frequency, repetitive
• Relatively stable input
• Clear output format
• Controllable error cost
• Human results available for comparison

Step 2: First, Compare Effectiveness

Using real, desensitized data, simultaneously compare:

• The current manual process
• External closed-source models
• Qwen3.5 or other open models
• The difference before and after connecting to the enterprise knowledge base

Evaluation metrics shouldn't just look at whether the answer is fluent, but also:

• Accuracy
• Completeness
• Citation reliability
• Manual correction time
• Cost per task
• Response latency
• Output stability
• High-risk error rate

Step 3: Build the Enterprise's Own Evaluation Set

It's best to save as early as possible:

• Correct cases, error cases, edge cases, and high-risk cases
• Manual correction content
• Expert scores
• Result differences between different models and different versions

With an evaluation set, you can judge whether the model is truly good, and also know whether a fine-tuning actually brought improvement.

Step 4: Choose the Deployment Method Based on Evaluation Results

After running the evaluation set, the choice of deployment method has a basis and doesn't need to be a gut decision:

• If external closed-source models clearly lead on core metrics, and data is allowed to leave the domain, first run it on a managed API to validate the business process.
• If data is sensitive or call volume is stable, evaluate private deployment, fixing the model version and deployment region.
• If task boundaries are clear and the evaluation set is stable, try using a large model to distill a small model to drive down unit costs.
• If data, expert, and evaluation capabilities are all strong enough, then consider continuous pre-training and post-training.

The core principle is: the choice of deployment method follows the evaluation results, not the desire to own a model. Open model weights don't mean you must privatize; forcing a 397B model when call volume is small only pushes up validation costs.

---

7. Is an Enterprise Building Its Own Model Saving Money or Just Swapping Bills?

Private AI Value = Saved API Fees + Saved Labor Time + Data Control Benefits − Compute, R&D, Operations, Governance, and Error Costs

Situations Where It Might Be More Cost-Effective

• Very high call volume
• Tasks are stable long-term
• The model can be reused by multiple business units
• The enterprise owns its own compute resources or has long-term resources
• The time value of professional staff is very high
• The costs of data leaving the domain and vendor dependency are very high

Situations Where It Might Be More Expensive

• Very low call volume
• Business requirements change frequently
• No dedicated engineering team
• Very poor data quality
• Lack of evaluation standards
• Purchased a large number of idle GPUs to deploy a large model
• Model performance is worse than off-the-shelf APIs

So, an enterprise private model is more like a long-term investment: it requires upfront investment in data, engineering, and governance costs, and only later may it yield lower unit costs, stronger data control, and more stable business capabilities.

---

Continuously Transforming Expert Capabilities into Model Assets

The significance of Qwen3.5-397B-A17B isn't to have every company deploy a 397B model, but to provide a path: enterprises don't have to train a foundation model from scratch, nor hand all AI capabilities over to external service providers. Instead, they can start from a sufficiently strong open-weight model and gradually solidify their data, expert judgment, business tools, and evaluation systems into model capabilities.

For most enterprises, the first thing to build isn't a private model, but four things:

• Their own data
• Their own expert standards
• Their own evaluation set
• Their own business closed loop

Only with these does it make sense to talk about private deployment and continuous training. The real question worth discussing for enterprises isn't Should we own a private model? but rather: Which AI capabilities are worth controlling ourselves, which are more cost-effective to continue renting, and which business data and expert experience need to be solidified into our own model assets?