Qwen3.8-2.4T-A95B 部署与性能解析：DigitalOcean 无服务器推理实测

Qwen3.8-2.4T-A95B 现已上线 DigitalOcean 推理引擎。它是从阿里巴巴 Qwen3.8-Max 旗舰模型衍生而来的开放权重纯文本版本：采用混合专家（MoE）架构，总参数量达到 2.4 万亿，每个 Token 大约激活 950 亿参数，主要面向编程、工具调用以及长周期 Agent 任务。根据阿里云公布的 Benchmark，Qwen3.8-Max 旗舰版在 PaperBench（93.0）和 IFBench（82.8）上排名领先，在 Terminal-Bench 2.1 上取得 86.6 分，高于 Claude Opus 4.8 和 Claude Fable 5（两者均为 84.6）；目前还没有针对这一开放权重版本单独公布的公开 Benchmark（详见下文“Benchmark”部分）。Qwen3.8-2.4T-A95B 的标价为每 100 万输入 Token 2 美元、每 100 万输出 Token 6 美元，而 Fable 5 的价格分别为 10 美元和 50 美元。

DigitalOcean 使用 NVIDIA HGX™ B300 GPU，并采用 NVFP4 量化权重来提供这款模型，相关技术工作由 DigitalOcean 与 Inferact 合作完成。你可以通过 DigitalOcean 无服务器推理按量调用，无需自行管理底层基础设施；也可以通过 DigitalOcean 推理路由器使用，将它加入现有模型路由组合，再根据成本、延迟或任务适配度把请求分配给它。注册 DigitalOcean 后即可开始调用。

新注册用户，需要先向DigitalOcean 中国区战略合作伙伴卓普云（aidroplet.com）申请，即可使用 DigitalOcean 平台上的 Claude、GPT 系列商业模型。

快速了解 Qwen 新模型

关于这个版本。 Qwen3.8-2.4T-A95B 是从 Qwen3.8-Max 旗舰模型衍生而来的开放权重纯文本版本，也是 Qwen 目前公开提供的版本。它不支持图片或视频输入。本文引用的 Benchmark 数据来自 Qwen3.8-Max 的纯文本测试结果；我们有意排除了阿里巴巴公布的多模态测试结果，因为这些数据并不适用于当前模型。

Qwen 模型适合做什么？

长周期 Agent 任务。 这是 Qwen 围绕这款模型重点打造的能力，也是最值得选择它的原因。阿里巴巴自己的评测重点放在持续数天的自主运行场景上：包括持续使用工具、根据执行反馈进行自我修正，以及在数百轮交互中保持一致的策略，而不是只做一次性的文本生成。

生产工作流中的指令遵循。 Qwen3.8-Max 旗舰版在 IFBench 上取得 82.8 分，在阿里巴巴对比的所有模型中排名第一，包括 Opus 4.8、Fable 5 和 GPT-5.6 Sol。如果你正在构建需要模型稳定遵守格式约定和约束条件的系统，那么这个指标尤其值得关注。

大文档和大型代码库推理，最高可使用 262K 上下文窗口。

对成本敏感的大规模工作负载。 以 2 / 6 美元的输入输出价格运行前沿级模型，在高请求量场景下明显比其他一些方案更便宜。

快速上手无服务器推理的 Qwen 模型

这个端点兼容 OpenAI API。迁移现有应用时，只需要修改 Base URL 和模型 ID。需要注意的是，DigitalOcean 平台上的模型 ID 是 qwen3.8-max，与模型完整名称不同。

from openai import OpenAI

client = OpenAI(
    base_url="https://inference.do-ai.run/v1",
    api_key="<YOUR_DIGITALOCEAN_INFERENCE_KEY>",
)

response = client.chat.completions.create(
    model="qwen3.8-max",
    messages=[{"role": "user", "content": "Refactor this function for readability: ..."}],
    reasoning_effort="low",
    max_tokens=1024,
)

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

推理强度。 Qwen3.8-2.4T-A95B 会在回答前进行推理，reasoning_effort 支持 low、high 和 xhigh。推理 Token 既会计入输出费用，也会占用上下文窗口，因此对于信息提取、分类、格式转换和路由任务，low 更适合作为默认值；只有在推理过程确实能带来明显价值的任务中，才建议使用 high 或 xhigh。本文后面给出的延迟数据是在没有设置这个参数的情况下测得的，因此反映的是服务端默认设置，而不是 low。

对于任何面向最终用户的场景，我们建议开启流式输出：

