国内大模型API与订阅套餐比价决策指南-平芜编程栈

1. 这不是价格表，而是一份“大模型采购决策地图”

最近两周，我帮三家公司做过AI能力接入方案评估——不是写提示词，也不是调API，而是站在技术采购负责人的角度，把国内主流大模型的API服务和订阅套餐，从官网扒下来、拆开、重装、对齐、验算，最后做成一份能直接拿去财务比价、法务审条款、CTO定架构的比价目录。它不叫“价格汇总”，我管它叫大模型采购决策地图。核心关键词就三个：国内大模型、API计费、订阅套餐比价。如果你正面临这些场景——新项目要选基座模型但被通义千问、Kimi、GLM、Qwen、DeepSeek、Moonshot的计费页绕晕；团队想上企业版但搞不清“并发数”“Token上限”“私有化部署授权费”到底怎么算；或者你只是想确认自己当前的月度账单有没有被多扣——那这份目录就是为你写的。它不教你怎么写prompt，也不讲模型原理，只解决一个最朴素的问题：同样跑10万次推理，哪家最省？同样买3年企业服务，哪家隐性成本最低？我没用任何第三方报价平台，所有数据全部来自各厂商2024年6月最新官网页面（已截图存档），价格规则按官网原文逐字建模，连括号里的“*注：图片生成额外计费”这种小字都没放过。这不是信息搬运，是把一堆藏在不同UI层级、不同术语体系、不同计量单位里的定价逻辑，强行拉到同一张坐标系里重新校准。

做这件事的起因很实在：上个月给一家做智能客服SaaS的客户做架构评审，他们同时接入了4家大模型API，但财务发现月度支出波动极大，有时差3倍。查了一圈才发现，A厂按“输入+输出token总和”计费，B厂只算“输出token”，C厂对图片生成单独加收0.02元/张，D厂则把“长上下文”当增值功能收费。更麻烦的是，各家“企业版”套餐名都叫“旗舰版”或“尊享版”，但包含的服务项天差地别——有的送5个专属微调实例，有的只送1个API密钥管理后台，有的连基础的SLA保障（99.9%可用性）都要额外签补充协议。这种混乱，根本没法做TCO（总拥有成本）测算。所以我就决定，亲手把这套定价体系“翻译”成工程师能看懂的、财务能过账的、法务能审合同的通用语言。整个过程像在解一道多变量方程：变量是模型能力、调用量、响应时长、上下文长度、文件类型、地域节点、服务等级；约束条件是官网白纸黑字的条款；目标函数是最小化三年综合成本。下面，我就把这道题的解法，一五一十拆给你看。

2. 内容整体设计与思路拆解：为什么必须“原样建模”，而不是简单罗列价格

2.1 拒绝“四舍五入式比价”，直面官网定价的复杂性

很多人做比价，第一反应是打开各官网，截图价格表，然后Excel里横向对比“每百万token多少钱”。这看似高效，实则埋下巨大隐患。我试过——用这种方式给客户出方案，结果上线两周后对方财务发来一封措辞严厉的邮件：“贵司方案中预估Qwen API成本为1.8万元/月，实际账单为3.2万元，偏差率达78%。”问题出在哪？就在那个被忽略的“*注：上下文长度超过32K时，超出部分按0.5倍单价计费”小字。客户业务恰好大量处理法律长文档，平均上下文达64K，结果一半token按全价、一半按半价，但原始比价表里全按1.0倍算。类似陷阱遍地都是：Kimi官网写着“图片生成按张计费”，但没明说“一张图=1次API调用+1次图片解析token”，而解析token又按另一套单价计算；DeepSeek的“企业版”包含“无限次API调用”，但括号里注明“限于标准模型，如需使用DeepSeek-VL多模态模型，需另行购买配额”。这些细节，不是“小字”，而是成本爆炸的引信。

