生产环境中运行Qwen 3：推理供应商对比

根据推荐用例、相对价格、速度和基础设施控制来比较流行的 Qwen 推理提供商。您可以将此表格作为基准，帮助确定最适合您工作负载的提供商。

没有放之四海而皆准的赢家。从工作负载出发：

• 如果您面对的是不可预测的流量，并希望最大程度地减少运维麻烦，请选择托管无服务器 API。
• 如果您确实需要低延迟的交互式聊天、语音通话和编码，请选择专注于速度的提供商。
• 在模型可移植性和提供商回退是需要重点考虑的情况下，您可以选择路由器。
• 当持续流量需要可预测容量时，选择专用推理。
• 当您需要基础设施控制、自定义权重、私有网络或专门的推理优化时，选择自托管。

广告中最便宜的每令牌价格并不总是能带来最低的生产成本。请使用相同的提示、相同的模型版本、输出长度和并发级别来评估提供商。

• 首令牌时间 (TTFT) 是指从提交请求到生成第一个输出令牌所经过的时间。该指标极大地影响聊天机器人或编码助手给人的响应速度感。
• 输出速度衡量系统在首个令牌之后每秒生成的令牌数量。快速输出对于长答案、推理轨迹、代码生成和多步骤智能体非常重要。
• 端到端延迟涵盖完整的请求生命周期，包括排队、提示处理、生成和网络传输时间。

DeepInfra和Novita通常是成本敏感的Qwen推理的良好起点；但是，比较应在等效的模型版本和服务层级之间进行。

例如，在评测时，DeepInfra在常规层级上列出Qwen3.5-27B的价格约为每百万输入token 0.26美元，每百万输出token 2.60美元。其Qwen3.5-397B-A17B的定价约为每百万输入token 0.45美元，每百万输出token 3.00美元。灵活层级可能成本更低，但调度优先级可能较低。请参阅当前的DeepInfra Qwen3.5-27B列表和Qwen3.5-397B-A17B列表。

较小的模型可能便宜得多。这一点很重要，因为许多分类、检索、摘要和路由任务并不需要旗舰模型。经过充分评估的4B、9B或27B模型在经济性上可能胜过更大的模型，即使更大模型的每个活跃参数价格更低。使用预期的输入与输出比例来计算成本：

假设一个代理请求消耗10,000个输入token并产生2,000个输出token。按每百万输入token 0.26美元和每百万输出token 2.60美元计算：

这样，100万次请求的推理账单约为7,800美元，不包括重试、嵌入、存储、路由费用或其他服务使用。

避免基于输入和输出token之间任意50:50的比例进行价格比较。RAG和文档分析系统通常生成的输入token远多于输出token。推理和代码生成类应用可能生成更多的输出token。由于输出token通常更昂贵，工作负载使用的token比例可能会影响哪家提供商更便宜。

DeepInfra、Together AI、Fireworks AI、Groq、Novita、OpenRouter和DigitalOcean提供的API在不同程度上支持兼容OpenAI的API端点。这意味着开发人员可以使用不同的base_url来利用OpenAI Python SDK。

以下是一个可复用的示例：

import os
import time
from openai import OpenAI

client = OpenAI(
   api_key=os.environ["INFERENCE_API_KEY"],
   base_url=os.environ["INFERENCE_BASE_URL"],
)

start = time.perf_counter()
first_token_time = None
output = []

stream = client.chat.completions.create(
   model=os.environ["QWEN_MODEL_ID"],
   messages=[
       {
           "role": "system",
           "content": (
               "You are a production reliability assistant. "
               "Return concise, technically accurate recommendations."
           ),
       },
       {
           "role": "user",
           "content": (
               "A Qwen inference endpoint has rising p99 latency while "
               "average latency remains stable. List likely causes."
           ),
       },
   ],
   temperature=0.2,
   max_tokens=400,
   stream=True,
)

for event in stream:
   if event.choices and event.choices[0].delta.content:
       if first_token_time is None:
           first_token_time = time.perf_counter()

       token_text = event.choices[0].delta.content
       output.append(token_text)
       print(token_text, end="", flush=True)

end = time.perf_counter()

print("\n")
print(f"TTFT: {first_token_time - start:.3f} seconds")
print(f"End-to-end latency: {end - start:.3f} seconds")