stream = client.chat.completions.create(
    model="qwen3.8-max",
    messages=[{"role": "user", "content": "Walk me through the basics of stock trading"}],
    max_tokens=1024,
    stream=True,
)

for chunk in stream:
    delta = chunk.choices[0].delta
    if delta.content:
        print(delta.content, end="", flush=True)

调用工具

Function Calling 使用标准 OpenAI 格式：模型返回一个 tool_calls 列表，你的代码执行对应函数，然后再把执行结果回传给模型，由它生成最终答案。

下面是一套完整、可实际运行的流程示例——使用 Open-Meteo，不需要 API Key：

import json
import urllib.parse
import urllib.request


def get_weather(city: str) -> str:
    """Look up current conditions for a city."""
    geo = json.load(urllib.request.urlopen(
        "https://geocoding-api.open-meteo.com/v1/search?"
        + urllib.parse.urlencode({"name": city, "count": 1})
    ))
    if not geo.get("results"):
        return "No location found for %r." % city

    loc = geo["results"][0]
    wx = json.load(urllib.request.urlopen(
        "https://api.open-meteo.com/v1/forecast?"
        + urllib.parse.urlencode({
            "latitude": loc["latitude"],
            "longitude": loc["longitude"],
            "current": "temperature_2m,wind_speed_10m",
        })
    ))

    now = wx["current"]
    return "%s, %s: %s°C, wind %s km/h" % (
        loc["name"], loc.get("country", ""),
        now["temperature_2m"], now["wind_speed_10m"],
    )


tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Get current weather for a city",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    },
}]

messages = [{"role": "user", "content": "Is it jacket weather in Lisbon right now?"}]

resp = client.chat.completions.create(
    model="qwen3.8-max", messages=messages, tools=tools, max_tokens=512
)
msg = resp.choices[0].message

if msg.tool_calls:
    messages.append(msg)                       # keep the model's request in history
    for call in msg.tool_calls:
        args = json.loads(call.function.arguments)
        result = get_weather(**args)           # your function actually runs

        messages.append({
            "role": "tool",
            "tool_call_id": call.id,           # must match the call
            "content": result,
        })

    final = client.chat.completions.create(
        model="qwen3.8-max", messages=messages, max_tokens=512
    )
    print(final.choices[0].message.content)

模型会判断 get_weather 是合适的函数，从一句完全没有出现“查询天气”的问题中提取出 {"city": "Lisbon"}，读取函数返回的实时温度，再回答用户真正关心的问题——现在去里斯本要不要带外套。

这里有两个细节一定要处理正确：需要把 Assistant Message 本身追加到消息历史里，而不是只追加工具返回结果；同时，每条 Tool Message 都必须带上与对应调用匹配的 tool_call_id。漏掉其中任何一个，后续请求都可能失败，或者模型会忘记自己刚刚调用过什么。

结构化输出

传入 JSON Schema，就可以直接得到符合 Schema 的 JSON，这样很多 Pipeline 里原本用于解析失败后重试的那层逻辑就可以省掉：

resp = client.chat.completions.create(
    model="qwen3.8-max",
    messages=[{"role": "user", "content": "Extract the invoice fields from: ..."}],
    reasoning_effort="low",
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "invoice",
            "schema": {
                "type": "object",
                "properties": {
                    "vendor": {"type": "string"},
                    "total": {"type": "number"},
                    "due_date": {"type": "string"},
                },
                "required": ["vendor", "total", "due_date"],
            },
            "strict": True,
        },
    },
)

这是真正的约束解码，不只是一个提示。我们使用了一条故意要求模型违反 Schema 的 Prompt 进行测试：让它输出枚举范围之外的值、在 Schema 要求整数的位置返回小数、增加禁止字段，并且在 JSON 前先写一段自然语言。附加 Schema 后，每次测试的输出都符合约束；使用完全相同的 Prompt 但不加 Schema 时，每一次都会违反约定。因此，这类场景下确实可以去掉原本的解析失败重试逻辑。

还有一点 Token 预算需要注意：推理 Token 和最终答案共用同一个 max_tokens 配额。在默认推理强度下，即使只是生成一个很小的 Schema 对象，512 Token 的预算也可能被推理过程耗尽，最终返回截断的 JSON。因此，使用 response_format 时，建议像上面的示例一样搭配 reasoning_effort="low"，并设置足够宽裕的 max_tokens。

服务端工具

Qwen3.8-2.4T-A95B 可以调用 DigitalOcean 提供的服务端工具。这些工具运行在 DigitalOcean 基础设施上，不需要你自己搭建和维护调用框架。