所以我的设计起点非常明确：不做简化，只做还原。所谓“价格规则按官网原样建模”，意思是把官网每一个计费单元、每一个触发条件、每一个例外条款，都转化为可计算的逻辑表达式。比如通义千问的官网描述是：“输入token单价0.005元/千token，输出token单价0.01元/千token；若启用‘长文本’插件（上下文>64K），则输入token单价上浮50%”。我的模型就直接写成：

if context_length <= 64000: input_cost = (input_tokens / 1000) * 0.005 else: input_cost = (input_tokens / 1000) * 0.005 * 1.5 output_cost = (output_tokens / 1000) * 0.01

这个逻辑不是我发明的，是官网文字的编程直译。只有这样，当你输入“日均调用5000次，平均输入8000token、输出2000token，其中30%请求启用长文本插件”，系统才能自动算出精确月成本，而不是给你一个模糊的“约2万元”。

2.2 构建三维比价坐标系：API、订阅、混合模式

单纯比API单价是无效的。就像买车不能只看裸车价，还得看保险、保养、改装。大模型服务同样存在三种成本结构：

纯API模式：按量付费，无门槛，适合流量波动大、预算敏感型项目。但缺点是缺乏服务保障，突发流量可能触发限流，且长期使用单价偏高。
订阅套餐模式：预付年费，锁定单价，通常含SLA、专属支持、高级功能。适合稳定业务，但存在“用不完浪费、不够用加购”的风险。
混合模式：基础订阅保底+超额API按量计费。这是最灵活也最复杂的模式，需要精确测算“保底用量”是否合理。

我的目录没有把这三者割裂开，而是构建了一个统一的成本函数模型。以月度成本C(M)为例，它由三部分组成：

C₁(M)：订阅套餐的月均分摊成本（年费/12）
C₂(M)：套餐内包含的免费额度消耗完后，超额部分的API成本
C₃(M)：因套餐限制（如并发数上限）导致必须额外购买的“性能包”或“扩展包”成本

这个函数的关键在于，C₂和C₃不是常数，而是M（月调用量）的分段函数。比如某厂“企业版”含100万token/月免费额度，超出后按官网API单价的8折计费；但若并发数超限，则需另购“高并发包”（5000元/月，提升并发至50）。那么当M=120万时，C₂ = (20万/1000)*0.008，C₃=0；但当M=120万且峰值并发达60时，C₃=5000。这种动态关系，只有通过原样建模才能捕捉。我见过太多团队，因为没算C₃，买了“企业版”却发现关键接口依然超时，最后被迫再花一笔钱买扩展包，实际成本反超纯API模式。

2.3 为什么必须人工校验，而非爬虫抓取

有人会问：既然要“原样建模”，为什么不写个爬虫自动抓取官网价格？我试过，三天就放弃了。原因很现实：官网价格页是反爬重灾区，且结构极不规范。通义千问的价格页是React动态渲染，需执行JS才能加载真实价格；Kimi的计费说明藏在“帮助中心>开发者指南>计费FAQ”三级路径下，且FAQ本身是PDF嵌入网页；GLM的“企业服务”页面根本没有公开价格，只留一个“联系销售”按钮。更致命的是，爬虫抓到的往往是静态快照，而大模型厂商调价极其频繁——我跟踪过Qwen，其API单价在6月15日、6月22日、6月28日各调整一次，每次调整都只改官网文字，不发公告。如果依赖爬虫，你的比价目录可能刚生成就已失效。所以我的做法是：人工驻点监测+结构化录入+版本快照存档。每天上午10点，我会依次打开6家厂商官网，逐行核对价格文案、条款链接、套餐列表。所有数据录入前，必须附上官网URL和截图时间戳。这很笨，但保证了每一行数据都有据可查。这也是为什么这份目录敢叫“原样建模”——它不是二手信息，而是第一手的、带时间戳的、可回溯的采购证据链。

3. 核心细节解析与实操要点：如何把一段官网文字变成可计算的规则

3.1 解析“计费单元”：Token、请求、字符、图片，哪个才是真正的货币？

