vLLM

vLLM

01-大模型技能点和相关概念

image-20261011124654613

RAG agent workflows 以 LLM 为基础的应用

微调， 优化， 蒸馏， 量化， 推理部署，训练 ai 相关算法的研究

1- MoE

MoE 就是 Mixture of Experts，混合专家，现在大模型最火的那种省算力的结构设计。

核心思路：一套大模型，里面藏了好多个"专家"

传统 Transformer 模型里，每个 token（词）过所有参数算一遍。MoE 的思路是：不再让全部参数都干活，而是 每个 token 只挑一小部分"专家"子网络来算。

输入 token
   │
   ▼
[路由器 Router/Gating]  ──→ 挑 2~3 个最合适的专家
   │
   ├── 专家1 ██
   ├── 专家2 ███    ← 只有被选中的专家在干活
   ├── 专家3 █
   └── 专家4 ██
   │
   ▼
把选中的专家结果加权合并 → 输出

几个关键点：

  1. 路由器（Router/Gating） ：一个小的门控网络，给每个 token 算"去哪个专家最合适"，通常选 top-k（一般 k=2，也就是挑 2 个）。
  2. 专家（Experts） ：每个专家就是一个小的 FFN（前馈网络）子块。专家之间各管一类知识——比如有的擅长数学、有的擅长编程、有的擅长闲聊（这是训出来的分工，不是人定的）。
  3. 稀疏激活（Sparse） ：名字里的精髓。整个模型参数很多（MoE 可以把参数量堆到几千亿，因为它"看起来大"），但每次只激活一小部分——所以推理时计算量并不随总参数涨，这就是它省算力的原因。
  • 同样的算力，更大的容量：模型总参数量可以很大（知识容量大、学得多），但每次推理只花小部分算力——"看起来大、跑起来便宜"。
  • 代表作品：Mixtral 8x7B、DeepSeek-V3、GPT-4 早期也有 MoE 结构、Gemini 也用了。DeepSeek 就是靠 MoE + 极致的成本控制出圈的。
  • MoE 是"内存换带宽"的游戏：所有专家参数必须常驻显存，只是不都算。所以 MoE 模型对显存要求高，但推理时计算快。

普通模型像"一个人啥都会但慢"；MoE 像"一家公司，几十个专家顾问，你来了前台（Router）快速判断你最可能有哪个专家擅长，只喊少数几个人来帮你——公司人很多，但你每次只见 2 个，所以又快又"人多势众"。

2- RAG agent workflows

✅ ① RAG 开发（检索增强生成，Retrieval-Augmented Generation）

解决什么问题：大模型"知识过期、不知道私有/实时信息、爱瞎编"。

核心思路：不指望模型记住所有知识，而是先检索，再生成。

用户问题 → ①把问题转成向量 → ②去知识库检索最相关的片段

​                                   ↓

​        ④模型基于【问题+检索到的片段】生成答案 ← ③拼进 Prompt
  • 关键组件：文档切块（Chunking）、向量化（Embedding）、向量数据库（存+检索）、把命中片段塞进提示词。
  • 典型场景：客服问答、企业知识库、文档助手——"让模型基于你自己/最新的资料回答"。
  • 一句话：模型记不住的，就从外部知识库里查出来喂给它回答，不再瞎编。

✅ ② Agent 开发（智能体）

解决什么问题：让模型不仅能聊，还能主动干活、调用工具、自主决策去完成一个目标。

核心思路：模型当"大脑"，会拆解任务 → 决定调用什么工具 → 执行 → 看结果 → 继续推进，直到目标完成。

用户目标

   ↓

[大模型大脑]: 规划步骤

   ↓

[工具调用]: 搜网页 / 查数据库 / 调API / 操纵软件 / 发消息...

   ↓

[观察结果] → 再决策 → 循环，直到完成
  • 关键点：工具调用（Function Calling/Tool Use）、任务规划（Plan）、多步循环（Reasoning → Acting → Observing，即 ReAct）。
  • 典型场景：帮你去订票、自动化办公、自主调研写报告、控制软件。
  • 一句话：从"会回答问题"升级到"会办事"——自己查、自己干、干不完继续干。