如果你正在做 Agent，MCP 是最值得优先关注的能力。 一款针对长周期自主任务优化的模型，可以直接连接到你已经部署好的 MCP Server，同时不需要自己运维额外的工具调用 Harness——这正是这次模型上线想要解决的一类典型场景。

这些工具运行在 DigitalOcean 侧。前面快速上手部分展示的 Function Calling 工作方式不同：模型负责返回调用请求，而真正的函数由你的应用执行。Qwen3.8-2.4T-A95B 同时支持这两种机制，而且可以在同一次请求中组合使用。

DigitalOcean 模型目录里还有一些工具是特定平台或模型专用的，因此 Qwen3.8-2.4T-A95B 暂不支持：Tool Search、Computer Use、Bash/Local Shell、Text Editor 和 Apply Patch。

Benchmark

下面的数据来自阿里云公开发布的 Qwen3.8-Max Benchmark，也就是当前开放权重版本所衍生自的旗舰模型。这里仅保留纯文本 Benchmark。目前还没有针对 Qwen3.8-2.4T-A95B 开放权重版本单独发布的公开 Benchmark，因此这些结果更适合看作参考，而不是精确代表当前版本；等独立机构发布针对开放权重版本的数据后，我们会更新这一部分。DigitalOcean 也没有独立复现这些结果。

领先项包括： PaperBench 和 IFBench，而且优势都比较明显。

相对落后的项： SWE-bench Pro，其中 Fable 5 的优势比较明显（80.0 对 67.7）；另外在 HLE 的纯文本推理上也不占优势。如果你的工作负载主要是高难度纯软件工程任务，或者追求最前沿的纯文本推理能力，建议在正式采用之前先针对自己的任务做 Benchmark。

关于这些结果还有一点需要说明：该模型的一些最强公开数据来自 Qwen 自己的内部 Benchmark，而且由 Qwen 自家的 Judge Model 评分。因此这里没有引用这些结果，只保留了第三方 Benchmark。

B300 上的 NVFP4：DigitalOcean 是如何部署这款模型的？

为什么使用 4-bit呢？

2.4 万亿参数的模型规模已经非常大，FP8 版本无法装入单节点。使用 NVFP4 量化之后，模型权重可以在 B300 单节点上完成加载，从而彻底去掉 Serving 路径里的跨节点 Expert Routing——拓扑结构更简单，关键路径中不再需要节点间通信，而且成本结构也更合理，这些优势最终也可以体现在价格上。这项工作由 DigitalOcean 与 Inferact 合作完成，基础权重来自 Qwen 在 Hugging Face 开放发布的模型。

质量方面。 DigitalOcean 对量化版本进行的一次内部抽样测试，在 GPQA Diamond 上得到 88 分，而阿里巴巴公开的 Qwen3.8-Max 旗舰模型成绩为 92.6。需要注意，这两个数字来自不同评测栈和不同 Harness 配置，而且差异同时包含两层变量——旗舰模型与开放权重版本的区别，以及未量化版本与 NVFP4 版本的区别。因此，这只能作为一个参考数据点，而不是严格的对照实验。同时，它只覆盖了模型相对较弱的一类 Benchmark（纯文本推理），并没有覆盖模型更擅长的领域。我们仍然选择公开这个数据，因为一个诚实的数字总比完全没有数据更有参考价值。Qwen3.8-2.4T-A95B 是开放权重模型，其他平台也可以部署它；如果你要横向比较不同平台，建议要求对方公开和这里相同的信息：量化格式、使用硬件、量化版本质量数据，以及带日期的性能测试结果。

实测性能

下面的数据于 2026 年 8 月 12 日测得：单客户端通过公网访问生产端点，采用带唯一前缀的 Streaming Request（因此不会命中 Prompt Cache），并且没有设置 reasoning_effort，所以反映的是服务端默认设置。这些数据更接近开发者真实使用时观察到的结果，因此包含公网网络延迟，可以视作性能下限而不是上限。不同测试 Session 之间的总吞吐量存在一定波动，因此这些数据应该被看作一次性能快照，而不是服务等级承诺。

不同输入长度下的首 Token 延迟

Prefill 在整个上下文范围内基本保持线性增长，大约为 16,000 Token/秒，没有出现明显性能拐点。

一个比较实用的估算公式是：TTFT ≈（输入 Token ÷ 16,000）+ 0.7 秒。

并发情况下的吞吐量

