字节跳动开源大模型Seed-OSS-36B，本地部署，性能实测

大家好，我是 Ai 学习的老章

字节跳动发布 Seed-OSS 系列大模型有段日子了，最近有空升级了 vLLM，拿出一张 H200 实际部署看看显存占用及性能情况

Seed-OSS-36B

本地字节跳动发布的大模型包括 3 个版本：

• Seed-OSS-36B-Base（基础模型，含合成数据版本）

• Seed-OSS-36B-Base-woSyn（基础模型的"纯净版"，不含合成数据版本）

• Seed-OSS-36B-Instruct（指令微调版本）

模型大小都是 36B。这个模型的特性是可以调整思考长度（类似 GPT-OSS 调整思考长度的 low-high）. 以及 Agent 性能进行了优化。原生上下文长度为 512K。

Seed-OSS-36B 模型的主要特性如下：

• 原生 512K 上下文窗口：端到端专为超长上下文训练，可一次性吞入海量文档、多步链路与智能体轨迹，远超常见 128K 开源上限。

• “思考预算”灵活可控：用户可动态调节推理长度，在成本/延迟与推理深度之间权衡——便于生产级推理管理。

• 推理与智能体性能：模型针对复杂问题求解与工具使用场景调优，同时保持均衡的通用能力。

• 面向研究的发布策略：提供两个基础模型——一个带有合成指令数据，开箱即用性能更高；一个不带合成数据，基础更“纯粹”——同时满足应用与学术需求。

• 现代 LLM 架构：因果解码器仅 Transformer，采用 RoPE 位置编码、GQA 注意力、RMSNorm 和 SwiGLU 激活；共 64 层、36B 参数、5120 隐藏维度、155K 词表。

原生 512K 上下文解锁了全新的应用类别：

• 长文本分析：多文档综合（RFP、法律、研究文献）、大规模日志分析，以及端到端会议语料推理。

• 智能体轨迹：在单会话预算内，保留多步工具调用及类似思维链的中间状态或批评。

• 大规模 RAG：最小化分块压力、扩大检索窗口，实现更丰富的跨段推理，无需激进截断策略。

由于长上下文是原生训练（而非后期追加），模型在超长文本上应能更好保持稳定性与注意力行为，不过仍需针对具体应用做延迟与内存优化。

Seed-OSS-36B-Instruct

完成预训练的 Seed-OSS-36B-Base 模型在多数评测基准上有较好表现，效果优于不包含合成数据的 woSyn 版本。

Seed-OSS-36B-Instruct 是基于 Seed-OSS-36B-Base 进行后训练的模型版本，在数学、代码、推理、Agent 能力、长文本能力等评测中，接近或达到同级别尺寸开源模型的最好水平。

经过指令微调的变体强调指令遵循、推理、智能体任务、编程、多语言、安全性和长上下文，在多个领域都取得了 SOTA 成绩：

• 数学与推理：Seed-OSS-36B-Instruct 在 AIME24 上取得 91.7% 的成绩，在 BeyondAIME 上取得 65，均代表开源领域的最新 SOTA 水平。

• 代码能力：在 LiveCodeBench v6 上，Instruct 模型得分 67.4，同样刷新 SOTA 纪录。

• 长上下文处理：在 RULER（128K 上下文长度）测试中，该模型达到 94.6，创下开源模型的最高分。

官方文档提到使用 vllm >= 0.10.0 或更高版本进行推理，还要安装支持 Seed-OSS 的 vLLM 版本：

VLLM_USE_PRECOMPILED=1 VLLM_TEST_USE_PRECOMPILED_NIGHTLY_WHEEL=1 pip install git+https://github.com/vllm-project/vllm.git

内网搞起来还是麻烦，我测试，vllm 至少要 0.10.2 版本才支持 Seed-OSS（0.10.1 和 0.10.1.1 都不行），还有最近热门模型 Qwen3-Next

我是使用 docker 部署的 vllm 0.10.2

具体过程：

docker pull vllm/vllm-openai:v0.10.2 docker save vllm/vllm-openai:v0.10.2 > vllm102.tar # tar 包传入生产内网 docker load -i  vllm102.tar  docker run --rm --runtime nvidia   --name seed36-server --ipc=host --gpus '"device=3"'   -p 8007:8000 -v /data/ai:/models vllm/vllm-openai:v0.10.2  --model /models/seed-oss-36-instruct  --chat-template   /models/seed-oss-36-instruct/chat_template.jinja   --served-model-name seed-oss-36 --port 8000   --max-num-seqs 8 --max-model-len  65536 --gpu-memory-utilization 0.6

我的卡是 141GB 显存，刚开始设置 64K 上下文，--gpu-memory-utilization 0.6 报错了，显示空间不足

这是因为模型文件 74GB 左右，64K 的max-model-len，KV 显存需要 16GB

所以调整后顺利加载模型了

对接到 openwebui

日志显示生成速度 48Tokens/s 的样子

跑了一下测试脚本，并发很低，总体生成速度 320 多

重新部署，将--max-num-seqs 调整到 50

docker run --rm --runtime nvidia --name seed36-server  --ipc=host --gpus '"device=3"'  -p 8007:8000  -v /data/ai:/models vllm/vllm-openai:v0.10.2  --model /models/seed-oss-36-instruct  --chat-template   /models/seed-oss-36-instruct/chat_template.jinja   --served-model-name seed-oss-36  --port 8000  --max-num-seqs 50  --max-model-len  65536 --gpu-memory-utilization 0.7

重新测试，总体平均 Tokens 1500+Tokens/s

很不错了

这个模型的官方测评结果看，各个方面都领先 Qwen3-32B，尤其是长上下文处理测试中，该模型达到 94.6，创下开源模型的最高分。据我所知，很多公司级的知识库应用多是调用 Qwen3-32B，Seed-OSS-36B-Instruct 这个超长上下文还是很有优势的。

另外，它还有可控思维预算机制，用户可以根据任务复杂性灵活指定模型的推理长度，如设置为 512、1K、2K、4K、8K 或 16K 等。模型在推理过程中会定期触发自我反思，估计已消耗和剩余的预算，对于简单任务可快速响应，复杂任务则可分配更多预算进行深度思考。

但是应该是为了实现这个灵活的推理预算控制，它的思考标签是 seed:think，所以在 openwebui 中它的思考过程不会被准确识别，将会被截断输出到对话框。如果后续对接 Agent 平台不知道会不会有毛病，增加开发成本。