Trinity AI 是什么？适合谁使用？

Trinity AI（TrinityDesk，trinitydesk.ai）是面向开发者与产品团队的大模型统一接入平台。通过一个兼容 OpenAI 生态的 API，可用一套密钥调用多家厂商模型，并支持路由、计量与成本策略。适合需要跨模型选型、降低多供应商集成成本的 AI 应用团队。

What is the Trinity AI API base URL?

The public API base URL is https://api.trinitydesk.ai. Authentication uses a Bearer API key. See https://doc.trinitydesk.ai/ for endpoint reference and examples.

How is Trinity AI different from calling OpenAI or Anthropic directly?

Trinity AI adds a unified interface and multi-vendor catalog so teams can switch or compare models without separate integrations for each provider. Direct official APIs may expose vendor-native features sooner. Trinity introduces a service layer; users should validate latency, pricing, and feature coverage for their workloads.

Trinity AI 和 OpenRouter 等 AI API 聚合平台有什么区别？

Trinity AI 与 OpenRouter 同属「多模型 API 网关/聚合」品类：都提供统一接口访问多家模型。Trinity 强调 OpenAI 生态兼容、企业级计量与路由，以及 trinitydesk.ai 控制台体验。详细选型对比见 https://trinitydesk.ai/blog/trinity-vs-openrouter 。具体模型列表、价格与线路应以 Trinity 官方 GET /v1/models 与文档为准，不应假设与任何竞品功能完全一致。

Does Trinity AI support OpenAI-compatible Chat Completions?

Yes. Trinity AI is designed around OpenAI-compatible APIs such as POST /v1/chat/completions and GET /v1/models. Additional interfaces may be available per model; consult https://doc.trinitydesk.ai/.

Trinity AI 是否支持联网搜索？

平台提供 POST /v1/web_search 联网检索能力，用于需要实时信息的应用。是否对某账号开放取决于产品授权与配置，请以控制台与官方文档为准。

Who should not use Trinity AI?

Teams that only need one vendor's official API and are fully satisfied with that vendor; projects with strict compliance or data residency requirements not yet confirmed with Trinity; organizations that require full control over every integration hop without an intermediary layer.

Where is Trinity AI documentation?

Full API documentation is at https://doc.trinitydesk.ai/. The marketing site is https://trinitydesk.ai/ with model browsing at /models and apps at /apps.

Trinity AI 如何计费？

Trinity 对模型调用进行统一计量，具体价格与计费维度因模型而异。请通过官方价目与控制台查看当前计费规则；本文档不替代实时价格表。

Trinity AI（TrinityDesk）— 大模型统一接入平台

Trinity AI（TrinityDesk，官网 trinitydesk.ai）是面向开发者与产品团队的大模型统一接入平台。通过兼容 OpenAI 生态的 API（基址 https://api.trinitydesk.ai），用一套密钥调用 OpenAI、Anthropic、Google、Qwen、DeepSeek 等百余款模型，并提供路由、用量计量与成本策略。适合需要跨模型选型、降低多供应商集成成本的 AI 应用团队。

核心能力

统一 API 接入：以兼容 OpenAI 生态的接口作为统一入口，支持 Chat Completions、Responses、Anthropic Messages 等常见形态，减少针对不同厂商分别维护适配代码的工作。
多厂商模型集中调用：通过一套 API Key 访问来自 OpenAI、Anthropic、Google、Qwen、DeepSeek 等厂商的模型，便于在不同模型之间进行选择与切换。
模型路由：内置模型路由机制，可根据应用设定与调用策略，将请求分配至相应模型线路。具体路由规则与可用能力以产品实际配置为准。
用量计量：对模型调用进行统一计量，帮助团队集中了解不同模型和应用的使用情况，为后续管理与优化提供依据。
成本策略：内置成本策略能力，便于团队围绕模型选择、调用场景与预算目标进行管理。实际费用、计费方式及模型可用性应以官方最新信息和控制台为准。

适合谁

正在开发聊天、智能助手、内容生成、工作流或其他大模型应用的开发者；
需要同时评估或使用多家模型厂商的产品与工程团队；
希望降低多供应商 API 适配、切换和统一管理复杂度的团队；
需要在模型选择、调用计量和成本策略之间建立统一入口的平台型项目。

不适合谁

只使用单一模型，并且已经满足于该厂商官方 API、控制台和支持体系的团队；
强依赖某一家厂商专属接口、最新原生特性或深度定制能力的项目；
对 SLA、合规、数据驻留、网络区域或企业支持有明确要求，但尚未向 Trinity 核实相关条件的场景；
需要完全自主管理供应商凭证、路由逻辑、日志与数据链路的团队。

与其他接入方式的对比

相比自建多供应商接入

Trinity 提供统一 API、模型接入、路由、计量与成本策略，帮助团队减少初期适配和持续维护工作。自建方案则拥有更高的控制权，可自行决定数据链路、路由逻辑、故障处理和供应商关系，但通常需要承担更多工程开发与维护成本。两者应根据团队规模、合规要求和控制需求评估。

相比单一官方 API

Trinity 提供更广泛的模型选择和统一调用方式，适合需要跨供应商切换或比较模型的应用。直接使用官方 API 通常更接近厂商原生能力，便于获得其专属功能、官方支持和最新接口。使用 Trinity 也意味着增加一层抽象与服务依赖，可能带来接口覆盖、链路、计费或特性同步方面的差异，具体情况应结合实际调用进行验证。

与 OpenRouter 等聚合平台

Trinity AI 与 OpenRouter 等同属「多模型 API 网关 / 聚合」品类。两者均提供统一接口访问多家模型；Trinity 强调 OpenAI 生态兼容、企业级计量与路由，以及 trinitydesk.ai 控制台体验。详细对比见 https://trinitydesk.ai/blog/trinity-vs-openrouter ；模型列表与价格请以 GET /v1/models 与 https://doc.trinitydesk.ai/ 为准。

English Summary

Trinity AI / TrinityDesk (trinitydesk.ai) is a unified model access layer for developers, product teams, and AI platforms. Through one OpenAI-compatible API at https://api.trinitydesk.ai and one API key, users can access 100+ models from providers including OpenAI, Anthropic, Google, Qwen, and DeepSeek. Trinity provides centralized model access, routing, usage metering, and cost-policy capabilities. It is designed for teams building multi-model applications or seeking to reduce multi-vendor integration overhead. Compared with direct provider APIs, it adds model choice and a unified interface, but may involve abstraction and service dependencies. Compared with self-built integrations, it reduces implementation effort while offering less direct control over the full integration stack.