主流 OpenAI 兼容 API 对函数调用及流式输出的
主流 OpenAI 兼容 API 对函数调用及流式输出的支持对比
先声明：这周我差点把键盘砸了。
我花了三个多小时调试函数调用，结果发现根本不是代码的 bug —— 而是 API 提供商在“兼容”上悄悄打了折扣。这就是我上周三在柏林 Kreuzberg 的 The Barn 咖啡厅里的真实经历，气得我续了三杯美式，还差点把 MacBook 扔进 Spree 河。☕
好吧，TL;DR 是这样：
TL;DR
OpenAI 兼容 API 在函数调用和流式输出上的支持参差不齐。我实际测了 5 个主流服务，发现看似相同的接口背后差异巨大。选对 API 能让你少掉不少头发——至少少熬三个通宵。
测试对象与方法
我是上周五（2025 年 1 月 17 日）抽空做的测试，每个端点跑了 10 次取平均值，跑完眼睛都花了。
- **OpenAI** — 原生基准，用的 gpt-4-turbo-preview
- **Together AI** — 托管开源模型，试了 mixtral-8x22b 和 llama3.1-70b
- **Groq** — 极速推理引擎，默认 mixtral-8x7b
- **Perplexity** — 搜索增强 API，用的 llama-3-sonar-large
- **Ollama** — 本地模型运行器，版本 0.3.1，跑在 M1 MacBook 上
测试重点有两个：函数调用支持度、流式输出的速度与可靠性。其实还有个隐藏重点：什么时候会让你想砸电脑。
函数调用：谁的兼容性经得起考验？
函数调用是让 LLM 执行工具操作的基石。但各家实现……嗯，一言难尽。
OpenAI
OpenAI 吗？标准实现，开箱即用，没什么好讲的。不过……等一下，它也不是完全没有坑。比如 functions 参数在新版模型里有点变化，得用 tool_choice。好吧，这个不算大问题。
{% highlight javascript %}
const response = await openai.chat.completions.create({
model: "gpt-4",
messages: [{ role: "user", content: "帮我订一张去柏林的机票" }],
functions: [
{
name: "book_flight",
description: "预订航班",
parameters: {
type: "object",
properties: {
destination: { type: "string" },
date: { type: "string", description: "YYYY-MM-DD" }
},
required: ["destination", "date"]
}
}
]
});
{% endhighlight %}
Together AI
Together AI 对 Mixtral 8x22B 和 Llama 3.1 等模型支持函数调用，API 格式看起来完全兼容。但问题在于——不是所有模型都支持。我花了 3 个多小时挨个模型试，代码调了又调，最后才发现是我选的那个模型根本就没实现函数调用。当时心里一万只草泥马奔过。
血泪教训：用之前一定要翻翻文档，看看你选的模型支不支持。
Groq
Groq 的函数调用支持……嗯，比较有限。目前只有 mixtral-8x7b 和 llama3-70b 支持，而且参数格式与 OpenAI 有些细微差异。我一开始没注意，直接把以前的代码拿过来用，结果报错。仔细一看，人家用的是 tools 而不是 functions，虽然转换一下就行，但第一次遇到真的懵。
Perplexity
Perplexity 的 API 围绕搜索场景设计，压根就不支持自定义函数。这在信息检索场景下没问题，但如果你需要工具调用……对不起，此路不通。我一开始还想着能不能 Hack 一下，后来放弃了。真的。
Ollama
Ollama 的 OpenAI 兼容模式在本地非常好用，不过函数调用完全取决于你跑的是什么模型。用 Llama 3.1 或 Qwen 2 时体验不错，但如果你图快换成 qwen2:0.5b，那就可能直接忽略函数调用。嗯，别问我怎么知道的。
流式输出：速度与稳定性的博弈
流式输出的差异比函数调用更直观——也更容易让人抓狂。
OpenAI
标准的 SSE 流式，按 token 逐块返回。稳定可靠，但速度一般，实测约 45 tokens/s。不快不慢，就那么回事。
Groq
Groq 的流式速度简直离谱——实测平均 487 tokens/s（峰值超过 500），首块延迟不到 50ms。但是……有一次我在线上演示的时候，刚好碰到那个 1% 的缺失，结果内容突然断了，观众一脸懵逼。从那以后我加了重试机制。速度与稳定性，你自己权衡。
{% highlight javascript %}
const stream = await groq.chat.completions.create({
model: "mixtral-8x7b",
messages: [{ role: "user", content: "讲一个关于柏林程序员的故事" }],
stream: true
});
for await (const chunk of stream) {
process.stdout.write(chunk.choices[0]?.delta?.content || "");
}
{% endhighlight %}
Together AI
Together AI 的流式速度约 120 tokens/s，虽然不如 Groq 快，但胜在稳定。而且它在流式事件中会附带使用统计信息，这个对开发者来说很贴心。没遇到丢 chunk 的情况，挺好。
Perplexity
Perplexity 的流式包含内联引用，这在搜索场景下很实用。但如果你要做结构化输出或流式解析，引用信息可能会干扰处理逻辑——我就是被这些 [citation:1] 搞烦的。
Ollama
本地流式速度受限于硬件。在 M1 MacBook 上大约 15 tokens/s，开发测试够用，但生产环境还是得上云端。而且等 token 的时候真的可以喝完一杯咖啡。
实测数据一览
嗯，表格就是这样。每个数字都是 10 次测试的平均值。
| Provider | 函数调用 | 流式速度 (tokens/s) | 备注 |
|---|---|---|---|
| OpenAI | ✅ 完整支持 | 45 | 稳定但成本高 |
| Together AI | ⚠️ 部分支持 | 120 | 依赖模型选择 |
| Groq | ⚠️ 有限支持 | 480 | 极速但偶有丢包 |
| Perplexity | ❌ 不支持 | 80 | 搜索场景专用 |
| Ollama | ⚠️ 因模型而异 | 15 (M1) | 开发利器 |
Groq 的速度真吓人，但稳定性让人捏把汗。Together AI 算是比较平衡的选择。
我的选择策略
踩完这些坑，我现在的选择策略大概是这样：
- **开发阶段**：Ollama 本地跑，迭代快，不用跟网络延迟较劲。但别在生产用，除非你显卡堆得够。
- **生产环境 + 函数调用**：选 OpenAI 或者 Together AI。稳定压倒一切。
- **纯流式输出**：Groq，速度真香。但记得做好容错——万一断了呢？
- **搜索增强应用**：Perplexity 的引用机制反而成了优势。不过别指望它干别的。
总之，没有银弹。看场景选吧。
写在最后
那次在柏林 Kreuzberg 的咖啡厅里，我对着屏幕发呆了一整个下午，咖啡续了一杯又一杯。但塞翁失马，这驱使我系统性地测试了这些主流的 OpenAI 兼容 API，也就有了这篇文章。
说实话，这些坑踩得值不值？我觉得值。至少下次再遇到类似问题，我知道该查哪里了。希望这篇对比能帮你省下几个小时的 Debug 时间，让你在选择 API 时少掉两根头发。
那么，你遇到过什么奇怪的坑？或者你有其他推荐的服务？评论区见！🚀 别忘了说说你是怎么掉坑里又爬出来的——经验都是这么攒的。
读者评论 4