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 新模型
| 参数项 | 具体特性 |
|---|---|
| 架构 | 2.4 万亿参数混合专家模型，每个 Token 约激活 950 亿参数 |
| 输入 / 输出 | 文本输入，文本输出 |
| 上下文窗口 | 总计 262,144 Token（输入 + 输出共用） |
| 最大输出 | 最高 131,072 Token |
| 硬件 | NVIDIA HGX™ B300，NVFP4 量化权重 |
| 价格 | 输入 / 输出分别为每 100 万 Token 2 / 6 美元；缓存输入每 100 万 Token 0.20 美元 |
| 可用方式 | DigitalOcean 无服务器推理 · DigitalOcean 推理路由器 |
| 工具调用 | 原生 Function Calling；服务端网页搜索、网页抓取、多模型融合、知识库检索（RAG）和 MCP |
| 其他支持 | 结构化输出（JSON Schema）、可配置推理强度、异步批量推理 |
关于这个版本。 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，与模型完整名称不同。
ini
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。
对于任何面向最终用户的场景，我们建议开启流式输出：
ini
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：
python
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 里原本用于解析失败后重试的那层逻辑就可以省掉：
lua
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 基础设施上，不需要你自己搭建和维护调用框架。
| 工具 | 作用 |
|---|---|
| Web Search （Public Preview） | 通过 Exa.ai 执行实时网页搜索 |
| Web Fetch （Public Preview） | 通过 Exa.ai 获取网页 URL 和 PDF 内容 |
| 多模型融合 （Public Preview） | 针对同一个任务并行运行最多 8 个分析模型，由 Judge 比较各模型结果，再由外层模型生成一份最终答案。参与分析的模型也可以使用服务端搜索和网页抓取。仅支持 API。 |
| Knowledge Base Retrieval | 在推理过程中查询私有数据源（RAG） |
| MCP | 访问远程 MCP Server，并编排不同工具调用 |
如果你正在做 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 也没有独立复现这些结果。
| Benchmark | Qwen3.8-Max | Opus 4.8 | Fable 5 | GPT-5.6 Sol |
|---|---|---|---|---|
| PaperBench | 93.0 | 80.3 | 88.8 | 90.5 |
| IFBench | 82.8 | 62.2 | 63.5 | 72.7 |
| Terminal-Bench 2.1 | 86.6 | 84.6 | 84.6 | 88.8 |
| SWE-bench Pro | 67.7 | 69.2 | 80.0 | 64.6 |
| GPQA Diamond | 92.6 | 92.0 | 92.6 | 94.1 |
| HLE (no tools) | 43.6 | 45.7 | 53.3 | 47.2 |
领先项包括： 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/秒，没有出现明显性能拐点。
| 输入 Token | TTFT p50 |
|---|---|
| 1,080 | 1.1 s |
| 46,484 | 3.5 s |
| 185,610 | 11.4 s |
| 199,524 | 12.9 s |
| 239,414 | 14.9 s |
| 254,370 | 15.8 s |
一个比较实用的估算公式是：TTFT ≈（输入 Token ÷ 16,000）+ 0.7 秒。
并发情况下的吞吐量
总吞吐量在并发请求数达到 256 之前，基本保持接近线性的增长，同时 TTFT p50 仍然维持在 1 秒左右。在这一区间内，我们没有测到明显饱和点，也就是说，性能上限还在 256 并发以上。
| 并发请求 | TTFT p50 | TTFT p95 | 总输出 Token/s |
|---|---|---|---|
| 1 | 1.12 s | 3.58 s | 9.8 |
| 8 | 0.73 s | 1.33 s | 106 |
| 32 | 1.03 s | 1.76 s | 289 |
| 64 | 0.95 s | 2.23 s | 669 |
| 128 | 1.07 s | 2.76 s | 1,230 |
| 256 | 1.24 s | 3.05 s | 1,937 |
输入约 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，一个比较合理的初始路由策略可以是：
| 更适合路由到 Qwen3.8-2.4T-A95B | 可以考虑其他模型 |
|---|---|
| Agent 和 Tool Use 工作负载 | 高难度纯 SWE 任务（SWE-bench Pro） |
| 严格指令遵循和格式约束 | 前沿纯文本推理（HLE） |
| 成本占主导的大规模工作负载 | 对延迟非常敏感的交互式聊天 |
| 大文档和大型代码库推理 | 任何需要图片或视频输入的任务 |
价格
| 每 100 万 Token | 价格 |
|---|---|
| 输入 | $2.00 |
| 输出 | $6.00 |
| 缓存输入 | $0.20 |
作为对比，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）获取技术支持。