AI Horde API 队列与额度机制详解

AI Horde API 密钥：排队、Kudos 与结果交付时间

当开发者获得 AI Horde API 密钥时，他实际上获得的是志愿者计算资源队列中的位置，而不是响应时间的保证。界面上的「生成」按钮看起来和付费供应商一样，但背后的合同截然不同：在随机网络参与者机器上运行的智能 FIFO 队列，其状态随每个请求而变化。如果产品对用户承诺基于这一基础设施的固定期限，它承诺的是项目文档直接未确认的内容。

具体论点如下：在 AI Horde 官方机制公布优先级到小时或分钟的换算公式之前，不能将其呈现为可预测的 API。以下我通过文档展示这一点：密钥的作用、Kudos 的用途、如何读取任务状态以及在哪些场景下队列有效、在哪些场景下会破坏产品。

我需要立即澄清信息来源的规范。关于密钥机制、Kudos、状态轮询和使用条件的所有内容都是来自官方项目文档的外部事实，已在 2026-07-18 验证。将场景分类为合适和不合适的做法，以及不应在志愿者网络上承诺 SLA 的建议，这些是我在这些事实基础上的推理，而不是 AI Horde 本身的声明。这两个层次的区分至关重要：混淆它们意味着重复本文所讨论的错误。

为什么队列不能隐藏在普通按钮后面？

需要承认的一个默认错误是：用与付费 API 相同的加载旋转来呈现志愿者队列。视觉上相同，实质上的合同不同。付费供应商背后有专属计算能力和声明的响应时间。AI Horde 背后是智能 FIFO 队列，其中位置和时间随当前网络中有多少人以及相邻请求的 Kudos 数而变化。

低入场门槛（甚至可以在不注册的情况下开始）造成了将服务视为现成可预测产品的诱惑。这在逻辑上是错误的：低入场门槛不会产生 SLA，这是基础设施的两个独立属性，一个不会从另一个推导出来。

如果场景需要具有清晰定价的路由且来自俄罗斯并且没有志愿者的不确定性，有一个单独的选项：provod.ai（俄罗斯版 OpenRouter）。这是不同级别的服务，它不会复制或承诺相同的队列机制；我将在下文回到比较。

API 密钥做什么以及 Kudos 与此有什么关系？

AI Horde 中的密钥定义了队列中的位置，而不是对额外计算能力的访问。根据 AI Horde 注册页面，有一个固定的匿名密钥 0000000000，可以在完全不注册的情况下发送请求。但根据文档，在高负载时，匿名请求的优先级最低。通过 OAuth2 或简单的用户名注册会发出个人密钥，该密钥在丢失时无法恢复，并绑定到 Kudos 余额。

Kudos 很容易被误读，所以值得精确引用。根据项目术语，Kudos 被定义为「优先级机制，而不是货币」：它们不能被购买或出售，它们通过运行自己的 worker 获得或作为礼物接收。Horde 以「先进先出」原则运行智能队列，具有更多 Kudos 的请求从队列中提取得更快。

这正是证据基础中心缺口所在。更多 Kudos 在统计上给出了队列中更好的位置，但没有官方来源公布公式或历史平均值，将 Kudos 和队列深度转换为时钟上的具体分钟数。对待命令顺序的杠杆存在，没有「这么多 Kudos 等于这么多秒」的函数，应该把这作为开放的未知数来处理，而不是用编造的等待数字来填补。

AI Horde API 密钥在实践中归结为一个问题：密钥给予什么以及它不给予什么。密钥和累积的 Kudos 改变队列中的位置，但不会购买固定的结果时间，这是选择基础设施时应该使用的唯一准确定义。

如何知道请求在队列中的位置？

AI Horde 中没有完成就绪的推送通知。根据项目的集成指南，进度通过客户端轮询状态端点获得：客户端本身访问 /v2/generate/status/{id} 之类的东西，并获得调用时刻的实时快照，显示请求的多少子任务仍在等待、有多少正在处理以及有多少已完成。快照描述当前状态，而不是完成时间的合同；可以问「现在怎么样」，不能问「什么时候准确完成」。

在实践中，周期是这样的：发送异步请求，获取 ID，然后在循环中轮询状态直到任务完成。重要的是不要将超时变成对用户的承诺，而是将长等待视为标准场景，而不是紧急场景。

import requests, time

# анонимный ключ: работает, но приоритет самый низкий
API_KEY = "0000000000"

start = requests.post(
    "https://stablehorde.net/api/v2/generate/async",
    headers={"apikey": API_KEY},
    json={"prompt": "a red fox in snow", "params": {"n": 1}},
)
req_id = start.json()["id"]

# опрос статуса: живой снимок, не гарантия времени
while True:
    snap = requests.get(
        f"https://stablehorde.net/api/v2/generate/status/{req_id}"
    ).json()
    if snap.get("done"):
        break
    time.sleep(5)

这段代码有意不包含可能向用户显示为承诺的 ETA 计算。我不提供诸如等待时间估计之类的精确字段名：官方 Swagger 通过 JavaScript 提供，在 2026-07-18 验证时读不了原始 HTML，因此文章保持集成指南记录的详细程度：等待、处理、完成。解决这个问题已足够，不应该过度指定未直接确认的内容。

作为比较。对于与 OpenAI 和 Anthropic 协议兼容的路由，集成的结构不同：客户端更改 api_key 和 base_url，获得同步响应而不轮询状态、不经过志愿者队列。在 provod.ai，它就是这样工作的：受支持的客户端通过替换 base_url 和密钥连接，而模型从平台的当前目录中调用。