✅ ③ Workflow 开发（工作流）

解决什么问题：把一个固定的、多步骤的任务，用预先编排好的流程稳定地串起来，每一步分配不同的模型/工具/逻辑。

核心思路：和 Agent 的"模型自由发挥"不同，Workflow 是把流程写死——像流水线一样，按你设计的步骤一步步走，每个节点是确定的。

输入 → 节点A(抽取出字段) → 节点B(调知识库) → 节点C(模型生成) → 分支判断 → 输出

​        （可用不同模型/工具/条件分支）               （可循环/可并行）
  • 关键点：节点编排、条件分支（if/else）、循环、并行、人机确认节点、可视化的流程画布（扣子/Coze 这类平台就是做这个的）。
  • 典型场景：自动审批流、内容批量生成流水线、"先审后发"这类要求稳定、可预期的流程。
  • 一句话：像搭积木一样把固定流程画出来，稳定可复用，不依赖模型临场发挥。

三者的关系和取舍（重点）：

Workflow RAG Agent
本质 固定流水线 给模型喂"查来的知识" 让模型自主决策干活
可控性 最高（流程你定） 高 低（模型自由）
灵活性/自主性 低 中 最高
适用 稳定、标准化的流程 基于私有/最新知识的问答 复杂、需要临场决策的任务
  • RAG 和 Agent/Workflow 不是对立的，RAG 常常作为其中一个节点/子能力被集成进 Agent 或 Workflow 里（比如"先检索再让 Agent 分析"）。
  • Workflow vs Agent 常被放一起对比：要走确定的流程就选 Workflow（可控），要应付不确定的复杂任务就让 Agent（灵活） 。业界有个形象说法—— "能上规则就上规则（Workflow），规则搞不定的才让 Agent 自由发挥" 。

一句话总结这张图：这是大模型应用开发的三大技能路线——用 RAG 补知识、用 Workflow 搭稳定流程、用 Agent 做自主智能体，实际项目里三者经常组合使用（Workflow 里套 RAG 节点、Agent 里也能用 RAG 工具）。

3- 训练 微调 蒸馏 量化 优化 部署推理

① 训练（Training）——"从零学会"

  • 做什么：拿海量文本，让模型从随机参数开始，学"下一个词是什么"。这是最烧钱最算力的一步，需要几千张 GPU、跑几个月。
  • 产物：得到一个"什么都知道一点"的基础模型（基座，如 Llama、GPT） 。
  • 特点：通用但不会听指令、不一定专业。

② 微调（Fine-tuning）——"定向补课"

  • 做什么：在训练好的基座基础上，用小得多的数据集（比如几千条客服对话）继续训练，让模型学会特定任务或领域的说话方式。
  • 关键点：它不是从零学，而是"在已有能力上打补丁"，成本远低于训练。
  • 代表方法：LoRA / QLoRA（只训练一小部分参数，省显存省算力）、RLHF（用人类反馈调优，让模型说人话）。

③ 优化（Optimization）——"让模型跑得更快更好"

  • 做什么：一个总称，泛指一系列让模型在推理速度、显存占用、精度上更优的手段。注意它是个大筐，下面这些概念很多都属于"优化"。
  • 常见优化手段：量化（省内存）、蒸馏（变小）、剪枝（砍掉不重要的参数/连接）、KV Cache 优化（加速推理）、算子融合（减少多次读写）。
  • 简单说：微调是"改内容"（让它更懂），优化是"改性能"（让它更快更省）。

④ 蒸馏（Distillation）——"大模型带小徒弟"

  • 做什么：让一个大而强的模型（教师 Teacher）去教一个小而快的模型（学生 Student）——学生模仿老师的输出，从而在接近老师能力的前提下大幅缩小模型。
  • 类比：名师带高徒，徒弟脑子没师傅全，但学到八成功夫，却小得多、跑得飞快。
  • 用途：想要一个能塞进手机/端侧、还不错的模型时用。这是"变快变省但不失智"的主要路径之一。

