Yi-1.5 是零一万物（01.AI）于 2024 年 5 月发布的开源大语言模型系列，包含 6B、9B、34B 三个 Dense 尺寸和一个 MoE 架构版本（Yi-1.5-9B-MoE-A3B）。它基于 Yi 的爬坡继续训练，使用约 500B tokens 高质量语料做持续预训练，再用 300 万条偏好数据做 DPO 对齐，核心解决通用开源模型在中文、代码、数学任务上能力不足的问题。Yi-1.5 支持最高 200K token 上下文窗口，性能对标 Llama-3 与 Qwen1.5 同尺寸模型，权重以 Apache 2.0 协议开源，可免费商用。本文按“速览 → 安装 → 上手 → 深入 → 部署 → 选型”的顺序组织，覆盖从单卡体验到多卡生产部署的完整路径，并附常见误区与面试题，帮助读者一次上手。
掌握 Yi-1.5 的部署、推理与微调，是低成本构建中文 RAG 与 Agent 应用的基础能力，也是大模型工程岗位面试中的高频考察点。
目录
速览卡是工具类内容的固定首屏模块：30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Yi-1.5：开源模型的中文短板与长上下文痛点
主流开源模型长期以英文语料为主。以 Llama 系列为例，预训练数据中中文占比极低，直接使用时常出现中文回答生硬、成语误用、中文知识错漏等问题。同时，许多开源模型上下文窗口只有 4K-8K token，处理一份长合同或整页代码库就需要切片、重写 prompt，RAG 管线被迫做得复杂。企业私有化部署时，还得逐一核对每个模型的商用许可证，存在法律风险。
Yi-1.5 的解法是三件事：第一，用约 500B tokens 经过清洗、去重、配比调整的高质量语料继续预训练，显著提升中文、代码、数学能力；第二，用 300 万条偏好数据做 DPO 直接偏好优化，让模型“说什么、不说什么”对齐人类偏好，对话更可控；第三，全系列支持 200K 上下文，长文档可直接整段送入。34B 尺寸在中文综合能力上对标同期的 Qwen1.5-32B，而 6B 和 9B 让消费级显卡也能跑起来。
与同期竞品的气质差异在于：Yi-1.5 是“中文原生 + 长上下文 + 宽松 License”的组合。Meta 的 Llama 3 使用自定义社区许可，中文能力弱；Qwen1.5 能力均衡但更新节奏快（现已迭代至 Qwen2.5 系列）；DeepSeek-V2 的 MoE 版本推理高效但模型许可附加条款限制更多。Yi-1.5 的 Apache 2.0 协议意味着可以自由修改、商用、再分发，这对企业内部系统落地是实打实的便利。
安装与环境配置：3 步就绪
第一步，准备环境。Yi-1.5 基于 PyTorch 生态，建议 Python 3.10+，CUDA 11.8 或 12.1，NVIDIA 显卡驱动已就位。显存参考：6B 模型 FP16 权重约 13GB，9B 约 18GB，34B 约 68GB。
第二步，安装推理依赖。开发调试用 HuggingFace Transformers，生产部署用 vLLM。两者可共存，但注意 vLLM 对 CUDA 版本有要求，建议在独立虚拟环境安装。
第三步，验证加载。用 Python 一行命令加载 9B-Chat 模型并打印参数量，能正常输出即说明环境配置成功。首次运行会自动从 HuggingFace 下载约 18GB 权重，国内网络建议设置 HF_ENDPOINT=https://hf-mirror.com 加速。
python -m venv yi-env && source yi-env/bin/activatepip install torch --index-url https://download.pytorch.org/whl/cu121pip install transformers accelerate vllmexport HF_ENDPOINT=https://hf-mirror.compython -c "from transformers import AutoModel; m=AutoModel.from_pretrained('01-ai/Yi-1.5-9B-Chat', device_map='auto'); print(m.num_parameters())"
快速上手：10 分钟跑通第一个对话
最小可用流程的思路：直接加载 HuggingFace 上的 Chat 版权重，调用 apply_chat_template 把消息列表转成模型需要的 prompt 格式，再 generate 生成回复。注意 Yi-1.5 的 Base 版是续写模型，不会按对话方式回答，必须使用 Chat 版。
操作步骤：
1. 在终端进入上一步创建的 yi-env 虚拟环境；
2. 创建 chat.py 文件，写入下方 Python 脚本（模型名可替换为 01-ai/Yi-1.5-6B-Chat 或 01-ai/Yi-1.5-34B-Chat）；
3. 运行 python chat.py，等待权重下载与模型加载；
4. 看到输出即为成功。将 messages 中的 content 换成你的问题即可复用。
进阶技巧：加载时指定 torch_dtype="auto" 会自动匹配权重精度；若显存不足，加 model.half() 或改用 bitsandbytes 4bit 量化加载。
from transformers import AutoModelForCausalLM, AutoTokenizer model_name = "01-ai/Yi-1.5-9B-Chat"model = AutoModelForCausalLM.from_pretrained( model_name, device_map="auto", torch_dtype="auto")tokenizer = AutoTokenizer.from_pretrained(model_name) messages = [{"role": "user", "content": "用一句话解释什么是 RAG"}]prompt = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True)inputs = tokenizer(prompt, return_tensors="pt").to(model.device)outputs = model.generate(**inputs, max_new_tokens=256, do_sample=True, temperature=0.7)print(tokenizer.decode(outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))
核心能力详解：4 大支柱
支柱一：高质量数据持续预训练。 Yi-1.5 在 Yi 的基础上，用约 500B tokens 数据继续训练。这批数据经过了去重、信息密度过滤、代码与数学比例调优，而非简单堆量。官方称这一阶段显著提升了模型在代码、数学、逻辑推理上的表现，中文能力保持领先。
支柱二：DPO 直接偏好优化。 对齐阶段没有采用传统 PPO 强化学习，而是用 300 万条偏好对做 DPO。DPO 把 RLHF 的奖励建模与策略优化合并为一步，训练更稳定、显存开销更低。效果上，模型能学会拒绝不合适的请求、遵循指令格式，多轮对话一致性更好。DPO 的技术细节（偏好对构造、β 超参）是官方博客公开介绍的重点。
支柱三：200K 长上下文。 全系列支持最高 200K token 上下文窗口。配合 RoPE 位置编码外推，模型能在超长文本中保持注意力。实际使用中，200K 是上限而非默认值，显存开销随序列长度近似二次增长，生产部署需根据显卡显存谨慎设置 max-model-len。6B 与 9B 版本在消费级显卡上处理 32K 上下文是现实可行的。
支柱四：MoE 高效推理架构。 Yi-1.5-9B-MoE-A3B 总参数 9B，但每次推理只激活约 3B 参数。官方宣称相比同等能力的 Dense 模型，训练效率提升数倍，推理成本大幅降低，适合高并发在线服务。该版本与 9B Dense 版能力接近，但显存占用和单 token 延迟都更优，是低成本部署的首选。
生产部署与监控：从上线到运维
标准生产方案是 vLLM 部署。一条命令即可把 Yi-1.5 对话模型包装成 OpenAI 兼容 API，业务侧无需改代码：vllm serve 01-ai/Yi-1.5-9B-Chat --max-model-len 32768。vLLM 的 PagedAttention 机制能显著提升吞吐，支持张量并行（--tensor-parallel-size 2）在多卡环境切分 34B 大模型。启动后通过 http://localhost:8000/v1/chat/completions 调用，与 OpenAI SDK 兼容。
备用方案是 SGLang 或 HuggingFace TGI。SGLang 在长上下文场景下 RadixAttention 有优势；TGI 集成度高，一条 Docker 命令即可启动。单机低资源环境可用 Ollama 直接跑 6B/9B 量化版，但自定义采样参数能力较弱。微调场景则用 LLaMA-Factory，支持 LoRA 与全参微调，数据格式与 Yi-1.5 官方模板兼容。
可观测性方面，vLLM 暴露 Prometheus 指标（/metrics），重点监控 TTFT（首 token 延迟）、token/s 吞吐、KV cache 使用率、GPU 显存占用。用 Grafana 配置告警：平均时延超过 2 秒或显存超过 90% 时触发扩容。34B 模型部署建议至少 2×A100 80GB 或使用 AWQ 4bit 量化（权重约 17GB，可在 24GB 单卡运行）。
<p class=“para-label“>避坑清单：</p><ul class=”dash-list”><li>Base 与 Chat 混用：Base 版是纯续写模型，直接对话只会返回 prompt 的续写；务必加载 Chat 版，并用 tokenizer.apply_chat_template 构造输入。</li><li>max-model-len 设置过大：200K 是模型上限，显存开销随序列长度近似平方增长，直接开满会导致 OOM；按业务评估 8K-32K 即可，vLLM 中合理设置，不要盲目拉满。</li><li>tokenizer 不匹配：必须使用模型自带的 tokenizer，不能拿其他模型（如 Llama 的）替换，否则 BOS 符号与词表错位，输出乱码。</li><li>许可证误解：Yi-1.5 系列为 Apache 2.0 可商用，但早期 Yi（非 1.5 版本）许可证不同，商用前在 HuggingFace 对应模型卡上核对 License 字段。</li></ul>
| 维度 | Yi-1.5 | Llama 3（8B） | Qwen1.5（7B） | DeepSeek-V2-Lite |
|---|---|---|---|---|
| 定位 | 中文原生开源通用模型 | 英文生态开源旗舰 | 中英双语开源系列 | MoE 高性价比开源模型 |
| 架构 | Dense + MoE 双版本 | Dense | Dense | MoE（16B 总参 2.4B 激活） |
| 上下文长度 | 最高 200K | 8K | 32K | 128K |
| 训练数据 | 500B tokens 续训 + 3M 偏好对 | 15T+ tokens | 3T tokens | 8T tokens |
| 中文能力 | 强（中文语料配比高） | 较弱 | 强 | 强 |
| 许可证 | Apache 2.0 | Llama 3 社区许可（含附加条款） | Apache 2.0 | DeepSeek 模型许可（有限制条款） |
| 部署成本 | 6B-34B 灵活可选 | 8B 单卡可跑 | 7B 单卡可跑 | MoE 推理更省显存 |
| 适合谁 | 中文 RAG/Agent、私有化部署 | 英文工具链、Llama 生态用户 | 中英通用任务 | 高并发、低延迟在线服务 |
选型建议：中文业务、需商用宽松协议的场景首选 Yi-1.5 或 Qwen1.5（新项目可关注 Qwen 迭代版）；英文为主、依赖 Llama 生态插件时选 Llama 3；高吞吐 API 服务用 DeepSeek-V2 或 Yi-1.5 MoE。三者许可证差异明显，商用前务必逐条核对。
版本迭代
Yi-1.5 的演进主线是“数据质量升级 + 对齐方法升级 + 架构扩展”。2024 年 1 月首发 Yi（6B/34B），2024 年 5 月发布 Yi-1.5（6B/9B/34B），用 500B tokens 续训和 DPO 对齐取代了初版的 SFT 路线；2024 年 10 月发布 Yi-1.5-9B-MoE-A3B，将系列扩展至 MoE 架构。截至 2025 年初，Yi-1.5 系列最新正式版为 Yi-1.5-9B-MoE-A3B，零一万物后续重心转向 Yi-Lightning 闭源 API 与 Yi-Coder 系列。
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| Yi（6B/34B） | 2024-01 | 首版开源系列 | 中英双语基座，34B 支持 200K 长上下文 |
| Yi-1.5（6B/9B/34B） | 2024-05 | 500B tokens 持续预训练；3M 偏好对 DPO 对齐 | 代码、数学、中文推理显著提升；新增 9B 中间尺寸 |
| Yi-1.5-9B-MoE-A3B | 2024-10 | MoE 混合专家架构（总参 9B、激活约 3B） | 推理成本大幅低于同能力 Dense 模型，适合高并发部署 |
Yi-1.5 的版本节奏体现“先做数据与对齐升级，再做架构降本”的思路。官方在发布时公布了与 Llama-3、Qwen1.5 同尺寸模型的对比评测（MMLU、C-Eval、GSM8K、HumanEval 等），Yi-1.5 在中文综合能力上处于同尺寸第一梯队，具体分数以各模型卡公布数据为准。选型建议：追求低部署成本选 MoE 版，追求单模型最强能力选 34B Dense 版，消费级显卡开发调试选 9B 或 6B。
AI 应用场景
中文企业知识库 RAG
阶段：RAG 管道构建
解决的问题：通用开源模型对中文专业术语理解弱，在金融、法律等垂直领域回答问题易出错。Yi-1.5 中文语料占比高，配合向量检索生成答案更准确；200K 长上下文让整篇合同、招股书可直接送入，减少切片丢失信息。
具体案例：某企业内部文档问答系统采用 Yi-1.5-9B-Chat + vLLM + 中文向量库（如 bge-m3）构建。9B 模型 FP16 权重约 18GB，搭配 32K 上下文，单张 A10/RTX 4090（24GB）即可部署，无需单独 GPU 集群。系统在“检索-阅读-生成”三段式管线中，用 200K 窗口直接处理长文档原文，替代了原先的多轮切分摘要流程。
私有化代码助手
阶段：Agent 编排与代码生成
解决的问题：代码数据涉及企业保密要求，不能调用外部 API。Yi-1.5 在 500B tokens 续训中提高了代码语料配比，代码生成与解释能力可满足内部开发场景，Apache 2.0 协议允许部署在内网。
具体案例：研发团队将 Yi-1.5-9B-Chat 部署在内部 GPU 服务器，通过 OpenAI 兼容接口接入 IDE 插件，提供函数级代码补全、单元测试生成、代码 review 建议。模型以 max_model_len=16384 运行，单卡 vLLM 实例支撑团队日常调用，代码补全延迟控制在秒级，避免了代码片段外传的安全风险。
长文档 Agent 后端
阶段：Agent 编排
解决的问题：普通模型上下文窗口短，Agent 在阅读长报告时被迫反复截断重读。Yi-1.5 的 200K 窗口让 Agent 一次读入完整材料，配合工具调用完成摘要、问答、要点提取。
具体案例：使用 Yi-1.5-9B-MoE-A3B 作为 Agent 推理后端，将几十页项目文档一次性注入上下文，模型自主决定调用检索工具或直接回答。MoE 版激活参数约 3B，单 token 生成时延低于同能力 Dense 模型，符合 Agent 多轮工具调用的低延迟要求。
常见误区
误区“Yi-1.5 听起来像是把 Yi 的参数量扩大了 1.5 倍，所以能力更强的版本参数量一定更大。”
正解1.5 是版本号，与参数量无关。Yi-1.5 在 Yi 基础上做的是约 500B tokens 高质量语料的持续预训练（continue pretraining），再叠加 300 万条偏好对的 DPO 对齐，属于训练方法与数据的全面升级，而非单纯增加模型尺寸。系列仍保持 6B、9B、34B 三档参数规模。
为何常见：软件行业常用版本号表示大版本升级，且“更大参数 = 更强能力”的印象深入人心，容易把版本号误解为参数量倍数。
误区“同样是 Yi-1.5，加载 Base 权重直接传入问题就能得到回答，和 Chat 版区别不大。”
正解Base 版是自回归续写模型，训练目标是预测下一个 token，不会识别“你问我答”的对话格式。直接输入问题，它会顺着你的话继续写下去而不是回答。必须使用 Chat 版，并通过 tokenizer.apply_chat_template 将消息列表转换为带特殊标记的 prompt，模型才会按对话方式生成。
为何常见：HuggingFace 上 Base 和 Chat 文件结构相似，且很多入门教程直接用 AutoModel 加载演示续写效果，容易让新手误以为两者等价。
误区“既然官方说支持 200K 上下文，那我生产环境直接把 max-model-len 设成 200000，所有长文档都能一次处理。”
正解200K 是模型能力上限，不是推荐配置。注意力计算的显存开销随序列长度近似二次增长，开满 200K 时即使 34B 模型也需要大幅超出常规 GPU 显存。生产环境应根据业务真实长度设置（大多数场景 8K-32K 足够），并评估显存余量，必要时结合长度外推或上下文压缩。
为何常见：厂商宣传强调上限数字，用户容易忽略物理资源约束；本地短文本测试也测不出长序列的显存压力。
误区“Yi-1.5 主打中文，那英文任务、代码任务肯定很弱，只适合中文场景。”
正解Yi-1.5 是中英双语模型，官方发布时同步公布了英文基准（如 MMLU、GSM8K、HumanEval）的评测，英文与代码能力均达到同尺寸开源模型的主流水平，并非“只能用中文”。其差异化优势在中文，但英文与代码任务完全可胜任。
为何常见：国产模型的宣传重心在中文能力，“中文原生”的标签容易让用户形成“偏科”的刻板印象。
面试题
Q1. Yi-1.5 系列的发布时间与主要升级方向是？
- A.2024 年 1 月，仅扩充参数量
- B.2024 年 5 月，高质量续训 + DPO 对齐← 正确答案
- C.2023 年 11 月，新增多模态能力
- D.2024 年 5 月，全套切换 MoE 架构
答案：B。Yi-1.5 于 2024 年 5 月发布，核心升级是约 500B tokens 高质量语料持续预训练与 300 万条偏好对 DPO 对齐。A 错误，参数量仍为 6B/9B/34B；C 错误，Yi-1.5 是纯文本模型；D 错误，该版本仍以 Dense 为主，MoE 版是 2024 年 10 月补充发布。
Q2. Yi-1.5 开源系列包含哪三个 Dense 参数量？
- A.70B / 130B / 700B 三档
- B.6B / 9B / 34B 三档← 正确答案
- C.13B / 70B / 405B 三档
- D.3B / 8B / 14B 三档
答案：B。Yi-1.5 发布时提供 6B、9B、34B 三个 Dense 尺寸，其中 9B 是新增的中间档位，兼顾消费级显卡部署与模型能力。13B/70B/405B 是 Llama 2/3 系列的参数分布，3B/8B/14B 是其他厂商模型的常见分类，均与 Yi-1.5 不符。
Q3. Yi-1.5 系列的模型权重使用何种开源协议？
- A.Llama 3 社区许可协议
- B.Apache 2.0 开源协议← 正确答案
- C.CC BY-NC 4.0 非商用协议
- D.仅限学术研究不可商用
答案：B。Yi-1.5 在 HuggingFace 上标注为 Apache 2.0，允许自由使用、修改、商用与再分发。Llama 3 使用 Meta 自定义社区许可，附加条款更多；CC BY-NC 禁止商用；D 与官方的免费商用宣称矛盾。
Q4. Yi-1.5 的对齐训练主要采用哪种方法？
- A.PPO 强化学习（RLHF）
- B.DPO 直接偏好优化← 正确答案
- C.仅有监督微调
- D.基于人类反馈的拒绝采样
答案：B。官方说明 Yi-1.5 使用约 300 万条偏好对进行 DPO 训练。DPO 将奖励建模与策略优化合并为直接优化目标，训练比 PPO 更简单稳定。A 是传统 RLHF 路线，C 缺少偏好对齐环节，D 不是 Yi-1.5 官方使用的对齐方案。
Q5. Yi-1.5-9B-MoE-A3B 名称中的"3B"指什么？
- A.模型总参数量为 3B
- B.每层网络固定 3B 参数
- C.激活参数量约 3B，总参数 9B← 正确答案
- D.训练使用了 3B tokens 数据
答案：C。MoE（混合专家）架构将网络拆分为多个专家子网络，每个 token 只路由到部分专家。A3B 表示总参数 9B、激活参数约 3B，推理时仅计算激活参数，从而降低成本。A 混淆了激活与总参，B、D 曲解了命名规则。
Q6. 生产环境用 vLLM 部署 Yi-1.5 对话模型时，正确的做法是？
- A.直接部署 Base 模型并按原始 prompt 调用
- B.max-model-len 直接设为 200000 获得最强效果
- C.部署 Chat 模型，合理设置 max-model-len← 正确答案
- D.强制用 float32 精度保证准确性
答案：C。生产部署应选择 Chat 版并调用其对话模板；max-model-len 需根据显存与业务长度合理设置（如 32768），而非盲目拉满 200K，否则显存 OOM。Base 模型不会按对话方式回复；float32 精度对现代 GPU 不是必需项，半精度即可满足精度要求且省显存。
Q7. Yi-1.5 相比初版 Yi，在训练阶段的核心差异是什么？
- A.用约 500B tokens 高质量语料继续预训练再做 DPO← 正确答案
- B.从零重新训练并扩大三倍数据量
- C.仅增加强化学习，未新增预训练数据
- D.将全部尺寸切换为稀疏 MoE 架构
答案：A。Yi-1.5 采用“持续预训练 + DPO”路线：在 Yi 权重基础上用 500B tokens 续训，再用 3M 偏好对做 DPO。它不是从零训练（B 错），也不是只加对齐不加数据（C 错），Dense 仍是主力尺寸、MoE 为补充版本（D 错）。这种“继续爬坡”策略大幅节约了训练成本。
Q8. 下列哪些方式可以加载或部署 Yi-1.5 系列模型？
- A.HuggingFace Transformers← 正确答案
- B.vLLM 推理服务← 正确答案
- C.SGLang 推理框架← 正确答案
- D.Adobe Photoshop 插件
答案：ABC。Yi-1.5 权重托管在 HuggingFace，Transformers 可直接加载推理；vLLM 和 SGLang 是生产级推理框架，均支持 Yi-1.5。Photoshop 是图像处理软件，与 LLM 推理无关。
Q9. 关于 Yi-1.5 的 200K 长上下文，以下说法正确的是？
- A.官方宣称系列最高支持 200K 上下文窗口← 正确答案
- B.实际可用长度受显存资源限制← 正确答案
- C.所有业务场景都应直接使用 200K 窗口
- D.部署时需根据显存调整 max-model-len← 正确答案
答案：ABD。200K 是模型能力上限，官方宣称支持；但注意力内存开销随序列长度近似二次增长，实际可用长度由显存决定，因此业务上按需设置 8K-32K 更稳妥。C 的观点忽视资源约束，是错误的。D 是生产部署的正确姿势。
Q10. 单卡 24GB 显存环境部署 Yi-1.5-34B-Chat，合理的降本手段包括？
- A.使用 AWQ 等 4bit 量化权重← 正确答案
- B.使用 vLLM 的 KV cache 量化特性← 正确答案
- C.不做任何处理直接加载 FP16 权重
- D.使用 bitsandbytes 的 4bit 量化加载← 正确答案
答案：ABD。34B FP16 权重约 68GB，远超 24GB 单卡，必须量化。AWQ（约 17GB 权重）可配合 vLLM 部署，KV cache 量化进一步降低显存；bitsandbytes 提供 4bit 加载，适合 Transformers 快速开发。C 直接加载 FP16 必然 OOM。
参考来源
- webpage零一万物官网公司动态与 Yi-Lightning 等新产品信息