# Configure it through environment variables rather than placing credentials in source code:
export INFERENCE_API_KEY="your-api-key"
export INFERENCE_BASE_URL="https://provider.example.com/v1"
export QWEN_MODEL_ID="provider-specific-qwen-model-id"

python app.py

从当前提供商的文档中获取特定于提供商的模型 ID 和基础 URL。Qwen3.5-27B 的拼写方式可能并不总是相同。

这种抽象使初始迁移更加容易。然而，对于可移植的生产代码，您还需要做一些额外的工作。不同模型在工具调用格式、推理控制、JSON 强制约束、token 使用跟踪、上下文窗口大小、安全过滤和错误代码等方面可能存在差异。如果您预计会更换提供商，请考虑构建自己的模型网关和提供商无关的评估套件。

OpenRouter 最好被视为一个聚合器和路由层。它为开发者提供了一个统一的 API，以访问由各种底层提供商托管的模型。这在构建需要自动回退、集中计费、快速模型比较或访问多种商业和开源模型的应用时非常有用。

例如，OpenRouter 展示了 Qwen3.5 Plus 具有一百万 token 的上下文窗口，并分别对输入和输出计价。您可以在其 Qwen 模型目录中查看当前模型，包括上下文大小、价格和可用路由。

以下示例通过 OpenRouter 发送 Qwen 请求。它优先选择成本较低的路由，允许在另一个提供商可用时进行回退，并排除可能收集请求数据的端点：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["OPENROUTER_API_KEY"],
    base_url="https://openrouter.ai/api/v1",
)

response = client.chat.completions.create(
    model="qwen/qwen3.5-plus-20260420",
    messages=[
        {
            "role": "user",
            "content": "Explain continuous batching in three sentences."
        }
    ],
    max_tokens=200,
    extra_body={
        "provider": {
            "sort": "price",
            "allow_fallbacks": True,
            "data_collection": "deny"
        }
    }
)

print(response.choices[0].message.content)

与聚合器交互时，对实际处理请求的基础设施的可见性和控制力会降低。必须在路由层和底层提供商层面仔细检查数据处理要求。固定在某个提供商可以提高可预测性，而动态路由则可能提供更高的可用性或更低的价格。

代理系统会反复向模型发出请求，向其发送计划、工具结果、检索到的文档和对话历史。在为这类系统选择提供商时，应重点权衡低首词延迟（TTFT）、可靠的工具调用、结构化输出支持、大上下文窗口、提示缓存和稳定的速率限制。

希望拥有自己的生产基础设施并定制模型的代理开发团队，可以考虑Together AI和Fireworks。如果代理能够产生大量令牌，且成本是主要约束条件，那么DeepInfra可能很有吸引力。如果代理执行顺序步骤且每次模型调用都会带来明显延迟，那么Groq是值得考虑的选择。当代理在提供商故障期间必须保持可用时，OpenRouter可以提供后备方案。

Qwen3.5模型尤其适合面向工具和多模态代理的应用。然而，模型在实际使用工具时的能力应使用您应用程序的具体工具进行测试。基准分数无法可靠地表明模型是否为您的内部函数生成了有效的参数。

构建一个包含失败工具调用、模糊指令、长对话历史、提示注入和出错工具输出的对话评估集。应同时评估任务完成率和每个完成任务的成本，而不是每个令牌的成本。

无服务器推理通常非常适合原型构建、流量模式多变的工作负载，以及不想操作/管理GPU的团队。定价基于使用的令牌数量，由供应商管理批处理、扩展和模型服务。

潜在的缺点包括冷启动、共享容量排队、速率限制、有限的自定义能力以及不太可预测的尾部延迟。这些影响的程度因提供商和服务层级而异。

专用推理为单个组织分配专用容量。当您有持续流量、严格的延迟要求，或者需要应用程序具有可预测的吞吐量时，可以使用此方案。它还可能允许对网络、扩展、可观测性和模型配置进行更多控制。

盈亏平衡点取决于利用率：

专用GPU在高利用率下可能很经济，但在空闲时则成本高昂。无服务器将利用率风险转移给了提供商。

DigitalOcean提供无服务器和专用推理服务。他们按GPU小时提供专用推理，并列出AMD MI300X以及NVIDIA H100、H200和B300的选项。您可以查看DigitalOcean当前的推理定价页面了解配置信息。

如果您需要自定义权重/适配器/量化、私有网络/数据驻留，或固定模型版本/直接控制推理引擎，则应使用自行托管。

