Why Chinese AI Models Are Opening Up: The True Meaning of Open-Weight

What does it mean to make a model public?
The questions posed by Kimi K3, DeepSeek, and Qwen are less about wins and losses on performance charts and more about a shift in how AI is chosen and deployed.

After Kimi K3 emerged, attention on Chinese AI grew again. If DeepSeek raised the question of cost-effectiveness, Kimi's release of its weights has changed the question itself. While who leads in benchmarks is important, in real-world scenarios, the primary question becomes, “Where and under what conditions can this model be used?”

The true value of open-weight isn't in being free. It lies in moving beyond borrowing AI only within a single company's API (connection rules that allow different programs or services to exchange data) to being able to choose models and deployment paths.

What does 'open-weight' mean?

AI models adjust countless numbers while learning from vast amounts of data. This bundle of numbers is calledweights. You can think of them as the outcome of learning, determining which words and judgments to follow when a question is received.

Open-weight is a method of making these weights public so they can be downloaded, run directly, or adjusted according to conditions. However, the single word 'public' often causes confusion due to different meanings being conflated.

Closed-source model

• Used only via API or service, without access to weights.

• Good for quick starts, but operational methods and model changes are subject to provider policies.

Open-weight

• Learned weights can be downloaded, run, adjusted, and deployed.

• Offers flexibility in choosing hosting and versions, but requires checking licenses and operational responsibilities.

Open-source

• Typically refers to the right to use, modify, and share source code. In AI, it's sometimes used in a broader sense to include training code and data information.

• Simply releasing weights does not automatically make an AI fully open-source.

Self-hosting

• Deploying models on a company's own servers or dedicated cloud.

• This is separate from whether a model is open-weight. It requires GPU (a device that processes large-scale computations like image/video/AI operations quickly and simultaneously), security, monitoring, and disaster recovery.

Simply put, open-weight is akin to receiving the 'secret recipe' of a finished dish in numerical form, while open-source is about how open the recipe, cooking tools, and rights to improve are. A public API is like ordering at a restaurant counter, and self-hosting is like making that dish in your own kitchen. These four concepts can coexist but are not the same.

Installing Claude Code does not mean you've received the Claude model.

This distinction becomes even more important in developer tools. Claude Code is a coding tool installed on your computer. However, just because the tool is installed on your machine doesn't mean the weights of the Claude model used within it have been downloaded to your server. Authentication and AI processing still require a service connection.

GPT is also difficult to categorize with a single answer. ChatGPT and the GPT-5.6 series are typical closed-source service models. In contrast, OpenAI has released a separate model, gpt-oss, as open-weight. Therefore, the statement “GPT is closed, and only Chinese models are open” is only half true. The current market is moving towards a direction where both closed-source and open-weight models coexist within the same company.

The same pattern is seen in Chinese companies. Qwen releases the weights for its smaller models while opting to keep its top-tier flagship models API-only. This is why it's important to look separately at which models a company opens and to what extent, rather than just which country the company is from.

What Chinese AI is opening is the distribution network, more than just model files.

So why do Chinese companies release weights? The answer is far more practical than 'giving it away for free.' Released weights can more easily integrate into development tools, model gateways, specialized hosting, enterprise-specific environments, and end-user apps. The model doesn't just stay within one company's chatbot but spreads as an option across various products.

The popularization of open-weight today is less about researchers downloading files and more about developers choosing models from code tools or APIs. Gateways that aggregate multiple models and specialized hosting that manages GPU operations fill this gap. Development environments like Replit don't directly let agents choose the models they use, but they allow users to connect gateways in their apps to integrate open-weight models. Users can call models without directly managing servers, and companies can consider the possibility of moving to dedicated environments or their own VPCs (a walled-off area within a public cloud for exclusive company use) when needed.

This change also impacts the code agent market, where Claude Code and Codex compete. The actual productivity of a code agent isn't solely determined by model scores. It requires the combined operation of repository reading, tool calling, test iteration, permission management, and retry mechanisms upon failure. Open-weight models can become a lower-cost or more tightly controlled inference backend for this execution environment, rather than the sole correct answer.

Kimi K3 shows that 'public' and 'easy to run' are different.

Kimi K3 is a symbolic model of this trend. After being released as an API and product, its weights were made public about ten days later, and avenues for use through official APIs, specialized hosting, gateways, and development products rapidly expanded. In essence, the distribution network was established before the model files. From a company's perspective, this means they can compare various deployment paths instead of relying on a single API.