⑤ 量化（Quantization）——"档案精简"

  • 做什么：把模型参数的精度降低，例如从 FP16（每个权重16位）压到 INT8 / INT4（8位/4位）。
  • 效果：权重文件更小（显存占用降 2~4 倍）、推理更快；代价是精度略降（但有量化感知训练等技术尽量保精度）。
  • 类比：同样一段话，你存在高清图（占空间）vs 压缩图（省空间、略微模糊）。量化就是"压成省空间的版本，糊一点点也能接受"。
  • 火的原因：这正是普通人能"本地跑大模型"的关键——几百 GB 的模型量化到几十 GB，消费级显卡才带得动。

⑥ 推理部署（Inference & Deployment）——"真正上线给人用"

  • 做什么：把训练/微调好的模型加载起来、对外提供服务，接收用户请求、实时给结果。
  • 关键问题：
    • 吞吐量（同时能服务多少人）、延迟（回一条多快）；
    • 显存管理（模型多大、能不能装下、能不能上多卡）；
    • 并发与流式输出（还记得你学的 CUDA 流吗——推理服务就是重度用流和并发重叠的地方）；
    • 常用工具/框架：vLLM、TensorRT-LLM、Ollama、vLLM + PagedAttention、TensorRT。
  • 和前面区别：训练/微调是"把模型做好"，推理部署是"把它磨到能稳定、快速、低成本地对外服务"——性能优化（量化、蒸馏）最终都是为了这一环省钱。
训练(从零造) → 微调(定向补课) → 优化(变快省) → 部署(上线给人用)
                         │        ├── 量化(压精度省显存)
                         │        └── 蒸馏(大教出小)

秒懂版本：

  • 训练 = 生孩子（最贵）
  • 微调 = 送去专业培训（便宜、补课）
  • 优化 = 减肥+提速（泛指）
  • 量化 = 压缩档案省空间（踩精度换速度）
  • 蒸馏 = 大模型带小徒弟（变小不弱化太多）
  • 推理部署 = 正式开业营业（把上面所有功夫变现成"响应用户"）

02-vLLM推理引擎核心框架

image-20261011131051341

image-20261011131203290

image-20261011131240780

一些专业名词的中英文对照

中文	英语
推理（模型跑起来给结果）	Inference（读作 /ˈɪnfərəns/）
训练	Training
微调	Fine-tuning
蒸馏	Distillation
量化	Quantization
部署	Deployment
推理引擎/推理框架	Inference engine / Inference framework

predict next token

预测 下一个词是什么？

根据模型的训练参数，得到一个多分类的概率分布， 取概率最大的 值，和词表进行对应

image-20261011133025546

01-推理流程概述

image-20261011133957426

image-20261011134122066

image-20261011134352669

image-20261011134925693

image-20261011135203770

image-20261011135633645

image-20261011135740633

image-20261011140626361

02-推理的核心问题

image-20261011140847474

03-Page Attention: 基于分页的动态 KV缓存机制

image-20261011142125179

  • KV Cache 是什么：LLM 自回归生成时，要把之前算过的 Key/Value 缓存下来，避免每步重算——这是 LLM 推理显存的头号消耗大户。
  • 传统做法：按最大长度整块预分配 → 利用率低（20~30%）；
  • PagedAttention 的做法：借鉴操作系统分页/虚拟内存——把 KV Cache 切成小页、用块表做逻辑↔物理映射、按需分配 → 利用率 96%+。
  • 为什么重要：显存省下来了，就能同时塞进更多请求 → 支撑起上一页的连续批处理，大幅提高吞吐。

Paged Attention = 给 KV Cache 套上"OS 虚拟内存分页"，按需分配、几乎零浪费，让连续批处理和超高吞吐成为可能——这是 vLLM 一举成名的核心技术。

image-20261011144337148