from openai import OpenAI

client = OpenAI(
    api_key="provod-...",
    base_url="https://api.provod.ai/v1",
)
resp = client.chat.completions.create(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": "..."}],
)

这并不意味着一条路由在所有方面都优于另一条。AI Horde 的分布式访问降低了对请求者的进入门槛——成本为零，但不能提供相同的期限控制。协议兼容的路由提供了可预测的响应同步，但这是不同的请求经济学。选择取决于特定场景中的关键因素：进入价格还是时间和数据控制。

志愿者队列何时不适用？

现在转向解决方案。有一个四列的矩阵：任务、队列、期限、数据风险，它不是按品味而是按网络的可验证属性来筛选场景。

第一个属性：期限。在项目官方常见问题中没有 SLA，明确说明在高需求时交付速度更慢，就像任何排队服务一样，没有最大或平均等待时间的义务。使用条款在法律上支持这一点：AI Horde 和 Haidra-Org 的总体责任限制为 100 欧元，项目本身设立为非营利服务，没有可购买的费率。这是志愿者基础设施，而不是有供应商保证的产品，具有硬截止日期的特定请求场景不适合这里。

第二个属性：数据。这里有两个事实，都应该精确阅读。第一：AI Horde 不存储发送的提示和结果，根据相同的常见问题，生成数据仅保存在内存中，并在交付或取消后不久删除，仅长期存储用于登录的账户标识符。第二：常见问题本身警告说，worker 程序在志愿者的机器上运行并作为开源发布，因此原则上 worker 可以被修改为查看或保存通过它的提示和图像，尽管标准 worker 既看不到请求者的账户 ID，也看不到其 IP。项目的记录建议听起来正是这样：发送请求时就像在公共论坛上发布一样。

这是项目本身披露的风险，而不是已确认的泄露事件，不应将诚实警告变成关于黑客攻击的声明。解决这个问题已足够：如果数据不适合公共论坛，这个队列不适合它。

拒绝标准直接从右列读出：需要保证的期限，那么这个基础设施不合适；数据不适合队列，那么也不合适；机制未验证特定用例，那么先验证然后决定。应该直接说明这个决定的代价：有意不向用户承诺对不可预测队列的固定期限。这是一个限制，而不是失败。

AI Horde 不会因为开发者有密钥和 Kudos 储备就成为可预测的 API。Kudos 改变队列中的位置，但不购买时间，官方公式转换为秒数不存在，也不能编造。服务也不承担供应商级别的 SLA 和责任：使用条款中 100 欧元的上限直接固定了这一点。它也不完全为开发者解决隐私问题：数据不会永久存储，但通道经过他人机器，意味着风险管理仍然由发送请求的人负责。

在对用户做出第一个承诺之前，根据两个轴（期限和数据风险）收集场景图。如果在任何一个轴上红灯亮起，对于这种情况不要选择志愿者基础设施：将其用于不敏感的灵活期限任务或选择另一条路由。这个决定只做一次，定义整个用户体验：队列应该是界面的可见部分，而不是隐藏在承诺不存在的速度的旋转器后面。

如果根据矩阵的结果需要一个可预测的路由，从俄罗斯付款，而不是没有时间保证的免费队列，那么为工作流配置 provod.ai：用卡、通过 SBP 或发票用卢布付款，不需要外币卡和 VPN，按官方供应商价格访问模型，没有平台加价。同时，provod.ai 不替代自有基础设施和本地部署，也不替代团队仍然需要做的集成和运营工作。

provod.ai — 企业数据的托管 AI 轮廓

对于内部文档，重要的是访问、角色和成本控制：provod.ai 提供工作区、单独的员工账户和集中的 AI 管理。该平台旨在考虑俄罗斯对个人数据处理和保护的要求；适用性取决于具体的场景和客户设置。

在一个目录中 — 用于文本和媒体的最新模型：来自 OpenAI 的 GPT、来自 Anthropic 的 Claude、来自 Google 的 Gemini、来自 xAI 的 Grok、DeepSeek、Qwen、GLM、Kimi 和 MiniMax；对于图像 — Nano Banana 2 Pro 和 GPT Image；对于视频 — 最新版本的 Sora、Kling、Veo 和 Google Omni。还可以访问用于推理、搜索、文档、嵌入、音乐和音频的模型。

企业控制不会变成价格系数：模型成本保持 1:1，与官方费率一致，没有 provod.ai 的自有加价。

探索 provod.ai 企业轮廓：注册表单 · 模型价格 · 根据 152-ФЗ 的数据保护 · 数据处理政策

AI Horde (Haidra-Org)，API 和注册：stablehorde.net/api，stablehorde.net/register。匿名密钥和队列优先级。已验证 2026-07-18。

AI-Horde 常见问题 (GitHub, Haidra-Org)：github.com/Haidra-Org/AI-Horde/FAQ.md。Kudos 定义、缺乏 SLA、内存中数据处理、关于 worker 端可见性的警告。已验证 2026-07-18。

AI-Horde 术语 (GitHub Wiki)：github.com/Haidra-Org/AI-Horde/wiki/Terminology。Kudos 作为优先级机制。已验证 2026-07-18。

AI-Horde README_integration (GitHub)：github.com/Haidra-Org/AI-Horde/README_integration.md。轮询状态端点，没有推送。已验证 2026-07-18。

AI Horde 隐私和条款：stablehorde.net/privacy，stablehorde.net/terms。非永久数据存储、100 欧元责任上限。已验证 2026-07-18（页面通过 JS 提供，建议在发布前在浏览器中手动验证）。