先说个去年让我印象很深的场景。团队里来了个实习生数学底子不错PyTorch 也能跑通经典分类任务但一聊到大模型微调、推理服务化、Agent 编排整个人明显接不上话。他不是不努力而是市面上大部分教程都在教“怎么搭一个模型”却没人给他一张完整的“AI 学习生态全景图”——哪些工具解决什么问题、哪些框架是当前主流、路线该怎么排、每一阶段怎么验证自己真的学会了。这篇文章就是想把这套图补上按 2026 年的实际技术栈来梳理适合准备进入大模型应用层的同学、想转型的传统机器学习工程师也在一定程度上覆盖嵌入式 AI 与具身智能方向的入门路径。1. 先把全景图立起来2026年大模型开发的真实技术栈1.1 还在“只会调参”你已经落后了我在跟很多准备入行 AI 的朋友聊天时发现大家的认知还停留在“炼丹师”阶段装好 PyTorch、跑通模型训练、调一调学习率和网络层数就觉得自己能胜任大模型岗位。可实际情况是2026 年的大模型开发早就不是单纯“调参”的游戏了。今天的 AI 工程师更像“AI 平台软件工程师”。模型本身是开源的能力基线也够用真正拉开差距的是数据工程能力、微调策略、推理优化、评估闭环、Agent 编排和产品化落地。说得直白一点会训练一个模型的人很多能把模型稳定跑在线上、成本可控、效果可评估的人很少。这不是某个公司的特殊需求而是整个行业正在发生的结构性变化。所以你去看招聘市场大模型岗位描述里出现频率最高的是什么不是“精通 Transformer 原理”而是“熟悉主流大模型微调框架有实际部署经验了解 RAG 与 Agent 工程”。这说明行业需要的是能把技术栈串起来的人而不是只懂某一个点的研究者。1.2 全景分层从底层算力到应用交付的六层结构我的习惯是把 2026 年的 AI 技术栈分成六层来看每一层解决一类问题选型和学习路线都围绕这六层展开第一层算力与资源层。包括 GPU 服务器、云实例、异构计算设备这一层主要解决“模型在哪跑”的问题。个人学习和中小团队早期不需要自建机房租云 GPU 或者用 Mac Studio 这类本地设备也能起步。第二层运行环境与基础框架层。包括 CUDA 环境、Python 生态、PyTorch / TensorFlow 等训练框架以及 vLLM、TensorRT-LLM 这类推理框架的底座。这一层的核心是让模型能高效跑起来。第三层模型层。包括基座模型Llama、Qwen、DeepSeek 等、向量模型、重排模型、多模态模型。这一层的重点是掌握模型的能力边界和适用场景学会怎么选模型、换模型。第四层工具平台层。包括数据标注与合成工具、微调框架peft、DeepSpeed、LLaMA-Factory、评测工具、实验管理工具wandb、LangSmith、向量数据库。这一层是工程效率的关键。第五层应用框架层。包括 LangChain、LangGraph、LlamaIndex、Dify、Coze负责把模型能力封装成 Agent、RAG、工作流等可复用的应用组件。第六层业务产品层。包括后端服务、前端界面、权限控制、成本监控、模型网关让 AI 能力真正嵌进业务系统而不是停留在 Demo 阶段。我见过太多人只盯着第三层和第五层猛学前两层的环境一团糟第六层的工程能力为零。真到上线的时候才发现模型不是瓶颈工程才是。所以下面的内容会按照这六层展开把每一层的关键工具和路线都说清楚。2. 必备环境与基础工具链先把“地基”打牢2.1 运行环境与开发容器Docker 和 conda 的组合拳很多初学者拿到一台新机器第一步就是直接 pip install torch然后痛苦开始CUDA 版本不匹配、cuDNN 报错、Python 版本冲突、上午还能跑的代码下午环境就崩了。我的建议是从一开始就养成“环境隔离”的习惯。我的做法是 conda 管 Python 环境Docker 管项目级环境。原因很简单conda 解决依赖隔离Docker 解决可复现性。你不可能要求团队所有人都手动装一遍同样的环境但一份 Dockerfile 就能让同事在十分钟内拥有完全相同的运行环境。举个例子一个典型的训练环境 Dockerfile 长这样FROM nvidia/cuda:12.1.1-cudnn8-devel-ubuntu22.04 ENV DEBIAN_FRONTENDnoninteractive RUN apt-get update apt-get install -y python3.10 python3-pip git curl RUN pip install torch2.1.0 --index-url https://download.pytorch.org/whl/cu121 RUN pip install transformers accelerate peft deepspeed datasets WORKDIR /workspace这个镜像固定了 CUDA、PyTorch 和核心库的版本无论在本地还是云服务器上构建结果基本一致。如果你是在本地电脑上学习也可以只用 conda 创建虚拟环境但项目一旦涉及多人协作或多卡训练Docker 几乎是必须的。2.2 模型与数据管理从 Hugging Face 到 ModelScope 的取舍国内同学用 Hugging Face 下载大模型权重时经常遇到一个尴尬网络不稳定一个几十 GB 的模型下到一半断了要重新开始。2026 年的现状是国内最顺的路径一般是魔搭 ModelScope或者用 hf-mirror 这类镜像站。ModelScope 上的开源模型同步速度已经很快Qwen、Llama、DeepSeek 等主流基座都有官方搬运而且提供了类似 Hugging Face 的 API。下载模型的示例pip install modelscope modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir ./Qwen2.5-7B-Instruct用 Hugging Face 时也可以设置镜像环境变量export HF_ENDPOINThttps://hf-mirror.com huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir ./Qwen2.5-7B-Instruct数据管理方面datasets 库几乎是标配它能直接加载本地 CSV、JSON、Parquet 文件也支持流式加载超大数据集不会一次性吃光内存。处理更海量的数据时可以用 WebDataset 做流式训练把数据切成 tar 包训练时动态读取这也是大模型预训练常用的手段之一。2.3 调试、监控与测试从业余走向专业的三个习惯先说说调试。PyTorch 训练出问题时很多人靠 print 大法硬怼效率极低。至少要做到三件事用 pdb 打断点定位崩溃位置用 torchrun 跑多卡训练时留意环境变量和 RANK 信息看到 loss 为 NaN 时先查学习率和数据分布而不是怀疑模型结构。再说监控。训练跑起来之后如果不用 wandb 或者 TensorBoard 追踪指标出了问题只能靠回忆对比实验。wandb 的优势是线上仪表盘和团队共享TensorBoard 的优势是轻量、不依赖外部服务。我个人强烈建议从第一个项目开始就养成本地记录训练曲线的习惯否则后面做消融实验时完全无法横向对比。最后是测试。很多人觉得 AI 项目里写测试很别扭但我见过太多因为数据预处理小 bug 导致整个模型白训的案例。用 pytest 给数据管线、Prompt 构造、后处理逻辑写单元测试看起来费时间实际上是在给实验做保险。比如测试一个 Prompt 模板def test_build_prompt(): messages build_prompt(帮我写一封请假邮件) assert messages[0][role] system assert messages[1][role] user assert 请假 in messages[1][content]这条测试的价值不在于“发现多大 bug”而在于当你调整模板格式时能立刻知道哪些下游逻辑被破坏了。3. 框架选型地图训练、推理、Agent 与业务集成的完整解法3.1 训练微调框架从 peft 到 DeepSpeed 再到全家桶微调框架的选择取决于你的任务复杂度。我按三个档位来说。第一档是 LoRA / QLoRA 微调工具是 Hugging Face 生态的 peft transformers。对于绝大多数领域适配场景比如让模型学会客服话术、代码风格、专业术语这一档就够了。参数小、显存占用低、训练快几乎不需要分布式配置。第二档是全参数微调Full Fine-tuning工具是 DeepSpeed。当数据量在几十万条以上希望模型整体能力发生明显迁移时LoRA 的容量可能不够这时候需要全参微调。DeepSpeed 的核心是 ZeRO 优化可以把参数、梯度、优化器状态分配到多卡上。你只需要在启动命令里加上 --deepspeed ds_config.json配置好 ZeRO Stage 和 offload 策略就能跑起来。第三档是全家桶方案我特别推荐 LLaMA-Factory。它把数据处理、模板、LoRA 和全参微调、DPO 等对齐方法都整合了提供 Web UI 和命令行两种用法。如果你的目标是快速做实验对比这个工具可以省掉 80% 的工程代码。选型逻辑很简单先用 peft 跑通小规模实验确认数据和方案可行再考虑是否升级到 DeepSpeed 全参微调只有需要反复实验和多人协作时才上全家桶。一上来就搞重框架只会把自己拖进配置地狱。3.2 推理加速与本地部署框架vLLM、TGI 与 Ollama 的定位训练模型只是第一步服务化才是真正的考验。如今推理框架的主流选择是 vLLM它的核心优势是 PagedAttention 和 continuous batching。简单说PagedAttention 把 KV Cache 按页管理显存利用率更高continuous batching 允许多个请求动态混批而不是等一个请求生成完再处理下一个。实测下来同等显存下 vLLM 的吞吐量往往比 naive 实现高几倍。Hugging Face 的 TGIText Generation Inference也是常见选择它对 HF 生态兼容性好文档完善适合团队已经有 HF 依赖的场景。Ollama 则更偏个人电脑和本地轻量使用安装即用内置大量模型的拉取与运行命令适合学习验证和原型开发。我的建议是本地学习和 Demo 用 Ollama正式上线首选 vLLM如果你已经是 HF 生态深度用户TGI 可以作为备选。这几个框架都是 OpenAI 兼容接口意味着你写一次客户端代码后续切换服务端只需要改 base_url。3.3 Agent 与工作流框架LangGraph 之外的选择2026 年聊 Agent 框架不能只提 LangChain 了。LangChain 的问题在于抽象层级太多、API 频繁变动很多同学在“链的写法”上投入大量精力最后发现自己只是在学框架而不是做产品。我更推荐按场景选型。如果你在做复杂状态流、多步骤决策LangGraph 是目前最稳的选择它把 Agent 流程建模成图节点和边清晰可控。如果你在做知识库问答LlamaIndex 对文档切分、索引、检索的封装做得更好开箱即用。如果你不想写大量代码想快速验证产品交互Dify 这类可视化工作流平台是最优解——拖拽节点就能搭一个带 RAG 和工具调用的应用。LangGraph 的入门代码并不复杂from langgraph.graph import StateGraph def agent_node(state): return {messages: [根据意图调用工具]} def tool_node(state): return {messages: [工具执行结果]} graph StateGraph(dict) graph.add_node(agent, agent_node) graph.add_node(tools, tool_node) graph.add_edge(agent, tools) graph.set_entry_point(agent) app graph.compile()这段代码就是 Agent 循环的最简骨架。记住一个原则工具调用和状态管理才是 Agent 框架的核心不要被花哨的抽象概念带偏。3.4 传统业务框架的衔接AI 不是孤岛很多同学学了一堆 AI 技术却不知道怎么接进现有系统。实际上在真实企业里 AI 应用通常是嵌在 Spring Boot 后端、若依这类低代码管理平台、甚至 Qt 桌面程序里的。一个典型的架构是前端发起请求到业务后端Spring Boot业务后端调用独立的 AI 推理服务vLLM 起的 OpenAI 兼容服务AI 服务返回结果后再由业务后端做权限校验、结果缓存、日志审计。偶尔也会用消息队列做异步处理防止大模型推理阻塞主链路。所以我的建议是不要只学 AI 框架至少要懂一层传统后端技术。比如 Spring Boot 里的 HTTP 客户端怎么调用外部接口、OpenFeign 怎么声明式调用、Redis 怎么做结果缓存。如果做桌面工具也需要了解 Qt 的信号槽机制或者 C# 的 MVVM 模式。会这些不是让你去当后端开发而是让你有能力把模型能力真正送到用户手里。4. 学习路线设计与阶段检验应用层 AI 工程师的晋级路线4.1 阶段一机器学习与深度学习基础约 6 到 8 周很多人一上来就啃 Transformer 论文结果在自注意力推导上卡了两周。我的建议是先务实手握 Python理解基础的数据结构和算法再学机器学习的经典任务分类、回归、聚类和模型评估方法最后用 PyTorch 实现几个经典网络结构比如 ResNet、TextCNN。这个阶段的检验标准很简单能不能独立完成一个图像分类或者文本分类的小项目并且说清楚数据怎么处理、模型怎么训练、指标怎么算比如准确率、F1、混淆矩阵。这个阶段不需要深挖数学推导但线性代数里的矩阵乘法、概率论里的常见分布要会用、能看懂公式即可。4.2 阶段二大模型核心概念与提示词工程约 6 周进入大模型领域后先别急着微调。你需要理解 Transformer 的核心结构、注意力机制、GPT 类模型的生成方式以及“上下文窗口”“KV Cache”“温度采样”这些基础概念。在这个基础上学习提示词工程和上下文工程也就是如何用自然语言控制模型行为、如何组织 Few-shot 示例、如何设计角色和输出格式。这个阶段的检验标准用任意一个开源模型建议 Qwen2.5-7B-Instruct 或 Llama-3.1-8B做一个带 RAG 的问答机器人能回答文档里的问题并能标注答案来源。这个项目同时让你熟悉 Embedding 模型、向量数据库和基本的检索流程是后面所有 Agent 应用的地基。4.3 阶段三微调、对齐与部署实战约 10 周有了 Prompt 和 RAG 的基础再进入微调阶段就顺理成章了。先做 LoRA 微调拿一份领域数据集客服、法律、医疗都可走通数据构建、训练、评估、导出的全流程再做 QLoRA 微调和 DPO 对齐理解 SFT 和 RLHF 之间的区别最后学习推理优化和部署至少会用 vLLM 起一个服务并写接口测试脚本。这个阶段的检验标准是所有路线里最重要的你能把微调后的模型用 vLLM 部署成一个 API支持流式输出和并发访问并且在新的测试集上给出效果提升的数据对比。能把这条链路完整走通你已经超过 80% 只会跑训练脚本的同学。4.4 阶段四Agent 工程化、评测与产品落地持续进行到达这个阶段你已经不再是“学习者”而是一个实际的 AI 应用开发者。需要补的东西开始工程化LangGraph 里的多智能体协作、复杂工作流的容错与重试、输出结果的校验与兜底、大模型应用的可观测性调用链日志、Token 消耗、成本监控。同时评估能力非常关键要学会建立评测集、跑模型对比、分析失败案例。检验标准是一道综合题做一个完整的 Agent 应用比如“客服工单自动分类与回复助手”要能调用工具查数据库、能处理用户歧义、能自动升级给人工并且你能给出上线后的准确率、延迟和成本数据。这里建议引入 pytest 做回归测试每次改完 Prompt 或 Agent 逻辑都能自动跑一遍历史用例防止改一个修一个。4.5 嵌入式与具身智能方向两条差异化路径如果你关注的是“嵌入式软件工程师学习路线”或者“具身智能学习路线”核心思路是在主线之外做加法。嵌入式方向的重点是边缘部署模型要量化INT8 / INT4、要转成 ONNX 或特定推理引擎格式TensorRT、RKNN、要考虑内存带宽和算力上限。你的学习重点是推理框架、算子适配、电源约束下的性能优化而不是训练技巧。具身智能方向的重点是多模态感知和决策闭环视觉语言模型VLM、动作规划、强化学习与模仿学习、模拟仿真环境。这个方向对数学要求更高适合你已经有良好编程和机器学习基础后再深入。可以把主路线走到阶段三再切向这两个分支不要一开始就分散精力。5. 大模型微调实战从数据准备到评估闭环5.1 微调前置条件检查清单我不建议一上来就“微调”。做任何微调项目之前至少要回答五个问题任务是什么用什么基座模型数据量有没有达到阈值评测标准是什么现有 Prompt 方案为什么不够如果前面的任务定义和数据质量一塌糊涂微调只会放大错误。一个可以准备的项目案例做一个“客服工单意图识别与话术生成”模型。基座选 Qwen2.5-14B-Instruct。目标是在线上数据上比 Prompt 零样本效果好评测标准是意图准确率和回复话术的人工满意度。前置清单里最容易被忽略的是数据量。几千条数据时微调效果往往和精心做的 Few-shot 差不多甚至更差。一般 SFT 希望数据量在万级以上LoRA 也最好有 5000 条以上高质量数据。如果数据不够优先做 RAG 或者数据合成扩充。5.2 数据准备与 Prompt 模板设计数据格式是微调的生命线。我见过太多人把微调失败归结为模型问题实际上是数据里充满噪声和重复。一个规范的数据集大约长这样{conversations: [ {role: system, content: 你是某电商平台的客服助手回答必须简洁专业。}, {role: user, content: 我买的手机到货后发现屏幕有坏点怎么申请换货}, {role: assistant, content: 您好非常抱歉给您带来不便。您可以在订单详情页点击“申请售后”选择“质量问题”并上传屏幕坏点照片系统会在1个工作日内审核。} ]}数据清洗的原则包括去掉重复和过于相似的样本过滤残缺对话保持标签一致性同类问题不能让模型给出风格完全不同的回答临时做一遍随机抽检人工判断输出质量。Prompt 模板固定后不要频繁改动每次改动都要跑回归测试。5.3 LoRA 参数设定与训练脚本以 Qwen2.5-14B 为例QLoRA 训练的核心参数如下现有消费级显卡24GB 显存可以支撑from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from datasets import load_dataset model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-14B-Instruct, load_in_4bitTrue, device_mapauto ) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) training_args TrainingArguments( output_dir./qwen_2026_finetune, learning_rate2e-4, per_device_train_batch_size2, gradient_accumulation_steps8, num_train_epochs3, logging_steps20, save_steps500, fp16True, report_towandb )关于 LoRA 参数的经验r 设为 8 到 16 通常足够不需要追求大数值lora_alpha 一般是 r 的两倍。学习率对效果影响非常大默认 2e-4 到 5e-5 区间需要小步尝试。训练时观察 loss 曲线如果出现断崖式下降或剧烈震荡先检查数据格式、学习率和 batch size而不是盲目换模型。5.4 评估与模型导出微调完了不等于任务结束评估环节能决定你这一步是有效还是白干。分类任务用准确率、F1生成任务用 ROUGE / BLEU 做粗筛再结合人工抽检做最终判断。更关键的是做对比实验把 Baseline零样本 Prompt、RAG 方案、微调后模型的输出放在一起让评估人不知道哪个是哪个避免主观偏好。确认效果满意后把 LoRA 权重合并回基座模型再转成部署格式from peft import PeftModel base_model AutoModelForCausalLM.from_pretrained(Qwen/Qwen2.5-14B-Instruct) merged_model PeftModel.from_pretrained(base_model, ./qwen_2026_finetune).merge_and_unload() merged_model.save_pretrained(./qwen_2026_finetune_merged)合并后的模型可以直接用 vLLM 加载也可以继续做量化以满足更低显存的部署需求。6. 部署与上线推理优化、量化与成本控制6.1 显存与算力估算先算账再买卡很多人部署模型翻车都是因为没算显存账。一个最基础的估算公式FP16 权重显存 参数量 × 2 字节。7B 模型 FP16 权重约 14GB14B 约 28GB70B 约 140GB。推理时还有 KV Cache 占用跟序列长度和并发数挂钩。显存不够时优先考虑量化而不是咬牙加卡。下面这张表可以作为选型参考数值来自常见配置下的估算实际会有浮动模型规模FP16 权重显存INT8 权重量化INT4 / 4bit 量化推荐单卡显存7B~14GB~7GB~4.5GB16GB / 24GB14B~28GB~14GB~9GB24GB / 48GB32B~64GB~32GB~20GB48GB / 80GB70B~140GB~70GB~45GB80GB × 2如果只是做学习实验24GB 显存是当前性价比比较高的起步线能覆盖 7B 到 14B 的主流开源模型。需要跑 70B 级别时别想着单卡能解决多卡切分加量化才是正路。6.2 量化方案选择GPTQ、AWQ、GGUF 与 FP8量化是部署绕不开的话题。当前主流方案各有侧重GPTQ 需要校准数据精度保留较好适合服务端部署AWQ 按激活值找敏感权重对模型结构的破坏更小GGUF 主要面向 llama.cpp 生态适合 CPU 和 Mac 端运行FP8 在 H 卡上利用 Tensor Core 加速精度损失接近无损是高端卡的首选。方案典型工具应用场景精度损失GPTQAutoGPTQ、vLLMGPU 服务端、批量推理较小INT4 下有明显改善AWQAWQ、vLLMGPU 服务端、重视吞吐较小且稳定GGUFllama.cpp、OllamaCPU、Mac、边缘设备中等适合轻量场景FP8vLLM、TensorRT-LLM高端 GPU、生产环境极小几乎可忽略我的经验是能不用量化就别量化先跑 FP16 看效果显存紧张时优先 INT8效果基本能保住只有显存实在不够才上 INT4。量化之后的模型必须重新过一遍评测集合不要只看显存降下来就上线。6.3 服务化封装与并发调优用 vLLM 起一个 OpenAI 兼容服务非常快python -m vllm.entrypoints.openai.api_server \ --model ./qwen_2026_finetune_merged \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000启动后可以用 OpenAI SDK 调用只需要改 base_url。很多人忽略的是“gpu-memory-utilization”这个参数默认值偏低导致显存浪费。调到 0.9 左右能显著提升吞吐。并发压测也要做建议先规划吞吐量需求再调整 max-model-len 和 continuous batching 相关参数。上线后关注三个核心指标首 token 延迟TTFT、每秒生成 token 数、显存峰值。这三个指标能直接反映用户体验和成本。配合 pytest 写接口测试、用脚本随机抽取历史问题做回归能防止模型迭代后效果下降。7. 常见问题与排查技巧实录7.1 环境层面的高频坑我自己的经历加上带团队的经验环境问题至少占新手踩坑的 40%。CUDA 版本不匹配是最常见的用 nvidia-smi 看到的驱动版本和 PyTorch 要求的 CUDA 版本不是一回事PyTorch 自带 CUDA runtime。处理思路是先确定驱动支持的 CUDA 版本再选择对应 wheel 包安装 PyTorch。另一个高频问题是 pip 安装依赖卡在某个包的编译上。多进程编译很吃内存小机器容易崩。加上环境变量限制并行数量会稳很多export MAX_JOBS4 pip install flash-attn国内网络环境下优先配置可信镜像源安装速度能快很多。遇到 transformers 和 peft 版本不兼容优先看官方文档标注的版本搭配不要盲目追新。7.2 训练与微调阶段的高频坑训练阶段的核心坑集中在“数据格式”和“显存”上。我见过最典型的报错是 “ValueError: Token indices sequence length is longer than the specified maximum sequence length”十有八九是样本没做长度截断或者数据里有超长文本。解决方式是统一设置 tokenizer 的 max_length并在数据集预处理时做截断和 padding。显存溢出OOM也不少见。排查顺序是先减小 batch size再开 gradient checkpointing然后才是换更小的模型或上量化。很多人一上来就换模型结果问题依旧因为真正的瓶颈可能是显存碎片的累积。多卡训练时遇到 “NCCL error” 先检查网卡类型和 ib 配置尤其是跨机训练时这个错误通常和环境有关和模型无关。如果训练时 loss 长时间不下降先检查数据是否打乱、学习率是否过大过小再用一小批数据跑过拟合测试。小批量能过拟合说明代码和数据管线基本正确再去调大模型。7.3 部署与测试阶段的高频坑部署阶段的坑类型不一样最难排查的是“模型生成质量波动”。同样一个 Prompt测试时正常、上线后偶尔胡说八道大概率是采样参数不一致或者上下文长度超限被截断。解决方式是固定 temperature 和 top_p并对长文本做截断策略。上传大模型权重也经常出问题。下载到一半中断、权重文件损坏加载时报 “file not found” 或 “unexpected key”。建议权重文件用 md5 校验一遍或者干脆用 huggingface-cli / modelscope 的断点续传功能。另外用 vLLM 部署出现 “ValueError: The models max model len is too small” 时显式设置 --max-model-len比如 8192不要让它猜。7.4 问题速查表常见问题可能原因快速排查方向CUDA error: out of memory显存不足或碎片化减小 batch_size开 gradient checkpointing检查显存利用NCCL error多卡通信异常检查网络接口、IB/RoCE 配置、全卡在同一交换机loss 为 NaN学习率过大或数据异常降低学习率检查数据是否存在 NaN / Inf生成重复内容采样参数或数据质量调高 repetition_penalty检查训练数据是否存在重复接口超时推理耗时过长开启 vLLM batching缩短 max_model_len减小并发限制模型下载中断网络不稳使用 modelscope 或 hf-mirror 镜像站校验权重完整性微调后效果下降数据量不足或格式混乱回退到 Prompt 方案增加数据量甚至重做数据清洗前面这 7 个章节基本覆盖了 2026 年大模型学习生态里最重要、最常被忽略的东西。我自己的体会是学 AI 真正难的不是模型原理而是把数据、训练、部署、评估这套循环建立起来。你不需要懂每一个框架的每一行源码但必须清楚每个技术节点解决什么问题、遇到问题去哪里排查。最后分享一个实用技巧从第一个项目开始就别把“跑通一次训练”当成目标。目标应该是“建立一套可以重复执行、可以对比、可以回归的流水线”。哪怕只是几千条数据的 LoRA 微调也把数据脚本、训练脚本、评估脚本、部署脚本全都分开维护每一步用 pytest 留下检查点。几次迭代之后你会发现这套方法比任何“三天速成大模型”的课程都值钱。