「静态批处理 vs 动态批处理（Static Batching vs Dynamic Batching） 」——讲 AI 推理服务里怎么把多个请求合在一起跑的两种策略，配了两条时间线图：

Static Batching（静态批处理）

R1 R2 R3 R4 │ R1 R2 R3 R4 │ R1 R2 R3 R4
     ↑──── 固定的 batch，整批一起等 │ ↑
──────────────────────────────► Time
  • 做法：请求按固定批次（batch）收集，凑满一批才一起送进 GPU 算，整批同时开始、同时结束。
  • 问题（图中可以看出）：每个批次要等最后一个请求到齐才开跑；一批里跑得快的请求也要等整批最慢的做完才返回。所以延迟高、GPU 有空窗。缺点是利用率/延迟不佳。

Dynamic Batching（动态批处理）

R1 R2 R3 │ R1 R2 R3 R4 │ R1 R2 R3 │ R1 R2
     ↑── 到达就进，到窗口/到量就发 │ ↑
──────────────────────────────► Time

  • 做法：请求到了就进当前批次，不傻等凑满；只要满足 "等待时间到了"或"攒够一定数量" 就立即把现有的打包开跑。每个批次的请求数量可以不一样（图里 3 个、4 个、3 个、2 个…）。

  • 好处：不用等最后一个到齐，延迟更低，GPU 持续有活干，利用率更平滑。

  • 静态批处理 = "攒满一桌才开席"——整齐但慢、有空窗；

  • 动态批处理 = "来一桌开一桌，凑几个就走"——更灵活，是现代推理引擎（比如 vLLM、TensorRT-LLM）的标准做法。

结合前面概念：这正是你问的"推理部署（inference deployment） "里最核心的吞吐优化手段之一——动态批处理能显著提升服务器同时服务多个请求的吞吐量、降低排队延迟。

image-20261011145213361

连续批处理（Continuous Batching） 」——现代 LLM 推理引擎（vLLM、TensorRT-LLM）吞吐优化的核心机制，比上一页的动态批处理又进了一步。图里用"请求 × 时间步"的网格来对比两种方案：

Continuous Batching（连续批处理）

左侧 = 动态批处理的"空等"问题：

  • 每个d序列（S）在自己的那批里占着一整行的时间，但它每个 token 步只算一次，其余时间（空白）就是在干等。
  • 问题：batch 里只要有一个慢的序列，其他序列就得陪着等；那些已经结束的序列占的算力位置，新的请求进不来，GPU 利用率被白白浪费。

右侧 = 连续批处理：token 级流水线（新请求随时插队）：

  • 每个序列的 token 是异步推进的，完成一个（END）就立刻腾位，让新请求（S5、S6、S7）随时插进来；

  • 每个时间步 GPU 都在算当前 batch 里所有活跃序列的下一步 token，不空转。

  • 动态批处理是 "请求级" 的批：一批请求一起进、一起出，慢的拖累快的；

  • 连续批处理（PagedAttention 的基础） 是 "token 级" 的批：把 batch 拆到每一步去精细调度——谁生成了 token 就继续跑，谁生成完就腾位，新请求立即补上。

  • 好处：GPU 每个时间步都满负荷运转，延迟更低、吞吐更高，尤其适合 LLM 这种自回归、每个请求长度不一（decode 步数不同） 的场景。

连续批处理 = "流水线上谁做完谁走、新活随时插队"，把 batch 从"请求的批次"细化为"每次 token 的批次"，这是大模型推理高吞吐的秘密武器。

04-什么是推理引擎

image-20261011151300915

github 上的类vLLM 项目

image-20261011152615896

image-20261011152040729

image-20261011152407040

image-20261011152425495

03-Qwen3 部署和微调

1- Qwen3

Qwen3（千问3）是阿里巴巴通义千问团队于2025年4月29日发布的第三代大语言模型系列‌，是国内开源大模型的标杆产品，同时提供开源权重版本与云端API服务，核心定位是平衡前沿AI性能与推理效率，覆盖从端侧小模型到万亿参数旗舰模型的全场景需求。

