跪拜 Guibai
← Back to the summary

Open Weights Are a Layer, Not a Strategy: What Kimi K3, Tencent Hy3, and ByteDance Seed Actually Hand Over

Open Weights Are Not the Only Form of Control: A Nine-Item Delivery Comparison of Kimi K3, Tencent Hy3, and ByteDance Seed

A control surface map of three model delivery structures

When enterprises evaluate models, the easiest wrong question to ask is: is it open or closed source?

This dichotomy is useful for software licenses, but it is insufficient to describe what a set of AI systems truly delivers to the adopting team. Obtaining the weights means you can fix a version, choose a deployment location, and modify the runtime, but it does not mean you have acquired mature workflows, product entry points, or the supplier's internal feedback. Conversely, not obtaining the weights does not mean you have no control: selections, layers, materials, characters, dialogue timelines, and continuations also determine whether a model can enter actual production.

The public releases of Kimi K3, Tencent Hy3, and ByteDance Seed precisely demonstrate three different delivery emphases. Kimi K3 places stronger control in the model asset and deployment layer; Hy3 simultaneously opens its weights while entering Tencent products, cloud services, and third-party platforms; Seedream 5.0 Pro and Seed Audio 1.0 push the granularity of control into image and audio creation workflows. [S1][S2][S3][S4][S5][S6]

This is not a strategic classification of the three companies, nor a ranking of model capabilities. It answers only one procurement and architecture question: On the public delivery surface, what can the adopting team control, and what responsibilities must it take on?

1. First, Decompose "Control" into Nine Observable Items

A matrix of nine control items

The nine control items used in this article are not an industry-wide standard, but a set of observation items for procurement review.

Model Assets refers to whether weights, configurations, and related legal authorizations can be obtained. It determines whether a team can continue to run the model independently of the supplier's hosted service.

Version Pinning refers to whether a production system can be locked to a reproducible model version, rather than being silently upgraded by the supplier.

Deployment Location refers to whether a team can decide to run the model on the supplier's cloud, a third-party cloud, an enterprise's private environment, or an offline environment.

Workflow Operation refers to whether users can control specific objects during the model's execution process, such as Agent Harnesses, tool calls, selections, layers, materials, characters, timelines, or continuations.

Product Distribution refers to whether model capabilities can be embedded into the adopter's own products, the supplier's existing products, or third-party developer platforms.

Feedback Visibility refers to whether the adopting team can see how usage feedback enters model iteration. A public statement that a feedback loop exists does not mean the adopter owns that loop.

Verification Responsibility refers to who needs to prove that the model is usable under specific harnesses, data, latency, stability, and security constraints.

Switching Cost refers to whether weights, protocols, workflows, and product couplings can be preserved when migrating from the current model to another.

Undisclosed Items is used to clarify the boundaries of evidence. Undisclosed only means that public primary sources have not stated it; it cannot be written as non-existent.

2. The Nine-Item Control Matrix

The four states in the matrix have the following meanings:

