Kimi K3: Capabilities, Hardware, and Access Options

Kimi K3 is Moonshot AI's open-weight multimodal model. Moonshot's model card lists 2.8 trillion total parameters, 104 billion activated per token, a 1,048,576-token context window, and a custom Kimi K3 License. Those are properties of the model as Moonshot releases it. What you get in practice depends on how you reach it.

There are three broad routes. You can run the weights yourself, which requires very large serving infrastructure. You can use Moonshot's API or another host. Or you can use K3 in Maple, where we offer it on our Pro, Max, and Team plans with a 262,144-token context window, through our protected inference path.

Each route differs in context length, input types, setup burden, and where your information goes. This guide separates what belongs to the model from what belongs to each route so you can choose among them.

Sources were checked on 11 October 2026. Model support, plans, and deployment recipes can change.

What is Kimi K3?

Kimi K3 is a mixture-of-experts model from Moonshot AI with 2.8T total parameters, of which 104B are activated for each token. The gap between those two numbers comes from the design: the model contains many specialized sub-networks, and only some of them run for each token. That reduces the computation per token compared with a dense model of the same total size.

It does not reduce the amount of model you have to store. All 2.8T parameters must be available to the serving system, because different tokens route to different experts. A simple calculation shows the scale: at one byte per parameter, the weights alone come to roughly 2.8 terabytes; at half a byte, roughly 1.4 terabytes.

Those figures cover only the weights. They leave out the memory a long context consumes during inference and any serving overhead, and they are not a hardware recommendation for any particular quantization.

The card's specification table also lists a 1,048,576-token context window, roughly a million tokens, with text and image input. The card's overview says K3 understands video as well, but its specification table lists only text and image. Confirm video support on the route you plan to use.

Is Kimi K3 open source?

Not in the standard sense. K3 is open-weight: Moonshot publishes the weights for download under the Kimi K3 License, a custom license. It is not MIT or another standard open-source license, and it includes conditions related to offering services and to revenue.

If you plan to build a product or service on the weights, read the license yourself and get legal advice where it matters. This guide describes the license; it doesn't interpret how the license applies to your situation.

How is Kimi K3 different from Kimi K2.6?

They are separate releases with different scale, context, and license terms. Moonshot's API guide also gives them different input and thinking-mode behavior. Those upstream and API differences should not be mistaken for a head-to-head test in Maple.

Moonshot says K3 always runs in thinking mode in its API, while K2.6 can switch between thinking and non-thinking modes. These statements describe Moonshot's own service; they do not establish the controls exposed by another host. If you need K2.6's video input or selectable thinking mode, confirm the route you intend to use before building around it.

What do Moonshot's evaluations show?

They show strong vendor-reported results, with a limit Moonshot states itself. Moonshot publishes benchmark comparisons in its K3 launch post⁸ and its technical paper.⁹ The launch post says K3's overall performance still trails the most powerful proprietary models it names.

These are vendor-reported results: Moonshot chose the benchmarks and conditions. They are useful evidence, but they are not Maple measurements of the model in our product.

A few habits help when reading them:

• Check the harness and effort settings. Agentic and coding benchmarks depend heavily on the scaffolding around the model and on how much reasoning budget it gets. Two scores on the same benchmark name may not be comparable if the setups differ.
• Check which version of each competitor was tested. Comparisons date quickly as other labs release models.
• Treat benchmarks as a shortlist signal. A strong result on a coding suite suggests K3 is worth trying on coding work. It doesn't promise performance on your codebase, your documents, or your prompts.

The most reliable evidence is still a test on your own representative tasks. That matters more than usual with K3, because route differences in context window and reasoning behavior can change results.

What hardware does Kimi K3 need to self-host?

There is no universal minimum, but both public deployments we found use multi-accelerator servers and about 1.5 TB of weights. Running K3 yourself gives you the most control: the weights, the serving stack, and the data stay under your operation. The cost is infrastructure and engineering work, and the scale of the model makes that work substantial.

Two public write-ups show what deployment looks like on specific hardware. The vLLM Ascend tutorial is a serving recipe for Huawei Ascend accelerators. Shakudo's AMD GPU write-up documents a hands-on deployment, from hardware choice and model conversion to launch configuration.

Those results belong to each author's configuration. Neither recipe is configured for the full million-token window, so a model's maximum context is not a promise about a particular deployment.

Neither source sets a universal minimum, and we don't offer one either. Hardware needs depend on the quantization you choose, the context length you want to serve, how many concurrent users you expect, and your serving framework. A team serving short prompts to a few internal users faces a different problem from one serving long-context requests at volume.

Self-hosting is the right call in some cases:

• your information must never leave hardware you control
• you need to modify, fine-tune, or deeply instrument the model
• you already operate multi-accelerator inference and have capacity to spare