总吞吐量在并发请求数达到 256 之前，基本保持接近线性的增长，同时 TTFT p50 仍然维持在 1 秒左右。在这一区间内，我们没有测到明显饱和点，也就是说，性能上限还在 256 并发以上。

输入约 1,080 Token，输出约 128 Token。在 256 并发下累计完成 1,536 次请求，错误数为 0。

单路生成速度

单路 Streaming 的 Token 间延迟中位数，在并发 1 时为 108 ms，并发 8 时为 115 ms，也就是每条流大约 8～9 Token/秒，并发增加后基本保持稳定。

这就是这款模型比较真实的性能特征：单路生成速度并不算特别快，而整体容量主要通过并发扩展，而不是靠单流速度提升。对于 Agent Pipeline、批处理和后台任务，这种取舍是合理的；如果是对延迟非常敏感的实时聊天场景，建议先根据自己的 UX 延迟预算做 Benchmark。

如何使用 262K 上下文窗口

262,144 Token 是模型训练时的原生上下文长度。虽然通过 Context Extension 技术，架构理论上可以扩展到略高于 100 万 Token，但 DigitalOcean 有意提供原生上下文窗口：扩展上下文意味着让模型运行在原生训练配置之外，同时也会破坏当前单节点 Serving 路径，而后者正是保持现有延迟和价格的重要原因（参见上面的“B300 上的 NVFP4”）。如果你的工作负载真的要求单次请求超过 262K，那么当前这个版本并不适合；对于绝大多数场景，包括带有大型稳定 Prefix 的 Agent Loop，原生上下文加 Prompt Cache 往往是更好的取舍。

实际测试中：254K Token 输入加 128 Token 输出可以正常完成；但相同输入如果再配置很大的 max_tokens 就无法完成。Prefill 成本会随着输入长度线性增加（见上文），所以满上下文窗口请求大约需要 16 秒之后才能看到第一个 Token。

如果你的 Agent Loop 会在多轮交互中不断重复一个较大的稳定 Prefix，这也是非常常见的模式，可以参考后面“价格”部分关于 Prompt Cache 的说明。

与推理路由器配合使用

Qwen3.8-2.4T-A95B 已经可以通过 DigitalOcean 推理路由器使用，因此可以直接加入现有模型路由组合。根据目前公布的 Benchmark，一个比较合理的初始路由策略可以是：

价格

作为对比，Claude Fable 5 的输入价格为 10 美元，输出为 50 美元。对于输出量较大的 Agent 工作负载——单个任务可能生成数十万 Token——这种价格差异会很快被放大。

在此基础上，Prompt Cache 每 100 万 Token 只需 0.20 美元，是另一个非常重要的降本手段：如果 Agent Loop 会在多轮请求中重复较大的稳定 Prefix，相当于输入价格可以打到十分之一。 DigitalOcean AI 推理云平台上所有模型的完整价格可以查看推理价格页面。

批量推理

对于不需要立即得到结果的工作负载，批量推理同样支持 Qwen3.8-2.4T-A95B，可以异步处理大量请求：上传输入文件、创建任务、轮询完成状态，最后下载结果。同一个 API 也支持查看和取消任务。

这和这款模型的性能特点很匹配。单路生成速度只有大约 8～9 Token/秒，但在并发请求下总吞吐量可以扩展到约 1,900 Token/秒。因此，对于更看重整体吞吐量的工作，例如批量分类、文档信息提取、数据集生成和离线评估，与其逐条发送同步请求，不如交给 Batch。

如果你正在考虑不同推理方式怎么选，可以参考我们发布在卓普云官网的这篇《无服务器推理、专属推理和批量推理对比》。

开始使用

Qwen3.8-2.4T-A95B 现已上线 DigitalOcean 无服务器推理。注册 DigitalOcean，创建推理密钥，把 OpenAI Client 指向 https://inference.do-ai.run/v1，并将 qwen3.8-max 作为模型名称即可开始调用。

接下来还可以：

• 在支持模型列表中查看平台当前提供的所有模型
• 在推理价格页面中查看各模型费率
• 通过无服务器推理、专属推理和批量推理对比选择合适的部署方式
• 阅读 Qwen 官方的 Qwen3.8-Max 发布文章，了解模型训练和评测细节
• 如果你更希望自行部署，可以从 Hugging Face 下载开放权重

常见问题

什么是 Qwen3.8-2.4T-A95B？

Qwen3.8-2.4T-A95B 是阿里云在 2026 年 8 月发布的旗舰级开源大语言模型。它是从 Qwen3.8-Max 旗舰模型衍生而来的开放权重纯文本版本，采用混合专家架构，总参数量 2.4 万亿，每个 Token 大约激活 950 亿参数，主要面向编程、工具调用和长周期 Agent 任务。在 DigitalOcean 上，它以纯文本输入、纯文本输出的形式提供。