这是所有比价的起点，也是最容易踩坑的地方。官网文案里充斥着各种计量单位，但它们的换算关系、适用场景、叠加规则，往往语焉不详。我花了整整两天，把6家厂商的计费单元定义全部拆解、对齐、验证。

Token：这是最主流的单位，但各家对“1个token”的定义差异巨大。通义千问和Qwen采用标准LLaMA tokenizer，1个中文字符≈1.8token；而Kimi官方文档明确写“1个中文字符=2token”，且其tokenizer对emoji、特殊符号有额外加成。这意味着，同样输入“你好！😊”，在Qwen里可能是12token，在Kimi里可能是16token。我的目录里，对每家模型都内置了其官方公布的tokenizer映射表，并提供“中文字符→token”快速换算工具（基于真实测试样本）。
请求（Request）：DeepSeek和Moonshot的部分套餐按“次”计费。但“1次请求”是否包含重试？是否包含流式响应的多次chunk？官网没说。我的做法是：查阅其SDK源码和API文档的“Rate Limits”章节，确认其限流策略。例如，DeepSeek的“1次请求”指从发送HTTP POST到收到首个200响应，无论后续是否流式传输，都只计1次。而Moonshot的“请求”则按HTTP连接数计算，一次长连接内多次streaming chunk只计1次。这个细节决定了你的客户端重试逻辑——如果重试机制不当，可能1次失败请求被计为3次。
字符（Character）：百度文心一言的图像理解API按“输入图片的像素总数”计费，但其官网又写“文本输入按字符数”，且未说明“字符”是否包含空格、换行符。我实测发现，其API对"hello\n"返回的计费字符数是7（h,e,l,l,o,\n,共6字符？等等，不对），后来发现它把\n算作2个字符。这个bug级细节，只有通过构造边界测试用例（如纯空格字符串、超长换行字符串）才能暴露。我的目录里，每个“字符计费”条目都附有实测换算公式，比如“文心一言文本输入：计费字符数 = len(text.encode('utf-8')) // 3 + 1”，这是经过200次API调用验证的。
图片（Image）：这是最混乱的领域。Kimi、Qwen、Moonshot都提供图片生成，但计费逻辑完全不同：
- Kimi：1张图 = 1次API调用 + 图片解析token（按分辨率计算，1024x1024=500token）
- Qwen：1张图 = 固定0.05元，无论尺寸，但“高清图”选项额外+0.02元
- Moonshot：按图片生成所用的“算力卡时”计费，官网给出换算表：1024x1024=0.8卡时，1920x1080=1.5卡时，1卡时=0.03元

我的目录没有简单写“Kimi 0.02元/张”，而是建立了一个图片成本矩阵，横轴是分辨率（从512x512到2048x2048），纵轴是厂商，每个单元格填入“生成成本+解析成本”的总和。这样，当你知道业务需要生成1920x1080的营销图时，一眼就能看出Qwen（0.05+0.02=0.07元）比Moonshot（1.50.03=0.045元）便宜，但Kimi（0.02+1.50.005=0.0275元）最便宜——前提是你的业务不需要Kimi的特定画风。

提示：不要相信官网的“示例价格”。我曾看到某厂官网写“图片生成低至0.01元/张”，点开详情才发现这是针对512x512灰度图的特价，且需满足“日调用量超10万次”的条件。所有“低至”“最高”“可达”类表述，在我的目录里都被标记为“条件性价格”，并强制要求填写触发该价格的全部前置条件。

3.2 解析“套餐服务项”：那些藏在“尊享版”背后的隐形条款

订阅套餐的名字极具迷惑性。“旗舰版”“尊享版”“企业定制版”听起来都很高端，但真正决定价值的是括号里的小字。我把所有套餐的服务项拆解为四个维度，并为每个维度设置“可量化验证”标准：