Control Item Kimi K3 Tencent Hy3 ByteDance Seed
Model Assets Explicitly Provided (full weights and related licenses, [S1][S2]) Explicitly Provided (Apache 2.0 weights, [S3]) Supplier-Held (public delivery surface is Seed/BytePlus products and APIs, [S4][S5][S6])
Version Pinning Explicitly Provided (can save and run a specified weight version, [S1][S2]) Explicitly Provided (can download weights and pin version, [S3]) Conditionally Provided (API exposes model IDs, but the underlying runtime is managed by the supplier, [S6])
Deployment Location Explicitly Provided (official API and self-hosted environment operation both have entry points, [S1]) Explicitly Provided (open weights, Tencent Cloud API, and third-party platforms coexist, [S3]) Supplier-Held (existing sources confirm BytePlus/API delivery, no self-hosted weights provided, [S5][S6])
Workflow Operation Conditionally Provided (model and interface can enter a self-built harness; specific processes are implemented by the adopting team, [S1]) Conditionally Provided (Agent, product, and platform integrations are clear; fine-grained processes still depend on surrounding systems, [S3]) Explicitly Provided (selections, lasso, sketch, materials, layers, scenes, dialogue timelines, and continuations, [S4][S5][S6])
Product Distribution Conditionally Provided (can be embedded in products or services, but subject to custom license conditions, [S2]) Explicitly Provided (Tencent products, Tencent Cloud API, open community, and third-party developer platforms in parallel, [S3]) Conditionally Provided (BytePlus API can be embedded in business, but model services and delivery channels are still operated by the supplier, [S5][S6])
Feedback Visibility Undisclosed (sources do not state how external usage feedback enters training or post-training, [S1][S2]) Supplier-Held (official sources explicitly state product feedback enters model improvement, but control is not delivered to the adopter, [S3]) Undisclosed (capability and API sources do not state the feedback loop mechanism, [S4][S5][S6])
Verification Responsibility Conditionally Provided (evaluation conditions are relatively transparent; production retesting and operational responsibility are transferred to the adopting team, [S1][S2]) Conditionally Provided (weights allow independent retesting; product and performance claims still require verification by the adopting team, [S3]) Conditionally Provided (official sources demonstrate capabilities, evaluations, and limitations; specific workflow success rates still require acceptance by the adopting team, [S4][S5][S6])
Switching Cost Conditionally Provided (weights and compatible APIs reduce lock-in, but runtime and license create migration costs, [S1][S2]) Conditionally Provided (open weights and multi-platform distribution reduce lock-in; group product integration increases system coupling, [S3]) Conditionally Provided (output assets can be saved; fine-grained control semantics and APIs are still bound to the supplier's workflow, [S4][S5][S6])
Undisclosed Items Undisclosed (training data, external feedback loop, real production costs, and long-term support commitments) Undisclosed (training data scale, feedback processing details, independent commercial performance, and real unit costs) Undisclosed (weights, license, training data, feedback loop, real stability, and complete costs)

The most important conclusion from the matrix is not whose "openness" is highest, but that the three release structures place control at different layers.

3. Kimi K3: Stronger Model Asset Control, More Complete Adoption Responsibility

Official evidence of Kimi K3's open weights

Kimi K3's public delivery structure simultaneously includes full weights, a custom license, an official API, and an inference entry point. [S1][S2] This allows adopting teams to choose between two directions: using the supplier's hosted interface for quick access, or obtaining the model assets to pin versions and organize runtimes in their own infrastructure.

The core value of weight availability is not "free," but the right to exit. When a supplier's API undergoes version changes, policy adjustments, or service interruptions, the team still possesses a model object that can be saved, verified, and kept running. For projects with strong requirements for data boundaries, long-term version freezing, offline environments, or deep customization, this kind of control is critical.

But the right to exit simultaneously hands responsibility to the adopting team. The Kimi model card explicitly states the inference intensity, tool enhancements, and harness conditions used for different evaluations, and acknowledges that some comparisons were not made in the same operating environment. [S1] This means that even if public scores are the same, changing the harness, toolset, context management strategy, or inference budget may change the results. The adopting team cannot treat a successful weight download as completed production acceptance.

Kimi's custom license also means that legal control is not unconditional. It broadly permits use, modification, deployment, fine-tuning, and derivation, but sets additional requirements for some model services and large-scale commercial use. [S2] No universal legal conclusion should be drawn here; enterprises need to conduct legal review based on their own product form and scale.

Therefore, Kimi K3 is most suitable not for "everyone who wants to save on API fees," but for teams that genuinely need to control model assets, versions, and deployment boundaries, and have the capability to bear the responsibility for infrastructure, evaluation, security, and upgrades.

4. Tencent Hy3: Open Weights and Product Closed-Loop Are Not Contradictory

Official evidence of Hy3's openness and distribution

Hy3 is most easily mischaracterized as the opposite of Kimi: Kimi opens weights, Tencent relies on group products. Official materials do not support this dichotomy.

On one hand, Tencent provides Hy3 weights under Apache 2.0 and distributes them to Hugging Face, ModelScope, and various third-party developer platforms; on the other hand, it integrates Hy3 into Tencent products and Tencent Cloud APIs. [S3] It simultaneously delivers model asset control, hosted service entry points, and product distribution channels.

This is a "dual-layer delivery." Teams needing autonomous deployment can obtain the weights; those lacking inference operation and maintenance capabilities can use the cloud interface; businesses wishing to enter existing office, knowledge base, OS assistant, customer service, or gaming scenarios can leverage Tencent's existing product integrations.

Hy3 is also the only one of the three for which the primary sources explicitly describe a product feedback-to-model improvement chain. Tencent states that real-world usage in developer and large-scale business scenarios provides input for the model's continuous evolution, summarizing it as a development closed-loop consisting of infrastructure reconstruction, product feedback, and model improvement. [S3]

But this fact only proves that Tencent publicly declares an internal feedback loop exists. It does not prove that external enterprises adopting Hy3 can see feedback samples, influence training priorities, or replicate the same improvement speed. For external teams, this control item remains primarily held by the supplier.

Hy3's practical advantage is therefore not "being more commercial than open weights," but placing open weights, cloud services, third-party distribution, and group product integration within the same release structure. It suits teams that need both model accessibility and a desire to reduce the integration distance from model to business entry point.

5. ByteDance Seed: Not Delivering Model Assets, But Can Deliver Production Control

Official evidence of Seedream's workflow control

Seedream 5.0 Pro and Seed Audio 1.0 demonstrate another type of control.

Seedream advances image editing from "re-describe the entire image" to "specify where and what to change." Public capabilities include point selection, lasso, box selection, doodling, color and material replacement, sketch-driven editing, region isolation, layer separation, and multi-image fusion. [S4][S6] These capabilities control not the weights, but the design objects themselves. Layers can be independently dragged and scaled, and local areas can be repeatedly modified, meaning generated results can more easily enter subsequent design pipelines.

Seed Audio expands the control object from a single speech line to a sound scene. Users can describe characters, emotions, environments, sound effects, and scene progression methods, and specify entry timelines for character dialogue; the model also supports long audio continuation and multi-language character consistency. [S5] For short videos, advertising, gaming, podcasts, and film/TV pre-visualization, this control is closer to the actual deliverable than "whether the model's weights are open."

ByteDance Seed's public delivery surface is currently mainly the Seed project page, BytePlus products, and APIs. Seedream's API uses explicit model IDs, and Seed Audio provides services through BytePlus. [S5][S6] Teams can control the process at the request, parameter, selection, timeline, and output asset layers, but have not obtained underlying weights, self-hosted runtimes, or training feedback mechanisms from these sources.

Therefore, Seed's control is closer to creative workbench control: the supplier holds the model service, and the creator controls the local objects, structure, and rhythm within the work. This structure can significantly reduce production iteration costs, but also leaves version upgrades, service availability, interface semantics, and underlying model changes on the supplier's side.

6. The Closer the Control Is to the Bottom Layer, the More Responsibility the Adopting Team Takes On

Three layers of control surface and responsibility transfer

The three release structures can be understood by control layer:

The Model Asset Layer addresses "can the model be taken away." The weights of Kimi K3 and Hy3 enable teams to save versions, choose operating locations, and establish exit paths.

The Service and Product Layer addresses "how the model enters the business." Hy3's cloud services, third-party platforms, and Tencent product integrations shorten the distance from model to real users.

The Workflow Layer addresses "how a user completes an editable task." Seedream and Seed Audio place control on selections, layers, materials, scenes, and timelines.

These three layers cannot substitute for each other. Having weights without a stable workflow may still prevent the model from entering production; having a strong workflow without weights leaves the team dependent on the supplier's service; having a product entry point without an independent verification system may lead to mistaking a supplier's demo for one's own business results.

More control is not always better. For each layer of underlying control gained, the adopting team typically takes on corresponding responsibilities:

Supplier-hosted services do not eliminate these responsibilities; they merely redraw the boundaries. The supplier is responsible for the model and infrastructure; the adopting team is still responsible for business results.

7. Selection Decision Tree: First Determine the Object to Control

A decision tree for selecting a model delivery structure

The decision tree below is not a ranking of model quality, but a sequence for selecting a release structure.

Start
│
├─ 1. Do data, network, or compliance requirements mandate that the model must run in a self-owned environment?
│     ├─ Yes → Prioritize evaluating the open weights of Kimi K3 or Hy3
│     │       ├─ Need a permissive standard license and multi-platform distribution → Focus evaluation on Hy3
│     │       └─ Need Kimi's specific model capabilities or interface structure → Evaluate Kimi K3, conduct license review first
│     └─ No → Go to 2
│
├─ 2. Is it necessary to pin the model version long-term and retain a supplier exit path?
│     ├─ Yes → Prioritize open weights; API only as a supplement for elasticity or cutting-edge capabilities
│     └─ No → Go to 3
│
├─ 3. Is the core issue local editability in image or audio creation?
│     ├─ Yes → Focus evaluation on ByteDance Seed
│     │       ├─ Image: selections, sketch, materials, layers, and multi-image fusion
│     │       └─ Audio: characters, emotions, scenes, dialogue timelines, and continuations
│     └─ No → Go to 4
│
├─ 4. Do you wish to directly leverage existing office, knowledge base, cloud, or group product entry points?
│     ├─ Yes → Focus evaluation on Hy3's product and cloud integrations
│     └─ No → Go to 5
│
└─ 5. Does the team possess continuous inference operation and independent evaluation capabilities?
      ├─ Yes → Can use open weights as the main path, and retain an API control group
      └─ No → First use a hosted API to validate business value, then decide whether to take over model assets

Real-world systems are often not a choice of one out of three. A more robust architecture is to layer the control surfaces: models are adapted through a unified interface, business workflows are maintained independently, output assets are saved in open formats, and supplier-specific features are encapsulated in replaceable modules. This allows simultaneous use of open weights, cloud APIs, and specialized creative models, rather than binding the entire product to a single vendor.

8. Five Questions to Add During Procurement

A checklist of five questions before procurement

First, what can we truly not afford to lose? Is it weights, a pinned version, private deployment, or selection, layer, and timeline capabilities? Without clarifying this, discussions about "openness" have no procurement meaning.

Second, when the supplier updates the model, can we refuse the upgrade? Weights can usually be pinned; API model IDs can provide a certain version boundary, but the backend runtime and policies may still be managed by the supplier.

Third, do the official evaluations reproduce our harness? The Kimi model card has already shown that different tools, inference budgets, and harnesses change results. [S1] All three types of models should be retested under the same business tasks, the same quality thresholds, and the same failure handling processes.

Fourth, who has the ability to fix things when they fail? Weight-based models allow teams to modify runtimes, quantization, prompts, and fine-tuning, but require stronger engineering capabilities; workflow APIs allow rapid adjustment of inputs and interactions, but cannot directly fix the underlying model.

Fifth, what assets can be taken away during migration? Model weights, evaluation sets, prompt templates, tool protocols, layer files, audio tracks, material metadata, and audit records should all be saved independently. True supplier exit capability comes from migratable assets, not a line in a contract saying "export is supported."

Conclusion

Open weights are not the only form of control, nor are they the entirety of control.

Kimi K3 publicly delivers model assets, versions, and deployment choices, but hands more of the verification, operation, and license responsibility to the adopting team. Hy3 simultaneously provides Apache 2.0 weights, cloud APIs, third-party platforms, and Tencent product integrations, with Tencent publicly describing product feedback entering model improvement; this feedback loop remains primarily held by the supplier. ByteDance Seed did not deliver underlying model assets in this public material, but advanced the granularity of control to image selections, layers, materials, and audio characters, scenes, timelines, and continuations.

The mature selection criterion is not "who is more open," but four questions: what object needs to be controlled, what responsibilities are you willing to take on, what dependencies can you accept, and what undisclosed items must be clarified before procurement.

Primary Sources