📊 完整模型阵容

Qwen3系列提供了覆盖不同规模的丰富模型矩阵，满足各类部署场景：

  • ‌6款密集（Dense）模型‌：参数量从0.6B到32B不等，其中0.6B等轻量模型可直接在手机、嵌入式设备等终端本地运行，资源占用极低。
  • ‌2款混合专家（MoE）架构模型‌：旗舰级Qwen3-235B-A22B总参数2350亿，激活参数仅220亿；Qwen3-30B-A3B激活参数仅30亿，性能可媲美更大规模的密集模型，大幅降低推理成本。
  • ‌闭源旗舰版本‌：后续推出的Qwen3-Max-Preview总参数量突破1万亿，支持256K上下文窗口，在多项国际权威评测中超越Claude-Opus 4、Kimi-K2等主流闭源模型。
  • ‌垂直领域衍生模型‌：包含Qwen3-VL多模态视觉模型、Qwen3-Coder编程专用模型、Qwen3-Embedding文本检索模型、Qwen3-Omni全模态音视频模型等专项版本。

✨ 核心技术亮点

  • ‌首创混合推理机制‌：国内首个实现“思考模式”与“非思考模式”无缝切换的大模型，简单问答场景自动启用高速模式降低延迟，复杂数学、代码任务自动切换深度推理模式提升准确率。
  • ‌超强多语言能力‌：基于36T tokens的海量预训练数据训练，原生支持119种语言及方言，大幅优化跨语言任务表现，减少语言切换错误。
  • ‌原生Agent支持‌：内置MCP协议标准，标准化外部工具调用流程，配合Qwen-Agent框架可快速构建浏览器助手、自动化工作流等智能体应用。
  • ‌超长上下文能力‌：基础版本支持256K token上下文，后续通过技术扩展可支持最高100万token的超长窗口，轻松处理整本书籍、大型代码库的一次性解析。

🌐 开源生态与使用方式

Qwen3全系列开源模型遵循‌Apache 2.0许可证‌，完全免费支持商业使用，可直接在Hugging Face、魔搭社区等平台下载权重。

  • 本地部署支持llama.cpp、Ollama、LM Studio等主流框架，普通消费级显卡即可流畅运行7B/14B参数版本。
  • 大规模生产环境可通过vLLM、SGLang等推理框架实现高并发部署，阿里云百炼平台同时提供全系列模型的云端API调用服务。
  • 截至2025年6月，Qwen3全球累计下载量已突破1250万次，0.6B、8B、30B、32B四款热门尺寸模型下载量均超过百万。

🚀 典型应用场景

  • ‌企业级智能助理‌：基于开源版本快速搭建内部知识库问答系统，配合检索增强生成（RAG）能力实现精准的企业内部信息查询。
  • ‌代码开发辅助‌：Qwen3-Coder在SWE-Bench Verified基准测试中取得69.6分的领先成绩，可直接生成完整可运行的复杂前端项目、自动化脚本。
  • ‌端侧AI应用‌：0.6B/1.8B等轻量模型可离线部署在智能设备中，实现无网络环境下的语音交互、本地文档处理功能。
  • ‌多模态内容处理‌：Qwen3-VL和Qwen3-Omni支持图片识别、音频交互、视频内容理解，可用于文档OCR、智能客服、内容审核等场景。

image-20261011184636299

image-20261011185249246

2- ModelScope（中文名：魔搭社区）

ModelScope（中文名：魔搭社区）‌ 是由阿里巴巴达摩院与中国计算机学会于2022年11月联合推出的国内头部AI开源模型社区，定位为“AI模型的GitHub”，是面向全球开发者的一站式“模型即服务（MaaS）”共享平台 。

核心发展规模

截至2026年4月，社区已汇聚超‌17万个开源模型‌，服务全球‌2500万开发者‌，模型总下载量突破1亿次，用户覆盖200多个国家和地区 。平台不仅汇集了Qwen、DeepSeek、Kimi等头部大模型，还联合20余所国内高校共建学术合作体系，线下开发者中心已入驻超100个AI创业团体 。

