蓝耘 MaaS 的「思考成本」怎么样？我写了个剖析器，把 6 个模型扒了个底朝天

蓝耘 MaaS 的「思考成本」怎么样？我写了个剖析器，把 6 个模型扒了个底朝天

你以为大模型的账单只按「输出字数」收？错。很多模型在你看不见的地方疯狂烧着reasoning token——这笔「思考成本」可能占到总消耗的95% 以上。今天我用蓝耘 MaaS 的 OpenAI 兼容接口，写了一个可复用的Token 成本剖析器maas_profiler.py，把同一道题喂给 DeepSeek、Qwen、GLM、Kimi、MiniMax 五个家族的 6 个模型，现场拆出延迟、思考税、有效信息密度和估算成本——结果有惊喜，也有翻车。

一句话结论先放这里

⚠️ 单价为测试日示例估算值（见文末 PRICE 表），以控制台实时单价为准。

为什么需要这个工具？

之前三篇文章教了怎么用 OpenAI SDK 接蓝耘 MaaS：

1. 半小时上手：client.chat.completions.create()最小闭环 ✅
2. 404→402 排障：models.list()查模型名、usage 读 Token ✅
3. 流式输出：stream=True+reasoning_content+max_tokens陷阱 ✅

但这些都只回答了「能不能用」。真正上生产前，你必须回答一个更关键的问题：

同样一句话，不同模型到底烧了多少 Token？其中多少是「看不见的钱」？

因为：

• reasoning_tokens（思考 token）不计入content，但你照样要为它付费；
• 不同模型对同一道题的「思考深度」差异巨大——有的想 50 个 token 就够了，有的想近千个 token 还答非所问；
• cached_tokens能省钱，但它真的命中了吗？（后文会给你一个反直觉的真实案例）

所以，我写了这个maas_profiler.py。

动手写一个「体检台」

核心思路

同一道题 ──→ 并行喂给 N 个模型（流式调用） │ ├── 每个 model 记录： │ TTFT（首字延迟） │ 总耗时 │ prompt / completion / reasoning / cached tokens │ 输出字数 │ 有效信息密度 = 字数 ÷ completion_token │ 思考税 = reasoning_token ÷ completion_token │ 估算成本 = (P×输入价 + C×输出价 + R×输出价) / 1M │ └── 输出 JSON + 终端排列表

完整代码（可直接复制运行）

#!/usr/bin/env python3# -*- coding: utf-8 -*-"""蓝耘 MaaS 多模型「全身体检」剖析器"""importjson,os,timefromdataclassesimportdataclass,asdictfromopenaiimportOpenAI BASE="https://maas-api.lanyun.net/v1"DEFAULT_MODELS=["deepseek-v4-flash","/maas/deepseek-ai/DeepSeek-V3.2","qwen3.6-flash","/maas/zhipuai/GLM-5.2","kimi-k2.5","minimax-m3",]DEFAULT_PROMPT="用不超过80字，解释 KV Cache 是什么，并给一个生活类比。"@dataclassclassRow:model:str;ok:bool;err:str=""ttft:float=0.0;total_sec:float=0.0prompt:int=0;completion:int=0reasoning:int=0;cached:int=0chars:int=0;density:float=0.0tax:float=0.0;cost_yuan:float=0.0head:str=""defprofile(client,model,prompt,max_tokens):t0=time.time();ttft=Nonecontent,reasoning=[],[]stream=client.chat.completions.create(model=model,messages=[{"role":"user","content":prompt}],max_tokens=max_tokens,temperature=0.3,stream=True,stream_options={"include_usage":True},)usage=Noneforchunkinstream:ifgetattr(chunk,"usage",None):usage=chunk.usageifnotchunk.choices:continued=chunk.choices[0].delta r=getattr(d,"reasoning_content",None)c=getattr(d,"content",None)if(rorc)andttftisNone:ttft=time.time()-t0ifr:reasoning.append(r)ifc:content.append(c)sec=time.time()-t0 txt="".join(content);reason="".join(reasoning)ifusageisNone:returnRow(model=model,ok=False,err="no usage")p=getattr(usage,"prompt_tokens",0)or0comp=getattr(usage,"completion_tokens",0)or0ctd=getattr(usage,"completion_tokens_details",None)rt=getattr(ctd,"reasoning_tokens",None)or0ptd=getattr(usage,"prompt_tokens_details",None)cached=getattr(ptd,"cached_tokens",None)or0returnRow(model=model,ok=True,ttft=round(ttftorsec,3),total_sec=round(sec,3),prompt=p,completion=comp,reasoning=rt,cached=cached,chars=len(txt),density=round(len(txt)/comp,2)ifcompelse0,tax=round(rt/comp,2)ifcompelse0,head=txt[:60].replace("\n"," "),)defmain():key=os.getenv("LANYUN_API_KEY")ifnotkey:raiseSystemExit("请设置 LANYUN_API_KEY")client=OpenAI(api_key=key,base_url=BASE)rows=[]forminDEFAULT_MODELS:try:r=profile(client,m,DEFAULT_PROMPT,400)exceptExceptionase:r=Row(model=m,ok=False,err=str(e)[:80])rows.append(r)status=f"[OK]{m:35s}税={r.tax:.2f}密度={r.density:.2f}¥={r.cost_yuan}"\ifr.okelsef"[ERR]{m:35s}{r.err}"print(status)# 按「思考税」排序ok=[rforrinrowsifr.ok]print("\n--- 思考税排行（越低越省）---")forrinsorted(ok,key=lambdax:x.tax):print(f"{r.model:35s}税={r.tax:.2f}密={r.density:.2f}")withopen("profiler_results.json","w")asf:json.dump({"rows":[asdict(r)forrinrows]},f,ensure_ascii=False,indent=2)if__name__=="__main__":main()

