Open-Source LLMs 2026: DeepSeek-V4, Kimi-K2.6, and the Enterprise Self-Hosting Decision

By Law Wen Feng, Principal Solution Architect — wenfeng.my

If you've been watching the open-source LLM space over the past twelve months, you know we've entered a new era. DeepSeek's V4 family openly competes with frontier closed-source models on reasoning and coding, and Moonshot AI's Kimi K2.6 has redefined what an agentic, code-first open-weight model can do. Both are open-weight. Both are serious. Both are MIT-licensed — with one caveat on Kimi that I'll cover.

For enterprise teams in Southeast Asia — particularly those already running on Azure — the question is no longer whether open-source LLMs are viable. The question is: should we self-host, on what hardware, and at what real cost?

This article breaks down both models with verified specifications, does the GPU memory math that most blog posts skip, lays out actual Azure Southeast Asia pricing, and walks through a deployment. If you're an Azure-first team in Malaysia, Singapore, or the broader region, this is for you.

The Two Models: What You're Actually Comparing

DeepSeek-V4

DeepSeek-V4 ships in two variants, both designed for long-context reasoning, coding, and agentic workflows, with a 1M-token context window:

• DeepSeek-V4-Pro: 1.6 trillion total parameters, 49 billion active per token. This is the flagship — a sparse Mixture-of-Experts model built for maximum reasoning, coding, and agentic performance.
• DeepSeek-V4-Flash: 284 billion total parameters, 13 billion active per token. The cost-efficient option. It trails Pro on knowledge-heavy tasks due to its smaller scale, but reaches comparable quality on many production workloads at a fraction of the serving cost.

The MoE architecture is the key point. Only a fraction of the total parameters activate on any given token, so inference compute per token is dramatically lower than a dense model of equivalent capability. But — and this is where most write-ups go wrong — all the weights still need to sit in GPU memory. Sparsity makes inference cheap; it does nothing for your memory footprint. I'll do that math properly below.

DeepSeek-V4 is released under the MIT license, supporting commercial use, modification, and distribution with minimal restrictions.

Kimi K2.6

Moonshot AI's Kimi K2.6 is a roughly 1 trillion parameter MoE model with 32 billion active parameters per token, built around Multi-head Latent Attention (MLA) for efficient long-context handling, with a 256K-token context window. It is natively multimodal — a MoonViT vision encoder supports image and video input, though video understanding is still experimental and currently limited to the official API.

Where K2.6 stands out:

• Long-horizon coding: Benchmark results are competitive with top closed-source models, and it sustains long autonomous coding sessions across frontend, backend, DevOps, and performance tuning — including niche languages like Zig.
• Agent swarm orchestration: K2.6 can decompose complex tasks into up to 300 parallel sub-agents across 4,000 coordinated steps — a major expansion from K2.5's 100 sub-agents and 1,500 steps.
• Proactive autonomous agents: In internal tests, a K2.6-backed agent operated autonomously for five days managing monitoring, incident response, and system operations without human oversight.
• A preserve_thinking mode that keeps full reasoning traces across turns, improving reliability in multi-turn agent workflows. Moonshot's Kimi Code CLI is the purpose-built framework for it.

On licensing: K2.6 uses a modified MIT license. The sole modification — if you use it commercially with over 100 million monthly active users or over $20 million monthly revenue, you must prominently display "Kimi K2.6" in your product UI. For nearly every enterprise reading this, that clause is irrelevant.

My short version: K2.6 is the specialist for code-centric and agentic workloads. DeepSeek-V4 is the generalist for reasoning, document processing, and multilingual enterprise AI.

When Self-Hosting Actually Makes Sense

Before infrastructure and costs, let's establish when self-hosting is the right call. From client engagements across the region, self-hosting makes sense when at least one of these is true and cost is not your only lens:

1. Data sovereignty requirements: Regulated data — financial records, healthcare information, government contracts under PDPA 2010 — that compliance will not allow to leave your infrastructure or flow to third-party API endpoints.
2. Deep customization: You need to fine-tune on domain data (legal documents, technical manuals, proprietary codebases) and need full control of the weights.
3. Extreme volume: You are processing tens of billions of tokens per month. API costs scale linearly; self-hosting amortizes fixed infrastructure.
4. Vendor risk management: You've been burned by API deprecations, pricing changes, or rate limits.

If none of these apply, API access is almost certainly cheaper and simpler. Don't romanticize self-hosting — it's an operational commitment. The break-even math below will show you exactly why.

The GPU Memory Math Most Articles Skip

MoE sparsity reduces compute per token, but every parameter still needs memory. Here's the honest arithmetic at different precisions:

Now map that to real hardware, before KV cache and batch headroom:

• V4-Pro at FP8 (~1.6 TB): needs roughly 12–16x H200 (141 GB each) or 20+ H100 80GB. A single 8-GPU node is not enough at any practical precision.
• V4-Flash at INT4 (~142 GB): fits on 2x H100 NVL (94 GB each = 188 GB) with headroom for KV cache at moderate context.
• K2.6 at FP8 (~1.0 TB): fits on 8x H200 (1,128 GB total) — one node, tight but workable.

This is the first place I see proposal math go wrong in the wild: "just rent an 8x H100 box" only works for the smallest of these three models, and only with aggressive quantization.

Azure Reality Check: What You Can Actually Rent in Southeast Asia

This is where it gets interesting for regional teams. I checked the live Azure retail pricing API for Southeast Asia (Singapore) while writing this:

• Standard_ND96isr_H200_v5 — 8x NVIDIA H200 (141 GB each, 1,128 GB total HBM3e), 96 vCPUs. Available in Southeast Asia at $110.24/hour (≈ $80,475/month pay-as-you-go). This is your workhorse for serious MoE serving in-region.
• Standard_NC80adis_H100_v5 — 2x NVIDIA H100 NVL (94 GB each = 188 GB), 80 vCPUs. $18.148/hour (≈ $13,248/month). The entry point for INT4-quantized serving.
• Standard_NC40ads_H100_v5 — 1x H100 NVL (94 GB), 40 vCPUs. $9.074/hour (≈ $6,624/month). Fine for experimentation, too small for these models in production.

What's not on the Southeast Asia retail price list: the 8x H100 ND_H100_v5 series and the 8x A100 ND96asr_A100_v4 series. If your architecture document assumes "rent an ND96asr_v4 in Singapore," that assumption needs revisiting — the in-region frontier is now H200-based. (The A100 workhorse appears in other regions, e.g. around $27.20/hour Linux in West US 3, if you can tolerate the latency and data residency implications.)

Risk: GPU capacity is quota-gated and supply-constrained. Request quota increases early, and have a fallback region agreed with your compliance team before you commit to a timeline.

Cost Analysis: The Real Numbers

Using verified Southeast Asia pay-as-you-go pricing, 730 hours/month, plus realistic storage, networking, and operational overhead:

Scenario A: DeepSeek-V4-Pro, FP8, on 2x ND96isr_H200_v5 (16x H200)

Scenario B: Kimi K2.6, FP8, on 1x ND96isr_H200_v5 (8x H200)

Scenario C: DeepSeek-V4-Flash, INT4, on 1x NC80adis_H100_v5 (2x H100 NVL)

Reserved capacity (1–3 year) can cut the VM line by roughly 40–60% — that's the first lever to pull if you commit.

The API Side

DeepSeek's published V4 API pricing (per million tokens, cache-miss rates): V4-Flash costs $0.22 input / $0.66 output off-peak (peak: $0.44 / $1.32); V4-Pro costs $0.66 input / $1.98 output off-peak (peak: $1.32 / $3.96). Cache-hit input drops to $0.007–$0.022, which matters enormously for RAG workloads with repeated context.

Break-Even

Take Scenario C at ~$16K/month all-in. At V4-Flash off-peak API rates with a typical 3:1 input-to-output mix (blended ≈ $0.33 per million tokens), break-even lands around 47 billion tokens per month. That's billions of tokens per day, every day, on one workload.

The math is unambiguous: unless you are at extreme scale, self-hosting is a compliance, sovereignty, or customization decision — not a cost decision. Anyone selling you self-hosting as the cheap option has not done this arithmetic.

Practical Deployment: V4-Flash on Azure

Here's a working deployment of DeepSeek-V4-Flash (INT4) on the NC80adis_H100_v5 — the most accessible entry point. Kimi K2.6 on the H200 node follows the same pattern, scaled up.

Step 1: Provision

# Resource group in Southeast Asia
az group create --name rg-llm-inference --location southeastasia

# 2x H100 NVL inference VM (request quota first: az vm list-skus --all)
az vm create \
  --resource-group rg-llm-inference \
  --name vm-v4-flash \
  --image Canonical:0001-com-ubuntu-server-jammy:22_04-lts-gen2:latest \
  --size Standard_NC80adis_H100_v5 \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --os-disk-size-gb 256 \
  --data-disk-sizes-gb 1024 \
  --nsg nsg-llm-inference

# Never expose the inference port publicly — internal access only
az network nsg rule create \
  --resource-group rg-llm-inference \
  --nsg-name nsg-llm-inference \
  --name allow-internal-inference \
  --priority 100 \
  --source-address-prefixes VirtualNetwork \
  --destination-port-ranges 8000 \
  --protocol Tcp \
  --access Allow