If none of those apply, it is worth asking whether the operational work buys you anything a hosted route can't. Our GLM-5.3 guide works through the same hardware question for another open-weight model.

How do you use Kimi K3 in Maple?

Choose Kimi K3 from the model picker in Maple Research on a Pro, Max, or Team plan. It is not available on Free. We configure K3 with a 262,144-token context window, which is about a quarter of the upstream maximum and still enough for long documents, substantial codebases, or extended conversations.

Plan details are on our pricing page. K3 also appears in our model library alongside the other models we offer.

You can upload an image while using K3 in Research. The app first has a vision model describe the image, then gives that description to the model you selected.¹⁰ K3's answer is based on that description, not a direct view of the image. This matters if your task depends on a small visual detail the description might miss.

For developer tools and existing applications, Maple Proxy is our API route. Check the current Proxy documentation for the model ID, input types, and context limit before building on it.

This route gives you two things. First, you get access to a very large open model without provisioning the terabytes of accelerator memory described above, maintaining a serving stack, or keeping up with framework updates. Second, your requests run through our protected inference path, not a conventional hosted API. The next section explains how that path works.

The route also has limits you should plan around:

• Context is 262,144 tokens, not 1M. If your workflow depends on feeding K3 more than that in one request, our route won't do it. Moonshot's API or a self-hosted deployment configured for long context will.
• No video input. Our K3 route takes text and images.
• A paid plan is required. K3 is on Pro, Max, and Team.

What information reaches each route?

That depends on who operates the model: you, a conventional host, or Maple. Privacy questions get blurry when several separate issues are treated as one. Who can read your prompts and outputs while they are processed? What happens to them afterward, and is any of it used for training?

Self-hosted weights. Your prompts and outputs stay on infrastructure you operate. The trust boundary is your own: your access controls, your logging choices, your retention policy. That makes this route the strongest option when information must stay on your hardware, and it makes you responsible for securing it.

A conventional hosted API. With Moonshot's API or another host, your requests are processed on the provider's servers in a form the provider's systems can read. What happens next depends on that provider's terms and practices on retention, training use, and access. Those vary by provider and sometimes by plan, so read the relevant terms for the specific service and tier you'd use.

Maple. Your requests are encrypted before they leave your device and are processed inside a secure enclave, an isolated computing environment. Our proof page describes the architecture and the attestation you can check yourself.

No third party can read your chats: the models run inside attested trusted execution environments. Our privacy notice covers everything outside your chats.

That design has a scope. It protects the contents of your chats: your prompts and the responses. It doesn't make information private if you've already shared it elsewhere.

It is also separate from the safety of what a model's output leads you to do. If you paste K3's code into a production system or let an agent act on its suggestions, confidential processing doesn't vouch for that code or those actions. Review outputs as you would any untrusted input.

Which route fits your task?

It depends on where your information may go, how much context you need, and how much infrastructure you can run. The table compares the three routes on the same terms.

A rough decision rule:

• Choose self-hosting if information must stay on your hardware, or you need control over the weights themselves.
• Choose Moonshot's API or another host if you need the full million-token window or capabilities outside our route, and a conventional provider boundary fits your data.
• Choose Maple if you want to use K3 on sensitive material without running infrastructure, and your work fits within 262,144 tokens of text and images.

Sources

1. Moonshot AI, Kimi K3 model card, accessed 11 October 2026. Source for total and activated parameters, the mixture-of-experts design, context length, listed input types, and the license label.
2. Moonshot AI, Kimi K3 License, accessed 11 October 2026. Source for the custom license and its service and revenue conditions.
3. vLLM Ascend, Kimi K3 tutorial, accessed 11 October 2026. Source for the four-node Atlas 800 A3 reference deployment, the W4A8 checkpoint size, and its configured context length.
4. Shakudo, “How We Deployed Kimi K3 on AMD GPUs”, updated 4 September 2026. Source for the eight-GPU MI325X deployment, the checkpoint size and conversion, the configured context length, and Shakudo's own speed measurement.
5. Moonshot AI, Kimi K2.6 model card, accessed 11 October 2026. Source for K2.6's parameters, context length, and license.
6. Maple, public model configuration and Research model picker, checked 11 October 2026. Source for Kimi K3's plan tier, configured context window, and listed input types in Maple.
7. Moonshot AI, Kimi API model selection guide, accessed 11 October 2026. Source for the API's context limits, K2.6's input types, and each model's thinking-mode behavior.
8. Moonshot AI, Kimi K3 launch post, accessed 11 October 2026. Source for Moonshot's evaluation claims and its statement about proprietary models.
9. Kimi Team, “Kimi K3: Open Frontier Intelligence”, arXiv, submitted 27 July 2026 and revised 7 August 2026. Moonshot's technical report on the architecture and evaluations.
10. Maple, Research image handling and vision helper, checked 11 October 2026. Source for image description before the selected model responds.