Xing4.0-29B-A4B

Xing4.0-29B-A4B is an open-weight mixture-of-experts text model from China Telecom Artificial Intelligence Technology Co., Ltd. It's the latest generation of the TeleChat line, now branded as Xing, and it's released under Apache-2.0, weights, config, and a GGUF build. That license alone puts it ahead of several nominally open models in this size class for commercial deployment.

The model occupies a specific niche: agentic work. China Telecom built it around tool calling, multi-step planning and long-horizon reasoning chains rather than general chat. The numbers back that up, 75.0 on SWE-bench Verified, 57.5 on Terminal-Bench 2.1, 76.55 on Claw-Eval, which is competitive with or ahead of models in the 26–35B range. It's also the first model of this scale trained entirely on Huawei Ascend 910C NPUs with the MindSpore/MindFormers framework, which makes it the most credible open reference point if you're evaluating non-Nvidia training or inference paths.

Key specs:

• Provider: China Telecom AI
• Total parameters: 29B
• Active parameters: 4B per token
• Architecture: MoE, 40 layers, 64 routed experts + 1 shared expert, 4 experts active per token, MLA attention
• Context length: 256K native, extensible to 512K
• Modality: Text-only
• License: Apache-2.0
• Training stack: Ascend 910C + MindSpore (cutoff not disclosed)

The model is built on what China Telecom calls an mHC + MLA + MTP stack. Two of those matter for anyone running it locally.

MLA (Multi-head Latent Attention) compresses the key-value cache, which is what makes 256K context practical at all. On a dense attention model, a quarter-million-token context would blow through any consumer card's memory before you generated a single token. MLA keeps that cost proportional and manageable, but not free, and not free of compute during prefill.

MTP (multi-token prediction) adds a speculative decoding path, so the model can propose more than one token per forward pass. That translates to higher decode throughput out of the box in runtimes that support it.

The MoE routing is 64 routed experts plus one shared expert, with 4 routed experts active per token. Expert intermediate size is 1024, hidden size 3584, dense FFN intermediate size 9216.

This is the single most important thing to understand before you download it. The 4B active parameter count sets compute per token, which is why a 29B model generates tokens at speeds closer to a 4B dense model. The 29B total parameter count sets memory, because every expert weight has to be resident somewhere accessible when the router picks it.

So: fast decode, full 29B memory footprint. That asymmetry is the entire MoE value proposition, and it's why quantization matters so much here, you can cut the memory requirement aggressively without tanking quality the way you would on a dense 29B model.

The 256K native context (512K extensible) is enough for repo-scale code analysis, long contract review, multi-document RAG, and agent transcripts that accumulate dozens of tool calls without truncation.

Text-only. No vision, no audio. Within that boundary, the model's strengths are concentrated in engineering and agent tasks.

• Coding agents: SWE-bench Verified 75.0, SWE-bench Multilingual 66.0, Terminal-Bench 2.1 57.5. This is the model's best showing, it handles shell-driven workflows, multi-file edits and terminal interaction better than either of the models it's compared against in its own card.
• Tool calling and function calling: Tau3-Bench 64.63, Claw-Eval 76.55. Format alignment exists for OpenCode, Claude Code, OpenClaw and Hermes.
• Deep research: DeepresearchBII 60.80, well ahead of the 26B comparison model's 39.30.
• Math and reasoning: AIME2026 90.0.
• Instruction following: 69.67 on IFBench, this is the weak spot. It trails both alternatives and is worth testing against your own prompts before committing.

Concrete uses that fit: automated PR review and refactoring on real repositories, a local CLI coding agent, structured extraction from long contracts and tables (China Telecom explicitly calls out contract auditing and intent classification as fine-tuning targets), and knowledge-base QA over large document sets. A enable_thinking template flag toggles reasoning mode, which lets you trade latency for accuracy per request.

The instruction-following gap means it's a poor fit for tightly constrained output formatting, persona control, or strict system-prompt adherence. If that's your workload, look elsewhere.

China Telecom's own figure for low-bit quantization is roughly 15 GB, which is what makes this model interesting for consumer hardware. Add KV cache on top: MLA keeps it smaller than you'd expect, but a full 256K context still costs several gigabytes. Using Q8 KV cache quantization roughly halves that.

• RTX 4090 / 3090 (24GB): the target configuration. Q4_K_M fits with full GPU offload and real headroom for long contexts. This is the best local AI setup for this model on a single card.
• RTX 5090 (32GB): Q4 with comfortable 256K headroom, or FP8 with a shortened context.
• 16GB cards (4080, 5070 Ti): weights barely fit and KV cache spills. Expect partial CPU offload and a large throughput penalty. Only worth it at short context.
• Apple Silicon: an M4 Max with 64GB unified memory runs Q4 comfortably, bandwidth-limited but usable. 48GB is workable; 36GB or below is not.

Q4_K_M is the right default for most people, it's the standard quality/size knee, and MoE models tolerate 4-bit quantization better than dense ones because only 4B parameters are active per token, so quantization error touches a smaller slice of the network at any moment. Go to Q5_K_M if you have 32GB and want the extra margin. Drop to Q3 only if you're memory-constrained and willing to accept degradation.

Expected tokens per second, batch size 1, Q4 on a 4090: roughly 60–100 tok/s for decode. Prompt processing at 256K is the real bottleneck and will be slow on a single consumer card. An M4 Max should land lower, in the 40–70 tok/s range. Treat these as estimates, runtime, context length and KV precision all move the number substantially.

GGUF weights are published, so llama.cpp-based runtimes including Ollama and LM Studio can load them. Ollama is the fastest path to a first token, but you may need a custom Modelfile with the correct chat template to get thinking mode and tool-call parsing right. For production serving, vLLM, SGLang and KTransformers all have first-class support, and an OpenAI-compatible endpoint is straightforward. Fine-tuning is supported through LLaMA-Factory and MindFormers.

Benchmarks below are vendor-reported from the model card. Treat them as directional.

vs. Qwen3.6-35B-A3Bthe closest architectural sibling (35B total, 3B active, similar VRAM at equal quantization). Qwen leads on math (92.70 vs 90.00), agent tool use per Tau3-Bench (67.20 vs 64.63), and marginally on SWE-bench Verified (76.00 vs 75.00). Xing wins on Terminal-Bench 2.1 (57.50 vs 51.50), Claw-Eval (76.55 vs 74.54) and DeepresearchBII (60.80 vs 59.70). Choose Xing if your agent lives in a terminal or does research synthesis; choose Qwen if you need math and structured tool schemas.

vs. Gemma4-26B-A4BGemma4 leads on instruction following (72.67 vs 69.67 IFBench) and long-context retrieval (66.00 vs 61.00 AA.LCR). Xing is decisively ahead on software engineering: SWE-bench Verified 75.00 vs 53.00, Terminal-Bench 57.50 vs 30.00, DeepresearchBII 60.80 vs 39.30. For a coding agent there is no contest. For a general assistant where you need reliable instruction adherence, Gemma4 is the safer pick.

The deciding factors beyond raw scores: Apache-2.0 licensing, the 256K context window, and native support across vLLM, SGLang and KTransformers. If you're building a local coding or terminal agent on a single 24GB card, Xing4.0-29B-A4B is one of the strongest options in its weight class right now.