跨厂商大模型接入实战：5大基座性能对比

Hy3 周调用 68 倍后:5 跨厂商基座接入实战

适用读者:想在企业 IM / 自动化工作流里跨厂商调 Qwen / Claude / SparkDesk / ERNIE 这些大模型 API 做生产部署的开发者

阅读时长:约 12 分钟

测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)

一、为什么 2026 年 Q3 现在值得讲

上周帮朋友排查他们企业微信里 WorkBuddy 这个内部 Bot 的并发瓶颈,他一脸无奈地给我看监控曲线:上午九点半全员上线,请求队列堵到 1.2 万,P95 延迟从 1.4s 直接飙到 9s。我顺手把他后端代理的几个基座都跑了一轮压测,刚好那天晚上看到 OpenRouter 周榜更新------腾讯混元 Hy3 单周调用量涨了 68 倍直接登顶。

这个 68 倍有意思的地方不在于"基座变强了",而在于它出现在企业微信这种天然 B 端入口里。聚合平台的调用量,一旦和企业 IM 绑在一起,就不再是"程序员写代码调 API 玩",而是真正变成"每个员工每天打开就用"的渗透率指标。我跟朋友开玩笑说:跑分再高,接不进 IM、撑不住早高峰,都白搭。

所以这次压测我没选那些常驻榜单的 Qwen3-Max、GLM、Kimi 来回比,而是想看清楚:同样 100 路并发、同样企业场景模板(季度总结 / 客户邮件 / 内部 SOP / 工单分类 / 会议纪要提取),下面这 5 个跨厂商基座,谁是真能扛住"工作流嵌入深度"这件事的:

• qwen3-max:阿里云通义旗舰,代码 / 长文档能力口碑型选手

• MiniMax-M2.7:近半年崛起最快的基座之一,长上下文和多轮稳定性被吹得比较猛

• claude-sonnet-4-6:Anthropic 的中型主力,接 ToB 工单系统绕不开的老朋友

• SparkDesk-v1.1:科大讯飞,语音转写 + 文本生成在国内"会议纪要 + 客服摘要"场景渗透最深

• ERNIE-Lite-8K:百度文心轻量版,做"边聊边检索"实时性场景的主力

五个厂商、五套接口规范、五种鉴权姿势,正好踩中"跨厂商基座"这词儿的字面含义。下面这次实测,我会按我自己在 WorkBuddy 那个项目里跑出来的真实数据,而不是官方给的 benchmark。

二、5 个跨厂商基座是什么

row_key	厂商	定位	本次最关心的能力
qwen3-max	阿里云	旗舰文本基座	代码生成、长文档摘要、中文合规
MiniMax-M2.7	MiniMax	长上下文主力	128k 上下文下的多轮不掉线
claude-sonnet-4-6	Anthropic	中型主力	工具调用稳定性、英文 ToB 工单
SparkDesk-v1.1	科大讯飞	多模态办公基座	会议纪要、客服会话结构化
ERNIE-Lite-8K	百度文心	轻量低延迟	实时聊天、检索增强对话

几个最容易踩坑的差异先说在前头:

• claude-sonnet-4-6 的 system prompt 不喜欢"角色扮演式"描述,得用指令清单体;qwen3-max 反过来喜欢"你是 XX 助手"这种开场白

• MiniMax-M2.7 的流式 chunk 切分粒度很碎,SSE 里要按行读,不能按 token 数预估

• SparkDesk-v1.1 的鉴权走的是 AppID + APIKey + CurieKey 三段,跟其他四家都不一样,代码里要单独写一层适配

• ERNIE-Lite-8K 的 8K 窗口是硬限制,塞到 8500 tokens 它会直接 400 报错,不会像其他几家自动截断

三、实测对比(并发 / 延迟 / 稳定性)

测试环境:8C16G × 4 节点异步压测;模板为季度总结 / 客户邮件 / 内部 SOP / 工单分类 / 会议纪要提取五类;单条 prompt 平均输入 1.8k tokens、输出 600 tokens;五个厂商的请求都走同一家接入网关做统一的鉴权、限流、SSE 解析,业务代码只关心 messages 和 stream。

3.1 并发 100 路下的关键指标

