网上给 Claude Code 接第三方 API 的教程一抓一大把,但清一色都在教你怎么填 base_url、api_key,填完能对话就算完事。可真正把它挂上去跑一阵子你就会发现:填 URL 是五分钟的体力活,选对平台才是真功夫。
我自己就踩过一次:一个挂着 Claude Code 跑的小工具,原本用官方额度,想省钱换了家便宜的第三方 API,结果月底账单不降反升。单价明明更低,总价怎么反而涨了?后来才搞明白,是漏看了一个关键的东西------缓存。
这篇就是把"换之前到底该看什么"这件事测明白后的复盘。用蓝耘元生代 MaaS 接 DeepSeek-V3.2,中间拉了另一家平台的同款模型做对照。数据都是自己 curl 跑出来的,截图都在,能复现。
结论先放这儿,后面全是论证:
延迟看尾部,成本看缓存,Agent 看工具调用。
一、先说清楚:为什么我最后落在蓝耘,而不是继续用官方
不绕弯子。我选平台时脑子里过的是这么几件事,按重要性排:
- 它到底支不支持 Claude Code 的原生协议,还是要我自己搭翻译层;
- 同样的活儿,重复上下文能不能命中缓存、省下那笔冤枉钱;
- 延迟稳不稳定,别一卡就是好几秒;
- 出了问题有没有地方查------用量、账单、调用日志。
蓝耘 MaaS 这几条我一条条测下来基本都能对上,尤其是第 1 和第 2 条,后面会拿数据说话。这里先给个平台的直观印象:模型广场里 DeepSeek、通义 Qwen、智谱 GLM、Kimi、MiniMax 这些主流的都在,一个 Key 全能调,想换模型改一行配置的事。

这个"一个 Key 调所有模型"的统一网关设计,是我后面能轻松做横向对比的前提------我不用去每家单独注册、单独拿 Key,选型这件事本身的成本就低了。
二、拿 Key:三个必须记下来的东西
先到蓝耘 MaaS 控制台(https://console.lanyun.net/#/register?promoterCode=a1acd000c1)注册登录,然后充值------不充值 Key 是激活不了的,这是我踩的第一个小坑,建的 Key 一直报 invalid company api key,后来发现是账户余额为空。充完值再建 Key 就正常了。


小提醒:Key 建好只在创建那一刻完整显示一次,记得马上复制存好。
拿到 Key 之后,有三个东西你必须在控制台确认清楚,这决定了后面怎么接:
- 调用地址(Base URL) :
https://maas-api.lanyun.net - 协议格式 :蓝耘同时提供了 OpenAI 兼容(
/v1/chat/completions)和 Anthropic 兼容(/anthropic/v1/messages)两套端点------这一点非常关键,下面单独讲。 - 模型的准确调用名 :比如 DeepSeek 是
/maas/deepseek-ai/DeepSeek-V3.2,注意它带/maas/前缀,不是干巴巴一个deepseek-chat,写错了直接 404。
控制台每个模型点进去都有 API 示例,照着抄不会错:

三、第一关:连通性冒烟,顺便看清它的 usage 长什么样
任何新 API 到手,我第一件事永远是发一个最小请求,确认"通没通",别急着写代码。
bash
export LY_KEY="你的Key" # 打码,别外泄
export LY_BASE="https://maas-api.lanyun.net/v1"
export LY_MODEL="/maas/deepseek-ai/DeepSeek-V3.2"
curl -sS "$LY_BASE/chat/completions" \
-H "Authorization: Bearer $LY_KEY" -H "Content-Type: application/json" \
-d "{\"model\":\"$LY_MODEL\",\"messages\":[{\"role\":\"user\",\"content\":\"只回复两个字:通了\"}]}" | jq .