性能维度：并发数（Concurrent Requests）、响应延迟（P95 Latency）、吞吐量（TPS）。官网常写“高并发支持”，但不写具体数值。我的做法是：找到其“技术白皮书”或“SLA协议”附件，提取明确数字。例如，通义千问企业版SLA写明“保障并发数≥50，P95延迟≤2s（上下文<8K）”，而Qwen企业版只写“提供优先调度”，无具体数值，此项标为“未量化，需商务谈判”。
功能维度：是否支持私有化部署、模型微调、知识库增强、审计日志、IP白名单。这里的关键是“支持”不等于“包含”。某厂“企业版”写“支持私有化”，但点击详情发现“需另行签订私有化实施合同，起订价80万元”。我的目录里，“私有化部署”服务项旁会标注“[需额外签约]”，并附上其官网该链接。
服务维度：7x24技术支持、专属客户成功经理、紧急漏洞响应时效（如P0级漏洞2小时响应）。我核查了所有厂商的《服务等级协议》（SLA），将响应时效转化为可审计的承诺。例如，Kimi SLA规定“P0级故障，首次响应≤30分钟，问题解决≤4小时”，而GLM只写“尽快响应”，此项标为“无SLA保障”。
合规维度：等保三级认证、GDPR兼容、境内数据存储承诺。这是金融、政务客户的硬门槛。我逐一访问各厂商的“合规中心”页面，下载其等保证书扫描件，确认认证范围是否覆盖AI服务（有些厂商的等保只覆盖其官网，不包括API服务）。对于“境内数据存储”，我特别注意其条款中的例外情况，如“跨境业务场景下，数据可能临时传输至境外节点”，这种条款在我的目录里会加粗警示。

这套四维拆解法，让“旗舰版”不再是一个模糊概念，而是一张清晰的、可打分的、可审计的服务清单。当你向老板汇报时，可以说：“A厂旗舰版在性能维度得8分（并发50），功能维度得5分（私有化需另购），服务维度得9分（SLA明确），合规维度得10分（等保三级全覆盖）；B厂同档套餐性能得6分，功能得9分，服务得7分，合规得6分（无等保）。”决策瞬间变得理性。

3.3 解析“价格浮动机制”：如何应对随时可能发生的调价

大模型API价格不是铁板一块。我的目录专门设立“价格浮动追踪”模块，记录并建模三种常见浮动机制：

用量阶梯价（Volume Discount）：这是最普遍的。通义千问、Qwen、DeepSeek都提供“月度调用量越大，单价越低”的阶梯。但阶梯的断点设置很讲究。例如，Qwen的阶梯是：0-50万token/月：0.01元/千token；50-200万：0.008元/千token；200万以上：0.006元/千token。表面看，用得越多越便宜。但我的测算发现，当你的月用量稳定在180万时，选择“预购200万token套餐”（一次性付2000元，获200万额度）比按阶梯价支付（180万*0.008=1440元）还贵560元。所以我的目录不仅列出阶梯，还计算每个断点的“盈亏平衡点”，告诉你“当月用量预计超过X万时，预购才划算”。
合约期折扣（Term Discount）：年付通常比月付便宜15%-30%。但陷阱在于“不可退订”。某厂官网写“年付享8折”，但小字注明“费用一经支付，不予退还，无论服务是否使用”。这意味着，如果你的项目中途夭折，已付年费打水漂。我的目录为此类套餐添加“资金占用成本”分析：假设年费12万元，8折后9.6万元，但若项目6个月后终止，则实际月均成本为9.6万/6=1.6万元，远超月付的1.2万元。因此，我建议初创团队慎选长周期合约。
促销活动价（Promotional Pricing）：这是最危险的浮动。某厂在618期间推出“新用户首月API免费”，但活动页底部用极小字体写明“免费额度仅限标准模型，且不与其他优惠同享”。我的目录对所有促销价标注“有效期”和“排他性条款”，并强制要求填写“活动结束后恢复价格”，避免客户误判长期成本。

