天工 Skywork 是昆仑万维科技股份有限公司自研的大语言模型体系,包含面向个人用户的天工 AI 产品线,以及面向开发者的 Skywork 开源模型系列。开源系列覆盖基座模型(Skywork-13B-Base)、对话模型(Skywork-13B-Chat)、混合专家模型(Skywork-MoE)与多模态推理模型(Skywork-R1V),并同步开源了 SkyPile-150B 中文预训练数据集,是国内少有的「模型权重 + 训练数据 + 训练代码」全链路开源项目。对 AI 从业者而言,Skywork 是研究中文预训练数据处理、MoE 稀疏化落地与国产大模型私有化部署的典型样本。本文从安装、推理、部署到选型对比,带你把 Skywork 完整跑通。
掌握 Skywork 的部署与微调,是中文大模型工程化、国产化替代与私有化交付方向的核心技能,也是理解 MoE 稀疏化落地的典型教材。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要天工 Skywork:中文开源模型的三重缺口
主流开源大模型中,Llama 等英文模型在中文场景的指令遵循与常识回答质量不稳定;闭源 API 存在数据出境与合规风险,政务、金融等场景无法直接调用;而部分国产开源模型只发布权重,训练数据与训练流程不透明,想研究预训练技术或基于原始语料做领域增强的团队无从下手。这是 Skywork 切入的三个核心痛点。
Skywork 的解法是「全链路开放」:Skywork-13B 基座模型基于超过 2 万亿 tokens 中英文语料训练,覆盖中文网页、百科、书籍等来源;同步开源 SkyPile-150B 数据子集,成为当时规模最大的中文开源预训练数据集之一;提供 Chat 对齐版本与 MoE 高效版本,覆盖「研究 → 微调 → 低成本推理」的完整链路。开发者既可以直接部署推理,也可以拿数据做继续预训练、蒸馏或数据质量研究。
与 Qwen、Baichuan、ChatGLM 等同期开源系列相比,Skywork 的气质差异是「研究友好」:训练数据与代码直接开放,适合复现预训练流程与中文数据配比实验。但其开发者生态与第三方工具链集成深度不及 Qwen 等头部系列,微调脚本、量化方案、云厂商镜像等周边资源更多依赖社区自建,生产集成时需要投入额外工程时间。
安装与环境配置:3 步就绪
第一步:创建 Python 环境并安装依赖。 Skywork 通过 HuggingFace Transformers 框架加载,需要 Python 3.10+、PyTorch 与 CUDA 11.8 及以上版本。建议使用 conda 隔离环境,避免与现有项目依赖冲突。
第二步:下载模型权重。 从 HuggingFace 或 ModelScope 拉取模型文件到本地目录。国内网络可先设置 HF_ENDPOINT 镜像环境变量加速下载。
第三步:验证加载。 用一段 Python 脚本加载模型并打印参数量,确认环境就绪。13B 模型以 BF16 精度推理约需 26GB 显存,24GB 显卡会内存溢出,可改用 8bit 量化或换用 40GB 以上显存的 GPU。
conda create -n skywork python=3.10 -yconda activate skyworkpip install torch transformers accelerate safetensors # 国内网络加速下载export HF_ENDPOINT=https://hf-mirror.comhuggingface-cli download SkyworkAI/Skywork-13B-Base --local-dir ./Skywork-13B-Base python - <<'EOF'from transformers import AutoModelForCausalLM, AutoTokenizername = "SkyworkAI/Skywork-13B-Base"tok = AutoTokenizer.from_pretrained(name, trust_remote_code=True)model = AutoModelForCausalLM.from_pretrained( name, trust_remote_code=True, torch_dtype="auto", device_map="auto")print("load OK, params =", sum(p.numel() for p in model.parameters()) / 1e9, "B")EOF
快速上手:5 分钟跑通 Skywork-13B-Chat 对话
最简使用路径是三步:加载对话模型 → 用 tokenizer 拼接对话模板 → 生成并解码回答。Chat 版本已经过监督微调与偏好对齐,开箱即用,无需自行构造特殊提示词格式。
1. 在本地或云 GPU 实例(建议 24GB 以上显存)中激活 skywork 环境;
2. 确认已下载 SkyworkAI/Skywork-13B-Chat 权重;
3. 运行下方脚本,将 messages 中的问题替换为你的实际提问。
运行成功后会在终端打印一段关于 RAG 的定义说明。do_sample=False 得到确定性输出,适合测试与评测;需要多样性时可改为 do_sample=True 并设置 temperature=0.7。进阶技巧是使用 generation_config 统一管理生成参数,并将输入输出协议封装成 HTTP 服务,便于业务系统集成。
from transformers import AutoModelForCausalLM, AutoTokenizer tokenizer = AutoTokenizer.from_pretrained( "SkyworkAI/Skywork-13B-Chat", trust_remote_code=True)model = AutoModelForCausalLM.from_pretrained( "SkyworkAI/Skywork-13B-Chat", trust_remote_code=True, torch_dtype="auto", device_map="auto") messages = [{"role": "user", "content": "用一句话解释 RAG 是什么"}]prompt = tokenizer.apply_chat_template( messages, tokenize=True, add_generation_prompt=True, return_tensors="pt").to(model.device) outputs = model.generate(prompt, max_new_tokens=256, do_sample=False)answer = tokenizer.decode(outputs[0][len(prompt[0]):], skip_special_tokens=True)print(answer)
核心能力详解:4 大支柱
支柱一:全链路开源的中文预训练基座。 Skywork-13B 使用超过 2 万亿 tokens 中英文语料预训练,并开源 SkyPile-150B 数据子集与训练推理代码。研究团队可以复现数据配比、分析中文语料质量、在小模型上做继续预训练实验;工程团队则可直接基于权重构建垂直领域模型。
支柱二:稀疏 MoE 高效推理。 Skywork-MoE 总参数量 75B,单个 token 仅激活 3B 参数,由 Skywork-13B 稠密权重初始化扩展而来。MoE(混合专家)架构将网络拆分为多个专家子网络,每次推理只路由到少数专家,计算量接近 3B 稠密模型,模型容量接近 75B,适合高并发、低成本的中文生成场景。
支柱三:对话对齐与指令遵循。 Skywork-13B-Chat 在 Base 基座上做监督微调与人类偏好对齐,多轮对话稳定,对中文指令的理解与执行在同期 13B 开源模型中处于第一梯队,可直接嵌入客服、问答等业务流。
支柱四:多模态推理探索。 Skywork-R1V 是 38B 视觉-语言模型,具备视觉思维链能力——先描述图像内容再逐步推理,支持高分辨率图像输入与 OCR、图表、数学题目理解,适合文档智能与多模态 Agent 场景。
生产部署与监控:从上线到运维
部署方式一:vLLM + OpenAI 兼容 API。 Skywork-13B 与 LLaMA 架构兼容,vLLM 可直接加载并提供 OpenAI 风格接口,便于接入 LangChain、FastGPT 等应用框架。以下命令以 BF16 精度起服务,默认监听 8000 端口。
部署方式二:MoE 多卡张量并行。 Skywork-MoE 虽单 token 只激活 3B,但 75B 权重需全部载入显存,BF16 约 150GB,单卡无法部署。使用 --tensor-parallel-size 4 将权重切分到 4 张 80GB 显卡(如 A100/H100)上并行推理;资源有限时可退回 Transformers + device_map="auto" 多卡加载,但吞吐明显低于 vLLM。
可观测性。 vLLM 在 /metrics 端点暴露 Prometheus 指标,包括请求 QPS、平均延迟、KV cache 使用率与 GPU 利用率,配合 Grafana 搭建监控面板。应用层需记录 prompt 与 response 日志,并对手机号、身份证等敏感信息做脱敏后再入库。MoE 场景还需关注专家路由分布,若部分专家长期过载,说明路由策略或数据分布异常,需离线 profiling 定位。每次发版登记模型权重哈希,便于线上问题快速回滚与审计。
<p class="para-label">避坑清单:</p>
<ul class="dash-list"><li>Skywork 社区许可协议与 Apache 2.0 不等价——允许商业使用但包含额外条款(如超大规模商用需书面授权),上线前必须通读协议原文。</li><li>trust_remote_code=True 会执行云端 modeling 代码,务必只从官方 HuggingFace/ModelScope 仓库下载,并核对文件 sha256 防止供应链投毒。</li><li>MoE 激活参数少不等于显存占用小:75B 权重约 150GB 必须全部载入显存,单张 24GB 卡无法部署。</li><li>升级 transformers 后旧的远端 modeling 代码可能报兼容错误,升级前先在测试环境跑通推理回归。</li><li>天工 App/网页(SaaS)与开源 Skywork 相互独立:开源模型不附带托管 API,天工产品的 AI 搜索等能力也不等于开源模型能力。</li></ul>
python -m vllm.entrypoints.openai.api_server \ --model SkyworkAI/Skywork-13B-Chat \ --trust-remote-code \ --dtype bfloat16 \ --port 8000 # 验证服务curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"SkyworkAI/Skywork-13B-Chat","messages":[{"role":"user","content":"你好"}]}'
| 维度 | 天工 Skywork | Qwen 千问 | Baichuan 百川 | ChatGLM 智谱 |
|---|---|---|---|---|
| 定位 | 研究友好型国产开源 + C 端产品 | 全系列开源 + 云 API 生态 | 开源 + 行业解决方案 | 开源 + 商业 MaaS 平台 |
| 编排范式 | 稠密 13B / MoE / 视觉语言多架构 | 稠密 + MoE + VL 全谱系 | 稠密为主 | 稠密为主 |
| 类型约束 | 自定义社区许可协议 | Apache 2.0(Qwen2 起) | 自定义协议,登记后商用 | MIT |
| 学习曲线 | 中:数据与代码开源,易深挖 | 低:教程与社区最丰富 | 低:上手快 | 低:文档友好 |
| 生态集成 | HF/ModelScope,第三方工具中等 | 最佳:vLLM/Ollama/云厂商全支持 | 中等 | 中等(智谱开放平台) |
| 生产部署 | vLLM / Transformers 私有化 | 私有化 + 云 API 全方式 | 私有化为主 | 私有化 + API 双通道 |
| License | Skywork Community License | Apache 2.0 | 自定义(登记可商用) | MIT |
| 适合谁 | 预训练/数据研究团队 | 广泛生产选型,求稳求全 | 中小团队快速落地 | 学术研究与对话应用 |
选型建议:追求生产生态与长期维护选 Qwen,其 License 更宽松、集成面最广;需要中文训练数据与预训练参考资料选 Skywork,它是四者中唯一同时开源数据与代码的方案;中小团队想最小成本跑起对话能力,选 ChatGLM 的 6B/9B 级模型即可。
版本迭代
天工 Skywork 沿着「闭源大参数 → 开源基座 → 稀疏 MoE → 多模态推理」演进,开源策略从仅发布权重走向权重、数据、代码全量开放,产品侧与开源侧双线并行。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| 天工大模型 1.0 | 2023-04 | 闭源千亿参数基座 | 发布「天工」C 端产品,中英多模态能力 |
| Skywork-13B-Base | 2023-11 | 开源 13B 基座模型 | 2 万亿 tokens 预训练,权重与推理代码开源 |
| Skywork-13B-Chat | 2023-11 | 开源对话对齐模型 | 在 Base 上做监督微调与偏好对齐,支持多轮对话 |
| 天工 3.0 | 2024-04 | 4000 亿参数 MoE | 稀疏注意力 + AI 搜索能力,接入天工产品 |
| Skywork-MoE | 2024-06 | 开源 MoE 模型 | 75B 总参 / 3B 激活,由 13B 稠密权重扩展,推理成本大幅下降 |
| Skywork-R1V | 2025-03 | 开源多模态推理模型 | 38B 视觉-语言模型,视觉思维链 + 高分辨率图像理解 |
天工的策略是「产品侧堆参数、开源侧求效率」。对开发者的启示:13B 系列适合单卡微调与研究,MoE 版适合追求吞吐的低成本推理,R1V 面向图文混合场景。官方对评测分数的发布口径不一致,且各版本基准不同,直接横向对比易失真,选型时建议以同批次的公开基准报告与自身业务评测集为准。
AI 应用场景
私有化中文 RAG 知识库
阶段:RAG 管道构建
解决的问题:金融、政务场景数据不能出域调用云端 API,通用英文模型中文检索与生成质量不稳定。Skywork-13B 本地部署配合中文 Embedding 模型(如 bge-large-zh),检索与生成全部在内网完成,规避数据出境合规风险。
具体案例:某券商内部投研文档库,使用 vLLM 部署 Skywork-13B-Chat,LangChain 做检索增强,回答附带引用来源。单卡 A100 即可支撑数十并发查询,敏感数据零出域。相比直接调用英文开源模型,中文回答的相关性与可读性显著提升。
多模态文档理解
阶段:文档智能
解决的问题:扫描版财报、合同中的表格与公式无法用纯文本模型处理。Skywork-R1V 以视觉思维链先理解版面再推理,可完成 OCR、表格结构化与摘要生成一条龙。
具体案例:某企业财务部门用 Skywork-R1V 处理年报 PDF,将人工录入每份约 40 分钟的流程压缩到 3 分钟内的模型推理加人工复核,表格字段抽取错误率明显低于传统 OCR 管线。
预训练与数据研究
阶段:模型预训练 / 数据工程
解决的问题:多数开源模型不开放训练数据,无法支撑数据配比、去重、质量评估等研究。SkyPile-150B 提供真实的中文预训练语料样本,配合开源训练代码可复现完整流程。
具体案例:高校 NLP 实验室基于 SkyPile-150B 做数据质量分层实验,筛选高质量子集训练 1B 级小模型,在 C-Eval 上以 1/10 的参数量达到接近 7B 模型的得分。
常见误区
误区Skywork 在 GitHub/HuggingFace 上开源了,那它就和 MIT/Apache 一样,拿去做任何商业项目都行。
正解Skywork 采用自定义的 Skywork Community License,允许商业使用但附有额外条款,包括对超大规模商用场景的书面授权要求。商用前必须通读协议原文,确认你的使用规模与场景在许可范围内,并保留授权记录。
为何常见:多数开发者习惯将「开源」默认理解为 Apache 2.0,未仔细阅读模型卡的 License 字段,导致合规风险后置。
误区Skywork-MoE 单 token 只激活 3B 参数,那它运行时只占 3B 模型的显存,24GB 游戏显卡足够。
正解激活参数少降低的是计算量,所有权重依然要载入显存。Skywork-MoE 总参 75B,BF16 权重约 150GB,需要多张 A100/H100 做张量并行。这是 MoE 部署的通用认知,激活参数与总参数是两个概念。
为何常见:混淆「激活参数」与「总参数」,只看官方宣传的「3B 激活」数字,忽略了权重加载的物理需求。
误区天工 AI 助手和 Skywork 开源系列同名,那 App 的能力就是开源权重,部署开源版就能获得天工产品的全部能力。
正解天工闭源产品线与 Skywork 开源系列是两套模型。天工 3.0 是 4000 亿参数闭源 MoE,开源侧最大的是 75B 的 Skywork-MoE;产品中的 AI 搜索、音乐生成等能力也未随开源发布。两者能力不对等,评测与选型需分开看待。
为何常见:品牌同名造成混淆,误以为开源版是产品版的完整权重释放。
误区trust_remote_code=True 只是让模型从网上下载配置文件,和 pip install 一样安全,对任何仓库都能开启。
正解该参数会执行模型仓库内的 Python 代码,等同于在本地运行任意第三方程序,存在供应链投毒风险。应只对官方可信仓库开启,下载后核验 sha256,企业内部还要做代码审查后再放行。
为何常见:把「远程代码」误解为「配置文件」,忽视了加载即执行的攻击面。
误区Skywork-13B 用 2 万亿 tokens 中英文训练,中文能力肯定全面碾压英文模型,任何中文任务都选它。
正解13B 规模在通用中文对话与 RAG 生成上表现良好,但在复杂中文推理、代码生成、数学解题等任务上仍弱于更大参数模型或专用模型。中文能力强是总体趋势,具体任务仍需用评测集验证,不能一概而论。
为何常见:以单一「中文能力」标签替代任务级评测,忽略了模型规模与任务类型对不同能力的制约。
面试题
Q1. Skywork-13B 预训练使用的中英文语料规模约为?
- A.20 亿 tokens
- B.200 亿 tokens
- C.2 万亿 tokens← 正确答案
- D.20 万亿 tokens
答案:C。Skywork-13B 官方模型卡标注其基于超过 2 万亿(2T)tokens 的中英文语料训练。20 亿与 200 亿量级远不足以支撑 13B 模型的通用能力,20 万亿则远超公开已知的任何开源模型训练规模。
Q2. Skywork-MoE 的总参数量与单个 token 的激活参数量分别是?
- A.13B / 3B
- B.75B / 3B← 正确答案
- C.75B / 13B
- D.38B / 7B
答案:B。Skywork-MoE 总参数 75B,每个 token 只激活 3B 参数。13B/3B 描述的是其初始化来源与激活量的组合,但总参不是 13B;75B/13B 与 38B/7B 均与官方数据不符。
Q3. SkyPile-150B 是指?
- A.一个 150B 参数的模型
- B.一个 150B tokens 的中文开源预训练数据集← 正确答案
- C.一个分布式训练框架
- D.一个推理加速工具
答案:B。SkyPile-150B 是昆仑万维随 Skywork-13B 开源的中文预训练数据子集,规模约 1500 亿 tokens。它是数据集而非模型或框架,用于支撑数据研究与继续预训练实验。
Q4. 以下哪些属于 Skywork 系列已开源的模型?
- A.Skywork-13B-Base← 正确答案
- B.Skywork-13B-Chat← 正确答案
- C.Skywork-MoE← 正确答案
- D.天工 3.0(4000 亿参数 MoE)
答案:ABC。Skywork-13B-Base、Skywork-13B-Chat、Skywork-MoE 均在 HuggingFace/ModelScope 开源。天工 3.0 是昆仑万维的闭源产品线模型,未开放权重,故不选。
Q5. 加载 Skywork-13B 时使用 trust_remote_code=True 的直接原因是?
- A.显著提升推理速度
- B.运行仓库自带的模型代码← 正确答案
- C.允许完全离线使用
- D.自动下载全部训练数据
答案:B。Skywork 模型仓库包含自定义的 modeling 代码,transformers 加载时需要该参数授权执行。它不加速推理、不负责离线与训练数据下载,纯粹是执行远端代码的开关,也因此带来供应链安全风险。
Q6. Skywork-R1V 相比 Skywork-13B-Chat 新增的核心能力是?
- A.视觉理解与思维链推理← 正确答案
- B.语音合成与识别
- C.代码自动执行
- D.文生图与视频生成
答案:A。Skywork-R1V 是 38B 视觉-语言模型,核心新增能力是图像输入与视觉思维链推理。语音、代码执行、文生图均不属于该模型的官方能力范围。
Q7. 在单块 24GB 显存 GPU 上以 BF16 精度加载 Skywork-13B-Base(权重约 26GB)会怎样?
- A.完全正常加载并推理
- B.直接 OOM,需量化或换更大显存← 正确答案
- C.自动丢弃部分权重运行
- D.自动溢出到硬盘运行
答案:B。BF16 下 13B 权重约 26GB,超过 24GB 显存上限,加载即 OOM。正确做法是使用 8bit/4bit 量化、更换 40GB 以上显卡,或通过 device_map 多卡拆分。模型不会自动丢弃权重或溢出到硬盘。
Q8. 下列哪些属于 Skywork-13B 开源的内容?
- A.全部模型权重文件← 正确答案
- B.SkyPile 数据集子集← 正确答案
- C.训练与推理代码← 正确答案
- D.完整 2 万亿语料全集
答案:ABC。Skywork-13B 开源了模型权重、SkyPile-150B 数据子集以及训练推理代码。完整 2 万亿 tokens 语料未全部公开,公开的只是 150B 子集,因此 D 不选。
Q9. 关于 Skywork-MoE 的正确说法有?
- A.每 token 仅激活 3B 参数← 正确答案
- B.部署时仍需加载全部 75B 权重← 正确答案
- C.单张消费级显卡即可完成部署
- D.与 Skywork-13B 存在权重继承关系← 正确答案
答案:ABD。Skywork-MoE 每 token 激活 3B、总权重 75B(约 150GB),部署需多卡张量并行,消费级显卡无法完成;它由 Skywork-13B 稠密权重初始化扩展而来。故 A、B、D 正确,C 错误。
Q10. 相比同总参数量的稠密模型,MoE 架构在推理阶段的主要收益是?
- A.总参数量明显减少
- B.单个 token 计算量下降← 正确答案
- C.显存占用大幅减半
- D.训练数据需求降低
答案:B。MoE 通过稀疏路由让每个 token 只经过部分专家,推理计算量(FLOPs)显著低于同总参数量稠密模型,从而提升吞吐。但总参数量不变、权重全部占用显存,也不降低训练数据需求,故 A、C、D 均不准确。
参考来源
- webpage昆仑万维官网公司动态与模型发布新闻