返回里有个细节我特意多看了两眼------usage 字段:
json
"usage": {
"prompt_tokens": 9,
"completion_tokens": 1,
"total_tokens": 10,
"prompt_tokens_details": {
"cached_tokens": 0,
"audio_tokens": 0
}
}
看到那个 prompt_tokens_details.cached_tokens 了吗?这个字段的存在,意味着平台把"缓存命中了多少 token"这件事透明地告诉了你。 很多人冒烟测试只看 content 对不对,我一定会看 usage------因为这决定了我后面能不能算清成本账。这里先记住它现在是 0,第五节我会让它"活"起来。
一个 URL 拼接的坑,我替你踩了 :控制台给的是带
/v1的。如果你像我一样export LY_BASE=".../v1",那命令里就只能拼/chat/completions;要是再手贱拼成/v1/chat/completions,就变成了/v1/v1/...,直接 405 Not Allowed。这种低级错误排查起来还挺费时间的,统一好前缀,一次性钉死。
四、第二关:延迟------只看平均值的评测都是外行
这是全篇我最想掰扯清楚的一点。
网上绝大多数"某某模型延迟实测",给你一个"平均 1.2 秒"就完事了。但对 Claude Code 这种 Agent 来说,平均值几乎没用,你该看的是尾部延迟(p95/p99)。
道理很简单:Agent 干一个活,不是发一次请求,是连着发十几到几十次工具调用。这一长串请求里,只要有一次卡了十秒,你整个任务的体感就崩了。平均值把这种"偶尔的暴雷"给抹平了,而你实际感受到的,恰恰是那些暴雷的瞬间。
延迟本身也得拆成两个指标看:
- TTFT(首 Token 延迟) :从发出请求到蹦出第一个字的时间,决定"跟不跟手"。流式输出下,
curl的time_starttransfer就约等于它。 - TPS(吞吐,tokens/秒):决定长输出要等多久,重构整个文件、生成大段代码时它才是瓶颈。
我用同一个 prompt、同样的流式请求,把蓝耘的 DeepSeek-V3.2 和另一家大厂的同款 DeepSeek-V3.2 各连打五次(苹果对苹果,同一个模型,只是平台不同):
bash
for i in 1 2 3 4 5; do
curl -sS -N -o /dev/null \
-w "#$i TTFT: %{time_starttransfer}s | 总耗时: %{time_total}s\n" \
"$LY_BASE/chat/completions" \
-H "Authorization: Bearer $LY_KEY" -H "Content-Type: application/json" \
-d "{\"model\":\"$LY_MODEL\",\"stream\":true,\"messages\":[{\"role\":\"user\",\"content\":\"用三句话解释什么是KV Cache\"}]}"
done

数据摆出来,自己看:
| 第几次 | 蓝耘 TTFT | 某大厂 TTFT | 某大厂总耗时 |
|---|---|---|---|
| #1 | 0.174s | 2.042s | 4.62s |
| #2 | 0.185s | 1.933s | 4.28s |
| #3 | 0.184s | 0.617s | 3.13s |
| #4 | 0.187s | 1.734s | 3.39s |
| #5 | 0.194s | 1.725s | 4.03s |
蓝耘这边,五次 TTFT 全部压在 174~194 毫秒 ,窗口窄到 20 毫秒,稳得像一条直线。某大厂那边,从 0.6 秒到 2.0 秒来回跳,波动幅度是蓝耘的十几倍。
这里的关键不是"蓝耘更快"这句大白话------快慢受网络、时段影响,不同人测未必一样。真正值钱的结论是:蓝耘这条链路的延迟方差极小。 对 Agent 来说,一个稳定的 200 毫秒,比一个"平均 800 毫秒但偶尔飙到 2 秒"的链路,体验上是碾压级的差距。这就是"延迟看尾部"的实际含义。
测的时候注意一个口径问题:如果你测的是 DeepSeek-R1 这类带思维链的推理模型,TTFT 会天然偏高------因为它要先"想"一大段再吐字,这是模型特性,不是平台慢。想量平台链路本身的延迟,就用 V3.2 这种普通对话模型,别拿 R1 的数去黑平台,那不公平。
五、第三关:缓存------这是我上次月账单暴涨的真凶
到这儿才是我这篇文章最想讲的东西,也是我上次"越换越贵"的谜底。
Claude Code 这类 Agent 有个特点:每一轮对话,它都会把一大坨东西重新发一遍------系统提示词、工具定义、你项目里的文件上下文......动辄几千上万 token。你以为你只问了一句"改下这个函数",实际发出去的 input 大得吓人,而且每轮都发。
官方 Anthropic 是支持提示词缓存(Prompt Caching)的:相同的前缀,第一次请求写进缓存,后面命中的部分只按大约十分之一计价。如果你换的那家第三方 API 不支持缓存,那你每一轮都在按全额 input 付费------成本翻个五到十倍轻轻松松。 我上次就是栽在这:图便宜换了家不支持缓存的,单价是低了,但缓存没了,总账单反而涨上去了。
所以选平台,缓存支持与否,对 Agent 场景是决定性的。光看单价那个"元/百万 token"根本不够,得看它算不算缓存价。
我怎么验的呢?造一个大的 system 上下文(约 6000 token),然后用完全一样的请求连发两次------注意,是一字不差,因为缓存靠前缀匹配,你改一个字都可能让它不命中:
bash
# 造一个约 6000 token 的大 system 上下文
BIG=$(python3 -c "print('你是一个资深工程师。以下是项目规范:'+ '规则条目。'*2000)")
# 连发两次完全相同的请求,盯 cached_tokens 的变化
for round in 1 2; do
echo "=== 第 $round 次 ==="
curl -sS "$LY_BASE/chat/completions" \
-H "Authorization: Bearer $LY_KEY" -H "Content-Type: application/json" \
-d "$(jq -n --arg m "$LY_MODEL" --arg s "$BIG" \
'{model:$m,messages:[{role:"system",content:$s},{role:"user",content:"回复ok"}]}')" \
| jq '.usage.prompt_tokens, .usage.prompt_tokens_details.cached_tokens'
sleep 2
done