Step 2: Install the Stack

sudo apt update && sudo apt upgrade -y
# NVIDIA driver + container toolkit (use the Azure-tuned NVIDIA package repo)
sudo apt install -y nvidia-driver-570-open nvidia-utils-570
python3 -m venv ~/llm-env && source ~/llm-env/bin/activate
pip install -U vllm transformers accelerate
nvidia-smi   # confirm both H100 NVL GPUs visible (2x 94 GB)

Step 3: Serve

# INT4 (W4A16) checkpoint of V4-Flash (~142 GB fits in 188 GB).
# Note: the official deepseek-ai checkpoint ships FP8 attention + FP4 experts;
# FP4 experts need Blackwell tensor cores, so on Hopper (H100) you need a
# W4A16/INT4 conversion such as this community checkpoint.
vllm serve baicai1145/DeepSeek-V4-Flash-0731-W4A16 \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --dtype bfloat16 \
  --kv-cache-dtype fp8 \
  --trust-remote-code \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.95
# The checkpoint's tested default is max-model-len 4096; raise it only as
# your KV-cache headroom allows (FP8 KV cache helps).

Step 4: Verify

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "baicai1145/DeepSeek-V4-Flash-0731-W4A16",
    "messages": [
      {"role": "system", "content": "You are a helpful enterprise assistant."},
      {"role": "user", "content": "Summarize the key compliance requirements for personal data processing in Malaysia under PDPA 2010."}
    ],
    "max_tokens": 1024,
    "temperature": 0.7
  }'

Step 5: Production Hardening

For production, add:

• Internal Azure Load Balancer or Application Gateway (private frontend) in front of the endpoint — SSL termination and health probes included. A VM is not a PaaS private-link resource, so don't reach for Private Endpoint here; an internal load balancer plus VNet integration is the correct pattern.
• Azure Monitor + Prometheus/Grafana for GPU utilization, KV-cache pressure, TTFT, and throughput.
• Private endpoints for storage and Key Vault so model weights and credentials never touch the public internet.
• RBAC and Key Vault for any API credentials your serving layer needs.
• A capacity fallback plan: GPU stock fluctuates; know your alternate region before you need it.

Decision Framework: Quick Reference

My Recommendation for Southeast Asian Enterprise Teams

After working through these numbers across several client engagements, here's my honest take:

Start with DeepSeek-V4-Flash. It's the pragmatic entry point — INT4 quantized, it fits on the NC80adis_H100_v5 that's actually priced and available in Singapore, and it covers the majority of enterprise use cases: summarization, extraction, internal Q&A, report generation.

Choose Kimi K2.6 when the workload is code or agents. If you're building developer tooling, automated code review, or multi-step autonomous workflows, K2.6's long-horizon coding and swarm orchestration are genuinely ahead of the curve. Budget for the H200 node.

Reserve V4-Pro for compliance-mandated frontier quality. At ~$167K/month all-in for a 16x H200 deployment, it's a serious budget line — justify it with a regulation, not a roadmap.

And don't self-host unless you have to. I know that's a strange note to end a deployment guide with, but the break-even math says it plainly: below tens of billions of tokens per month, the API wins on cost by orders of magnitude. Hybrid is the right default — API for development and most production traffic, self-hosted only where sovereignty, customization, or scale demand it.

Two years ago we were debating whether open models could match GPT-3.5. Today we're deploying open models that trade blows with the frontier — and the enterprise decision is no longer about capability. It's about operations, compliance, and honest arithmetic.

Key Takeaways

1. DeepSeek-V4 (MIT) and Kimi K2.6 (modified MIT) are frontier-class open-weight models — but MoE sparsity cuts compute per token, not memory: all weights still need GPU RAM.
2. The honest GPU math: V4-Pro needs 12–16x H200 at FP8; K2.6 needs an 8x H200 node; V4-Flash at INT4 fits on 2x H100 NVL — the only option affordable on a departmental budget.
3. Azure Southeast Asia reality: the 8x H100 and 8x A100 ND-series aren't on the regional retail price list — the in-region workhorse is the ND96isr_H200_v5 at $110.24/hour (≈ $80.5K/month).
4. Self-hosting is a compliance or scale decision, not a cost decision: at verified DeepSeek API rates, break-even for the cheapest self-hosted scenario sits around 47 billion tokens/month.
5. Deploy with vLLM behind an internal load balancer, NSG-locked, with Azure Monitor for GPU and latency metrics — that's the battle-tested pattern for enterprise LLM serving in this region.

Have questions about LLM deployment on Azure in Southeast Asia? Reach out at wenfeng.my — I'm always happy to chat architecture.