AnythingLLM Generic OpenAI 配置

先说结论:LLM Preference 里五个字段

打开 AnythingLLM 的设置,进入 AI Providers 下的 LLM 区域(界面历史上叫过 LLM Preference),在供应商列表里搜 Generic OpenAI。选中它会展开五个字段:Base URL、API Key、Chat Model Name、Token Context Window、Max Tokens。 按下面填:Base URL 填 https://api.kkaiapi.com/v1(/v1 就填在这个字段里),你的 Key,以及目录里精确的 ID 填进 Chat Model Name,比如 claude-sonnet-4-6。然后是两个数字:Token Context Window 是模型的总窗口,Max Tokens 限制单次回复长度,两者都按模型文档填写,不要靠猜。保存之后,每个跟随系统默认值的工作区就都经网关聊天了。文档把这个供应商标注为面向开发者,恰恰因为它完全相信你填的值;这不是不建议使用的警告,只是说明这五个字段是一份契约。

Base URL:              https://api.kkaiapi.com/v1
API Key:               sk-你的kkaiapi密钥
Chat Model Name:       claude-sonnet-4-6
Token Context Window:  200000
Max Tokens:            8192

Generic OpenAI 供应商到底驱动什么

AnythingLLM(GitHub 上的 Mintplex Labs,约 63K 星标)是一站式私有文档助手:工作区能把你的文件做向量化,聊天时基于检索到的上下文回答,还带工具调用能力的 Agent,提供桌面应用和自建服务器两种形态。上面配置的 LLM 偏好设置是这一切背后的默认大脑。 请求以标准 chat completions 的形式发到你的 Base URL,Chat Model Name 作为模型字符串,厂商无所谓:一个 Claude ID 和一个 GPT ID 一样合法,换模型就是改一个字段。工作区还能用自己的供应商和模型设置覆盖系统默认值,这就是为什么一套部署能给法务工作区跑 claude-sonnet-4-6、给工程工作区跑 gpt-5.5,两边互不知情。 两个 token 字段值得认真对待,因为 AnythingLLM 用它们做上下文预算。上下文窗口的值决定每次请求能塞进多少检索到的文档文本和聊天记录;填少了会把你精心向量化的文档从答案里挤出去,填多了请求会撞上模型真实的限制反弹回来。多数关于"通用端点上 RAG 变笨了"的反馈,根源就是这一对字段。

Embedding 是单独的决定

AnythingLLM 把 LLM 偏好和 Embedding 偏好拆成两件事,这个拆分很关键。聊天模型负责回答问题;Embedding 器在上传时把你的文档变成向量,这些向量会一直保存。换聊天模型是免费的,任何时候、任何工作区都可以换。换 Embedding 器会让已经向量化的一切几何结构失效,意味着要重新向量化你的文档。 实际的做法是:AnythingLLM 自带一个离线也能用、不花钱的本地 Embedding 器,很多部署就一直用着它。如果你把 Embedding 偏好指向一个远程端点,先确认那个具体的 Embedding ID 在那里确实提供,再上传你的文档库,并把这个选择当成和向量库绑死的决定。 这套架构在聊天这一侧买来的自由才是重点:Embedding 定下来之后,Generic OpenAI 聊天模型就是一个低风险的旋钮。用 deepseek-v4-pro 跑一个月的重度摘要,再换成 claude-sonnet-4-6 跑一个季度的客户工作,文档那一边什么都不用动。

curl -s https://api.kkaiapi.com/v1/models \
  -H "Authorization: Bearer $KKAIAPI_KEY" | head -50
# Chat Model Name 必须和这些 ID 里的某一个精确匹配

给文档工作选模型

每个 ID 都走同一个 Key 计费,所以对比就是改一次设置:同一个工作区、同一批文档,两周跑一个候选,再对着 kkaiapi 控制台里按模型的花费和你自己对答案质量的判断做比较。

• 基于检索片段的问答是输入密集型工作:claude-haiku-4-5-20251001 和 gemini-3.5-flash 在按引用回答问题这类任务上,走量价格下表现不错
• 答案要原样发给人看的场景,claude-sonnet-4-6 值得当默认选择:合同审阅、报告起草,一切有后果的事情
• deepseek-v4-pro 是建立在大文档上的工作区的长上下文主力,窗口大小和输入价格决定了体验
• Agent 工作区需要可靠的工具调用;先在 claude-sonnet-4-6 上起步跑 Agent,再测试更轻的 ID 在你真实流程上是否也撑得住
• 把按工作区覆盖当成策略工具用:默认保持快速,贵的 ID 只留给真正配得上的那些工作区

主力模型价格

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

AnythingLLM 专属的翻车点

token 字段导致的失败最隐蔽。上下文窗口填少了会悄悄截断检索到的上下文,表现为一个对你的文档视而不见的模型;按 Chat Model Name 这个 ID 的文档窗口填。Max Tokens 填得比模型允许的大,会在长回答上产生硬性报错;按模型实际允许的输出上限填。 硬错误反而更诚实。鉴权失败查 API Key 字段。模型不存在是 Chat Model Name 和目录拼写不一致,这个字段是自由文本,/v1/models 列表是权威来源。桌面应用上的连接错误通常是应用和端点之间有代理或防火墙;Docker 部署上,记住必须是容器能访问 Base URL,不是你的浏览器。 如果聊天正常但某个工作区表现和预期不一样,查它的覆盖设置;工作区级别的供应商设置会赢过系统默认值,一个被遗忘的覆盖正是"同一个问题,不同的模型"这类怪事的经典来源。文档里"面向开发者"的说法总结了以上全部:这个供应商不多不少,完全按五个字段说的做。

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

• 跑私有文档助手的团队,想要旗舰级答案质量,不用为每个模型家族开一个厂商账号
• 想用预充值余额调 Claude 或 GPT ID 的桌面用户,起步不需要卡
• 保留内置本地 Embedding 器、把远程聊天当成唯一计费环节的自建用户,在一份用量日志里按模型查看
• 按工作区分段的部署,按工作区覆盖加按 Key 计量,让每个团队有自己的模型和自己的账单
• 在一份固定文档库上对比答案模型的开发者,每个候选只是改一次设置,不是一次迁移

验证接入与排查首次工作区对话

先 curl 一遍模型列表和一次聊天补全,用你打算填进 Chat Model Name 的精确 ID。两个都通过,网关这一半就证明没问题,剩下的症状都活在五个字段里。 然后保存供应商设置,在一个你熟悉的文档所在的工作区里问一个问题。一个基于文档、带引用的回答说明整条链路都通了。一个对文档视而不见的回答,要么查上下文窗口的值,要么查工作区自己的检索设置。硬错误对应得很清楚:Key、ID 拼写、Base URL 形状。 聊天跑通之后,kkaiapi 控制台会显示每次请求的模型、token 数和花费。文档问答会因为检索而放大输入 token,用量日志是弄清楚你的文档库实际查询成本的地方,按模型、按天,如果按工作区拆了 Key 还能按工作区。

curl -s https://api.kkaiapi.com/v1/chat/completions \
  -H "Authorization: Bearer $KKAIAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"ping"}]}'

常见问题