核心功能与特色

  1. ‌全领域模型库‌
    覆盖自然语言处理、计算机视觉、语音、多模态、科学计算五大AI方向，从0.5B到110B全参数规模模型均有收录，每个模型都附带详细文档、在线体验入口和开源协议说明 ‌官网。
  2. ‌极简开发API‌
    提供封装完善的Pipeline接口，仅需3行Python代码即可完成模型加载与推理，自动处理环境依赖、数据预处理和后处理，大幅降低AI开发门槛 。
  3. ‌全流程微调部署‌
    内置Training API支持自定义数据集快速微调预训练模型，无需从零搭建训练框架；还支持大模型一键部署至阿里云边缘云节点，快速落地生产环境 。
  4. ‌活跃开源生态‌
    配套提供中文语料库、医学影像数据集等海量开源数据集，支持Git版本管理；同时上线了开发者激励体系“魔粒体系”，鼓励用户分享模型、教程和AI应用项目 ‌官网。

典型使用场景

  • 快速在线体验各类AI模型效果，无需本地部署
  • 基于预训练大模型微调定制垂直场景专属模型
  • 低成本搭建AI智能体、多模态生成等创新应用
  • 学术研究中获取标准化的模型基准与复现环境

ModelScope魔搭社区官网 浏览完整模型库和官方入门教程 ‌官网。

image-20261011190937627

3- LoRA 高效微调原理

image-20261011191323494

🎯 AI大模型高效微调LoRA原理对比

这张图清晰展示了传统全量微调与LoRA低秩适配两种大模型权重更新机制的核心差异，是理解参数高效微调的经典示意图。

📊 常规全量微调的权重更新逻辑

  • ‌核心流程‌：输入维度为d的特征，经过预训练权重矩阵W后，直接学习一个完整的权重更新矩阵ΔW，最终输出结果为W与ΔW的叠加。
  • ‌特点‌：ΔW是和W同维度的满秩矩阵，参数量规模为d×d，训练时需要更新模型全部的增量参数，计算和显存开销极大。

🔍 LoRA低秩适配的核心机制

  • ‌核心思路‌：不直接学习完整的ΔW，而是用两个极小的低秩矩阵A和B的乘积来近似ΔW，即ΔW ≈ B·A。

  • ‌关键细节‌：两个低秩矩阵的内维度r是人为设置的超参数，r的取值远小于原始权重矩阵的维度d，这让新增可训练参数量从O(d²)骤降到O(r·2d)，通常仅为原模型总参数量的0.1%～1%。

  • ‌训练特性‌：预训练权重W全程完全冻结，仅训练低秩矩阵A和B，大幅降低训练门槛，同时推理时可直接将A、B合并回原始权重，不会带来额外推理延迟。

    ✨ 两者核心差异对比

    对比维度 常规全量微调 LoRA微调
    可训练参数 全量ΔW，参数量极大 仅低秩矩阵A、B，参数量极少
    显存需求 极高，大模型需数百GB显存 极低，单消费级GPU即可支持7B级模型微调
    推理延迟 无额外开销 合并权重后无额外开销
    灾难性遗忘风险 高，直接修改全部原始权重 极低，原始预训练权重完全保留

4-上下文长度（Context Length)

image-20261018084747592

上下文长度是指 提示词的长度 + reponse 回复的长度 之和。

什么是上下文长度（Context Length）

模型一次能"同时看到并记住"的 token 数量上限。

大模型是自回归的：每生成一个词，都要基于它前面已经看到的所有词来预测下一个。上下文长度就是它这个"前面看过多少"的窗口上限。

你输入的问题 + 历史对话 + 它正在生成的回答   ← 所有这些都算"上下文"
[──────────────────────────────────────────]
                  ↑ 长度上限 = 上下文窗口

两个重要概念要分清

概念 含义
训练时上下文（训练窗口） 模型训练时用的窗口大小（比如 128K、1M token）
推理时上下文 实际部署时能支持的窗口。推理窗口可以比训练窗口更长（通过 RoPE 外推 / 位置插值等技术），但质量可能下降

