What Is Kimi K2? Model Size, K2.6 vs K2.7 Code, and How to Deploy It with GreenNode

What is Kimi K2?

Kimi K2 is a family of open-weight large language models (LLMs) developed by Moonshot AI. The model uses a Mixture-of-Experts (MoE) architecture, with 1 trillion (1T) total parameters but only 32 billion (32B) parameters activated per token.

This mechanism lets Kimi K2 tap the capacity of a very large model without activating every parameter on each pass. Deploying the model, however, still requires substantial memory to store the weights.

The newer versions, including Kimi K2.6 and K2.7 Code, support a context window of up to 256K tokens and are released under a modified MIT license.

In this article, we'll look at Kimi K2's size, the hardware requirements for self-hosting, the differences between versions, how to set up prompts and call the API, and what to weigh when choosing a model for a real project.

Kimi K2 technical specs: how many resources does a 1T-parameter model need?

To understand Kimi K2's size and its hardware requirements, you need to distinguish two concepts: total parameters and the number of parameters activated on each pass.

Kimi K2 technical specifications

Why does the model have 1T parameters but activate only 32B?

Kimi K2 uses an MoE architecture, in which experts specialize in handling different parts of the input. Instead of activating the entire network for each token, the model selects a suitable group of experts to perform the computation.

As a result, only about 3.2% of the total parameters are activated at each processing step. This reduces the amount of computation compared with activating all 1T parameters.

However, the number of active parameters is not the same as the memory needed to run the model. When you self-host Kimi K2, you still have to store the weights of all the experts so the model can select from them when needed. This is why Kimi K2 can be relatively compute-efficient yet still require a GPU system with large memory.

How much VRAM do you need to run Kimi K2?

The weight size depends on the parameter precision and the quantization method. As a rough estimate, the memory needed for the weights equals the number of parameters times the bytes stored per parameter.

Note: These are estimates of weight size, not configurations guaranteed to run the model reliably in every case. Actual requirements also depend on the weight format, how the model is sharded, the KV cache, context window, batch size, and inference engine. Check compatibility before choosing a configuration.

To deploy Kimi K2 in production, developers typically need a multi-GPU system combining techniques such as tensor parallelism and expert parallelism. Engines such as vLLM, SGLang, KTransformers, or TensorRT-LLM may be considered, depending on the model version and level of support.

Quantizing to 4-bit or lower significantly reduces the weight size but can affect output quality. So you should evaluate the model on your real data and tasks before an official rollout.

For teams without existing GPU infrastructure, the question is not only whether Kimi K2 can run, but whether the cost of maintaining the system is proportionate to the usage. This is also an important factor when weighing self-hosting against an API.

How do Kimi K2, K2 Thinking, K2.5, K2.6, and K2.7 Code differ?

Moonshot AI has developed several Kimi K2 versions to meet different usage needs. The main differences lie in release timing, what each version is optimized for, and the type of task it targets.

K2.6 or K2.7 Code on GreenNode MaaS: which version fits your needs?

Instead of only asking "which model is stronger?", start from the problem you need to solve. Each Kimi version is optimized for different task groups. On GreenNode MaaS, you can choose between the two flagship versions - K2.7 Code and K2.6 - depending on your deployment needs.

K2.7 Code: for coding and multi-step agentic workflows

K2.7 Code fits programming applications and code-focused AI agents, especially when the work requires many consecutive processing steps:

• Coding assistant: support for programming in an IDE or CLI.
• Software engineering: complex tasks such as large-scale refactoring, codebase migration, and debugging across many files.
• Coding agent: automatically generating code, calling tools, and iterating on edits until the test conditions are met.
• Code review: helping review pull requests and generate unit tests.

Why choose K2.7 Code? This version is purpose-built for coding, always runs in thinking mode, and is reported to use about 30% fewer thinking tokens than K2.6. With a 256K context window, the model can also handle large amounts of context in complex programming tasks. Actual effectiveness depends on your codebase and deployment configuration.

K2.6: for enterprise knowledge and general-purpose tasks

If your application needs to tap enterprise knowledge or handle many different kinds of work, K2.6 is worth considering:

• Enterprise knowledge and RAG: retrieval, synthesis, and Q&A over internal document stores.
• General-purpose AI assistant: content writing, document summarization, and information analysis.
• Multimodal workflows: processing text, image, or video input, per the model's supported capabilities.
• Enterprise chatbot: building customer-support assistants or internal Q&A systems.

Why choose K2.6? It's a flexible choice for applications that need to combine multiple task groups. The 256K context window supports long context, useful when working with documents and enterprise knowledge bases.

Flexible model selection with GreenNode MaaS

Because K2.6 and K2.7 Code are offered through one unified API on GreenNode MaaS, businesses can choose the version per task group without building a separate integration pipeline for each model.

For example, an application can use K2.7 Code for its coding agent and K2.6 for an enterprise-knowledge assistant. This approach lets teams flexibly pick the model each workflow needs, while simplifying the integration and management of AI applications.

Kimi K2 prompt format and the parameters you need to know

Kimi K2 supports an OpenAI-compatible chat interface (OpenAI-compatible API). If your application already uses the OpenAI SDK, you can reuse the familiar request structure to integrate the model.

System prompt for Kimi K2

The basic system prompt recommended in the model card is:

You are Kimi, an AI assistant created by Moonshot AI.

This is a minimal system prompt, suitable to start testing. For a real application, you can add the role, goals, output format, and any constraints needed for your use case.

Key parameters when calling Kimi K2

Temperature

Temperature affects how much variation there is in the model's output. Per the reference configuration in the source documentation, you can start with temperature=0.6 for K2-Instruct. The K2.7 Code coding benchmarks used temperature=1.0 and top_p=0.95.