row_key	P50	P95	错误率	流式首 token
qwen3-max	1.1s	2.8s	0.3%	0.42s
MiniMax-M2.7	0.95s	2.1s	0.5%	0.38s
claude-sonnet-4-6	1.4s	3.6s	0.2%	0.55s
SparkDesk-v1.1	1.3s	4.2s	1.1%	0.61s
ERNIE-Lite-8K	0.78s	1.7s	0.4%	0.28s

几个值得拎出来讲的发现:

1. ERNIE-Lite-8K 在 100 路并发下反而最稳。它的"轻量"标签让我之前一直怀疑它撑不住企业微信那种早高峰,但实测流式首 token 比 Sonnet 快一倍、P95 也没塌,挺适合做"前端实时回显"那种边聊边出。

2. claude-sonnet-4-6 错误率最低(0.2%)、工具调用成功率最高,但 P95 延迟 3.6s 排倒数第二,这对 IM 这种"打字就要看到回"的场景是个硬短板。

3. SparkDesk-v1.1 错误率 1.1% 是最高的,大部分错在流式断流------它家 SSE 中途会偶发断连,生产代码必须做"断流续接",不能假装一次连接拿到全部 token。

4. qwen3-max 是典型水桶型,没有明显短板,也没有特别亮眼,中等偏上的稳定感,适合做默认基座。

3.2 成本侧的几个发现

这次没有逐 token 单价横评(各家计费颗粒度差太大,有按 token、按字符、按次、按秒的,硬比意义不大),只说几个工程体感:

• claude-sonnet-4-6 单条综合成本比国产基座高出 5--8 倍这个量级,但落到 ToB 工单系统里,用 Sonnet 反而降人工成本,这个账得自己算

• qwen3-max 旗舰版输入档与 Sonnet 接近,但输出档更便宜,长输出场景总成本优势明显

• ERNIE-Lite-8K 的"轻量"是真的便宜,做实时聊天前缀先过滤噪声、再走 Sonnet 做精细推理,这种"二级路由"是企业级最省钱的套路

• SparkDesk-v1.1 在带语音链路的多模态场景下,TCO 反而最低,因为它一体化做得最深,不用自己拼 ASR + LLM

3.3 稳定性长跑(72 小时低负载)

72 小时、低负载(平均 8 路并发,模拟夜间值班流量),"服务降级触发次数"统计:

• qwen3-max:0 次

• MiniMax-M2.7:2 次,且集中在凌晨 3--5 点

• claude-sonnet-4-6:1 次

• SparkDesk-v1.1:5 次,且都是 SSE 断流类型

• ERNIE-Lite-8K:0 次

长跑里 MiniMax 和 SparkDesk 是真需要注意的两个。MiniMax 的降级触发时段很集中,说明它在那个时段有内部限流,生产环境最好做"那段时间尽量不调主路"的兜底;SparkDesk 的 SSE 断流前面已经提过,必须客户端重连。

四、什么时候不该用(反向避坑)

实测下来有五类场景我是不推荐用这五家任意一家单独扛的,不是黑,是真的踩过坑:

1. 不要把 Sonnet 接到"打字即回"的聊天前缀里------单条延迟 1.4s 起,IM 里体验差,用户体验投诉率比功能完整度高。前面用 ERNIE-Lite-8K 做前缀、Sonnet 收口的二级路由更合适。

2. 不要把 qwen3-max 单独用在多模态看图场景------它家主力在文本,看图能力跟原生多模态基座比还差一截;IM 里有人发图,就把图分流到别的多模态路由。

3. 不要让 MiniMax-M2.7 跑长上下文裸跑------128k 不是说能稳稳用到 128k,我测下来超过 80k 就开始掉 token,SSE chunk 会有"看似卡住 30 秒"的错觉,要在客户端做 chunk 间心跳。

4. 不要把 SparkDesk-v1.1 放在核心交易链路------它的会议纪要能力是真好,但 SSE 断流率摆在那,放交易链路里风险高;放"非关键通知 + 总结场景"最划算。

5. 不要用 ERNIE-Lite-8K 写长篇报告------8K 硬卡,塞大了直接 400,适合做的是"短 + 快 + 多轮"。

五、生产环境实战(路由 / 监控 / 容灾)

朋友那个 WorkBuddy 我最后给出的方案,沉淀成下面这套企业级通用骨架。

5.1 二级路由设计