结果非常干净:
| prompt_tokens | cached_tokens | 命中率 | |
|---|---|---|---|
| 第 1 次 | 6015 | 0 | 写缓存 |
| 第 2 次 | 6015 | 5888 | 97.9% |
第二次请求,6015 个 input token 里有 5888 个命中了缓存,命中率 97.9%。
翻译成人话:在 Claude Code 那种"每轮重发大 prompt"的场景里,从第二轮开始,你的输入成本里近 98% 的部分都能走缓存价。DeepSeek-V3.2 在蓝耘上的定价是输入 2 元/百万 token,而据 AI Ping 的数据(下一节),蓝耘的缓存命中价只要 0.40 元/百万 token------也就是原价的两成。
算一笔账你就懂差距了。假设一个任务跑 20 轮,每轮重发 6000 token 的上下文:
- 不走缓存:20 × 6000 × 2元/M = 约 0.24 元
- 走缓存(第二轮起命中):首轮全价,后续按 0.4 元/M ≈ 约 0.05 元
同一个任务,光输入这块就差了将近 5 倍。 我上次账单暴涨的谜,到这儿彻底解开了------不是模型贵,是我把缓存这个最大的省钱杠杆给弄丢了。
六、第四关:接入 Claude Code------协议对不对,决定你省不省心
前面说蓝耘同时给了 OpenAI 和 Anthropic 两套端点,这一节讲为什么这件事重要。
Claude Code 说的是 Anthropic 的方言 (/v1/messages,认证用 x-api-key)。而 DeepSeek 原生 API 说的是 OpenAI 的方言 (/v1/chat/completions,认证用 Bearer)。两者不通。
所以接 Claude Code,你有两条路:
- 路 A :平台只有 OpenAI 端点。那你得自己挂一个
claude-code-router或LiteLLM在中间做协议翻译。能用,但多一层进程、多一个故障点、多一份延迟,还多一堆配置。 - 路 B:平台直接提供 Anthropic 兼容端点。那就是填几个环境变量的事,零翻译层。
蓝耘给了 Anthropic 端点(https://maas-api.lanyun.net/anthropic),所以我走的是路 B,直连:
bash
export ANTHROPIC_BASE_URL="https://maas-api.lanyun.net/anthropic"
export ANTHROPIC_AUTH_TOKEN="你的蓝耘Key"
export ANTHROPIC_MODEL="qwen3.6-flash" # 也可换成 /maas/deepseek-ai/DeepSeek-V3.2
claude


这里插一句关于"多模聚合"的实感:因为是统一网关,我想从 DeepSeek 换成通义的 qwen3.6-flash(蓝耘模型广场里主打 agentic coding 的那个),就是改一行 ANTHROPIC_MODEL 的事,Claude Code 那头完全无感。选型阶段能这么低成本地横向切模型试,这个价值比宣传页上"多模聚合"四个字实在多了。
一个必须提醒的坑 :
ANTHROPIC_BASE_URL填到/anthropic这一层就行,后面的/v1/messages是 Claude Code 自己补的,你别画蛇添足写全,写全了反而 404。
但是------能聊天,不等于能干活。 这是我要讲的"Agent 看工具调用"。
Claude Code 的本质是个 Agent,它靠的是稳定、格式正确地发起工具调用(tool_use):读文件、写文件、跑命令。很多"OpenAI 兼容"的网关,普通对话跑得好好的,一到 function calling 就静默降级------非 Claude 原生的模型(比如 DeepSeek、Qwen)偶尔会把工具调用的格式吐歪,Claude Code 直接报错中断。所以验证接入成不成功,绝不能只问一句"你好"看它回不回,必须让它做一件真正需要动文件的活:
在当前目录创建 demo.py,写一个计算斐波那契第 30 项的函数并打印;
然后运行它,把输出读回来确认结果是 832040。
盯着看它有没有依次触发 Write(写文件)→ Bash(执行)→ Read(读回结果) 这条完整的工具链。跑通了,才叫真的接上了。

顺带说一句方法论:这一步无论成功失败都有价值。跑通,说明这条链路对 tool_use 支持良好;万一报错卡住,那也不是白测------它恰好印证了"工具调用保真度是选型必测项"这个判断。真实的失败,比虚假的成功有用得多。
七、第五关:交叉验证------把自测的数,拿去和第三方榜单对一遍
到这我其实已经挺满意了,但一个习惯让我没停手:自己测的数,一定要找个独立信源对一遍,不然容易自我感觉良好。
我用的是 AI Ping(aiping.cn),它对各家平台的同款模型做标准化压测。我把蓝耘的 DeepSeek-V3.2 那一行拉出来看(数据为 7 月中旬截图,以实时榜单为准):

这里我必须诚实地说一个反直觉的事,因为藏着的话,这篇文章就不值得信了:
AI Ping 上蓝耘的吞吐是 20.18 tokens/s、延迟 4.33s,在这张榜单里都属于偏低的。 跟我自己 curl 测出来的 180 毫秒,差了二十多倍。
这个矛盾怎么解释?我想了一下,原因是几个测法上的差异,都合理:
- prompt 长度和负载不同。我 curl 用的是"用三句话解释 KV Cache"这种极短 prompt、轻负载;AI Ping 用的是标准化的较长 prompt、固定并发压测。短 prompt 轻负载当然快,这不是谁作弊,是量的东西本来就不一样。
- 网络路径不同。我从本地直连,AI Ping 从它自己的探测节点打,链路不一样。
- 有没有吃缓存。我重复请求容易命中缓存,AI Ping 每次大概率是冷启动。
所以看待延迟这事儿,得认清:没有一个"绝对的延迟数字",只有"在特定测法下的延迟"。 我的 180ms 和 AI Ping 的 4.33s 都是真的,只是回答的是不同的问题。
那蓝耘的真正价值在哪?恰恰不在裸吞吐。 看 AI Ping 这张表里蓝耘那些不显眼但要命的指标:
| 指标 | 蓝耘元生代 | 我的解读 |
|---|---|---|
| 最大输出长度 | 128k | 全表最高,多数厂商只给 32k/64k |
| 可靠性(近6h) | 100% | 满分,Agent 最怕的就是随机 5xx |
| 缓存命中价 | ¥0.40/M | 输入价的两成,呼应我第五节实测的 97.9% 命中 |
| 精度 | 83.33% | 中上 |
| 吞吐 | 20.18 t/s | 确实一般 |
| 延迟 | 4.33s | 确实偏高 |
对 Claude Code 这种"每轮重发大 prompt、经常要吐长文件"的 Agent 场景,可靠性 100%、最大输出 128k、缓存价两折这三样,比裸吞吐值钱得多。我要的不是跑分榜第一,我要的是它别在我写代码写到一半的时候抽风、别把我的长输出截断、别让我为重复上下文反复付全价。这三点它都稳稳做到了。
这也是我实测完缓存命中率 97.9% 之后,决定把 side project 长期落在蓝耘的真实原因------不是它某个单项最亮眼,是它在我真正在乎的维度上都不掉链子,还便宜。
八、把这半天的教训,压缩成一张选型清单
如果你也要给自己的项目挑第三方大模型 API,别只盯着单价。照着下面这张表打勾,能帮你避开我踩过的坑:
工程层------决定能不能用
- 延迟看 p95/p99 尾部 ,别信平均值;流式下
time_starttransfer约等于 TTFT - 用真实工具调用任务验 tool_use(读写文件),不是问一句"你好"就算接上了
- 确认协议:有 Anthropic 端点就直连,只有 OpenAI 端点就得挂翻译层
- 看可靠性 / 有没有智能路由做故障转移------Agent 发几十次请求,1% 错误率就够你崩
成本层------决定贵不贵
- 支不支持提示词缓存,以及缓存命中怎么计价(这是 Agent 场景最大的省钱杠杆)
- 计价粒度透不透明,有没有用量看板 / 调用日志能对账
- 标称上下文 vs 真实可用的最大输出,别被"128k 上下文但输出砍到 4k"坑了
长期层------决定敢不敢一直用
- 模型版本能不能锁定,别今天满血明天偷偷换量化版
- 数据合规:你的代码 prompt 会不会被拿去训练、日志留多久
我自己这轮测下来,蓝耘 MaaS 在"Anthropic 直连、缓存命中 97.9%、可靠性 100%、延迟方差极小"这几条上是实打实过关的,截图和数据都在上面,你可以自己复现。它不是每一项都第一,但在我这个"自费跑 Agent"的场景里,它把我真正在乎的都做对了。
结尾
回到开头那个让我肉疼的账单。上次换便宜 API 越换越贵,不是因为我运气差,是因为我压根没搞懂该看什么------我只看了单价那一个数字,漏掉了缓存这个真正决定 Agent 成本的杠杆。
这半天测下来,我最大的收获不是"蓝耘好用"这个结论,而是那三句话:
延迟看尾部,成本看缓存,Agent 看工具调用。
下次再有人问我"接第三方 API 是不是填个 base_url 就行",我会把这篇甩给他。填 URL 谁都会,但选之前先把这几个数测一遍,能省下的可能就是你下个月的账单。