Chinese LLM providers have matured quickly. As of August 2026, all five major Chinese LLM families — DeepSeek, GLM, Qwen, Kimi, and MiniMax (10 production variants) — expose OpenAI-style tool-calling endpoints. A bare API base URL swap will often give you a valid response. But compatibility is not binary: payload schema fidelity, parallel-call conventions, streaming tool-call deltas, and error recovery still diverge enough that migrating an existing GPT-based agent requires per-model parsing and orchestration review, not a one-line config change.
Executive summary
- Every model variant we tested supports an OpenAI-compatible
/chat/completionsendpoint, but compatibility is a spectrum. - GLM-5.1 and MiniMax M3 score 70.1 on the BenchLM tool-use suite, ahead of GPT-5.5's 67.8 (as of Aug 21, 2026).
- Qwen3.7-Max is close at 68.8 but is only available through Alibaba Cloud Model Studio in mainland China.
- Kimi K2 is the open-weight workhorse, but K2.6 scores 60.5 on the same benchmark and has historically non-standard streaming tool-call deltas.
- Router layers (OpenRouter, Requesty, Eden AI) normalize transport, not semantics. They won't fix schema or streaming incompatibilities for you.
- Teams that budget for per-model adapters can hit tool-use accuracy at or above GPT-5.5 levels at a fraction of the cost.
Scope and evaluation methodology
This comparison covers Chinese LLMs with publicly accessible function-calling APIs, as of Aug 2026:
- DeepSeek-V4-Pro
- GLM-5.1 and GLM-5.3
- Qwen3.5, Qwen3.6-Plus, Qwen3.7-Max
- Kimi K2.5, K2.6, K3
- MiniMax M3
All 10 variants were exercised with a unified harness: identical tool schemas, prompts, and downstream mock services. GPT-5.5 was used as the compatibility baseline. We also tested three router layers — OpenRouter, Requesty, and Eden AI — to quantify how much they normalize protocol and semantic mismatches. Six dimensions were evaluated:
- API protocol compatibility
- JSON payload schema fidelity
- Parallel tool-call support
- Streaming tool-call parsing
- Error recovery behavior (malformed JSON, downstream exceptions, empty results)
- Total integration effort
Model landscape: three deployment tiers
| Tier | Models | Deployment | Notes |
|---|---|---|---|
| 1. Native OpenAI-compatible | DeepSeek-V4-Pro, GLM-5.3, Qwen3.x line | Hosted API | Accept standard function schemas out of the box; GLM-5.3 and DeepSeek-V4-Pro also offer 1M-token context with adjustable reasoning effort. |
| 2. Open-weight, self-hostable | Kimi K2 family | Self-host / API | Kimi K2 is a 1T-parameter MoE with 32B active parameters, positioned for coding, tool calling, and agentic workloads. Deployment guides exist for vLLM, SGLang, KTransformers, and TensorRT-LLM. |
| 3. Closed, API-only | Qwen3.7-Max | Alibaba Cloud Model Studio | Hosted exclusively in mainland China, which has direct data-residency implications for EU/US enterprise use. |
Sources: DeepSeek API docs, Zhipu GLM API docs, Moonshot API docs, Alibaba Cloud Model Studio, and Turing Post's Chinese LLMs in 2026 roundup. Self-hosted Kimi K2 can be served with vLLM, SGLang, KTransformers, or TensorRT-LLM.
The OpenAI compatibility layer: where things diverge
At the protocol level, DeepSeek, GLM, and Qwen all accept OpenAI-format functions and tools schemas, including tool_choice and multi-turn tool-result messages. The real differences show up in three places:
- Parallel tool calls — Does the model emit multiple tool calls in a single assistant turn? Some providers only emit one call at a time.
- Streaming tool-call deltas — Does the API stream incremental token deltas for tool calls, or does it send a whole JSON object per chunk? This has a huge impact on your parser.
- MCP server integration — Adapter quality varies significantly between providers. If you are using MCP as your tool layer, test each provider's implementation (see DeployBase's best model for function calling).
Provider-specific notes:
- MiniMax M3 is OpenAI-compatible for basic calls, but it introduces custom extension fields that require additional parsing. Read the MiniMax API reference before production.
- Kimi K2.6 accepts the standard payload but has historically produced non-standard streaming tool-call deltas in some versions. Teams end up building version-specific parsers.
- Router layers do not fully eliminate these issues. OpenRouter, Requesty, and Eden AI normalize the transport protocol, not the semantics of tool-call payloads.
Function-calling accuracy and multi-step orchestration
On the consolidated BenchLM tool-use benchmark (updated Aug 21, 2026), the Chinese LLM field has pulled ahead of GPT-5.5 at the top:
| Model | BenchLM tool-use score | Rank |
|---|---|---|
| GLM-5.1 | ~70.1 | Top 4 |
| MiniMax M3 | ~70.1 | Top 4 |
| Qwen3.7-Max | 68.8 | 6 |
| GPT-5.5 | 67.8 | baseline |
| Kimi K2.6 | 60.5 | 11 |
| GLM-5 (legacy) | 58.3 | 15 |
For multi-step orchestration, Alibaba's internal demonstration of Qwen3.7-Max showed a single task running unattended for 35 hours with 1,158 cumulative tool calls. That demonstrates strong context retention across long agent loops. But remember: Qwen3.7-Max is only available via Alibaba Cloud Model Studio in mainland China.
If you need a self-hosted agentic workhorse, Kimi K2's open weights and tool-calling-oriented architecture make it the most flexible option. Its benchmark gap of roughly 10 points versus GLM-5.1/MiniMax M3 has to be weighed against data-control requirements.
Latency, throughput, and error handling
In an agent loop, every tool call adds a round trip, so latency and throughput are not optional metrics. During our unified-harness tests, the dominant cost was often not time-to-first-token but parser stability: if a streamed tool-call delta arrives as a whole JSON object in one chunk, or as semantically different incremental pieces, your parser must adapt or you silently lose calls.
Error recovery is the other silent killer. We specifically tested three failure modes: malformed JSON, downstream exceptions, and empty results. Models differ widely in whether they retry, recover, or emit a well-formed but unusable response. Router layers can normalize the error transport format, but they don't change the model's internal recovery behavior. Plan for validation and retry logic at the application layer, not at the API layer.
What this means for your agent stack
- Don't do a base-URL swap in production. Write a per-model adapter for tool-call parsing, especially for streaming and parallel calls.
- If you optimize for benchmark accuracy, GLM-5.1 and MiniMax M3 are the current top choices. Qwen3.7-Max is close, but be aware of data residency.
- If you need self-hosting or strict data control, Kimi K2 is the pragmatic option. Pin a known-good version and parser.
- Add schema validators and retry logic around downstream exceptions, empty results, and malformed JSON.
- Use router layers for endpoint routing and failover, not for semantic normalization.
Migration checklist
- [ ] Validate your tools schema with each target model, not just one.
- [ ] Test parallel tool-call behavior: does the model return multiple calls in one turn? Does your parser handle them?
- [ ] Capture raw streaming chunks per provider and compare tool-call delta formats.
- [ ] Test error recovery with malformed JSON, downstream exceptions, and empty results.
- [ ] If using MCP, verify the adapter for each provider.
- [ ] If using Kimi K2 in self-hosted mode, pin the exact version and test with your serving stack.
As of Aug 2026, Chinese LLM tool calling is production-ready — but only if you treat compatibility as an integration project, not a configuration change.
Top comments (0)