Qwen3.8-2.4T-A95B 在 DigitalOcean 上的模型 ID 是什么？

DigitalOcean 无服务器推理中的模型 ID 是 qwen3.8-max。调用时把这个字符串传给 model 参数即可——平台 ID 和 Hugging Face 上的完整模型名称 Qwen/Qwen3.8-2.4T-A95B 不同。

Qwen3.8-2.4T-A95B 在 DigitalOcean 上的上下文窗口有多大？

总共 262,144 Token，由输入、推理和输出共同使用。API 把它当成同一个总预算——如果超出限制，会返回 HTTP 400，并提示 max_model_len=max_total_tokens=262144，同时给出实际 Token 数量。系统不会静默截断，因此设置输出 Token 预算时，需要和输入 Token 一起考虑。

Qwen3.8-2.4T-A95B 支持图片或视频吗？

不支持。Qwen3.8-2.4T-A95B 是从 Qwen3.8-Max 旗舰模型衍生而来的开放权重纯文本版本，也是 DigitalOcean 当前提供的版本。本文引用的 Benchmark 都是纯文本测试；阿里巴巴针对旗舰模型公布的多模态结果并不适用于它。

Qwen3.8-2.4T-A95B 在 DigitalOcean 上多少钱？

每 100 万输入 Token 2 美元，每 100 万输出 Token 6 美元，缓存输入每 100 万 Token 0.20 美元。作为对比，Claude Fable 5 的输入价格为 10 美元，输出为 50 美元。

Qwen3.8-2.4T-A95B 有多快？

根据 DigitalOcean 在 2026 年 8 月 12 日进行的测试，在输入约 1,000 Token 时，首 Token 延迟大约为 1.1 秒；Prefill 速度大约为 16,000 Token/秒，因此 TTFT 可以近似估算为（输入 Token ÷ 16,000）+ 0.7 秒。单路生成速度大约为 8～9 Token/秒，而在 256 并发请求时，总吞吐量可以扩展到约 1,900 Token/秒，而且测试中还没有达到饱和点。

Qwen3.8-2.4T-A95B 支持 Function Calling 和工具调用吗？

支持。它可以通过标准 OpenAI tools 参数使用原生 Function Calling，同时支持 DigitalOcean 的服务端工具，包括网页搜索、网页抓取、多模型融合、知识库检索和 MCP。这两类机制也可以在同一次请求中组合使用。

Qwen3.8-2.4T-A95B 支持结构化输出吗？

支持，而且是真正的 Schema 强制约束。通过 response_format 传入 JSON Schema 后，输出会遵循对应 Schema——DigitalOcean 使用一条明确要求模型违反 Schema 的 Prompt 做过测试，约束输出每次都能符合规则。需要注意，推理 Token 和 max_tokens 共用同一预算，所以使用 Schema 时建议同时设置 reasoning_effort="low" 并给出足够大的 Token 上限。

什么是 NVFP4 量化？

NVFP4 是 NVIDIA Blackwell GPU 原生支持的一种 4-bit 浮点格式。DigitalOcean 使用 NVFP4 量化权重来部署 Qwen3.8-2.4T-A95B，是因为 2.4 万亿参数模型的 FP8 版本无法装入单节点；使用 4-bit 后，可以在 HGX B300 单节点内加载模型，从而去掉 Serving 路径里的跨节点 Expert Routing。

我可以自己部署 Qwen3.8-2.4T-A95B 吗？

可以。Qwen 已经在 Hugging Face 开放发布模型权重。不过，自托管一个 2.4 万亿参数 MoE 模型需要相当可观的 GPU 资源，这也是托管式无服务器端点存在的主要价值之一。

Qwen3.8-2.4T-A95B 支持批处理吗？

支持。它可以配合 DigitalOcean 批量推理处理异步、高吞吐量工作负载。对于批量分类、文档提取和离线评估等任务，相比逐条同步发送请求，Batch 通常更合适。

最后，DigitalOcean 无服务器推理还支持 Claude 系列、GPT 系列、DeepSeek、Qwen、Llama、Mistral、GLM、Kimi 等多种主流大模型，并可通过一个 API 统一接入，无需自行部署和管理 GPU。如果你想进一步了解模型接入、提示词缓存配置或推理成本优化方案，欢迎联系卓普云（aidroplet.com）获取技术支持。