1. 大模型入门到底在学什么1.1 先搞清楚“大模型”这三个字指代的范围很多人一上来就问“大模型怎么入门”这个问题其实没法直接回答因为“大模型”这个词在日常语境里被用得太宽了。有人指的是ChatGPT这类对话产品有人指的是LLaMA、Qwen这种开源权重文件有人指的是背后那套Transformer架构还有人指的是围绕模型搭建的整套应用系统。你如果连自己学的是哪一层都没搞清楚后面看再多教程都是散的。我一般把大模型相关的知识分成四个层次来理解。最底层是模型本身包括架构设计、注意力机制、位置编码、归一化方式这些属于论文和源码级别的东西。往上一层是训练与微调涉及预训练、指令微调、对齐、LoRA、QLoRA这些具体技术。再往上是推理与部署关心的是怎么把几十GB的权重跑起来用vLLM还是llama.cpp量化到几bit显存够不够。最上层是应用与集成也就是提示词工程、RAG、Agent、流式输出、工具调用这些面向业务的东西。系统性入门的意思是你得知道这四个层次各自解决什么问题彼此之间怎么衔接而不是只盯着某一层猛钻。我见过太多人一上来就啃注意力机制的数学推导啃了两周放弃了也见过人只会调API遇到模型输出不稳定就完全不知道从哪下手。这两种都是因为缺少全局视角。入门阶段最重要的不是深度而是建立一张完整的地图。知道每个知识点在地图上的位置比把某一个点挖到多深更有价值。1.2 不同背景的人入门路径完全不一样我带的实习生里有科班做NLP的也有从后端转过来的还有做产品想理解技术边界的。这三类人的入门路线差别很大不能用同一套资料硬套。如果你是有编程基础但没接触过AI的开发者你的优势是工程能力强短板是数学和机器学习直觉。你的路径应该是先跑通一个本地部署建立感性认识再回头补Transformer的基本原理然后学微调和应用开发。先动手再补理论对你来说效率最高。如果你是算法或数据方向的学生数学底子好但工程经验可能偏弱。你的路径可以反过来先把Transformer论文精读一遍理解self-attention的矩阵运算然后自己用PyTorch手写一个mini版本再去看HuggingFace的源码实现。工程部分可以边做边补。如果你是产品、运营或管理者你不需要会训练模型但你需要知道模型能做什么、不能做什么、成本大概多少、延迟受什么影响。你的路径是理解token、上下文窗口、温度参数、幻觉这些概念的实际含义然后动手用API搭一个小demo感受一下从输入到输出的完整链路。下面这张表可以帮你快速定位自己该从哪切入背景类型建议起点第一阶段目标预计投入有编程无AI本地部署跑通理解模型文件、量化、推理流程1-2周算法/数据方向Transformer原理手写attention、理解训练目标2-3周产品/运营API调用demo理解token、上下文、参数影响3-5天全栈开发应用集成流式输出、RAG、Agent链路2-4周1.3 系统性入门的最小知识闭环所谓“系统性”我的标准是你能独立完成一个从模型选择到应用落地的完整小项目中间遇到问题知道往哪个方向查。这个闭环大概包含六个环节。模型认知知道主流模型有哪些各自的特点是什么。比如Qwen系列中文能力强、LLaMA生态最丰富、Mistral推理效率高、DeepSeek在代码和数学上表现突出。你不需要记住所有模型但要知道去哪里找模型、怎么看模型卡片、怎么判断一个模型适不适合你的场景。环境搭建能在自己的机器上把模型跑起来。这一步卡住的人最多因为涉及Python环境、CUDA版本、显存管理、依赖冲突一堆问题。但这一步必须自己走一遍看别人教程和自己踩坑是两回事。推理与部署理解推理框架的选择逻辑。llama.cpp适合CPU和低显存场景vLLM适合高并发服务端Ollama适合快速本地体验Transformers适合研究和调试。每个框架的取舍点在哪里你得心里有数。微调知道什么情况下需要微调什么情况下用提示词或RAG就够了。微调不是万能药很多时候你把提示词写好、把检索做准效果比微调还好成本还低。应用开发能把模型接入实际业务。提示词工程、上下文管理、流式输出、工具调用、多轮对话状态维护这些是应用层的核心技能。评估与迭代知道怎么判断模型输出好不好怎么系统性地改进。这一步最容易被忽略但恰恰是区分玩具项目和可用产品的关键。2. 模型选择别在起跑线上纠结太久2.1 主流开源模型的定位与取舍新手最容易犯的错是在模型选择上纠结太久。今天看这个榜单Qwen排第一明天看那个评测DeepSeek更强后天又听说某个新模型超越了GPT-4。这种信息焦虑会消耗你大量精力而且没有实际产出。我的建议是先选一个中等规模的模型跑通全流程再根据实际需求换。入门阶段模型之间的差异对你来说不是主要矛盾流程跑通才是。目前开源生态里几个主流选择的特点大致如下。Qwen系列通义千问中文支持好社区活跃从0.5B到72B都有适合中文场景入门。LLaMA系列生态最成熟工具链支持最全英文资料最多。Mistral和Mixtral系列推理效率高MoE架构在同等参数下速度有优势。DeepSeek系列在代码和数学推理上表现突出适合技术类任务。Gemma系列是Google出的轻量级做得好适合端侧。参数规模上入门阶段我推荐7B到14B这个区间。太小1B-3B能力有限你会觉得模型“笨”影响学习信心太大70B以上对硬件要求高推理慢调试周期长。7B模型在量化后大概需要4-6GB显存一张消费级显卡就能跑速度也可以接受。选模型的黄金法则是先看你的显存有多少再看你的任务是什么语言最后看社区活跃度。这三个因素比榜单排名重要得多。2.2 量化让小显存跑起大模型的关键量化这个词听起来很技术但理解起来很简单。模型权重原本是用16位浮点数FP16存储的一个7B模型大概需要14GB显存。量化就是把这些数字用更少的位数来表示比如8位、4位这样显存占用就降下来了。常见的量化格式有GGUF、GPTQ、AWQ几种。GGUF是llama.cpp生态用的适合CPU和混合推理文件格式是单个文件方便分发。GPTQ和AWQ是GPU推理用的需要配合对应的推理框架。入门阶段你接触最多的应该是GGUF因为Ollama和llama.cpp都用这个格式。量化的代价是精度损失。4位量化Q4通常能保留原模型90%以上的能力但某些对精度敏感的任务比如数学计算、代码生成可能会有明显下降。8位量化Q8损失很小但显存节省有限。我的经验是日常对话和文本处理用Q4_K_M就够了代码和推理任务建议Q5或Q8。这里有个实际的显存估算方法。一个7B模型FP16需要约14GBQ8需要约7GBQ4需要约4GB。但这只是权重部分实际推理还需要额外的KV Cache和中间激活值。KV Cache的大小跟上下文长度成正比上下文越长这部分占用越大。所以如果你要跑长上下文显存要留出余量。量化等级7B模型显存需求质量保留适用场景FP16~14GB100%训练、高精度推理Q8~7GB~99%代码、数学、精细任务Q5~5GB~97%通用对话、文本处理Q4~4GB~93%日常对话、快速体验Q3~3GB~85%极低显存应急2.3 本地部署还是API调用先想清楚你的约束这个问题没有标准答案取决于你的约束条件。本地部署的优势是数据不出本地、无网络延迟、无调用成本、可以自由微调。劣势是硬件投入、维护成本、模型能力受限于你能跑动的规模。API调用的优势是即开即用、模型能力强、无需维护。劣势是数据要发出去、有调用费用、受服务商限制。我的建议是入门阶段两条路都走一遍。先用API快速体验不同模型的能力边界建立感性认识然后在本地部署一个7B模型理解推理的完整流程。两条路都走过之后你自然知道什么场景该用什么方案。本地部署的硬件门槛其实没有想象中高。一张RTX 3060 12GB就能跑7B的Q4量化模型速度大概每秒20-40个token日常对话完全够用。如果没有独立显卡用CPU跑Q4模型也能到每秒5-10个token虽然慢但能用。Mac的M系列芯片因为统一内存架构跑本地模型体验很好M1 16GB就能跑7B模型。3. 环境搭建与本地部署实操3.1 从零搭建推理环境的完整步骤这一节我按实际操作的顺序来写你可以跟着一步步做。以Windows NVIDIA显卡为例Linux和Mac的差异我会标注出来。第一步确认硬件和驱动。打开命令行运行nvidia-smi看显卡型号、显存大小、CUDA版本。如果这个命令报错说明驱动没装好先去官网装驱动。CUDA版本建议12.1以上太老的版本很多新框架不支持。第二步安装Python环境。强烈建议用conda或venv创建独立环境不要用系统Python。大模型相关的包依赖复杂版本冲突是家常便饭独立环境能帮你隔离问题。Python版本选3.10或3.113.12有些包还没适配。conda create -n llm python3.11 conda activate llm第三步选择推理框架并安装。入门阶段我推荐先用Ollama它把模型下载、量化、推理都封装好了一条命令就能跑。等你熟悉了再换llama.cpp或vLLM做更细粒度的控制。Ollama的安装很简单官网下载安装包一路下一步。装完之后在命令行运行ollama run qwen2.5:7b它会自动下载模型并启动对话。第一次下载需要一些时间模型文件大概4-5GB。第四步验证推理是否正常。模型跑起来之后问它几个问题观察输出速度和内容质量。如果速度很慢检查是不是在用CPU跑如果输出乱码检查模型文件是否下载完整。第五步接入自己的代码。Ollama提供了HTTP API默认在11434端口。你可以用curl测试也可以用Python的requests库调用。import requests import json response requests.post( http://localhost:11434/api/generate, json{ model: qwen2.5:7b, prompt: 用一句话解释什么是大模型, stream: False } ) print(response.json()[response])3.2 llama.cpp部署更细粒度的控制Ollama底层用的就是llama.cpp但封装之后你失去了很多控制权。当你需要调整上下文长度、线程数、批处理大小这些参数时直接使用llama.cpp会更灵活。llama.cpp的安装有两种方式。一种是下载预编译的二进制文件适合不想折腾编译的用户。另一种是从源码编译能针对你的硬件做优化。Windows上预编译版本直接解压就能用Linux上建议编译安装以启用CUDA加速。编译的命令大概是这样git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON cmake --build build --config Release -j编译完成后你需要下载GGUF格式的模型文件。HuggingFace上搜“模型名 GGUF”就能找到选Q4_K_M或Q5_K_M版本。下载完之后用llama-cli启动./build/bin/llama-cli -m models/qwen2.5-7b-q4_k_m.gguf \ -c 4096 \ -n 512 \ --temp 0.7 \ -ngl 99这里的参数含义需要解释一下。-c 4096是上下文长度越大占用显存越多。-n 512是最多生成多少token。--temp 0.7是温度参数控制输出的随机性。-ngl 99是把多少层放到GPU上99表示全部放GPU如果显存不够可以调小这个值。实测经验7B模型Q4量化上下文4096全部放GPU大概需要5-6GB显存。如果你的显卡是8GB跑这个配置没问题但同时开浏览器和其他应用可能会爆显存。3.3 vLLM面向服务端的高效推理如果你要做的是给多个用户提供推理服务vLLM是目前最主流的选择。它的核心优势是PagedAttention能大幅提升显存利用率和吞吐量。同样的硬件vLLM的并发处理能力比朴素实现高好几倍。vLLM的安装需要CUDA环境pip安装即可pip install vllm启动服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9vLLM会启动一个兼容OpenAI API格式的服务你可以用openai的Python SDK直接调用。--gpu-memory-utilization 0.9表示用90%的显存留10%给系统。--max-model-len是最大上下文长度根据你的显存调整。vLLM的取舍点在于它启动时会预分配显存启动慢但启动后吞吐量高。适合长期运行的服务不适合频繁启停的调试场景。另外vLLM对模型格式有要求不是所有模型都支持用之前查一下文档。3.4 环境搭建常见坑与排查环境搭建阶段的问题占了新手提问的八成以上。我把最常见的几个问题和解决方法整理出来你遇到问题时可以先对照排查。问题现象可能原因排查方法解决方案CUDA out of memory显存不足nvidia-smi看占用降低量化等级、减小上下文、减少GPU层数模型加载报错文件损坏或格式不对检查文件大小和MD5重新下载确认格式匹配框架推理速度极慢在用CPU跑看GPU利用率检查CUDA是否启用-ngl参数是否设置输出乱码或重复量化损失或参数问题换Q8模型测试调整温度、重复惩罚参数依赖冲突包版本不兼容pip list看版本用独立环境按框架要求装版本端口被占用其他程序占用netstat查端口换端口或关掉占用程序有一个坑我特别想提醒不要混用不同来源的教程。A教程让你装transformers 4.36B教程让你装4.40你两个都装环境就乱了。选定一个框架的官方文档按它的要求来遇到问题再查社区。4. 微调什么时候需要怎么做4.1 微调不是第一选择很多人一上来就想微调觉得微调了模型就“懂”自己的业务了。这个想法需要纠正。微调的本质是让模型学习一种输出格式或风格而不是往模型里灌知识。如果你想让模型知道你的产品文档、公司制度、专业知识正确做法是RAG检索增强生成不是微调。微调真正适合的场景是你需要模型稳定输出某种特定格式比如固定的JSON结构、你需要模型遵循特定的对话风格、你需要模型在某个窄领域任务上提升准确率。这些场景的共同点是任务定义清晰、有足够的标注数据、格式要求严格。判断要不要微调可以问自己三个问题。第一提示词能不能解决如果能通过写清楚指令、给几个示例就让模型做对那就不需要微调。第二RAG能不能解决如果问题是模型缺少知识那RAG更合适。第三你有没有至少几百条高质量的训练数据微调需要数据数据质量比数量重要几十条垃圾数据不如没有。我的经验是80%的需求用提示词工程加RAG就能解决15%需要微调剩下5%才需要动预训练或架构。新手把精力花在前80%上回报率最高。4.2 LoRA微调的核心原理与实操如果确定要微调LoRA是目前最实用的方案。它的思路很巧妙不改动原模型的权重而是在旁边加一对小矩阵只训练这对小矩阵。这样训练参数量从几十亿降到几百万显存需求大幅下降训练速度也快很多。LoRA的原理用一句话说就是原权重W保持不变新增一个低秩分解的增量ΔW BA其中B和A是小矩阵。前向传播变成h Wx BAx。训练时只更新A和BW冻结。因为A和B的参数量远小于W所以显存和时间都省了。实操上现在最方便的工具是LLaMA-Factory和Unsloth。LLaMA-Factory提供了Web界面点点鼠标就能配置训练参数适合不想写代码的用户。Unsloth优化了训练速度同样的硬件能训更大的模型。以LLaMA-Factory为例微调一个7B模型的步骤大致是准备数据JSON格式包含instruction、input、output字段、配置训练参数学习率、batch size、epoch数、启动训练、导出合并后的模型。关键参数我列一下学习率LoRA通常用1e-4到3e-4比全量微调大一个数量级LoRA rank常用8、16、32rank越大表达能力越强但参数量越多LoRA alpha通常设为rank的2倍target modules一般选q_proj、v_proj也可以加上k_proj、o_projbatch size受显存限制7B模型QLoRA微调batch size 1-4比较常见epoch1-3轮通常够太多会过拟合# LoRA配置示例 from peft import LoraConfig lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM )4.3 QLoRA消费级显卡微调7B模型的可行方案LoRA虽然省但7B模型FP16加载还是需要14GB显存加上训练中间状态24GB显存才比较稳。如果你的显卡只有12GB甚至8GB就需要QLoRA。QLoRA的思路是把原模型量化到4bit加载然后在上面加LoRA适配器训练。这样7B模型只需要4-5GB显存就能加载加上训练开销8-10GB显存可以跑起来。代价是训练速度慢一些精度略有损失但对大多数任务来说够用。QLoRA的关键配置是load_in_4bitTrue和bnb_4bit_compute_dtypetorch.bfloat16。前者控制4bit加载后者控制计算时的精度。计算精度不要用float16容易溢出bfloat16更稳。from transformers import BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16, bnb_4bit_use_double_quantTrue )我实测过在RTX 3060 12GB上用QLoRA微调Qwen2.5-7Bbatch size设为2梯度累积8步训练1000条数据大概需要2-3小时。效果上格式遵循类的任务提升明显知识类的任务提升有限。4.4 微调数据准备质量比数量重要微调效果好不好七成看数据。我见过太多人拿几百条从网上爬的、格式混乱的数据去微调结果模型输出变得莫名其妙。数据准备有几个原则。格式统一。每条数据的结构要一致instruction、input、output字段清晰。不要有的数据有input有的没有有的output是JSON有的是一段话。模型会学习数据的模式格式混乱会导致输出不稳定。质量优先。100条精心构造的数据效果可能好过1000条粗糙数据。每条数据的output应该是你期望模型输出的样子措辞、格式、详细程度都要符合你的要求。覆盖全面。你的训练数据要覆盖实际使用中可能遇到的各种情况。如果只覆盖了简单情况遇到复杂输入模型就懵了。可以故意构造一些边界情况、异常输入让模型学会处理。去重和清洗。重复数据会让模型过拟合到特定模式。训练前做一下去重检查有没有明显的错误标注。数据量上格式遵循类任务500-1000条通常够。风格迁移类任务1000-3000条效果更稳。知识注入类任务老实说微调不是好选择用RAG吧。5. 应用开发从模型到产品5.1 提示词工程的核心原则提示词工程听起来玄乎其实核心就几条原则。理解了这几条你写的提示词质量会有质的提升。明确角色和任务。不要上来就问问题先告诉模型它是谁、要做什么。比如“你是一个专业的法律顾问请用通俗语言解释以下合同条款”比直接贴条款问“这是什么意思”效果好得多。给出输出格式。如果你需要特定格式的输出明确说出来最好给个示例。模型对格式的遵循能力跟你的指令清晰度直接相关。需要JSON就写“以JSON格式输出包含以下字段...”需要列表就说“分点列出”。提供上下文和示例。少样本提示few-shot比零样本提示效果好这是被反复验证的。给两三个输入输出的示例模型就能理解你要的模式。示例要选有代表性的覆盖不同情况。分步骤引导。复杂任务拆成几步让模型一步步来。比如分析一篇文章可以先让模型提取要点再让模型基于要点写摘要最后让模型检查摘要是否准确。这种链式提示比一步到位效果好。控制输出长度和风格。明确说“用三句话概括”“用专业术语”“用小学生能懂的语言”。模型默认的输出风格是中性偏正式你不指定它就用默认的。一个实用技巧把提示词当成给一个新员工的指令。你会怎么跟一个聪明但完全不了解你业务的人交代任务把那些隐含的假设都写出来提示词质量就上去了。5.2 流式输出与实时渲染流式输出是提升用户体验的关键。模型生成一个token就返回一个用户看到文字逐渐出现感觉响应很快。如果等全部生成完再返回用户要盯着空白屏幕等好几秒体验很差。实现流式输出服务端需要用SSEServer-Sent Events或WebSocket。SSE更简单单向推送适合这种场景。Python端用FastAPI可以很方便地实现from fastapi import FastAPI from fastapi.responses import StreamingResponse import requests app FastAPI() app.post(/chat) async def chat(prompt: str): def generate(): response requests.post( http://localhost:11434/api/generate, json{model: qwen2.5:7b, prompt: prompt, stream: True}, streamTrue ) for line in response.iter_lines(): if line: yield fdata: {line.decode()}\n\n return StreamingResponse(generate(), media_typetext/event-stream)前端用EventSource接收const eventSource new EventSource(/chat?prompt你好); eventSource.onmessage (event) { const data JSON.parse(event.data); document.getElementById(output).textContent data.response; };这里有个细节要注意流式输出时用户可能想中断生成。你需要提供一个abort机制前端调用eventSource.close()后端检测到连接断开后停止推理。Ollama的API支持通过设置请求超时或主动断开连接来中断。5.3 RAG让模型用上你的私有知识RAG是应用层最重要的技术之一。它的思路是用户提问时先从你的知识库里检索相关内容把检索结果和问题一起发给模型模型基于这些内容回答。这样模型就能“知道”你的私有数据而且不需要微调。RAG的流程分三步。索引阶段把你的文档切分成小块每块用embedding模型转成向量存到向量数据库。检索阶段用户提问时把问题也转成向量在数据库里找最相似的几块。生成阶段把检索到的内容和问题拼成提示词发给模型生成回答。切分策略很关键。切太大检索不精准切太小上下文不完整。一般按语义切分每块300-500字块之间可以有重叠。embedding模型可以用开源的BGE、M3E也可以用API。向量数据库入门用Chroma或FAISS就够生产环境可以考虑Milvus或Qdrant。RAG的常见问题是检索不准。用户问“退款政策是什么”检索出来的却是“配送政策”。这时候需要优化检索策略比如用混合检索向量加关键词、加rerank模型重排、或者让模型先改写问题再检索。5.4 Agent与工具调用Agent是让模型自主决定调用什么工具、按什么顺序执行的能力。比如用户问“今天北京天气怎么样”模型判断需要调用天气API拿到结果后再组织语言回答。实现Agent的核心是函数调用function calling。你定义好可用的工具和参数格式模型根据用户输入决定调用哪个工具、传什么参数。模型返回的不是自然语言而是结构化的调用请求。tools [ { type: function, function: { name: get_weather, description: 获取指定城市的天气, parameters: { type: object, properties: { city: {type: string, description: 城市名称} }, required: [city] } } } ]模型返回tool_calls后你的代码执行实际调用把结果再发给模型模型基于结果生成最终回答。这个循环可以多轮直到模型认为不需要再调用工具。Agent的难点在于错误处理和循环控制。模型可能调用不存在的工具、传错参数、或者陷入无限循环。你需要设置最大轮数、校验参数、处理异常。另外工具的描述要写清楚模型才能正确选择。6. 学习路线与资源取舍6.1 分阶段的学习路线我把大模型入门分成三个阶段每个阶段的目标和产出物不一样。第一阶段跑通流程1-2周。目标是能在本地跑起一个模型能通过代码调用它理解从输入到输出的完整链路。产出物是一个能对话的本地demo。这个阶段不要纠结原理先动手。第二阶段理解原理2-4周。目标是理解Transformer的基本结构、注意力机制、训练目标、微调原理。产出物是能读懂模型卡片和论文摘要能判断一个技术方案是否合理。这个阶段可以配合手写mini模型来加深理解。第三阶段应用开发3-6周。目标是能独立搭建一个RAG或Agent应用处理实际业务问题。产出物是一个可用的应用原型。这个阶段重点是工程能力提示词工程、流式输出、检索优化、错误处理。每个阶段之间不是严格串行的可以交叉进行。但大方向是先跑通再深入先应用再原理。反过来容易卡在数学推导上出不来。6.2 资料筛选少即是多大模型领域的信息过载很严重。每天都有新论文、新模型、新框架你不可能全部跟上。我的建议是选定一条主线其他作为补充。主线资料我推荐几个。原理方面Andrej Karpathy的“Lets build GPT”视频是公认最好的入门材料从零手写一个GPT讲得清楚透彻。应用方面HuggingFace的课程和文档质量很高边看边做。微调方面LLaMA-Factory的文档和示例很全跟着做一遍就懂了。论文不要一上来就啃。先看博客解读理解了核心思想再去看原文。Transformer那篇论文值得精读其他论文按需查阅。榜单和评测看看就好不要作为选型的唯一依据。社区方面HuggingFace、GitHub、Reddit的LocalLLaMA板块信息质量比较高。中文社区里一些技术博客和公众号的实操文章有参考价值但要注意甄别有些内容是翻译或拼凑的不一定准确。6.3 硬件投入的理性建议如果你打算认真学硬件投入是绕不开的。我的建议是按需投入不要一步到位。入门阶段如果你已经有游戏本或台式机先用现有的跑。8GB显存能跑7B的Q4模型12GB能跑得更舒服。如果没有独立显卡先用CPU跑小模型或者用云GPU按小时租。云GPU的好处是不用一次性投入坏处是数据要上传、环境每次要重配。如果确定要买卡12GB显存是入门甜点。RTX 3060 12GB、RTX 4060 Ti 16GB都是不错的选择。24GB的RTX 3090/4090能跑更大的模型和更舒服的微调但价格高不少。Mac的M系列芯片统一内存大跑推理体验好但训练支持不如NVIDIA。我的个人建议先用云GPU或现有硬件跑通全流程确定自己真的要深入再买卡。很多人买了卡之后发现兴趣转移了卡就吃灰了。7. 常见问题与避坑经验7.1 新手最容易踩的五个坑坑一在模型选择上纠结太久。前面说过了入门阶段模型差异不是主要矛盾。选一个主流的7B模型跑通再说。坑二跳过动手直接看理论。看十篇注意力机制的文章不如自己跑一次推理。理论可以慢慢补动手的感性认识是基础。坑三微调当万能药。遇到问题就想微调结果数据不够、效果不好、时间浪费。先试提示词和RAG不行再考虑微调。坑四忽视评估。做完一个应用自己试了几个例子觉得不错就上线了。没有系统评估你不知道模型在什么情况下会出错。建一个测试集定期跑一下。坑五追新不追稳。今天出新模型就换明天出新框架就试结果什么都没深入。选定一套技术栈用熟了再考虑换。7.2 模型输出质量问题的排查思路模型输出不好原因可能有很多。我按排查顺序列一下。先看提示词。指令是否清晰格式要求是否明确有没有给示例大部分输出问题通过改提示词就能解决。再看上下文。是不是超出了上下文窗口检索的内容是否相关多轮对话的历史是否太长导致模型混淆然后看参数。温度是不是太高导致输出发散重复惩罚是不是设置不当最大生成长度是不是不够最后看模型本身。这个任务是不是超出了模型能力换一个更大的模型或者专门针对该任务微调的模型试试。7.3 性能优化的实用技巧推理速度慢是常见问题。优化方向有几个。量化是最直接的Q4比FP16快一倍以上显存占用也小。批处理能提升吞吐量vLLM的continuous batching能把多个请求合并处理。KV Cache优化能减少显存占用PagedAttention和FlashAttention都是干这个的。投机采样用小模型预测、大模型验证能在保持质量的同时提速。如果这些都不想折腾最省事的办法是换更小的模型或者减少上下文长度。7B的Q4模型在消费级显卡上跑到每秒30-50 token日常使用完全够了。7.4 安全与合规的注意事项做应用开发时有几个安全点要注意。输入过滤防止提示词注入攻击用户可能通过特殊输入让模型忽略之前的指令。输出审核模型可能生成不当内容需要加一层过滤。数据隔离多用户场景下要确保用户数据不串。权限控制模型能调用的工具要限制权限不能让它执行危险操作。这些不是入门阶段的核心但如果你要做面向用户的产品必须考虑。入门阶段先建立意识知道有这些问题深入时再具体处理。8. 从入门到进阶的路径延伸8.1 多模态方向文本模型跑通之后可以往多模态延伸。多模态模型能处理图像、音频、视频输入。入门可以从图文对话开始用Qwen-VL或LLaVA这类模型理解视觉编码器怎么和语言模型对接。多模态的应用场景很广文档理解、图表分析、图像描述、视频摘要。技术栈上视觉编码器如ViT负责把图像转成向量然后通过投影层映射到语言模型的输入空间。理解这个架构你就能判断一个多模态模型的能力边界。8.2 推理加速与工程优化当你需要服务更多用户或者处理更长上下文时推理加速就变成核心问题。这个方向涉及CUDA编程、算子优化、分布式推理。入门可以从理解KV Cache、FlashAttention、PagedAttention这些概念开始然后看vLLM和TensorRT-LLM的源码。工程优化还包括服务架构。怎么部署多个模型实例、怎么做负载均衡、怎么做灰度发布、怎么监控推理延迟和显存占用。这些偏后端工程但对做产品很重要。8.3 模型评估与迭代评估是区分玩具和产品的关键。你需要一套系统的评估方法包括自动评估用测试集跑指标和人工评估抽样看质量。评估维度包括准确性、相关性、流畅度、安全性。迭代的闭环是评估发现问题、分析原因、调整方案、重新评估。这个循环跑得越快产品进步越快。建议从第一天就建立评估集哪怕只有几十条也比没有强。我个人在实际操作中的体会是大模型入门最大的障碍不是技术难度而是信息过载带来的选择困难。你不需要学完所有东西才能开始做选定一个最小闭环跑通它然后在做的过程中按需学习。跑通一个7B模型的本地部署加简单应用比看一百篇教程都有用。踩过的坑、调过的参数、改过的提示词这些才是真正长在你身上的经验。