小红书这一波开源动作直接把一个 280B 总参数、16B 激活参数、512K 上下文的多模态大模型抛了出来。型号代号是 dots3关键词很密集开源、MoE、多模态、Agent、超长上下文。还没下载模型的人可能已经在猜一个问题这玩意儿到底是不是又一个“纸面很强本地跑不动”的模型从标题参数来看dots3 属于典型的 MoE 架构设计280B 是全部专家权重总和但一次推理只激活其中 16B 左右。这意味着理论计算成本更接近一个中等规模模型但权重文件本身仍然是超大模型级别。很多人看到“16B 激活”会有一种错觉觉得 8G、16G 显存能跑实际上完全不是一回事。权重加载、KV Cache、视觉编码器、Agent 中间态都会把显存需求顶上去真正的门槛往往比想象中高很多。这篇文章不会替你“云评测”出花来而是先把 dots3 的技术点拆开再从环境准备、部署流程、功能测试、接口调用、批量任务、显存监控和排障清单这几个维度给你一套可以直接照做的验证路线。项目刚开源时文档和脚本都可能变动部署时请以官方仓库 README 为准下面给出的命令和参数都属于通用可执行模板需要你按实际环境替换路径和端口。1. dots3 核心能力速览从目前标题公开的信息出发dots3 的核心规格可以整理成下面这张表。表格里凡是标注“待确认”的项都不能当作最终结论需要在官方模型卡或仓库文档里核对。项目说明项目类型多模态大语言模型支持文本、图像等输入模型架构MoE 混合专家架构总参数约 280B单次激活参数约 16B上下文长度512K 级别超长上下文开源状态小红书团队开源具体协议以官方仓库为准主要能力文本生成、多模态理解、Agent/工具调用场景支持支持平台需根据官方发布信息确认常见目标为 Linux CUDA 环境推荐硬件待确认单卡大概率无法直接全精度加载优先考虑多卡或量化显存占用待实测确认不能按 16B 激活参数估算启动方式推测支持 Transformers 加载或 vLLM 部署具体见官方仓库是否支持 API需确认官方是否提供 OpenAI 兼容服务或自有 API是否支持批量任务部署成服务后可自行做批量原生态待确认适合场景长文档理解、长对话、多模态 Agent、大规模知识抽取这里先给一个特别重要的判断如果你是在 16G 显存的消费级显卡上跑习惯 7B、14B 模型的用户dots3 不适合一上来就全量推理。它的激活参数是 16B但“激活 16B”不等于“只需要 16B 模型显存”。MoE 模型在推理时需要把参与计算的专家权重或全部专家权重载入显存路由机制还要额外占用显存带宽和缓存。哪怕是量化版本消费级显卡跑 280B 总参数量模型也很大概率不够用。是否支持 CPU-only 运行、是否支持 50 系显卡优化、是否有官方量化分支都必须回到官方仓库确认。2. dots3 技术点拆解MoE、长上下文、多模态、Agent2.1 MoE 架构280B 总参数为什么能只激活 16BMoE 不是新概念核心思想是让模型内部有多个“专家子网络”每次输入只让其中少数专家参与计算通过一个门控路由器选择最合适的专家组合。dots3 的 280B 总参数量可以理解为把大量知识分散到了不同专家中16B 激活参数表示单次前向计算实际使用的参数量不大推理时每一步的浮点计算量远小于 280B 稠密模型。这会带来两个方面的结果。第一训练阶段能塞进更多知识模型容量上限更高第二推理速度理论上比同等总参数的稠密模型快甚至更接近 16B 稠密模型的计算量。但工程上有个陷阱即使一次只激活 16B 参数权重分片和内存交换依然要管理全部 280B 参数。如果你的设备没有足够大的统一内存或显存模型加载阶段就会失败这不是量化能完全解决的问题。2.2 512K 超长上下文能做什么512K 上下文意味着模型可以一次性看到的 token 数量非常可观。中文场景下大约对应几十万字的文本内容常见用途包括长文档问答一次塞入几百页 PDF 文本而不用切片后反复检索。代码仓库分析把多个目录下的源码拼接成一个长上下文让模型理解跨文件函数调用。超长多轮对话Agent 任务中需要保留大量历史状态普通模型 8K、32K 上下文很容易截断512K 能缓解这个问题。多模态序列视频多帧、长图切片、图文交错文档都会消耗大量 token 数。需要注意长上下文不是打开就能白拿的。推理时 KV Cache 会随着输入长度线性增长512K 上下文如果真被塞满显存压力会非常恐怖。实际使用时往往不是模型不支持长文本而是硬件装不下对应的 KV Cache。很多模型只把最大值写在论文里真实场景仍然建议先用 32K、64K 小步验证确认显存和延迟都能接受再逐步增加长度。2.3 多模态与 Agent 的组合逻辑dots3 的关键词里有“多模态”和“Agent”这两者组合起来可以做的事情很多。多模态指模型不只是读文字还能接收图像输入理解截图、表格、文档照片等。Agent 则强调模型不只是生成文本还要能理解环境状态、决定调用什么工具、输出结构化指令。一个典型的多模态 Agent 任务是这样的给 Agent 一张系统界面截图让它识别页面上的按钮位置和状态再根据用户指令调用外部 API 完成操作。这类任务对两个能力要求很高第一视觉编码器能不能准确描述图像内容第二模型在长上下文中能不能稳定维持工具调用的格式不会生成到一半就跑偏。dots3 的 16B 激活参数和 512K 上下文从纸面上说确实适合做 Agent 后端。Agent 在连续多轮工具调用中会把历史记录、工具返回结果、中间推理全部拼进上下文短上下文模型很容易丢状态。但在没有跑通实际案例之前最好先把它当成一个宣传参数然后用具体任务去压测。不要因为激活参数是 16B 就期待消费级显卡能无压力跑 AgentAgent 任务往往会多轮调用模型总耗时和显存占用都会被放大。3. dots3 适用场景与使用边界3.1 适合谁使用dots3 的开源价值和测试价值最明显的用户应该是这几类第一做长文本应用的技术团队。需要处理数百页合同、论文、技术手册、客服聊天记录的场景512K 上下文能减少切片、检索、重新排序的工程量。第二多模态 Agent 开发者。希望让视觉理解和工具调用在一个模型内完成而不是拼一个复杂的多模型管道。第三了解 MoE 推理优化的研究人员。280B 总参数、16B 激活的配置非常适合做路由策略、显存管理、KV Cache 压缩的实验。第四有大显存服务器或多卡集群的内容平台开发者。如果手上有 80GB 级别 A100/H100或者是多卡节点可以尝试直接部署官方版本做能力评测。3.2 不适合谁使用如果你手里只有一块 16G 显存的 RTX 4060 或 4070想本地跑一个完整的 280B MoE 多模态模型需要提前做好心理准备。16B 激活不意味着低显存可用这种体量的模型要跑起来通常需要大显存单卡、多卡张量并行或者等待官方和社区推出足够优秀的量化分支。即便量化后能加载长上下文的 KV Cache 也会再次冲击显存上限。如果你需要一个超大显存占用的纯 OCR 工具或者单纯想做快速图片描述dots3 大概率不是最优选择中等规模专用多模态模型会更轻量。3.3 版权、隐私与合规边界开源模型不等于可以随意商用每个开源项目都有自己的 License使用前务必查看官方仓库的授权协议。涉及人脸、隐私位置、商业机密、受版权保护的文档和图片时必须获得必要授权。模型生成的输出也可能包含偏见、错误或版权风险发布前要人工复核。部署模型服务时建议限制访问范围不要直接把未鉴权的 API 暴露到公网。4. dots3 本地部署环境准备如果你已经准备在服务器上部署 dots3下面是一份通用环境检查清单。dots3 官方仓库如果有专用安装说明请以其为准这里只提供比较稳妥的通用步骤。4.1 硬件配置先确认 GPU 型号和显存总量。建议提前用 nvidia-smi 查看当前环境nvidia-smi部署这类超大 MoE 模型优先考虑以下条件显存总量多卡总显存至少达到模型全精度或半精度权重所需容量具体数值要看官方模型文件格式和精度。内存大小系统内存要足够加载权重并留出交换空间。磁盘空间模型权重文件从几十 GB 到几百 GB 不等SSD 传输速度也影响加载时间。CPU 与 GPU 通信多卡部署时 PCIe 或 NVLink 带宽会影响并行效率。4.2 软件依赖推荐在 Linux 环境下运行。主要依赖包括 Python、PyTorch、CUDA 驱动、Transformers、vLLM 或模型仓库指定的推理框架。可以用一段命令快速检查环境是否一致python -c import torch, transformers; print(torch.__version__, transformers.__version__, torch.cuda.is_available())如果 torch.cuda.is_available() 返回 False说明 PyTorch 的 CUDA 版本和当前驱动不匹配需要先解决驱动问题再继续。4.3 模型文件获取建议优先通过官方仓库提供的下载地址获取。如果下载源访问不稳定可以留意国内可用的模型托管平台或官方自定义源。下载完成后先记录模型文件所在路径后续加载时需要用到。4.4 目录规划建议部署前先建立清晰的目录结构比如dots3-deploy/ ├── models/ # 模型权重文件 ├── logs/ # 运行日志 ├── inputs/ # 测试图片和文本 ├── outputs/ # 模型输出结果 └── scripts/ # 启动脚本和调用脚本模型文件、输入素材、输出结果分开管理会让后续批量任务调试轻松很多。5. dots3 安装部署与启动方式不同推理框架的启动命令差异很大。下面提供的是一种基于 Transformers 的通用加载方式以及一种基于 vLLM 的服务化部署方式。如果官方仓库给出了专用脚本优先用官方脚本。5.1 用 Transformers 加载并做基础推理先安装基础依赖pip install transformers torch accelerate sentencepiece pillow然后写一个最小的 Python 加载脚本。这里模型路径需要替换成你下载的模型实际路径加载时的参数也只是一个示例需要根据 dots3 的模型架构和官方文档调整from transformers import AutoModelForCausalLM, AutoProcessor, AutoTokenizer model_path ./models/dots3 processor AutoProcessor.from_pretrained(model_path, trust_remote_codeTrue) tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_path, device_mapauto, torch_dtypeauto, trust_remote_codeTrue ) messages [ {role: user, content: 请用三句话介绍一个多模态 Agent 架构的设计要点。} ] text processor.apply_chat_template(messages, add_generation_promptTrue) inputs processor(texttext, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokens512, do_sampleTrue, temperature0.7 ) response processor.decode(outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue) print(response)这段代码不保证在 dots3 上直接可用dots3 的 processor 和模板可能不同但它能帮你快速验证模型文件是否下载完整、权重能否正常加载、基础文本生成是否能跑通。如果加载时报错缺少某个模块或者模型类不存在请优先检查 trust_remote_code 是否设置以及模型路径是否正确。5.2 用 vLLM 部署 OpenAI 兼容 API如果模型架构支持 vLLM推荐直接把模型部署成服务后续做批量任务和 Agent 调用都方便。先安装 vLLMpip install vllm启动命令通常是这样的形式端口号和模型路径按实际环境修改vllm serve ./models/dots3 \ --served-model-name dots3 \ --tensor-parallel-size 1 \ --max-model-len 131072 \ --port 8000需要特别说明tensor-parallel-size 要按 GPU 数量调整单卡无法容纳权重时需要设置成可用 GPU 数量。max-model-len 可以先设成 131072 或更小值不要一开始就挑战 512K。长上下文如果已经超出本地显存承受范围启动时会直接报错。如果 dots3 的模型结构不是 vLLM 原生支持需要用 vLLM 官方提供的注册或扩展方式具体见 vLLM 文档。5.3 多卡并行部署注意事项多卡部署时每张卡的显存都会被占用。启动前先确认节点上有几张卡、每张卡空闲显存是多少nvidia-smi --query-gpuindex,memory.total,memory.used,memory.free --formatcsv如果出现 CUDA out of memory优先减少 max-model-len或者降低并发数不要直接调大张量并行度因为部分场景下并行会额外复制缓存。6. dots3 功能测试与效果验证部署完成后不能只跑一次生成就下结论。建议按下面的维度拆开测试每个测试都要记录输出结果和显存数据。6.1 基础文本生成测试这个测试的目的是确认模型能正常启动、生成流程没有错误。输入一段相对简单的指令观察首个 token 生成延迟。每秒生成 token 数。输出内容是否语义连贯。是否出现重复或中断。一句话成功标准多轮输入输出都正常没有中途崩溃显存没有持续异常增长。6.2 多模态图片理解测试如果 dots3 支持图像输入准备一张不含隐私的测试图例如包含文字的截图、表格图片或自然风景图。然后用类似下面的方式调用from PIL import Image image_path ./inputs/test_screenshot.png image Image.open(image_path).convert(RGB) prompt 请描述这张图片中的主要内容并提取其中的文字信息。 inputs processor(textprompt, imagesimage, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokens1024 ) response processor.decode(outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue) print(response)判断点包括视觉信息是否被准确理解、图片里的文字是否被正确识别、模型是否会产生与图片无关的幻觉内容。如果输出只是泛泛而谈或者把图中文字张冠李戴说明视觉编码或投影层表现不稳定需要进一步测试不同分辨率图片。6.3 多模态 Agent 工具调用测试Agent 测试需要构造一个工具调用场景。首先给模型一段系统提示说明它可以调用某个查询天气的接口然后输入用户问题。理想情况下模型应该输出一个结构化工具调用请求而不是直接编造天气数据。由于 dots3 的具体工具调用模板还没确认下面用 OpenAI 工具调用风格做一个通用示例实际使用时需要按模型支持的方式进行curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: dots3, messages: [ {role: system, content: 你是一个智能助手可以调用工具查询天气。用户提问时请先输出工具调用参数。}, {role: user, content: 北京今天天气怎么样} ], tools: [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } } } ], tool_choice: auto }如果模型输出了格式正确的函数调用参数说明 Agent 工具调用链路基本可用。如果输出的是普通文本而不是结构化 JSON需要检查模型是否理解工具模板或者需要换用该模型的 prompt 格式。更可靠的 Agent 测试还可以模拟多轮工具调用历史让模型在连续对话中跟踪任务状态观察它是否忘记前面步骤。6.4 长上下文压力测试长上下文是 dots3 的重点卖点测试时不要拿几个短句子糊弄。准备一段真实长文本比如连续拼接几份技术文档然后设置一个依赖前文细节的问题。具体步骤如下读取文本文件计算字符数和 token 数。把完整文本放进 user message。让模型回答文本末尾或中间位置的一个细节问题。对比模型输出与原文事实。短上下文模型在长文本上容易“记不住”输出会出现明显复述错误。dots3 的 512K 上下文是否能扛住需要通过多个长度档位来验证先测 8K再测 32K、64K、128K看显存增长和答案准确率。如果某一个长度档位出现 OOM 或响应时间急剧上升说明该长度已经逼近本机承受上限。一个值得注意的细节是长上下文测试中 KV Cache 增长会导致显存占用越来越高。很多模型能生成到一半不是因为生成失败而是因为前面的 KV Cache 已经占满显存。因此长文本测试要重点记录峰值显存。6.5 批量任务与稳定性测试批量任务也可以直接用 API 来做。写一个 Python 脚本读取一批输入文件逐个请求接口将结果写入文件import requests import json import time from pathlib import Path inputs_dir Path(./inputs) outputs_dir Path(./outputs) outputs_dir.mkdir(exist_okTrue) url http://127.0.0.1:8000/v1/chat/completions for text_file in inputs_dir.glob(*.txt): text text_file.read_text(encodingutf-8) payload { model: dots3, messages: [ {role: user, content: f请总结以下内容\n{text}} ], max_tokens: 2048 } try: response requests.post(url, jsonpayload, timeout300) response.raise_for_status() result response.json()[choices][0][message][content] output_path outputs_dir / f{text_file.stem}_result.txt output_path.write_text(result, encodingutf-8) print(f处理完成: {text_file.name}) except Exception as e: print(f处理失败: {text_file.name}, 错误: {e}) time.sleep(0.5)批量任务最重要的不是单次效果而是长时间运行下的稳定性。建议脚本里要加日志、失败重试和超时控制。如果某一个文件特别长可能造成单条请求长时间占着显存这种情况要给请求设置合理超时或者把文件先切片再处理。7. dots3 接口 API 与批量任务接入如果 dots3 成功以 OpenAI 兼容服务启动那么外部系统可以像调用 OpenAI API 一样调用它。这种方式对 Agent 项目非常友好因为很多 Agent 框架本身就支持 OpenAI 格式接口只需要把 base_url 改成 vLLM 地址即可。7.1 启动接口服务确认服务启动成功的标志是访问健康检查接口有响应curl http://127.0.0.1:8000/v1/models如果返回模型列表说明服务正常。如果页面或端口不通先确认服务进程是否存在再确认端口是否被占用netstat -tunlp | grep 80007.2 Python 客户端调用示例下面这个请求使用了 OpenAI SDK 风格但只用 requests 完成。实际接入时把 messages、max_tokens、temperature 按照任务需求调整即可。import requests import json url http://127.0.0.1:8000/v1/chat/completions payload { model: dots3, messages: [ {role: user, content: 用一句话解释为什么 MoE 模型适合超长上下文场景。} ], max_tokens: 256, temperature: 0.2 } response requests.post(url, jsonpayload) if response.status_code 200: data response.json() print(data[choices][0][message][content]) else: print(请求失败:, response.status_code, response.text)7.3 批量任务设计建议服务部署好后批量任务的设计建议控制并发数。不要一次性把几十个请求丢上去先用 1 个并发测试观察延迟和显存再逐步增加。日志记录每个请求的输入长度、输出长度、响应时间、状态码。失败重试要退避避免不断重试把服务打挂。长输入优先排队不并行占满显存。8. dots3 资源占用与性能观察对这类超大参数模型性能观察比单次输出质量更关键。下面整理几种常见的观察手段和判断方法。8.1 显存监控方法部署服务后另开一个终端定时查看显存比如每 5 秒刷新一次watch -n 5 nvidia-smi重点看每个进程的显存使用量。一次推理结束后显存应该回落到接近初始负载水平。如果显存占用持续上升可能是服务端存在 cache 累积或内存泄漏需要排查。8.2 延迟指标模型推理主要关注两个指标首 token 延迟和生成速度。首 token 延迟高通常是模型加载阶段或长输入 prefill 阶段耗时生成速度低则可能是显存带宽、量化精度或专家路由导致。简单计时可以用 Python 的 time 模块把发送请求时间到收到响应时间记录下来。8.3 如何判断是否该用量化如果加载完整权重时显存不够可以等待官方或社区发布量化版本。量化能显著降低权重占用的显存但也可能带来精度下降。判断标准很简单先在关键任务上跑一遍全精度模型结果再用量化模型跑同一批任务对比准确率和输出质量。如果差异在可接受范围内量化就是可取的部署方案如果模型本身在复杂多模态任务上质量波动很大量化可能放大问题。8.4 降低显存占用的通用思路在无法更换硬件的前提下可以尝试缩短 max-model-len减少 KV Cache。降低并发请求数量。使用更小的输入图片分辨率。等待官方量化分支或社区 GGUF/AWQ 版本。对长文做切片处理只保留关键部分不要总想一次性塞满 512K。9. dots3 常见问题与排查方法问题现象可能原因排查方式解决方案启动时提示 CUDA out of memory显卡显存不足以加载完整权重或初始化 KV Cache查看 nvidia-smi确认权重文件大小减少 max-model-len、使用量化版本、多卡并行加载模型时报错缺少模块需要依赖自定义代码或指定模型实现类查看完整报错堆栈开启 trust_remote_code或安装缺失依赖模型能启动但生成很慢显存带宽不足或没有使用 GPU 加速检查 GPU 利用率nvidia-smi确认 PyTorch/CUDA 版本匹配调整并行参数图片输入得不到有效结果视觉处理器未正确加载或图片分辨率不合适单独测试图片加载检查 processor调整图片预处理方式长文本输入后掉线或卡死超长输入造成显存瞬间爆满或请求超时查看服务端日志缩短输入长度增大客户端超时再做切片API 请求返回 404接口路径不正确或模型未注册成功调用 /v1/models 确认模型名修改 URL 或调整 --served-model-name批量任务中途失败某个超长文本导致 OOM或并发设置过高检查失败请求的特征记录日志降低并发加失败重试输出存在幻觉模型本身能力限制或上下文宽度超出实际有效范围用更短、更明确的问题重复测试降低上下文长度提供更充分的背景信息下载模型文件很慢网络源不稳定检查下载工具连接状态选择国内可访问的平台下载或自定义下载源显存占用持续增长可能存在显存泄漏或服务缓存策略长时间压测观察显存曲线重启服务按轮次清理缓存检查框架版本实际排障时最忌讳直接看最后一行报错就下结论。先把完整日志保存下来找到第一次出现异常的位置多数问题都出在模型加载阶段或长输入 prefill 阶段。10. dots3 部署最佳实践与使用建议第一先用最小配置跑通。不要一开始就挑战 512K 上下文不要第一次部署就开满并发。把 max-model-len 调低用一条短消息验证完整调用链路再逐渐加压。第二保留一套最小可运行配置。把能成功启动的模型路径、模型名、端口、并行数、Python 依赖版本记下来最好写成一个 shell 启动脚本避免环境变动后自己都忘了怎么跑起来。第三分目录管理模型文件、测试输入和输出结果。如果后续要做批量任务历史和日志会非常关键。输出文件命名建议带上时间戳比如 result_20250101_101010.json。第四Agent 接入务必加上鉴权和访问限制。把模型 API 暴露到公网而不加任何鉴权很容易被扫到并被滥用造成算力浪费和数据泄露风险。至少在服务前加一层 API Key 校验。第五涉及人脸、声音、版权素材时必须确认授权。dots3 这类多模态模型可以处理图像、文档等输入。如果测试数据来自真实用户或者受版权保护的资料不要在没有授权的情况下上传到共享服务或直接进入训练流程。第六发布或商用前要做效果复核。模型可能生成看起来合理但事实错误、隐含偏见或违反平台规定的内容。交付材料需要设置人工复核机制不能完全依赖模型输出。第七官方文档是最高优先级。当前处在开源初期仓库 README、推理脚本、模型卡里的系统提示词和接口格式可能随时更新遇到与本文不一致的地方以官方仓库为准因为那才是能跑通的最新版本。11. 总结与下一步dots3 这次开源值得关注的点非常清楚280B 总参数的 MoE 架构、16B 激活参数带来的理论计算优势、512K 超长上下文、多模态和 Agent 能力的组合每一项都是当前大模型应用中的热点。但这些纸面指标只有真正部署起来才变成价值。准备动手做实测的人建议按这个顺序推进先看懂官方仓库里的模型卡和部署要求确认自己的显存、内存、磁盘是否够用然后照官方脚本跑通一次文本生成接着用图片输入测试多模态能力再设计一个真实的 Agent 工具调用场景最后用不同长度长文和批量任务做压力测试。每跑完一个阶段就用 nvidia-smi 记录一次显存峰值把日志保存下来。最容易踩的坑有两个。第一个是误以为“16B 激活”等于“低显存可跑”。第二个是直接用 512K 上下文挑战本机硬件结果模型一加载就 OOM。只要你避开这两个误区用分阶段验证的思路去部署dots3 的能力是不是真材实料很快就能得到第一手答案。后续如果官方推出量化分支、更稳定的推理模板或 Agent 专用数据集值得继续跟进测试。建议收藏这篇文章等模型下载完回来照着跑一遍。