完整版含 PRICE 表和更多指标在 demo/maas_profiler.py，本文展示的是核心逻辑精简版。

运行方式

exportLANYUN_API_KEY=你的密钥 python3 maas_profiler.py

它会自动：

1. 用client.models.list()可选地列出所有可用模型（完整版支持）
2. 对每个模型发同一个 prompt（流式，同时捕获reasoning_content和content）
3. 从usage.completion_tokens_details.reasoning_tokens提取隐藏思考量
4. 打印终端表格 + 写出profiler_results.json

实战跑一遍：数据说话

我在 2026-07-31 下午实跑了一次，题目是：

「用不超过 80 字，解释 KV Cache 是什么，并给一个生活类比。」

这是一道需要「理解 + 类比 + 字数控制」的综合题，能较好地区分出哪些模型在认真思考、哪些在空转。

终端原始输出（节选）

图：python3 demo/maas_profiler.py实跑输出——6 个模型的 TTFT、Token 消耗、密度、思考税一目了然。注意 qwen3.6-flash 的R=877（近千 token 在「想」）和 GLM-5.2 的CHARS=0（白花钱）。

三个「翻车现场」

翻车一：qwen3.6-flash 的「95% 思考税」

看这行数据：

C= 927 R= 877 CHARS=69 密度=0.07 税=0.95

• completion tokens = 927（看着不少）
• reasoning tokens = 877（占 94.6%！）
• 实际输出字数 = 69（不到 80 字限制的一半）
• 有效信息密度 = 0.07（每 14 个 token 才换来 1 个中文字）

翻译成人话：qwen3.6-flash 花了近一千个 token 在「想」，最后只挤出了 69 个字。而且它还花了 5 秒多才完成。

这不是 bug，是特性——Qwen 系列默认开启强推理模式，对于简单题也会做大量内部推理。如果你用它做高频低复杂度的任务（比如客服自动回复、文案润色），这笔「思考税」会让你的账单膨胀好几倍。

翻车二：GLM-5.2 的「空转翻车」

C= 400 CHARS=0 密度=0.00 税=0.00 ¥=0.00492

GLM-5.2 烧了400 个 completion token，但输出了0 个可见字符。它既没有返回 reasoning_content（税=0），也没有返回 content（chars=0）。最离谱的是——它的估算成本还是所有模型里第二高的（¥0.00492）。

这说明 GLM-5.2 在这道题上出现了纯空转：token 计费了，但用户什么都没收到。可能是模型触发了某种内部格式化/工具调用流程但没有正常回退到文本输出。在生产环境中，这种「白花钱」的情况比 404 错误更隐蔽也更危险——因为你连报错都没有，只是账单悄悄涨了。

翻车三：minimax-m3 的「标签泄漏 + 无视字数限制」

C= 400 R= 399 CHARS=1391 密度=3.48 税=1.00 CACHE=128 head="The user asks me to explain what KV Cache is in no mo..."

三个问题叠加：

1. 思考税 100%：399/400 个 token 都是 reasoning
2. 把Think标签漏进了正文：输出的 head 以英文开头，说明原始推理标签没有被正确剥离
3. 无视 80 字限制：输出了 1391 字（要求 ≤80）

唯一亮点：它是唯一命中 prompt 缓存的模型（cached=128），说明 MiniMax 的缓存机制确实在工作。但如果缓存命中的内容还是带着泄漏标签的超长回复……那缓存只是在加速错误而已。

把数据画出来：三张图看透真相

图 1：每个模型的 completion token 里，「可见内容」vs「隐藏思考」各占多少？

这张堆叠柱状图一目了然：

• DeepSeek-V3.2 / kimi-k2.5 / GLM-5.2：蓝色柱子（可见内容）占满，红色（思考）为零——它们不烧思考税
• deepseek-v4-flash：约 40% 是思考（合理范围）
• qwen3.6-flash：几乎全是红色！927 个 token 里 877 个是思考——这是典型的「过度思考」
• minimax-m3：100% 红色——它在用思考 token 来生成内容（标签泄漏导致 content 被归入 reasoning）

图 2：哪个模型「惜字如金」？有效信息密度排行

密度 = 输出中文字数 ÷ completion token 数。越高说明每个 token 越值钱。