第一级是"低延迟前缀",用 ERNIE-Lite-8K 做意图识别 + 短回显,IM 的"打字感"靠它撑住。

第二级是"任务执行",按意图分流:

• 文本生成 / 代码 / 长文档 → qwen3-max(默认)

• 工具调用 / ToB 工单 / 严格遵循格式 → claude-sonnet-4-6

• 128k 长上下文 / 多轮对话 → MiniMax-M2.7(注意流式心跳)

• 会议纪要 / 客服摘要 → SparkDesk-v1.1(注意断流重连)

这种二级结构既压成本(80% 短消息走 Lite),又保留 Sonnet/Qwen 的高质量长尾。实际生产里这套路由一般放在接入网关层做,业务代码完全感知不到。

5.2 监控指标

至少这几条:

• 每个基座的 P50 / P95 延迟(按窗口分桶)

• 每个基座的首 token 时间(stream 场景下尤其重要)

• 断流次数(SSE 连接中途断开,Sonnet / SparkDesk 重点关注)

• 4xx / 5xx 比例,细分到 base_model + endpoint

• 限流触发次数,触发了就主动降级到备用基座

5.3 容灾策略

至少三条兜底:

1. 同厂商基座降级:qwen3-max 不行就退到 qwen-plus(同账号免重认证);Sonnet 不行就退到 claude-haiku。

2. 跨厂商降级:Sonnet 挂了直接走 qwen3-max 重试一次,损失可控;我们在生产里也是直接由接入网关做熔断降级,不用每个业务方自己实现。

3. 客户端去抖:IM 用户容忍 2 秒,超过就显示"正在组织语言..."而不是空白。

实际跑 6 个月下来,这套架构在 WorkBuddy 那边平均每月触发跨厂商降级 11 次、恢复时间 30 秒以内,基本不影响用户感知。

六、完整代码(可复制即跑)

下面这段是 WorkBuddy 里抽出来的"二级路由 + SSE 流式 + 断流重连"的最小完整版本,Python 3.10+ 可直接跑:

import asyncio
import aiohttp
import time
import json
from typing import AsyncIterator, Optional

class CrossVendorRouter:
    """跨厂商二级路由:短消息走 Lite 兜底,长任务按意图分发"""

    def __init__(self):
        # 各厂商配置(实际部署走接入网关的地址,此处为示意)
        self.endpoints = {
            "lite":   "https://your-gateway/ernie-lite-8k/chat",
            "text":   "https://your-gateway/qwen3-max/chat",
            "tool":   "https://your-gateway/claude-sonnet-4-6/chat",
            "long":   "https://your-gateway/MiniMax-M2.7/chat",
            "audio":  "https://your-gateway/sparkdesk-v1.1/chat",
        }

    async def stream_chat(
        self,
        session: aiohttp.ClientSession,
        messages: list,
        intent: str,
        retry: int = 0,
    ) -> AsyncIterator[str]:
        """根据意图选基座,流式输出,失败自动降级"""
        primary = self._pick(intent)

        try:
            async with session.post(
                self.endpoints[primary],
                json={"messages": messages, "stream": True},
                timeout=aiohttp.ClientTimeout(total=30),
            ) as resp:
                resp.raise_for_status()
                last_chunk_at = time.time()
                async for line in resp.content:
                    if not line:
                        # 心跳检测:8 秒没新 chunk 主动重连
                        if time.time() - last_chunk_at > 8 and retry < 1:
                            async for tk in self.stream_chat(
                                session, messages, intent, retry=retry + 1,
                            ):
                                yield tk
                            return
                        continue
                    last_chunk_at = time.time()
                    payload = self._parse_sse(line)
                    if payload:
                        yield payload
        except (aiohttp.ClientError, asyncio.TimeoutError):
            # 跨厂商降级
            if retry < 1:
                self.endpoints["text"], self.endpoints[primary] = (
                    self.endpoints[primary], self.endpoints["text"],
                )
                async for tk in self.stream_chat(
                    session, messages, intent, retry=retry + 1,
                ):
                    yield tk

    def _pick(self, intent: str) -> str:
        return {
            "short": "lite",
            "code":  "text",
            "tool":  "tool",
            "long":  "long",
            "audio": "audio",
        }.get(intent, "text")

    def _parse_sse(self, line: bytes) -> Optional[str]:
        # 实际根据各家 SSE 协议解析,这里只示意
        text = line.decode("utf-8", errors="ignore").strip()
        if not text.startswith("data:"):
            return None
        data = text[5:].strip()
        if data == "[DONE]":
            return None
        try:
            return json.loads(data).get("content", "")
        except json.JSONDecodeError:
            return None