However, this doesn't mean it can be run lightly on a personal laptop. K3 is an ultra-large sparse model (meaning its overall size is very large, but only a portion is selected for each query), with the released original weights exceeding 1.5 terabytes. It requires not just multiple high-end GPUs but a cluster of several machines, and it cannot run on a single server at all. Even community quantized versions (lightweight versions with reduced precision to lower capacity) are in the hundreds of gigabytes, making them unsuitable for general equipment. There's a significant gap between receiving the files and stably operating the service, involving GPU, memory, network, long context processing, security, and disaster recovery.

The gap isn't just technical. K3's weights were not released under a permissive license that anyone could use; instead, they came with their own license requiring separate contracts or attribution obligations depending on revenue and user scale. Considering that the previous generation had looser conditions, the same company changes its terms across generations. 'Being public' and 'being able to use it as-is for my business' are separate matters.

Therefore, K3's open-weight isn't a promise of 'free local execution for everyone' but rather a long-term negotiation leverage that allows companies to choose how far they want to go, from starting with an API to specialized hosting, dedicated capacity, or their own environment.

The idea that running it yourself is free is almost always wrong.

Open-weight models may have no or low download costs for weights. However, actual service costs begin there. GPU, memory, storage, power and cooling, deployment engineering, monitoring, security patches, quality evaluation, and standby personnel for failures are all costs.

Especially if usage is small or erratic, a public API is often more economical. Conversely, if traffic is sufficiently large and consistent, sensitive data paths need strong control, and there's internal GPU operational capability, then dedicated hosting or self-hosting becomes more meaningful.

Even with the same model, the data's path differs.

For most companies, a hybrid approach combining methods by task is more realistic than choosing just one. Even when using the same model, the scope of data flow and level of control change depending on the invocation path.

• Low and variable usage:Quickly test with an API and manage costs as variable expenses.

• Tasks requiring repetitive use and control:Consider specialized hosting or dedicated endpoints (call addresses opened exclusively for your company).

• High-confidentiality data and closed networks:Consider a dedicated VPC or self-hosting, while also accounting for operational responsibilities.

The risks of Chinese models are more complex than 'total ban'.

The claim that the U.S. has universally banned private entities from downloading or self-hosting Chinese open-weight models does not accurately describe current policy. Actual regulations and discussions are divided into multiple strands, such as government networks, provision of advanced GPUs and cloud services to China, access to large amounts of sensitive U.S. citizen data, investment, intellectual property infringement allegations, remote control, and supply chain risks.

Each strand also has different stages. The ban on government networks has only been legally confirmed for the Department of Defense and its contract execution scope, while legislation covering the entire federal government is still in committee. Prohibition measures enacted by various states are also limited to government devices and networks and do not prevent private use. Legislation to control cloud remote access has passed the House and is awaiting action in the Senate, and export controls on advanced GPUs were adjusted in 2026 to move towards case-by-case review, effectively easing them. Assuming regulations are tightening in only one direction can lead to misjudgment.

The lesson for businesses is simple: merely asking “Is it a Chinese model?” is not enough. You must also consider where prompts and files go, who controls updates and remote management, which cloud and GPU are used, and whether there's a connection to U.S. government or defense customers. Overseas hosting doesn't automatically make it safe, nor does a self-managed VPC eliminate all supply chain risks.

However, this landscape is not fixed. Measures currently in discussion could be accelerated at any time, or conversely, they could be eased. Therefore, it's safer to build systems that can switch models if conditions change, rather than tailoring them to a specific regulatory state at one point in time.

What Korean companies need to build first is a 'changeable structure'.

Korean companies do not need to immediately standardize on a single model from a specific country. What's more important is a structure where business systems and data flows don't collapse even if models are changed. Separating model calls from applications, defining permissible models by data classification, and comparing the same task across at least two models and two deployment paths can be a starting point.

In practice, simply recording the quality of results is insufficient. You must also consider tokens per request (the unit AI uses to count text and for billing), first response time, completion time, number of failures and retries, tool call accuracy, and data retention conditions. The cheapest token can become the most expensive token within a failed agent loop.

The trend of Chinese AI opening its models is not a declaration of defeat for U.S. models. However, it is weakening the premise that good AI must only be rented via expensive, single APIs. Future competitiveness will likely not come solely from choosing the most famous model. It is more likely to emerge from the ability to design business, data, cost, and deployment paths together, and to switch models when necessary.