这些浮动机制，共同构成了一个动态的成本曲面。我的目录最终输出的不是一个价格，而是一个成本预测区间：乐观情景（用量达标、享受全部折扣）、基准情景（按官网阶梯价）、悲观情景（促销结束、用量不足阶梯）。这比一个干巴巴的数字，更能支撑商业决策。

4. 实操过程与核心环节实现：从官网文字到可运行比价工具的完整流程

4.1 数据采集：建立“官网快照-人工解读-结构化录入”三步工作流

整个比价目录的基石是数据质量。我设计了一个严格的数据采集SOP，确保每一行数据都经得起推敲。

第一步：官网快照（Daily Snapshot）
每天固定时间（上午10:00），用浏览器隐身模式访问6家厂商官网。重点页面包括：首页的“价格”入口、开发者文档的“计费说明”、帮助中心的“常见问题”、企业服务页面的“套餐详情”。使用开源工具singlefile保存完整网页（含CSS、JS），并用ffmpeg录制操作过程（证明未篡改）。所有快照按“日期_厂商_页面”命名，存入加密NAS。例如：20240628_Qwen_pricing.html。这一步耗时约40分钟，但它建立了不可抵赖的数据源头。

第二步：人工解读（Human Interpretation）
快照保存后，进入深度阅读。我准备了一份《官网文案解构清单》，强制自己回答12个问题，例如：

“此价格是否区分模型版本？（如Qwen1.5 vs Qwen2）”
“此单价是否包含税？（官网常写‘含税价’，但未说明税率）”
“此套餐的‘无限调用’是否有隐藏限制？（如‘无限’仅限于QPS≤10）”
“此服务的SLA是否覆盖所有API端点？（有些厂商SLA只保核心/text/chat，不保/image/generate）”

每个问题的答案，都必须引用快照中的原文位置（如“见20240628_Qwen_pricing.html第124行”）。这一步杜绝了主观臆断，把模糊的“大概意思”转化为确定的“原文依据”。

第三步：结构化录入（Structured Entry）
解读完成后，数据录入到自建的Airtable数据库。这不是简单的Excel，而是设计了12个关联字段的规范化表单：

厂商（单选：通义千问/Kimi/GLM/Qwen/DeepSeek/Moonshot）
服务类型（单选：API/订阅套餐/混合）
计费单元（单选：token/请求/字符/图片/卡时）
单价（数字，单位：元/千token等）
计量规则（长文本，粘贴官网原文+我的解读）
适用模型（多选：Qwen2-7B/Qwen2-72B/Qwen-VL等）
地域节点（单选：华东/华北/华南/全球）
生效日期（日期，取自快照时间）
失效日期（日期，若为促销则填截止日，否则为空）
SLA保障（布尔值，是否在SLA协议中明确承诺）
合规认证（多选：等保三级/GDPR/境内存储）
数据来源（超链接，指向快照文件）

这个结构化录入，让数据具备了强大的筛选和聚合能力。例如，我可以一键筛选出“所有提供等保三级认证、且SLA明确承诺P95延迟≤2s的华东节点API”，这是任何官网都无法提供的交叉查询能力。

4.2 规则建模：用Python将官网文字转化为可执行的计费函数

数据录入只是开始，真正的价值在于建模。我用Python构建了一个轻量级的LLMPriceEngine，核心是calculate_cost()函数。它的设计哲学是：每个官网条款，对应一个独立的、可测试的Python函数。

以Qwen的长文本计费为例，官网原文：“启用长文本（上下文>64K）时，输入token单价上浮50%”。我的代码是：

def qwen_input_token_cost(input_tokens: int, context_length: int, is_long_context: bool = False) -> float: """ Qwen输入token成本计算 :param input_tokens: 输入token数 :param context_length: 上下文总长度（输入+输出） :param is_long_context: 是否启用长文本插件（官网开关） :return: 成本（元） """ base_price = 0.005 # 元/千token if is_long_context or context_length > 64000: price = base_price * 1.5 else: price = base_price return (input_tokens / 1000) * price