RunPod和GPU Droplets是基础设施解决方案，而不是托管的模型端点。您的团队负责选择GPU、部署推理服务器（例如vLLM、SGLang）、配置自动扩展，并管理监控和升级。

一个基本的vLLM部署可以通过兼容OpenAI的端点暴露Qwen：

# 1) Install vLLM (pin a version to avoid surprises)
pip install "vllm>=0.8.4"

# 2) Run vLLM with Qwen3-8B over an OpenAI-compatible HTTP API
export LOCAL_API_KEY="your-local-key"

vllm serve Qwen/Qwen3-8B \
 --host 0.0.0.0 \
 --port 8000 \
 --api-key "$LOCAL_API_KEY" \
 --max-model-len 32768 \
 --gpu-memory-utilization 0.90 \
 --trust-remote-code

# The application can then call it with the same OpenAI client:
# ---------
# Python: call Qwen3-8B via OpenAI client
# ---------

import os
from openai import OpenAI

# Read the same API key used by vLLM; fall back to a default for demos
api_key = os.getenv("LOCAL_API_KEY", "your-local-key")

client = OpenAI(
   api_key=api_key,
   base_url="http://localhost:8000/v1",
)

response = client.chat.completions.create(
   model="Qwen/Qwen3-8B",
   messages=[
       {"role": "user", "content": "Explain continuous batching simply."}
   ],
   temperature=0.2,
   max_tokens=300,
)

print(response.choices[0].message.content)

此示例仅供学习目的，并非可直接用于生产的部署方案。对于生产服务，您还需要为您的服务添加TLS、身份验证、健康检查、指标监控、请求限制、容器安全、多个冗余副本、自动扩缩容、部署回滚、GPU容量规划等功能。

DigitalOcean的GPU Droplets支持这种自管理方法。较低成本的GPU可用于运行较小的量化Qwen模型。对于大型MoE变体，您可能需要多个高内存GPU加速器。DigitalOcean最近推出了1-Click Models，让您可以通过兼容OpenAI的端点快速部署受支持的开源模型。请查看DigitalOcean关于在GPU上托管模型的指南。

不要因为提供商展示了SOC 2徽章就假定其符合您受监管的工作负载要求。合规性取决于服务、合同条款、区域、数据流和配置。

请向每个提供商询问：

• 推理服务是否包含在其SOC 2报告中？
• 他们是否会为HIPAA工作负载签署业务伙伴协议？
• 提示或响应是否会被保留？
• 客户数据是否会用于训练？
• 请求和数据在何处处理和记录？
• 是否提供私有网络和客户管理的密钥？
• 子处理器或路由推理提供商能否访问数据？
• 提供哪些审计日志和删除控制？

如果您使用聚合器，请务必提出额外的问题，因为底层推理将由另一家公司运行。自托管将让您对架构拥有更多控制权，但您的组织将承担安全性、补丁管理和审计的责任。

运行Qwen 3或Qwen 3.5的最佳位置取决于工作负载，而非提供商的整体声誉。

DeepInfra和Novita在成本敏感的推理场景中表现突出。Groq为低延迟需求的交互式应用提供了极具竞争力的性能，但请核实其当前的模型可用性和弃用时间线。如果您的团队需要更高级的服务优化、定制化或专用基础设施，Together AI和Fireworks提供了更成熟的生产环境。OpenRouter可以轻松地将请求路由到多个提供商并实现故障回退，但代价是增加了一个额外的路由层。DigitalOcean提供了从按token计费的无服务器推理到完全专用推理，甚至自管理GPU Droplets的完整服务梯度。RunPod非常适合倾向于自行管理基础设施并运行自有服务栈的团队。

最安全的生产策略是避免长期依赖未经测试的声明。选择特定的模型版本，准备真实的评估数据集，在实际并发水平下对几个提供商进行基准测试，并使用实际的输入-输出token比率估算成本。将您的应用程序保持在兼容OpenAI的内部接口之后。但是，请务必测试工具使用、结构化输出、上下文限制和错误处理方面的提供商特定差异。

随着Qwen推出新一代模型，推理目录将持续变化。因此，可复现的评估流程比任何静态的提供商排名都更有价值。

• Hugging Face上的Qwen模型
• Qwen3.5-27B API参考与定价
• 推理概览：无服务器、预置吞吐量和专用
• 可用的无服务器模型
• 通过无服务器推理和专用部署查询文本模型
• 支持的模型
• 提供商路由与提供商选择