Don't assume the benchmark configuration is optimal for every application. Adjust the parameters based on your requirements for consistency, accuracy, and output quality.

Tool calling

Kimi K2 supports tool calling. You can declare a list of tools and set tool_choice="auto" so the model selects the appropriate tool for the request.

When the model returns finish_reason="tool_calls", your application needs to execute the corresponding tool, then send the result back as a message with role="tool" and the matching tool_call_id. This flow must be implemented in your application code, and the inference engine must support the tool-call parsing that corresponds to the model.

Context window

K2.6 and K2.7 Code support a context window of up to 256K tokens. A long context window is useful when processing large repositories, long documents, or an agent's interaction history.

However, a maximum context window does not mean every request uses all of it. Input and output tokens still affect cost, latency, and the resources required.

Kimi K2.7 Code benchmarks: how good is it at coding and AI agents?

Moonshot AI positions Kimi K2.7 Code as a model for in-depth coding and agentic tasks. According to the vendor, the model outperforms K2.6 on the listed benchmarks while using about 30% fewer thinking tokens.

To assess these results, you need to consider both the benchmark methodology and the usage context. The figures below are drawn from results Moonshot published in October 2026, not from independent verification.

Coding benchmarks

Agentic benchmarks

Per the methodology described in the source, the Kimi K2.7 Code benchmarks were run through the Kimi Code CLI with thinking enabled, temperature 1.0, top-p 0.95, and a 256K context window. GPT-5.5 was run in Codex, and Claude Opus 4.8 in Claude Code.

Results across different models should be read in this context, since the execution environment, supporting tools, and test setup can all affect the outcome.

What should developers take away from the benchmarks?

Kimi K2.7 Code shows an improvement over K2.6 on the published tests, especially on tasks that require coding and multi-step tool use. However, the model does not lead on every benchmark against the options it is compared with.

Beyond benchmark scores, there are three factors you should evaluate before putting the model into production:

• Task completion rate: Does the model correctly solve requests on your real codebase and data?
• Cost per successful task: Do the tokens used, API price, and number of retries push total cost up?
• Stability: Does the model maintain quality across different request types, edge cases, and tool-use flows?

Using fewer thinking tokens can help reduce cost, but it isn't enough to conclude the model is always cheaper. Real cost must be calculated across the entire execution process and the successful-completion rate.

If you need a systematic evaluation method, see the guide on how to choose the right AI model with MaaS.

Why should developers consider Kimi K2?

Now that you've seen the definition, specs, and how the versions differ, here's why Kimi K2 is worth considering for an AI application:

• More control with open weights. Under the modified MIT license, developers can download the weights to self-host, inspect, and fine-tune as needed, rather than depending entirely on a closed API.
• A fit for coding and AI agent tasks. Kimi K2.7 Code is optimized for multi-step software-engineering tasks, while K2.6 serves a more diverse set of needs.
• Potential to optimize cost per task. K2.7 Code uses about 30% fewer thinking tokens than K2.6, according to published figures. Actual savings also depend on token pricing, output length, and task completion rate.
• Long context support. The 256K-token context window lets the model take in large amounts of information, such as a repository's source code or an AI agent's long interaction history.
• Usable via API without running GPUs yourself. Kimi K2.6 and K2.7 Code are available on GreenNode MaaS with an OpenAI-compatible API, making it easier for developers to integrate and test the model.

Should you use Kimi K2 via a managed multi-model service or self-host the model?

After identifying the right model, the next step is choosing how to deploy it. With Kimi K2, two common directions are self-hosting the model on GPU infrastructure or using a managed API.

Using Kimi K2 via a managed multi-model service (GreenNode MaaS)

If your goal is to integrate the model into your application quickly without investing in GPU infrastructure right away, a model-as-a-service approach is a good fit.

Kimi K2.6 and K2.7 Code are available on GreenNode MaaS, letting developers call the model through an OpenAI-compatible API. This approach simplifies testing and makes it more convenient to compare or switch between models.

Businesse can learn more about ready-to-use AI models and how to integrate via API, or use the No-code Playground to test the model before integrating it into your application.

One thing to note is that Kimi on GreenNode MaaS is a partner model, not a model self-hosted on GreenNode's GPUs. Requests are routed to the partner's inference infrastructure under a service-provision model. If your application handles sensitive data, you need to review the data-handling terms, data flow, and governance requirements before choosing.

When should you self-host Kimi K2?

Self-hosting Kimi K2 on your own infrastructure may be appropriate if you:

• Have strict data-sovereignty requirements or an air-gapped environment that doesn't allow sending data to a third party.
• Have large and relatively stable inference volume, enough to justify the economics of maintaining your own GPU system.
• Have an ML and infrastructure team capable of operating the inference engine, allocating experts, optimizing quantization, and handling incidents.

In return, you need to actively manage the hardware, serving capacity, GPU utilization, scalability, and maintenance costs.

When is a managed service the more sensible choice?

A model-as-a-service is usually a fit if you:

• Want to test and get to market fast without building your own inference infrastructure yet.
• Have moderate or time-varying usage traffic.
• Need the flexibility to compare, switch, or combine multiple models.
• Want to reduce the workload around capacity planning, GPU utilization, and infrastructure upgrades.

There is no single choice that fits every case. For an accurate comparison, calculate the total operating cost of the self-host option and compare it with the API cost on the same workload, while also accounting for output quality, latency, and data-governance requirements.

Beyond the Kimi models, GreenNode MaaS offers a diverse catalog of AI models designed to meet different enterprise needs. Businesses, therefore, can explore, compare, and integrate the models that best align with their application requirements and AI development goals.

Explore Kimi K2.6, K2.7 Code, and the AI model catalog on GreenNode MaaS.