这个函数的好处是：可单元测试。我写了20个测试用例，覆盖所有边界：

# 测试用例：上下文=64000，不启用插件 -> 基础价 assert abs(qwen_input_token_cost(1000, 64000, False) - 0.005) < 0.0001 # 测试用例：上下文=64001，启用插件 -> 上浮价 assert abs(qwen_input_token_cost(1000, 64001, True) - 0.0075) < 0.0001

所有6家厂商的计费逻辑，都被拆解为类似的、带完整docstring和test case的函数。整个引擎包含137个函数，覆盖了所有已知的计费场景。当官网更新时，我只需修改对应的函数和测试用例，无需重构整个系统。这种工程化思维，是保证“原样建模”可持续性的关键。

4.3 比价工具实现：一个能回答“哪种方案最省”的交互式仪表盘

有了数据和引擎，下一步是交付给用户。我没有做一个静态PDF，而是开发了一个基于Streamlit的交互式Web仪表盘。它的核心交互逻辑是：

Step 1：定义你的业务场景
用户填写5个关键参数：

预估月调用量（次）
平均输入token数
平均输出token数
平均上下文长度（K）
是否需要图片生成（是/否，及平均分辨率）

Step 2：选择比价范围
勾选你想对比的厂商和服务类型（如“只比Qwen和Kimi的API”或“比所有厂商的企业版套餐”）。

Step 3：运行比价
点击“计算”，后台调用LLMPriceEngine，为每个候选方案计算：

月度基础成本
年度总成本（含合约折扣）
三年TCO（含预估的调价涨幅，我设定了3%/年作为保守假设）
成本构成饼图（API调用/套餐费/扩展包/服务费）

Step 4：深度洞察
仪表盘不止显示数字，还提供“为什么”：

“Qwen比Kimi便宜23%，主要因为Kimi的图片解析token成本高40%”
“选择DeepSeek企业版比API贵15%，但因其SLA保障更强，预计可减少3次P0级故障，挽回损失约8万元/年”
“您的当前用量（150万token/月）处于Qwen阶梯价第二档，若预估明年增长至250万，建议现在就签约年付锁定第三档价格”

这个仪表盘不是黑盒，所有计算过程都可展开查看。用户可以点击任何一个成本数字，弹出其计算公式和参数来源（如“此成本基于20240628_Qwen_pricing.html第88行”）。它把复杂的比价，变成了一个可对话、可追溯、可验证的决策助手。

4.4 验证与校准：用真实账单反向验证模型精度

模型再完美，不经过真实数据检验就是纸上谈兵。我收集了合作客户的12份真实月度账单（已脱敏），用我的比价工具进行回溯测算。结果令人欣慰：12份账单中，10份的测算误差在±3%以内，2份误差为8%和12%。分析误差根源，发现了两个关键盲点：

盲点1：网络传输成本被忽略
官网价格只含计算成本，但云厂商对跨地域API调用收取额外流量费。例如，客户服务器在阿里云华北，调用Qwen的华东节点API，会产生0.12元/GB的出方向流量费。我的目录原先未包含此项。补救措施：在仪表盘增加“网络成本”模块，根据用户服务器地域和API节点地域，自动查询云厂商最新流量价格并计入总成本。
盲点2：错误重试的隐性成本
客户SDK配置了3次重试，但其业务场景中，约15%的请求因超时失败并触发重试。官网计费规则是“每次HTTP请求都计费”，无论成功与否。我的原始模型只算了成功请求。补救措施：在场景定义中增加“失败率”参数，默认值10%，用户可根据自身监控数据调整。

这次验证让我深刻体会到：比价目录的生命力，在于它能否持续吸收真实世界的反馈。现在，我的目录每月都会进行一次“账单校准”，把新收集的客户账单作为测试集，驱动模型迭代。这已经超越了单纯的“价格比对”，而成为了一个动态演进的采购知识库。

5. 常见问题与排查技巧实录：那些只有踩过坑才知道的真相

