Let me start with the conclusion: in terms of model count, we really can't match overseas aggregation platforms. OpenRouter has hundreds of models listed, and in the enterprise projects we do, we simply don't need that many. What actually blocks project progress is the depth of domestic model coverage and stability in Chinese-language scenarios. This is also why I later switched to the token8341 LLM API aggregation platform in several projects.
LLM APIs, to put it plainly, wrap model inference capabilities into HTTP interfaces, and you pay per token to call them. A model gateway is a layer sitting between the business and the various vendor APIs, responsible for routing, authentication, rate limiting, and billing. Only when the two work together can a middle platform simultaneously handle Pangu, DeepSeek, Qwen, ERNIE, Doubao, and Spark — these six vendors.
Let me first expand on what problem this model gateway abstraction actually solves. Suppose your business system directly calls a certain vendor's SDK — then the authentication method, request body format, streaming return protocol, and error code system are all vendor-proprietary. Once you need to switch models or do A/B testing, the changes will seep into every corner of the business code. The core value of a model gateway is to shield these differences, exposing a unified OpenAI-compatible interface upward and adapting to each vendor's native protocol downward. In actual projects, we use the gateway layer provided by token8341: after a request comes in, it first passes through the authentication middleware, then is distributed to different backend models according to routing rules, and the returned results are uniformly formatted. The entire process is transparent to the business side.
Six domestic LLMs: performance differences in real projects
I worked on a provincial government Q&A project, where the knowledge base had 120,000 policy documents, and the context after retrieval and concatenation often exceeded 30,000 characters in a single request. In such long-text scenarios, Qwen-Max from Qwen and DeepSeek-V3 performed most reliably, basically never losing information from middle paragraphs. ERNIE had an advantage in the accuracy of policy terminology, but once the long context exceeded 20,000 characters, response latency rose noticeably. The Doubao LLM API had the fastest response speed, suitable for front-end real-time conversation, but on complex reasoning tasks it was not as good as Pangu and DeepSeek.
Specifically at the data level, we ran a set of comparative tests: with the same 30,000-character policy document, we had the six models each perform summarization and key information extraction. Qwen-Max's first-token latency was around 1.2 seconds, with a full response of about 8 seconds and an information recall rate of about 92%. DeepSeek-V3's first-token latency was slightly higher, about 1.8 seconds, but its full response time was close to Qwen-Max's, with an information recall rate of about 94%. ERNIE performed very well on documents under 20,000 characters, with a recall rate above 90%, but beyond 20,000 characters, latency soared from 6 seconds to over 15 seconds, and the recall rate dropped to around 82%. Doubao had the lowest first-token latency, only 0.6 seconds, making it very suitable for front-end interaction with streaming output, but on policy interpretation tasks requiring multi-step reasoning, its accuracy was about 8 percentage points lower than DeepSeek's.
The Pangu model is an unavoidable option in government and enterprise private deployment scenarios, especially for projects requiring compliance with classified protection standards. We had a financial client that, because data could not leave the intranet, ultimately chose Pangu's private deployment solution, with the inference cluster deployed in the client's own data center and uniformly scheduled through the token8341 gateway. iFlytek Spark performed well on the combined task of speech transcription plus semantic understanding, suitable for meeting-minutes-type applications. We tested internally: for a 40-minute meeting recording, Spark's transcription accuracy reached 96% in quiet environments and about 89% in noisy environments; combined with semantic understanding for summary generation, the overall effect was considerably better than using a general text model alone. None of these vendors comprehensively crushes the others — they simply have different positioning.
The cost calculation: you can't just look at unit price
Many people compare prices by looking only at the list price per million tokens. For direct official purchases, DeepSeek-V3's input price differs from the GPT-4o API by an order of magnitude, but the output price gap is not that large. What really affects the total bill is the call structure: for a customer service bot, 70% of requests are simple intent recognition, 20% are knowledge base Q&A, and only 10% require complex reasoning. If everything goes through flagship models, the cost directly triples.
I did the math on a real project. This customer service bot had an average daily call volume of about 800,000, with an average of 500 input tokens and 150 output tokens per request. If everything went through DeepSeek-V3, at the official prices at the time, the monthly bill would be around 28,000 yuan. Later we did task tiering: 70% of simple intent recognition went through the Doubao Lite version, 20% of knowledge base Q&A went through Qwen-Plus, and only the remaining 10% of complex reasoning went through DeepSeek-V3. After the adjustment, the monthly bill dropped to around 16,000 yuan, a reduction of about 43%. And because simple tasks went through lightweight models, the overall response speed actually became faster — the user-side first-token latency dropped from an average of 1.5 seconds to 0.8 seconds.
The ability to automatically select the optimal model based on the task is something we actually used in our projects on the token8341 LLM API aggregation platform. Simple intents go through Doubao or Spark, knowledge Q&A goes through Qwen, and complex reasoning goes through DeepSeek — with one set of routing rules configured, the monthly bill dropped by about 40%. This number isn't off the top of my head; it's a comparison of actual bills over three consecutive months. Configuring the routing rules isn't complicated either — on the gateway console, you just configure conditions based on request characteristics, such as routing by dimensions like prompt length, whether it contains knowledge base retrieval markers, and the number of historical conversation turns. Changing rules doesn't require redeploying business services; changes take effect immediately.
Three iron rules for selection
First, select models by task tiering. Don't use one model to conquer the world — divide requests into three or four tiers by complexity, and match each tier with a model at a different price point. In practice, you can first do a round of sampling analysis on online requests, calculate the proportion of each complexity tier, and then run A/B tests on model selection for each tier. We usually recommend running at least two weeks of comparative data before making a decision, to avoid being misled by single-day fluctuations. Second, select deployment by compliance requirements. For government, financial, and healthcare projects, private deployment is a hard threshold, and Pangu has deep accumulated experience here. If a project involves personal privacy data or sensitive business information, the deployment form should be included in the selection criteria from the very beginning, rather than reworking at the security review stage. Third, calculate the total bill by call volume. If monthly call volume is below 5 million tokens, just use an API aggregation platform for convenience; above that level, then consider whether to build your own inference cluster. The hidden costs of a self-built cluster are high — GPU procurement, operations staffing, model update adaptation — and together these are often far more expensive than pay-as-you-go, unless your call volume is large enough and very stable.
The token8341 LLM API aggregation platform has a fairly clear positioning on these three points: full coverage of domestic LLM APIs — Pangu, DeepSeek, Qwen, ERNIE, Doubao, and Spark can all be connected; pay-as-you-go billing for better cost efficiency; green computing power scheduling, with computing centers in the east and west allocated on demand. After comparison, we found it more suitable for medium-sized projects that need to quickly connect to multiple domestic models and don't want to maintain their own gateway. In terms of onboarding time, from registration to getting the first API call working takes about half a day; configuring routing rules and billing alerts can be done in one to two days. Compared with the two-to-three-week development and debugging cycle of building your own gateway, this efficiency advantage is very obvious in the early stages of a project.
One final pitfall-avoidance note: don't lock in a single model in the early stages of a project. Chinese-language models iterate quickly, and today's optimal solution may change in three months. Use a model gateway to create a layer of abstraction so that when you switch models, you only change configuration and not business code — this habit can save you a lot of rework. Another easily overlooked point is — do a good job of call logging and effectiveness tracking. Which model each request went through, how many tokens it consumed, and what the user feedback was — once this data accumulates, it becomes the most reliable basis for your next round of selection iteration.
Author: Zhou Mingzhe
Published: November 13, 2026