BibiGPT 音视频总结接入统一 API

先说结论:三个环境变量

BibiGPT 的示例环境文件直接写明了这套配置:OPENAI_COMPATIBLE_BASE_URL 设置端点(默认 https://api.openai.com/v1),OPENAI_COMPATIBLE_API_KEY 存密钥(留空会回退到 OPENAI_API_KEY),OPENAI_COMPATIBLE_MODEL 选总结用的默认模型。把 base URL 填成 https://api.kkaiapi.com/v1,密钥变量填一个 kkaiapi 的 Key,模型变量填目录里任意一个 ID。 base URL 在使用时会被校验:必须以 http:// 或 https:// 开头,末尾的斜杠会被自动去掉,所以上面这个带 /v1 的写法完全正确。底层用这三个值构建了一个基于 Vercel AI SDK 的 openai-compatible provider,再拿配置好的 ID 调用 chatModel,这也是为什么端点提供的任何模型都能直接用、不用改代码。

# 可选:接入 OpenAI 兼容供应商(留空会回退到 OPENAI_API_KEY)
OPENAI_COMPATIBLE_API_KEY=sk-你的kkaiapi密钥
OPENAI_COMPATIBLE_BASE_URL=https://api.kkaiapi.com/v1
OPENAI_COMPATIBLE_MODEL=deepseek-v4-flash

BibiGPT 往端点发了什么

BibiGPT(GitHub 上的 JimmyLv,开源 v1 约 6K 星标)是一键式音视频 AI 总结工具:粘贴一个 B 站或 YouTube 链接、一段播客、一份会议录音或本地文件,它会拉取文字稿,压缩成摘要,还能就内容继续追问。项目最早叫 BiliGPT,专做 B 站总结,后来长成中英双语工具并衍生出托管版,这里讲的环境变量配置针对的是自建开源 v1。 这个负载的形状是转写稿:输入长、输出短。一小时的语音是很大量的文字稿,应用会先把它切成模型能处理的片段再逐段总结,所以一条视频背后可能是好几次 chat-completions 调用,输入 token 远远超过最终产出的摘要。输入单价因此就是整个成本的大头,长上下文模型能减少长讲座、长播客的切片次数。 provider 的构建顺序很讲究:单次请求带的 Key(给允许用户自带 Key 的实例用)优先于 OPENAI_COMPATIBLE_API_KEY,后者又优先于 OPENAI_API_KEY;base URL 和模型也是同一套优先级。还有一个 OPENAI_COMPATIBLE_KEY_PREFIXES 变量,专门用来接受不是 sk- 前缀的用户输入密钥,当你的用户手里拿的是网关 Key 而不是 OpenAI 官方 Key 时用得上。

完整配置:自建实例的部署环境

BibiGPT 是个 Next.js 应用,环境变量跟着部署方式走:本地是 .env 文件,Vercel 是项目环境变量,Docker 是容器环境变量。三个变量设好,重新部署或重启,总结就经网关跑。 模型变量只是默认值,不是硬限制。请求可以带一个按视频的配置,里面的 model 字段如果存在会覆盖 OPENAI_COMPATIBLE_MODEL,所以一个实例可以默认用便宜模型,特定流程再单独指定更强的模型。如果你运营的实例给别人用、允许粘贴自己的 Key,把 OPENAI_COMPATIBLE_KEY_PREFIXES 设成包含你网关的 Key 前缀,表单才会接受。

OPENAI_COMPATIBLE_API_KEY=sk-你的kkaiapi密钥
OPENAI_COMPATIBLE_BASE_URL=https://api.kkaiapi.com/v1
OPENAI_COMPATIBLE_MODEL=deepseek-v4-flash

# 如果要在界面里接受用户自己粘贴的网关 Key:
OPENAI_COMPATIBLE_KEY_PREFIXES=sk-

中英内容怎么选总结模型

对比方式很直接:同一条视频,两个模型 ID 各跑一遍,对着转写稿读两份摘要。按 Key 的用量日志会给每个候选模型按真实内容定价,转写类负载的差异在输入 token 那一列立刻看得出来。

• 中文内容是 BibiGPT 的主场:B 站讲座、抖音片段、中文播客。glm-5.2、deepseek-v4-flash、kimi-k2.6 对中文转写稿天然强,和其它模型走同一个端点
• 英文与中英混合内容(YouTube、海外播客)用 claude-haiku-4-5-20251001 和 gemini-3.5-flash 表现不错,两者都能稳定处理长而杂的转写稿
• 这个中英分工正是一个网关的实际意义:一个端点、一个 Key,按视频的模型覆盖能按内容来源精确挑模型,而不是被迫用一家模型应付两种语言
• 长讲座更吃长上下文。切片越少,调用次数越少,摘要也更连贯;拿你最长的内容测一个长上下文 ID,再决定要不要作为默认
• 走量的实例(一个团队总结看过的所有内容)默认用 deepseek-v4-flash,有选择地升级,输入密集的负载会让快速档模型的价格优势被放大

主力模型价格

价格按 kkaiapi 中文区实时价格计算,单位 ¥/1M tokens(输入/输出)。

BibiGPT 专属的翻车点

回退链会带来意外。如果 OPENAI_COMPATIBLE_API_KEY 是空的,应用会悄悄回退到 OPENAI_API_KEY。这在两者指向同一服务时没问题,一旦不一致就麻烦:网关的 base URL 配上一个官方 OpenAI Key,会产生看起来像网关问题的鉴权错误。换路由时,把 compatible 前缀的这一对变量一起设置,别留一个指向别处的 OPENAI_API_KEY,或者确保它存的也是同一个网关 Key。 base URL 校验器会拒绝没有协议头的值,裸域名会直接报错;记得带上 https:// 和 /v1 路径。末尾斜杠会被自动规整,两种写法都行。 模型 ID 是精确字符串,以端点 /v1/models 的返回列表为准;OPENAI_COMPATIBLE_MODEL 拼错字,第一次总结就会报模型不存在。也别忘了按视频覆盖:如果某个流程一直用旧模型,说明请求配置里传了显式的 model 字段。 转写稿获取是独立的另一套管线。如果某条视频因为字幕或音频抓取失败而没有摘要,那是内容管线的问题(平台接口、字幕可用性),不是 LLM 端点的问题,本文的环境变量只影响总结这一步调用。另外要注意,托管版 bibigpt.co 自己管理模型,这些变量只对你自己部署的开源 v1 生效。

哪些人会把 BibiGPT 接到一个网关上

• 同时看 B 站和 YouTube 的双语用户,把中文强的 ID 和海外 ID 配在同一个 Key 下,不用一个语言配一家
• 国内自建场景的用户,一个 OpenAI 兼容端点同时提供 GLM、DeepSeek、Kimi,彻底省掉多厂商账单的麻烦
• 给团队跑共享总结服务的人,按 Key 计量用量,默认走量档 ID
• 重度播客听众,每周几十小时的转写稿量让输入 token 单价成为唯一要紧的成本变量
• 手头没有某家厂商官方支付渠道的开发者,充值即用不需要海外卡

验证接入与排查首次总结

先列出你的 Key 能调用的模型,确认 OPENAI_COMPATIBLE_MODEL 里配的 ID 在列表里,这一个检查能防住大多数首次失败。 然后总结一条短内容。鉴权错误说明解析出来的 Key 和解析出来的端点对不上,考虑到回退链的存在,先打印实际生效的是哪个变量再下结论;配置层的 api_key 配上环境层的 base URL(或反过来)是经典的错配。模型不存在的报错是 ID 拼错了。请求肉眼可见地打到了别的域名,说明回退到了 OPENAI_API_KEY。总结迟迟不开始但端点本身健康,说明是转写稿抓取在 LLM 调用之前就失败了。 总结跑起来之后,kkaiapi 控制台会显示每次请求的模型、token 数和花费。音视频总结是最典型的输入密集型负载,一周的用量数据就能告诉你每小时内容对每个模型的真实成本,这个数字才值得优化。

curl -s https://api.kkaiapi.com/v1/models \
  -H "Authorization: Bearer $KKAIAPI_KEY" | head -50

常见问题