网上给 Claude Code 接第三方 API 的教程一抓一大把，但清一色都在教你怎么填 base_url、api_key，填完能对话就算完事。可真正把它挂上去跑一阵子你就会发现：填 URL 是五分钟的体力活，选对平台才是真功夫。

我自己就踩过一次：一个挂着 Claude Code 跑的小工具，原本用官方额度，想省钱换了家便宜的第三方 API，结果月底账单不降反升。单价明明更低，总价怎么反而涨了？后来才搞明白，是漏看了一个关键的东西——缓存。

这篇就是把“换之前到底该看什么”这件事测明白后的复盘。用蓝耘元生代 MaaS 接 DeepSeek-V3.2，中间拉了另一家平台的同款模型做对照。数据都是自己 curl 跑出来的，截图都在，能复现。

结论先放这儿，后面全是论证：

延迟看尾部，成本看缓存，Agent 看工具调用。

一、先说清楚：为什么我最后落在蓝耘，而不是继续用官方

不绕弯子。我选平台时脑子里过的是这么几件事，按重要性排：

1. 它到底支不支持 Claude Code 的原生协议，还是要我自己搭翻译层；
2. 同样的活儿，重复上下文能不能命中缓存、省下那笔冤枉钱；
3. 延迟稳不稳定，别一卡就是好几秒；
4. 出了问题有没有地方查——用量、账单、调用日志。

蓝耘 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 之后，有三个东西你必须在控制台确认清楚，这决定了后面怎么接：

1. 调用地址（Base URL）：https://maas-api.lanyun.net
2. 协议格式：蓝耘同时提供了 OpenAI 兼容（/v1/chat/completions）和 Anthropic 兼容（/anthropic/v1/messages）两套端点——这一点非常关键，下面单独讲。
3. 模型的准确调用名：比如 DeepSeek 是 /maas/deepseek-ai/DeepSeek-V3.2，注意它带 /maas/ 前缀，不是干巴巴一个 deepseek-chat，写错了直接 404。

控制台每个模型点进去都有 API 示例，照着抄不会错：

三、第一关：连通性冒烟，顺便看清它的 usage 长什么样

任何新 API 到手，我第一件事永远是发一个最小请求，确认“通没通”，别急着写代码。

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 字段：

"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 各连打五次（苹果对苹果，同一个模型，只是平台不同）：

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），然后用完全一样的请求连发两次——注意，是一字不差，因为缓存靠前缀匹配，你改一个字都可能让它不命中：

# 造一个约 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，直连：

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 毫秒，差了二十多倍。

这个矛盾怎么解释？我想了一下，原因是几个测法上的差异，都合理：

1. prompt 长度和负载不同。我 curl 用的是“用三句话解释 KV Cache”这种极短 prompt、轻负载；AI Ping 用的是标准化的较长 prompt、固定并发压测。短 prompt 轻负载当然快，这不是谁作弊，是量的东西本来就不一样。
2. 网络路径不同。我从本地直连，AI Ping 从它自己的探测节点打，链路不一样。
3. 有没有吃缓存。我重复请求容易命中缓存，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 谁都会，但选之前先把这几个数测一遍，能省下的可能就是你下个月的账单。