• minimax-m3（3.48）：密度最高——如果不算标签泄漏的话，它确实很能装信息
• DeepSeek-V3.2（1.95）/ kimi-k2.5（1.84）：高密度 + 零思考税 = 性价比双冠
• deepseek-v4-flash（0.72）：中等偏下，被思考拖累
• qwen3.6-flash（0.07）：灾难级——14 个 token 换 1 个字
• GLM-5.2（0.00）：零——白花钱

图 3：性价比散点地图——左下角又快又省

• X 轴 = 总延迟（越左越快）
• Y 轴 = 估算成本（越下越省）
• 气泡大小 = 信息密度（越大越值）
• 颜色红度 = 思考税（越红越烧）

理想区域（左下角绿色大气泡）：DeepSeek-V3.2 和 kimi-k2.5

• 快（~3s）、便宜（<¥0.001）、零思考税、高密度

危险区域（右上角红色）：qwen3.6-flash 和 minimax-m3

• 一个贵且水，一个慢且满脑子都是想法

中间地带：deepseek-v4-flash

• 各项均衡，适合通用场景

深坑排查：我以为开了缓存能省钱，结果命中率 0%

在写这篇文章的过程中，我还做了一个 Prompt Cache 实验（复用了_deep_lab.py的 LAB3），结果让我大吃一惊：

实验设计

构造一个超长 system prompt（4229 字符），然后连续发 3 次完全相同的请求，观察cached_tokens是否增长：

rules=("项目规范条目：代码必须有类型注解；禁止提交密钥；API 错误要结构化。"*120)system="你是资深后端工程师。以下是超长项目规范（用于缓存实验）：\n"+rules# system 长度 = 4229 字符forround_iin(1,2,3):resp=client.chat.completions.create(model="deepseek-v4-flash",messages=[{"role":"system","content":system},{"role":"user","content":"只回复两个字：收到"},],max_tokens=32,temperature=0,)print(f"Round{round_i}: P={resp.usage.prompt_tokens}"f"CACHED={resp.usage.prompt_tokens_details.cached_tokens}")

结果

图：4229 字 system prompt 连发 3 次，CACHED=0——缓存命中率 0%。唯一例外是 minimax-m3（见正文数据表命中 128 cached）。

为什么？

我排查了几个可能的原因：

1. 平台层未开启 Prompt Caching：蓝耘 MaaS 作为统一网关，可能在某些模型/路由上没有启用或透传上游的缓存功能。虽然usage结构里有cached_tokens字段（说明协议支持），但实际缓存策略取决于上游模型实现。
2. 模型不支持：不是所有模型都实现了 prompt caching。DeepSeek-V3.2/V4 系列在官方 API 中支持，但通过网关转发时行为可能不同。
3. 前缀匹配要求严格：部分平台的缓存要求前缀（如 system prompt）完全一致且超过一定长度阈值（如 1024 token）。我的实验满足长度条件（2305 > 1024），但网关可能在请求级别做了某些修改（如添加系统指令、改写 messages）导致前缀不匹配。
4. 冷启动效应：第一次请求建立缓存条目，后续请求才能命中。但我的实验连续发了 3 次，间隔 1.5 秒，理论上应该命中。

唯一例外：minimax-m3 在主实验中命中了 128 个 cached tokens（见上文数据表），说明 MiniMax 这条线路的缓存确实在工作。这进一步佐证了「缓存能力因模型/路由而异」的判断。

教训

不要假设缓存一定生效。在上线前，必须用类似上面的实验验证你的目标模型 + 目标路由是否真的命中缓存。否则你以为自己在享受折扣价，其实一直在付全价。

选型建议：不同场景该选谁？

基于以上实测数据，给出场景化选型建议：

避坑清单

• ❌ 不要用qwen3.6-flash做简单任务——95% 思考税会让你哭
• ❌ 不要用GLM-5.2做短文本生成——可能出现空转翻车
• ⚠️ 使用minimax-m3时务必检查输出是否包含Think标签残留
• ✅ 上线前跑一遍maas_profiler.py，用真实数据选模型，别凭感觉

附录

A. 示例单价表（仅作估算参考）

⚠️ 以下为测试日从控制台/文档获取的示例价格，以控制台实时显示为准。不同时段可能有浮动。

B. 完整脚本 & 数据

• 剖析器完整版：demo/maas_profiler.py（含 PRICE 表、JSON 输出、多轮排序）
• 画图脚本：demo/maas_chart.py（读取 JSON → 3 张 PNG）
• 本次实测原始数据：profiler_results.json
• 更早的一组 6 组实验（含并发/TTFT/多轮上下文增长）：demo/_deep_lab_out.txt

C. 环境

• Python 3.9+ / openai >= 1.40 / matplotlib >= 3.7
• Base URL：https://maas-api.lanyun.net/v1
• 注册送额度：蓝耘元生代 MaaS（推广码a1acd000c1）

本文所有数据均为2026-07-31 实时调用蓝耘 MaaS API 采集，图表由matplotlib直接从 API 返回的usage字段生成，未经人工修饰。如需复现，克隆仓库后pip install -r demo/requirements.txt && export LANYUN_API_KEY=你的key && python3 demo/maas_profiler.py即可。