A.X-K1
A.X K1 is a 519-billion-parameter sparse Mixture-of-Experts language model from SKT that activates only 33 billion parameters per token. It supports both reasoning-intensive and fast inference modes, handles five languages (English, Korean, Chinese, Japanese, Spanish) plus code, and is available under Apache 2.0 without gating. The model was trained from scratch and shows competitive performance on knowledge, math, code, and instruction-following benchmarks, though it underperforms on some long-context tasks.
Key facts
Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.
| Field | Value |
|---|---|
| Developer | skt |
| Parameters | 519B |
| Context window | Unknown |
| License | apache-2.0 — OSI-approved |
| Modality / task | text-generation |
| Gated on HuggingFace | No |
| Downloads | 33.3k |
| Likes | 286 |
| Last updated | 2026-06-29 |
| Source | skt/A.X-K1 |
What A.X-K1 is
A.X K1 is a decoder-only Transformer with 192 total experts (1 shared, 191 sparse) and 61 layers. It uses Multi-Latent Attention (MLA), RMSNorm before and after MLP blocks, a 163,840-token vocabulary optimized for multilingual and code data, and supports 131,072-token context length. Training employed multi-token prediction (MTP) as an auxiliary objective. The sparse MoE design allows scaling capacity without proportional compute increase. Model card indicates vLLM and SGLang integrations are available (via non-upstream branches); standard Hugging Face Transformers support is provided.
Run A.X-K1 locally
Load the open weights with 🤗 Transformers and generate — the same model, self-hosted.
from transformers import pipelinepipe = pipeline("text-generation", model="skt/A.X-K1")out = pipe("Explain retrieval-augmented generation in one sentence.", max_new_tokens=128)print(out[0]["generated_text"])Swap in vLLM or Ollama for production-grade serving. DEV.co can stand up the inference stack.
How you'd run it
A typical self-hosted path — open weights, an inference server, your application.
DEV.co builds each layer — from GPU infrastructure to the application.
Best use cases
Running & fine-tuning it
Estimated 208–280 GB GPU VRAM for full-precision inference (519B params ÷ sparse activation ratio ~1.9–2.5x overhead for routing, activation maps). Tested configuration used TP=32 across 4 nodes (128 GPUs, likely H100/A100 class). For a single 8xH100 setup: requires bfloat16 quantization or expert offloading. Exact VRAM per-GPU depends on batch size, context length (tested to 131k), and quantization; model card does not specify minimum or recommended specs.
Unknown. Model card provides no guidance on LoRA, QLoRA, or instruction-tuning feasibility for sparse MoE. Standard fine-tuning on MoE models introduces challenges (expert load balancing, gradient sparsity). Contact vendor ([email protected]) for guidance; quantized/lightweight variants (potentially easier to fine-tune) are vendor-gated.
When to avoid it — and what to weigh
- Strict Long-Context Retrieval Requirements — Performance on long-context benchmarks (AA-LCR: 36%, Humanity's Last Exam: 8.6%) significantly trails competitors (DeepSeek-V3.1, GLM-4.6). Not recommended if needle-in-haystack or long-document QA is mission-critical.
- Need for Guaranteed Factuality or Reasoning Transparency — Model card explicitly states outputs may be 'incorrect or misleading' and that Think-mode reasoning should not be interpreted as a 'faithful representation' of internal decision processes. Unsuitable for high-stakes applications requiring explainability.
- Single-GPU or Edge Deployment — 519B total parameters with sparse activation still requires substantial GPU memory and distributed setup. Quantized/lightweight versions are only available via direct contact to vendor ([email protected]), limiting off-the-shelf edge feasibility.
- Production Deployment Without Vendor Support — vLLM and SGLang integrations are on non-upstream branches (fort726 forks) and noted as 'initial' with evolving parameters. No guaranteed LTS or production SLA documented.
License & commercial use
Apache-2.0. Permissive OSI license allowing modification, distribution, and private use with no copyleft obligations. Model is ungated (gated: false).
Apache-2.0 is a permissive license generally compatible with commercial use. However, the model card states that lightweight and quantized variants are available 'for business applications or scalable deployment' only via direct vendor contact ([email protected]), implying potential commercial licensing terms or SLAs beyond the base open model. Full-parameter open model may be commercially usable as-is, but production deployment should confirm with vendor whether commercial support, indemnification, or separate terms apply.
DEV.co evaluation signals
Editorial assessment — not user reviews. Directional, with an explicit confidence level.
| Signal | Assessment |
|---|---|
| Maintenance | Active |
| Documentation | Adequate |
| License clarity | Clear |
| Deployment complexity | High |
| DEV.co fit | Good |
| Assessment confidence | High |
No security audit, adversarial robustness testing, or red-teaming results provided. Model trained on large-scale data (composition unknown); potential for embedded biases or unvetted content echoes. Think-mode outputs should not be assumed to reflect true reasoning; possible to misinterpret confidence in incorrect answers. No data provenance, filtering, or deduplication methodology disclosed. Users deploying at scale should conduct internal adversarial testing and implement guardrails.
Alternatives to consider
DeepSeek-V3.1 (685B-37B active)
Larger total and active parameters; stronger on long-context (AA-LCR: 53.3 vs. A.X K1: 36%) and GPQA (77.9 vs. 74%), but heavier inference cost. Model card does not disclose its license/commercial terms clearly.
GLM-4.6 (357B-32B active)
Smaller total parameter count (easier deployment); competitive on MMLU-Pro, IFEval, code; mixed performance vs. A.X K1 by benchmark. Korean support and license/availability terms not specified here.
Llama 3.1 or Llama 3 (70B–405B, dense)
Fully open-source, extensive ecosystem support (quantization, fine-tuning), broader deployment simplicity. Trade-off: dense models, higher inference cost per token; no sparse-MoE efficiency gains or Think-mode reasoning control.
Ship A.X-K1 with senior software developers
Get expert guidance on infrastructure sizing, quantization options, and production integration. Our team can help you configure tensor parallelism, validate Think/Non-Think modes for your use case, and connect you with vendor support for business-grade variants.
Talk to DEV.coRelated open-source tools
Surfaced by semantic similarity across the DEV.co open-source index.
Related on DEV.co
Explore the category and the services that help you build with it.
A.X-K1 FAQ
Can I use A.X K1 for commercial products under Apache-2.0?
What GPU setup do I need to run A.X K1 locally?
How does Think mode differ from Non-Think mode at inference time?
What languages does A.X K1 support?
Custom software development services
Need help beyond evaluating A.X-K1? DEV.co is a software development agency offering software development services and web development for teams of every size. Our software developers and web developers build custom software, web applications, APIs, and open-source llms integrations — and maintain them long-term.
Ready to Deploy A.X K1?
Get expert guidance on infrastructure sizing, quantization options, and production integration. Our team can help you configure tensor parallelism, validate Think/Non-Think modes for your use case, and connect you with vendor support for business-grade variants.