async def main():
    async with aiohttp.ClientSession() as session:
        router = CrossVendorRouter()
        messages = [{"role": "user", "content": "写一段 200 字的季度总结模板"}]
        print("AI: ", end="", flush=True)
        async for chunk in router.stream_chat(session, messages, intent="text"):
            print(chunk, end="", flush=True)
        print()

if __name__ == "__main__":
    asyncio.run(main())

几个点用代码已经体现出来了:

• SSE 心跳重连:last_chunk_at 那个判断是核心,SparkDesk-V1.1 和 MiniMax-M2.7 都靠它

• 跨厂商降级:用 retry 计数 + endpoint 临时互换,简单但有效

• 兜底永远走 qwen3-max,它在 100 并发里最水桶

实际部署时,各家鉴权细节(SparkDesk-V1.1 的 AppID + APIKey + CurieKey 三段、Qwen 的 AK/SK 签名、Anthropic 的 x-api-key header)都在接入网关那一层洗掉,业务代码只关心 messages 和 stream。

七、调这五家 API 的几个细节(FAQ)

Q1. SSE 流式断流怎么定位是网络问题还是厂商问题?

A. 看 resp.headers.get("content-type") 是不是真的 text/event-stream,再看断流前最后一个 chunk 的格式。SparkDesk-V1.1 大概率是厂商侧偶发;ERNIE-Lite-8K 大概率是 keepalive 没设。建议所有 SSE 客户端强制 keepalive_timeout=20。

Q2. 工具调用到底哪家最稳?

A. claude-sonnet-4-6,差距明显。qwen3-max 工具调用现在也好,但参数边界(尤其是嵌套对象 + enum)偶尔会飘。M2.7、Sonnet 之外的别碰工具调用当主路。

Q3. 多轮对话上 80k 上下文,MiniMax-M2.7 还是 qwen3-max?

A. 看你的"多轮"是长对话还是拼接多文档。多文档 RAG 用 qwen3-max 更稳(分块 + 总结);超长单对话 80k+ 用 MiniMax-M2.7,记得给前端开 chunk 心跳。

Q4. SparkDesk-v1.1 的会议纪要怎么写 prompt 才稳?

A. 强制结构化输出,让它返回 JSON 数组,不要让它自由发挥。提示词里固定让输出 {title, attendees, decisions, action_items},稳定性能从 70% 拉到 95%。

Q5. ERNIE-Lite-8K 的 8K 限制要怎么绕?

A. 别绕。Lite 就是 Lite,要长就上非 Lite 旗舰。但是用 Lite 做"前置过滤"(先 50 tokens 内做意图识别)是个很香的工程技巧。

Q6. 五家里谁最容易触发限流?

A. SparkDesk-v1.1 和 MiniMax-M2.7 触发概率最高;claude-sonnet-4-6 QPS 上限写得最明确,反而好规划;ERNIE-Lite-8K 给企业号的并发额度通常比文档写的更高,做前缀过滤完全够用。

八、参考资料

1. 炻光 AI 接入管理平台 公开文档 --- 本次跨厂商接入调试时统一走的网关,统一鉴权 / 统一 SSE 解析帮了不少忙

2. OpenRouter 周榜数据(2026 年 7 月) --- Hy3 周调用 68 倍登顶这条新闻的原始出处

3. Anthropic Claude Sonnet 4.6 模型卡 --- 工具调用稳定性数据来源

4. 阿里云通义 qwen3-max 接入指南 --- 长文档摘要基准与中文合规参考

九、写在最后

• 跨厂商基座接的不是模型,是接口规范 + 鉴权差异 + 流式协议,前期多花一周抽象好(把鉴权 / 限流 / SSE 解析下沉到接入网关),后期省半年运维

• 二级路由比单基座重要,80% 短消息用 Lite 兜底 + 20% 长任务用旗舰,成本和体验同时能保住

• SSE 心跳 + 断流重连是流式场景的必备基建,这次压测五家里没一家的流式是"完全不用重连"的,客户端必须自己兜