dots3多模态MoE模型部署评测：280B总参数、16B激活与512K长上下文

如果只看参数表dots3 的关键词是三组总参数 280B、激活参数 16B、上下文 512K。再加上“开源”“多模态”“Agent”三个标签这基本就是一个“单卡想跑又不太敢跑跑起来又想知道能不能当生产模型用”的典型命题。先说结论方向这种 MoE 架构模型的竞争力不在“总参数很大”而在“每次推理只激活 16B 却拿到接近大模型的智能水平”。所以评估时不只要看能不能部署还要看三件事长上下文是不是真的“长了还能用”而不是一长就丢信息多模态输入是只在图片问答上能用还是能稳定支撑文档、截图、UI 理解Agent 场景下的工具调用、结构化输出、多轮任务跟踪稳不稳定。这篇文章不预设“我手头有 8 卡 A100 跑完了一遍”而是按照一份可复用的评估流程来拆解先看规格再准备环境再分别从多模态、长上下文、Agent 三个方向做功能测试最后给接口接入和批量任务的建议。如果你正在关注小红书开源的 dots3、MoE 大模型、多模态模型或 Agent 开发这篇可以直接收藏。1. 核心能力速览能力项说明项目类型多模态大语言模型基于 MoEMixture of Experts架构开源团队小红书总参数量约 280BMoE 总参数激活参数量约 16B单次推理实际激活上下文长度512K官方宣传值多模态能力支持图像输入可做视觉理解类任务Agent 能力面向工具调用、结构化输出等 Agent 场景优化开源状态以正式开源仓库的 Release 说明为准推理硬件必须结合权重精度、量化方式、推理框架和 batch 大小实测不能只看激活参数启动方式官方仓库推荐方式常见为 vLLM / SGLang / Transformers 等推理框架启动接口 API一般通过 OpenAI 兼容接口暴露具体路径以官方服务端实现为准批量任务支持通过接口批量提交但要注意显存和 KV Cache 规划这里要特别提醒MoE 的“激活 16B”不等于“部署只需要 16B 模型的内存”。280B 总参数意味着权重文件整体依然很大只是单次前向计算只触发部分专家。实际显存占用要看权重是否分片、是否量化、KV Cache 设多大、并发请求多少不能拿激活参数直接换算。2. 适用场景与使用边界2.1 适合谁需要“一个模型同时处理文本和图像”的应用开发者。需要超长上下文做代码仓库分析、长文档问答、日志审计的团队。正在做 Agent 框架选型希望模型原生支持工具调用的人。关注 MoE 路线想用较小推理成本换更强能力的算法工程师。2.2 能解决什么问题多模态模型解决的是“输入混合内容”的问题。比如一张产品截图加一段描述让模型输出结构化信息或者一份 PDF 页面截图加一列问题让模型做表格理解。传统做法是把 OCR、物体识别、文本分类拆成多个子模型而多模态大模型可以一步完成。Agent 化解决的是“模型输出之后怎么办”的问题。模型不只返回文本还可以输出工具调用参数由外部系统执行搜索、查数据库、调用 API再把结果回传给模型继续推理。dots3 这类模型如果在功能调用上做过针对性训练就能直接接到 Agent 框架里用。长上下文解决的是“输入材料太大”的问题。512K 理论上能装下几十万字但真正有意义的是在长输入中依然能定位关键信息而不是开头读完就忘。2.3 不适合什么场景低延迟高并发场景如果单机推理吞吐跟不上可能要引入多卡分布式甚至多机推理。对数据安全要求极高、必须纯离线私有化部署又只有单张消费级显卡的环境。需要确定性规则保证的业务逻辑例如金额计算、法务条款强校验这类场景更适合“小模型规则引擎”而不是完全交给大模型。实时音视频流处理如果模型没有原生视频输入能力就不要硬接。2.4 使用边界与合规提醒开源模型不等于可以无限制商用使用前确认仓库许可证、模型权重许可证和官方附加条款。处理图片、PDF、聊天记录时需要确认内容来源合法尤其是涉及人脸、隐私、受版权保护的素材。Agent 工具调用的目标系统必须有访问控制防止模型输出被外部恶意利用。使用社交平台内容做评估或微调时注意遵守平台规则和用户授权要求。3. 本地部署环境准备由于 dots3 的总参数达到 280B部署前先不要急着执行启动命令而是把环境和权重情况摸清楚。下面是一份通用环境清单具体版本以官方仓库 README 为准。3.1 基础环境检查检查项建议操作系统Linux 优先Ubuntu 22.04 / 24.04 是常见选择GPU 驱动使用最新稳定版 NVIDIA 驱动并用nvidia-smi确认CUDA按推理框架要求安装一般选择 CUDA 11.8 或 12.xPython建议 3.10 / 3.11避免过旧版本与最新依赖冲突磁盘空间先检查权重文件总大小预留至少 1.5 倍空间CPU 内存权重加载阶段和 CPU offload 阶段需要较大内存建议不低于 64GB具体看部署方式推理框架vLLM、SGLang、Hugging Face Transformers 任选其一按仓库推荐为准3.2 显存规划思路关键点是不能用“激活 16B”直接判断显存。正确做法是下载权重后先看文件总大小。如果全部模型权重是 FP16/BF16大致能估算完整加载所需显存。如果官方提供量化版本例如 FP8、INT8、AWQ、GPTQ显存占用会明显下降但要看推理框架是否支持。如果单卡放不下考虑张量并行或多卡推理。对超长上下文KV Cache 是隐藏显存杀手。不要一上来就开 512K先用 4K 或 8K 跑通再逐步加长。当前不确定官方权重格式和推荐切分方式因此“单卡最大能跑多少上下文”必须在本机用真实配置测试。可以先运行下面命令检查 GPU 基础状态nvidia-smi python -c import torch; print(torch.__version__, torch.cuda.is_available())3.3 Python 环境准备建议先建一个独立的虚拟环境或 conda 环境避免和其他项目依赖冲突。conda create -n dots3-env python3.11 -y conda activate dots3-env pip install --upgrade pip然后再根据官方文档安装对应推理框架例如pip install vllm或者pip install sglang如果只是为了临时验证权重加载也可以安装 Transformerspip install transformers accelerate sentencepiece依赖安装顺序建议是先装 PyTorch再装推理框架再装辅助库。遇到版本冲突时优先看官方 requirements 文件。4. 模型下载与权重目录规划4.1 目录结构建议模型下载和大文件管理要提前规划不要把权重散落在临时目录里。dots3/ ├── models/ │ └── dots3-weights/ # 模型权重目录 ├── outputs/ # 测试输出 ├── logs/ # 启动日志 ├── inputs/ │ ├── images/ # 多模态测试图片 │ └── documents/ # 长文本测试材料 └── scripts/ ├── start_server.sh └── test_api.py4.2 使用 Hugging Face CLI 下载如果官方仓库发布在 Hugging Face可以使用命令行下载pip install huggingface_hub huggingface-cli download \ --repo-type model \ --resume-download \ 你的组织名/dots3-weights \ --local-dir ./models/dots3-weights如果仓库体积很大可以先只下载配置文件检查分片情况huggingface-cli download \ --repo-type model \ 组织名/dots3-weights \ config.json检查 config.json 中的num_experts、num_experts_per_token、architectures、vocab_size等字段能看出模型结构是不是标准 MoE以及当前权重需要怎样的加载方式。有些模型平台也支持 Git LFS 下载但面对超大权重时断点续传体验不如专用下载工具。如果下载速度不稳定建议开代理后使用HF_ENDPOINT镜像环境变量但本文不做具体代理配置说明请根据你所在网络环境自行选择合规下载方式。5. 推理服务启动测试5.1 通过 vLLM 启动 OpenAI 兼容服务vLLM 是目前大模型部署中最常见的推理框架之一特点是高吞吐和 PagedAttention。下面是通用启动命令模板实际参数需要按模型权重路径和框架版本调整python -m vllm.entrypoints.openai.api_server \ --model ./models/dots3-weights \ --task generate \ --dtype bfloat16 \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --port 8000如果显存不够完整加载 280B 权重需要确认框架是否支持多卡张量并行python -m vllm.entrypoints.openai.api_server \ --model ./models/dots3-weights \ --tensor-parallel-size 4 \ --dtype bfloat16 \ --max-model-len 32768 \ --port 8000这里先把--max-model-len设成 32768不要一上来就跑 512K。原因有两个超长上下文的 prefill 耗时和显存占用会非常夸张如果短上下文都没测稳定直接长文本会很难定位问题。等 32K 跑通后再根据显存逐步调大。5.2 启动后的健康检查服务启动后先看进程日志里有没有Uvicorn running on http://0.0.0.0:8000类似输出。然后用以下命令确认接口是否响应curl http://127.0.0.1:8000/v1/models如果正常会返回模型名称和元信息。此时再跑一个最基础的文本生成测试curl http://127.0.0.1:8000/v1/completions \ -H Content-Type: application/json \ -d { model: 本机加载的模型名, prompt: 你好请用一句话介绍你自己。, max_tokens: 100, temperature: 0.7 }5.3 如果使用 Transformers 做最小加载测试不想启动复杂服务时可以先做一个最小化加载测试确认权重格式没问题。from transformers import AutoModelForCausalLM, AutoTokenizer model_dir ./models/dots3-weights tokenizer AutoTokenizer.from_pretrained(model_dir, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_dir, device_mapauto, torch_dtypeauto, trust_remote_codeTrue, ) input_text 测试多模态和长上下文的第一个问题。 inputs tokenizer(input_text, return_tensorspt) output model.generate(**inputs, max_new_tokens64) print(tokenizer.decode(output[0], skip_special_tokensTrue))注意MoE 模型在device_mapauto下可能会触发 CPU 卸载速度会极慢。这个脚本只用来验证权重能否加载和 tokenizer 是否匹配真正测试效率要用 vLLM、SGLang 或者 TGI。5.4 如果端口被占用启动时如遇到端口冲突可以换端口python -m vllm.entrypoints.openai.api_server \ --model ./models/dots3-weights \ --port 8001确认端口lsof -i :8000如果之前的进程没有退出先停进程或 kill 残留进程pkill -f vllm6. 多模态能力功能测试dots3 是多模态模型只测文本生成没有意义。多模态测试重点覆盖四类任务图片内容描述图片中的文字识别与信息抽取截图理解与界面分析图文混合输入问答。6.1 图片内容描述测试准备一张包含明确物体、场景、文字信息的图片调用接口import base64 import requests def encode_image(image_path): with open(image_path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) image_path ./inputs/images/test_chart.png image_base64 encode_image(image_path) payload { model: 本机加载的模型名, messages: [ { role: user, content: [ {type: image_url, image_url: {url: fdata:image/png;base64,{image_base64}}}, {type: text, text: 请详细描述这张图的主要内容并识别图中所有文字。} ] } ], max_tokens: 512, } response requests.post( http://127.0.0.1:8000/v1/chat/completions, jsonpayload, timeout120, ) print(response.json()[choices][0][message][content])判断重点模型是否把图中的文字完整识别出来描述是否和画面内容一致是否混淆不同区域的信息如果是表格图能不能按行列关系输出。6.2 视觉问答与表格结构测试输入一张表格截图要求输出 Markdown 或 JSON{ 请求文本: 请把图中的表格转为 Markdown不要遗漏任何列。 }不要只问“这是什么”要强制结构化输出。比如请把这张表格输出为 JSON 数组字段名使用表头原词数字不要格式化。如果看不清请输出 unknown。预期结果是结构化且字段逐一对应。如果模型漏列或数字错位常见原因是图片分辨率不够或表格太密集可以适当切图后分块识别。6.3 多模态测试通过标准测试项通过标准物体描述能准确说出主要物体和空间关系OCR印刷体文字基本全部识别正确表格结构化行列信息不丢失能生成可解析结构截图理解能根据截图判断操作流程和页面状态图文推理能结合图片内容和问题做出正确推断常见失败原因图片被压缩太狠目标区域太小输入分辨率超过模型支持范围请求格式不支持多图拼接。7. 512K 长上下文测试长上下文测试不能只靠“给 50 万字再问一个问题”来验收这样很难判断模型是否真的在长文本中定位信息。建议按下面分层验证。7.1 短上下文基线先跑一个 4K 到 8K 的基础问答确认模型在普通输入下逻辑稳定再拉长。否则长上下文出错你无法判断是长文本能力问题还是模型本身质量问题。7.2 关键信息定位测试准备一份长文档比如 100 页技术手册在文档中间位置埋入一个冷门数字第 200 行附近提到“当前服务超时阈值是 3.5 秒。”然后把整份文档作为上下文问当前服务超时阈值是多少秒如果模型能从长文本里准确找到“3.5 秒”说明检索能力可用。7.3 多信息交叉测试比单一信息定位更严格的是交叉验证。在长文档开头给出用户名文档中部给出用户订单号文档末尾给出退款状态然后让模型综合回答“处理这笔订单需要联系谁”。这能测试模型是否在长上下文中保持多跳推理。7.4 长文本内容一致性测试把长文本切成多段后让模型对全文做摘要再把摘要和原文的关键段落对比。重点不是看摘要句子漂不漂亮而是看关键实体、数字、结论是否被保留。7.5 长上下文显存观察长文本 prefill 阶段显存会剧烈波动。建议在做长上下文测试时开一个窗口持续观察watch -n 1 nvidia-smi如果显存被占满或 OOM优先降低--max-model-len从 512K 降到 128K 或 32K减小长文档长度开启 chunked prefill如果框架支持用更低精度和量化版本减少并发请求。长上下文宣传参数是一回事能不能稳定跑起来是另一回事。更稳妥的判断是先用 16K 和 32K 验证业务效果再评估 128K 以上是否有必要。因为上下文越长KV Cache 开销越大单请求成本和延迟都会明显上升。8. Agent 与工具调用验证Agent 场景最核心的不是“模型能不能聊天”而是“模型能不能输出符合工具定义的参数并且在多轮中准确维护任务状态”。8.1 工具调用格式一个标准的工具调用流程是这样系统给模型工具列表模型根据对话内容选择某个工具模型输出结构化参数Agent 框架执行工具执行结果返回给模型模型总结结果或继续下一步。8.2 最小工具调用测试用 OpenAI 兼容接口调用时先构造一个简单工具比如查询天气curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: 本机加载的模型名, messages: [ {role: user, content: 北京现在多少度} ], tools: [ { type: function, function: { name: get_weather, description: 查询城市当前天气温度和风力, parameters: { type: object, properties: { city: {type: string, description: 城市名}, date: {type: string, description: 日期} }, required: [city] } } } ], tool_choice: auto }成功标准是模型返回类似这样的结构而不是直接编造天气{ role: assistant, tool_calls: [ { function: { name: get_weather, arguments: {\city\: \北京\, \date\: \今天\} } } ] }如果模型直接把城市和天气编出来了说明没有按工具调用训好需要看是否要调整提示词或者使用更明确的tool_choice。8.3 多轮工具调用压力测试Agent 真实的难点是多轮对话里工具结果怎么回流。测试时构造这样的流程第一轮调用查天气把工具返回结果作为消息追加再问“那上海呢”看模型能不能再次触发get_weather。如果模型在多轮后忘记工具格式或把上一轮城市当成上海需要排查上下文是否被工具结果冲掉工具描述是否太长messages 结构中 role 是否设置正确是否使用了系统提示词来约束调用策略。8.4 结构化输出Agent 不只是工具调用还经常需要结构化输出。测试时可以让模型输出 JSONimport requests payload { model: 本机加载的模型名, messages: [ {role: user, content: 把这段描述整理成 json订单状态是已发货物流单号是 SF123456预计明天到达。} ], response_format: {type: json_object}, max_tokens: 256, } response requests.post( http://127.0.0.1:8000/v1/chat/completions, jsonpayload, timeout60, ) content response.json()[choices][0][message][content] print(content)重点检查JSON 是否能被json.loads()直接解析字段名是否稳定。如果模型经常输出 JSON 前后有多余文字说明解码策略需要调优或者需要换更强的结构化约束方式。8.5 Agent 场景通过标准检查点通过标准工具选择对用户意图能选对工具参数抽取必填参数都能从对话中抽取多轮跟踪上一轮工具结果能用于下一轮判断拒答工具不适合当前问题时能明确拒绝不硬调用JSON 输出可直接被程序解析不需要正则硬清洗9. 接口 API 调用与批量任务接法如果你关心的是“模型能不能接到自己的 Agent 或批处理脚本里”那么模型开不开源是一件事API 兼不兼容是另一件事。一般本地推理框架会提供 OpenAI 风格兼容接口但具体路由和参数需要通过/v1/models或文档确认。9.1 文本补全接口调用import requests url http://127.0.0.1:8000/v1/completions payload { model: 本机加载的模型名, prompt: 请输出 5 条用于长文本测试的问题。, max_tokens: 256, temperature: 0.3 } response requests.post(url, jsonpayload, timeout300) print(response.status_code) print(response.json()[choices][0][text])9.2 Chat Completion 调用import requests url http://127.0.0.1:8000/v1/chat/completions def chat(messages, toolsNone): payload { model: 本机加载的模型名, messages: messages, max_tokens: 1024, temperature: 0.3, } if tools: payload[tools] tools payload[tool_choice] auto resp requests.post(url, jsonpayload, timeout300) return resp.json() messages [ {role: system, content: 你是查询助理调用工具回答问题。}, {role: user, content: 查一下苹果今日股价。} ] result chat(messages) print(result[choices][0][message])9.3 批量任务设计如果要用 dots3 处理批量文档或图片不建议直接用 for 循环一条条同步调用。原因是超长上下文和多模态输入的单条耗时很高同步等待会浪费大量时间。建议用任务队列import json import time import requests from concurrent.futures import ThreadPoolExecutor, as_completed API_URL http://127.0.0.1:8000/v1/chat/completions MODEL_NAME 本机加载的模型名 def process_one(item): text item[text] payload { model: MODEL_NAME, messages: [ {role: user, content: f请对下面内容做摘要\n{text}} ], max_tokens: 512, temperature: 0.2, } try: resp requests.post(API_URL, jsonpayload, timeout600) resp.raise_for_status() return {id: item[id], ok: True, result: resp.json()} except Exception as e: return {id: item[id], ok: False, error: str(e)} tasks [ {id: 1, text: 这里放第一份长文档}, {id: 2, text: 这里放第二份长文档}, ] results [] with ThreadPoolExecutor(max_workers2) as pool: future_map {pool.submit(process_one, item): item for item in tasks} for future in as_completed(future_map): results.append(future.result()) for r in results: print(json.dumps(r, ensure_asciiFalse, indent2))注意并发数不要一开始就拉满。多模态模型和长上下文模型对显存非常敏感先并发 1 到 2 个请求观察显存和响应时间再逐步增加。9.4 批处理失败重试策略离线批处理建议遵循三条原则记录每个任务的输入、输出日志失败任务单独重试不要整批重跑设置超时时间防止某个请求卡住整个队列。def run_with_retry(payload, max_retries3): for attempt in range(max_retries): try: resp requests.post(API_URL, jsonpayload, timeout300) if resp.status_code 200: return resp.json() except Exception: pass time.sleep(2 ** attempt) return {error: failed after retries}10. 资源占用与性能观察方法10.1 显存观察方式启动推理服务后至少开两个终端一个看推理日志一个看显存watch -n 2 nvidia-smi重点观察模型权重加载后 baseline 显存占用prefill 阶段显存尖峰decoding 阶段显存变化多请求并发后显存增长曲线。10.2 影响性能的关键因素因素影响上下文长度越长则 prefill 耗时和 KV Cache 越大图片输入图片会转成大量视觉 token单图可能消耗数千 tokenbatch size并发变大后显存线性增长量化精度FP8/INT8 比 BF16 更省显存但要看框架支持张量并行多卡能装下更大模型但卡间通信会增加延迟10.3 性能基线记录建议不要只记“能跑”要记录一组可复现基线。建议每次测试记录模型dots3 权重精度BF16 推理框架vLLM 显卡记录实际型号和数量 上下文长度32K 并发数1 单请求平均耗时记录值 首 token 延迟记录值 峰值显存记录值如果没有官方硬件规格和实测数据这些数字都需要自己跑一遍才能填写。后续换参数时用同一份格式对比才能判断优化是否有效。10.4 如何降低显存占用使用模型中低精度权重或官方量化版本关闭多余计算图使用图模式加速减小max-model-len开启 chunked prefill降低并发请求数对不需要极长上下文的业务单独开启短上下文服务不要所有请求共享同一个 512K 配置。11. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后接口一直超时模型还在加载或显存不足导致 swap观察启动日志和 nvidia-smi等待加载完成减小 max-model-len使用更低精度OOM 显存不足权重分片方式不对或 KV Cache 过大查看进程崩溃日志和显存占用增加张量并行数量换量化版本减小上下文降低并发图片识别结果为空多模态输入格式不正确检查图片编码和 content 格式使用 base64 data URL确认 url 对应协议长文本答案错乱上下文太长导致信息被稀释缩短输入长度做对比测试增加检索前置步骤只保留关键段落Agent 不触发工具调用提示词或 tools 格式不匹配检查接口 tools 参数格式参照 OpenAI 工具格式逐字对照降低 tools 描述复杂度JSON 输出有多余文字解码参数或约束方式不对查看 response_format 是否生效尝试response_format{type:json_object}或使用后处理解析批量任务部分失败超时或上游接口限流查看失败日志增加超时时间与重试降低并发失败任务单独重列CPU 内存暴涨权重加载阶段需要大量 RAM用 free -h 观察内存分批加载或使用推理框架的流式加载模式12. 最佳实践与工程建议12.1 第一轮先跑最小可运行配置不要第一步就追求 512K 上下文和最大并发。先把模型启动成功用短上下文完成一次图片问答和一次工具调用确认整个链路通顺再逐步加压。12.2 把输入输出都用目录管理多模态和长上下文测试会产生大量素材。建议inputs/ ├── images/ # 图片测试集 ├── docs/ # 长文档测试集 └── cases/ # 每类任务的 prompt 用例 outputs/ ├── images/ # 图片识别输出 ├── summary/ # 摘要任务输出 └── agent/ # 工具调用记录每条测试用例尽量带上参数记录方便恢复现场。12.3 日志和监控做在接入之前如果你的目标是把 dots3 接到 Agent 或批量任务里第一件事是保留日志所有请求的 token 数每次工具调用参数每次接口失败的响应体每批任务的开始时间和结束时间。没有日志的 Agent 接入出问题后只能靠猜。12.4 多模态素材剪辑和大图处理建议对于文字密集的大图可以先用工具切图把图片区域划成小块分别给模型识别后再合并。这样比直接丢一整张大图更能降低漏字概率。不过切图也会破坏原有版式关系需要根据实际任务做权衡。12.5 Agent 安全使用边界通过 Agent 调用外部 API 时注意目标接口的鉴权、频控和操作敏感度。比如查天气这类只读接口可以做自动调用但涉及下单、发送消息、修改数据库等写操作必须先引入人工审批节点。12.6 版权与内容合规不要让模型处理你没有权限使用的图片、文档和聊天记录不要用模型批量抓取其他平台内容做商用分析生成内容发布前需要做人工复核尤其是涉及数据、法律、医疗等高风险领域如果你要基于 dots3 做二次开发或商用需要核对模型许可证和官方发布说明。12.7 选型建议最终决定用不用 dots3不要只看参数表而是用一个固定评测集对比你的 100 条业务问题20 张代表性业务图片10 个 Agent 工具调用场景一篇超过 16K token 的业务文档。用同一套评测集跑 dots3 和你目前使用的模型记录准确率、失败率、延迟和显存占用最后选 Type。13. 总结与下一步最值得关注的点不是 280B 参数本身而是“总参数 280B、激活 16B”这种设计能否在你的业务数据上带来超出预期的小模型效果。MoE 的价值在于用可控的推理成本提供更强能力但前提是推理框架、硬件配置和权重精度都能配合到位。如果你决定试第一个动作是先验证三件事模型能不能在你的硬件上用短上下文稳定跑起来图片输入能不能正确生成结构化结果工具调用能不能按预期输出参数。第一步只要有一个不通过后面 512K 和 Agent 测试就先别做。MoE 模型的部署问题往往不是“模型结构有问题”而是权重加载、框架版本和显存规划三者没有对齐。接下来可以继续做的事包括对照官方仓库说明部署 vLLM 或 SGLang 服务拿一个真实业务长文档测试 16K/32K 场景的召回质量测试不同量化方式对准确率和显存的影响把 dots3 接入现有 Agent 框架跑一个含 3 个以上工具的自动化场景积累一份“长上下文 多模态 工具调用”的评测集作为团队的模型选型基线。如果你准备入手 dots3建议先按本文第 3、4 节把环境和权重目录建好然后用第 6、7、8 节的用例逐项测试。跑通后再考虑 API 接入和批量任务这样踩坑成本最低。