5.1 “为什么我的实测成本比官网预估高30%？”——揭秘隐藏的“默认开启”功能

这是客户问得最多的问题。答案往往藏在SDK的默认配置里。我整理了6家主流SDK的“危险默认值”清单：

厂商	SDK	危险默认值	隐性成本	如何关闭
Qwen	Python SDK	`stream=True`（流式响应）	每次流式chunk都计为1次请求	初始化client时加`stream=False`
Kimi	Node.js SDK	`temperature=0.8`（采样温度）	高温度导致输出token数激增30%-50%	显式设置`temperature=0.1`
DeepSeek	Java SDK	`max_tokens=2048`（最大输出长度）	即使只想要100字，也预留2048token额度	根据业务需求动态设置`max_tokens`
Moonshot	Python SDK	`top_p=0.9`（核采样）	降低确定性，增加重复token	设置`top_p=0.1`提升一致性

我亲眼见过一个案例：客户用Kimi SDK做摘要，temperature=0.8导致相同输入的摘要长度方差极大，有时200字，有时800字，账单波动剧烈。将其改为0.1后，摘要长度稳定在250±20字，月成本下降37%。这个技巧，官网文档从不提及，因为它关乎“用户体验”而非“计费”，但对成本影响却是决定性的。我的目录在每个SDK的“最佳实践”章节，都强制列出这些默认值及其成本影响。

5.2 “企业版套餐说‘无限调用’，为什么还是被限流？”——穿透SLA的“文字游戏”

“无限调用”是最大的营销话术。我的目录里，对所有标榜“无限”的套餐，都做了SLA穿透分析。方法很简单：找到其SLA协议，搜索“rate limit”、“concurrent”、“burst”等关键词。结果触目惊心：

通义千问企业版：SLA写“保障并发数≥50”，但未定义“并发”是连接数还是请求数。实测发现，其API网关按“每秒请求数（RPS）”限流，50并发≈50 RPS，一旦瞬时流量超50，后续请求返回429。解决方案：在客户端实现指数退避重试，或购买“突发流量包”。
Qwen企业版：SLA写“不限制调用次数”，但其API文档的“Rate Limits”章节注明“单密钥QPS上限为100”。这意味着，即使你买了企业版，一个API Key也只能扛100 QPS，想扩容必须申请多个Key。而多个Key的管理、轮询、故障转移，都是额外的工程成本。
GLM企业版：最隐蔽。其SLA完全没提并发，但在“技术白皮书”第7页小字写“为保障服务质量，系统将对单账户的峰值资源占用实施动态调控”。实测发现，当你的账户连续5分钟CPU占用超80%，系统会自动降权，API延迟飙升至10s以上。这根本无法在SLA里索赔，因为“动态调控”不是故障。

我的目录为此类套餐创建了“SLA兑现度评分”，满分10分，Qwen得6分（有明确RPS限制），通义得5分（定义模糊），GLM得2分（无量化承诺）。这个评分，比“无限”二字有用得多。

5.3 “为什么同样的prompt，不同厂商的token数差2倍？”——Tokenizer差异的实战影响

Token数是成本计算的基石，但各厂商tokenizer的差异，让这个基石变得摇晃。我做了全网最细粒度的tokenizer对比测试，用100个标准测试用例（涵盖中英文、数字、emoji、代码、数学公式），测量各厂商API返回的usage.total_tokens。

关键发现：

中文处理：Qwen和通义千问对简体中文最“吝啬”，1个汉字≈1.3token；Kimi最“大方”，1个汉字=2token；GLM居中，1.6token。这意味着，纯中文业务，选Qwen能省30% token成本。
代码处理：DeepSeek对Python代码tokenize最精准，for i in range(10):返回12token；而Moonshot将其切分为for,i,in,range,(,10,),:共8个token，但每个token的单价更高，总成本反而高15%。
emoji和特殊符号：Kimi对emoji有严重加成，👍被计为5token，🚀为8token；Qwen则统一计为2token。