关键：训练窗口决定模型"基准能力"，推理窗口是部署时的灵活上限。

上下文长度由什么决定？（硬件约束是最硬的）

上下文越长，显存占用越大，主要来自 KV Cache：

  • 模型算每个 token 时，要把之前的 K（Key）、V（Value） 缓存下来（避免每步重算）——这就是 KV Cache；
  • KV Cache 大小 ∝ 上下文长度 × 层数 × 隐藏维度 × 2（K和V） ；
  • 所以：上下文翻倍 → KV Cache 翻倍 → 显存需求翻倍。这就是为什么长上下文那么"贵"。

直观感受：一个 70B 模型，上下文从 4K 拉到 128K，KV Cache 可能占掉几十 GB 显存——这就是你学的 PagedAttention 存在的意义（按需分页，尽量省显存）。

当前的量级格局（2026 年左右）

档位 典型长度 说明
短上下文 4K~32K 早期主流，日常问答够用
中长 32K~128K 现在的主流标配，能塞进一本书
长/超长 128K~1M+ Gemini、DeepSeek、Claude 这类，能处理整本小说/长文档/长对话

参数单位：1K = 1024 个 token。中文大概 1 个汉字 ≈ 1~2 个 token，所以 128K 窗口 ≈ 能给到约 10 万汉字的一本书的内容量级（粗略）。

为什么"越长越好"但有代价

好处：

  • 一次能处理更长文档/更多历史，不用频繁截断丢失信息
  • 适合长文档问答、整本书阅读、长时间对话、长代码

代价（这是重点） ：

  1. 显存爆炸（KV Cache 线性增长）——最大的瓶颈；
  2. 慢：生成时每步都要看过往全部 token，长上下文的注意力计算量也涨；
  3. "迷失在中间"（Lost in the middle） ：模型哪怕有窗口，也容易出现中部信息记不牢——不是越长越好用；
  4. 幻觉 & 质量：过长的可能效果反而变差。

几个相关术语

  • 长上下文（Long Context） ：128K+ 这一类
  • RoPE（旋转位置编码） ：让模型能处理超出训练窗口的位置——外推/插值是"把推理窗口撑长"的关键技术
  • KV Cache / PagedAttention：管理长上下文时爆掉的显存
  • Streaming / 无限上下文：用滑动窗口等技术"看起来能一直对话"

上下文长度 = 模型能同时记住的 token 数上限；它决定模型能处理多长的输入，但受 KV Cache 显存约束最狠

5- 微调小案例

image-20261018084146075

image-20261018090006526

image-20261018090558767

image-20261018090650853

image-20261018090856948

image-20261018091035036

image-20261018091141295

image-20261018091936892

image-20261018091751850

image-20261018092130399

image-20261018092212326

image-20261018092400226

image-20261018092516824

image-20261018092912970

image-20261018093100184

这是用 Qwen3-8B + LoRA（PEFT）微调一个"扮演甄嬛"的角色模型

from datasets import Dataset
import pandas as pd
from transformers import AutoTokenizer, AutoModelForCausalLM, DataCollatorForSeq2Seq, TrainingArguments, Trainer

# 将JSON文件转换为CSV/Dataset
df = pd.read_json('./data/huanhuan.json')
ds = Dataset.from_pandas(df)

  • 数据集是

    huanhuan.json（甄嬛传台词集），每条样本分三栏：

    • instruction：别人说的话（"小姐，别的秀女都在求中选…"）
    • input：补充输入（这里是空）
    • output：甄嬛的回复（"嘘——都说许愿说破是不灵的"）

  • 目标就是让模型学会"听到 command 就回 output"，也就是把甄嬛这个角色"装"进模型。

04-Deep Research

image-20261018100104528

image-20261018095949677

image-20261018100229409

image-20261018101021565

posted @ 2026-10-18 10:17  Ref-brief  阅读(16)  评论(1)    收藏  举报