“大语言模型 vs 大模型”这个题目一摆出来内行人的第一反应多半是这有什么好比的但我做了这么多年大模型相关的工作发现真有不少人把这两个词混着用甚至包括一些已经摸爬滚打一两年的从业者。简历上写“熟悉大模型”细问只会调大语言模型的API方案里写“大模型应用开发”实际做的是RAG加向量库。如果连这两个概念都没掰扯清楚后面的选型、部署、微调、面试处处都是坑。这篇文章就是为了把“大语言模型”和“大模型”的关系彻底讲透再带你从概念落地到实操本地部署怎么选工具、微调怎么入门、Attention到底怎么回事、并发请求和量化怎么权衡。不管你是刚入门的新人还是想系统补齐知识的老手这篇都能给你一个清晰的坐标系。1. 先搞清楚大语言模型和大模型到底差在哪1.1 大模型是家族大语言模型是其中重要的分支先说结论大模型是一个更宽泛的概念大语言模型是它下面最重要、也最出名的一个子集。大模型英文常叫Large Model或Foundation Model指的是参数规模很大、在海量数据上预训练、具备较强通用能力的模型总称。它是个“家族”。这个家族里有擅长写字的、有擅长画画的、有擅长看图的也有跨着玩的。而大语言模型也就是Large Language Model简称LLM是家族里专心搞“语言理解和生成”的那一支。我用一个生活化的类比大模型像一所综合性大学里面有文学院、美术学院、理学院大语言模型就是文学院专门训练语言文字能力。平时大家口里的ChatGPT、GLM、Qwen、Llama、DeepSeek都是LLM这个文学院出来的学生。但你千万别以为文学院就代表整个大学因为大学里还有一堆不碰文字的学院对应到模型里就是视觉大模型、多模态大模型、科学计算大模型这些东西。这个区分不是文字游戏。我见过不少人开会时说“我们用大模型做客服”结果需求只是文本问答也见过有人说“用LLM做图片理解”结果跑不起来因为很多纯LLM根本不吃图片输入。概念不清楚选型一定翻车。1.2 为什么这个区分会影响你的技术选型理解了概念紧接着就是技术选型。你自己做项目时第一个要回答的问题就是我的输入和输出是什么形态如果你只需要处理文本比如写文章、改邮件、生成代码、做语义检索那纯大语言模型完全够用没必要为了追“大模型”三个字去上多模态方案。多模态模型往往需要额外的视觉编码器推理更慢、显存占用更高、API也更贵反而拖后腿。但如果你需要让模型“看懂”用户上传的截图、识别商品图片、分析视频帧那纯LLM帮不了你必须选视觉语言模型或多模态大模型。举个例子ChatGPT早期版本是纯LLM只能聊天后来GPT-4系列加入了视觉理解能力输入图像也能处理这就是从“大语言模型”升级到了“多模态大模型”的典型变化。同样是“大模型”这个词能力边界完全不同。部署层面的差异也很明显。纯LLM跑文本推理用Ollama、vLLM这类工具就能搞定量化和显存规划相对简单多模态模型往往要同时加载文本模型和图像编码器显存占用和框架适配都要重新考虑。所以搞清楚“大语言模型 vs 大模型”不是学院派抠概念而是直接影响你接下来的每一行配置命令。1.3 从参数、训练目标到产出形态的对比我整理了一张表方便你一眼看明白两者的核心差异对比维度大语言模型LLM大模型广泛概念核心能力文本理解、生成、推理视分支而定文本、图像、视频、音频、科学计算典型代表GPT系列、GLM、Qwen、Llama、DeepSeek涵盖LLM还包括ViT、SAM、Stable Diffusion、AlphaFold等训练目标自回归语言建模、掩码语言建模等对比学习、扩散建模、自回归、掩码重建等输入输出形态文本进、文本出图文进、图文出多模态组合主要任务问答、写作、代码、翻译、摘要图像分类、生成、跨模态检索、科学预测、视频生成部署复杂度相对低可能要求多编码器、多模态融合复杂度更高一句话总结所有大语言模型都是大模型但所有大模型不都是大语言模型。这个集合关系考试、面试、做方案时都很实用。再补充一个面试里常见的坑对方说“我们做的是大模型”你要先问清楚到底是纯语言模型还是视觉大模型、多模态大模型。很多时候面试官自己口语上把“大模型”当成了“大语言模型”的代称但招聘需求里写的任务却涉及图文数据如果你是求职者建议直接问“具体输入是纯文本还是包含图像音频”否则方向很容易搞偏。2. 大模型家族图谱除了语言还有哪些庞然大物2.1 语言之外视觉、多模态、科学计算大模型既然大模型是家族那家族里除了LLM到底还有哪些成员我把常见的几类列出来第一类是视觉大模型。它专门处理图像信息核心任务是看懂图片里的内容。经典代表有ViTVision Transformer、SAMSegment Anything Model、DINOv2、Florence等。ViT是把图片切成一个个patch然后用Transformer结构处理和LLM用token处理文本的思路很像只是处理的对象变成了图像块。SAM则是能做像素级分割你给它一张图它能帮你把前景背景、物体边界都切出来这在图像编辑和标注工具里用得很多。第二类是多模态大模型。它们不满足于单一模态而是把文本、图像、音频、视频等信息融合起来。热门代表有GPT-4o、Gemini、Qwen-VL、LLaVA、InternVL。这类模型通常以LLM为“大脑”外面接上视觉编码器、音频编码器让模型既能理解文字也能看图听声。多模态大模型是当前最活跃的方向很多智能客服、内容审核、辅助驾驶场景用的就是它。第三类是生成式大模型偏图像视频生成方向。比如Stable Diffusion、Flux、AnimateDiff、Sora。它们主要做文生图、图生图、文生视频。我们常说的AI绘画就是这类模型。虽然它们也算大模型但和“大语言模型”完全不是一个技术路线训练目标从“预测下一个token”变成了“逐步去噪生成图像”或“生成视频帧”。第四类是科学计算大模型。比如AlphaFold预测蛋白质结构、盘古气象大模型用于天气预测、还有各种材料、金融领域的行业大模型。它们的价值不在“聊天”而在解决特定专业问题。2.2 为什么多模态成为当前的主战场现在你打开任何一个大模型公司的产品页几乎都在强调多模态。为什么因为真实世界的业务需求本来就是混合形态的。举个例子客服机器人如果只能处理文字用户发了张商品损坏的截图它啥也看不出来但如果接入了多模态能力模型能直接读懂图片再结合文字背景生成处理方案问题解决率会提升不少。医疗场景也一样医生需要结合影像和病历文本来辅助诊断单靠纯LLM做不了。多模态大模型的核心技术是“跨模态对齐”。说白了就是让模型明白“猫”这个字、猫的图片、猫的叫声指的是同一个概念。模型通过海量的图文对数据训练把不同模态的信息映射到同一个向量空间里然后再通过LLM这个“大脑”统一理解和生成。这也是为什么很多多模态模型都叫“视觉语言模型”——它们本质上是语言模型加视觉编码器的组合。热词里提到的“视觉大语言模型”恰恰就是介于纯LLM和多模态大模型之间的过渡产物。它的结构与多模态模型相似通常用统一的生成框架处理图文任务但侧重点在于让语言模型拥有“视觉理解能力”。如果你要做的项目涉及图片输入加文本输出视觉大语言模型或成熟的多模态API往往是最优解。2.3 用“家族图谱”梳理大模型全景不用画图我用文字给你梳理一张家族图谱方便你建立框架语言大模型LLMGPT、GLM、Qwen、Llama、DeepSeek、Mistral、Phi视觉理解大模型ViT、SAM、DINOv2、Florence、CLIP多模态大模型GPT-4o、Gemini、Qwen-VL、LLaVA、InternVL、Moondream文生图/视频大模型Stable Diffusion、Flux、Sora、AnimateDiff、可灵科学计算与行业大模型AlphaFold、盘古气象、金融大模型、蛋白质结构模型建议你把这张图存到脑子里。以后听到“大模型”一词先归个类对方说的是家族还是某个具体成员说的是语言、视觉、还是多模态这样你的思路不会乱选型也不会被一句模糊的概念带着走。3. 从概念到落地部署、微调与推理的完整链路3.1 本地部署怎么选Ollama、vLLM、llama.cpp 的适用场景概念讲再多不跑通一次本地部署等于白学。这里我给你梳理三个最常见的本地部署工具以及它们各自的定位。Ollama适合个人电脑和开发环境快速体验。你只需要装好Ollama拉模型、跑服务都是几行命令的事# 拉取模型 ollama pull qwen2.5:7b # 运行模型进入交互式对话 ollama run qwen2.5:7b它最大的优点是简单适合新手验证模型效果、在本地玩玩。Ollama还能在后台启动HTTP服务默认端口11434这样Dify、Open WebUI这类应用可以直接对接。vLLM适合线上推理服务和高并发场景。它的核心优势是PagedAttention和Continuous Batching能在显存有限的情况下支持很高的并发吞吐。如果你要做一个生产级的APIvLLM是绕不开的选择vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000启动后它会提供一个兼容OpenAI格式的接口直接POST /v1/chat/completions就能用。它比较吃显存但换来的是高吞吐和低首Token延迟。llama.cpp则专攻CPU和边缘设备。它把模型量化成GGUF格式可以在没有独立显卡的机器上运行虽然速度不如GPU但胜在兼容性和轻量。AI大模型本地部署配置里如果你的机器性能一般优先考虑llama.cpp加GGUF量化模型。三个工具怎么选我直接给结论个人尝鲜、快速验证选Ollama要做服务化、面对多人并发选vLLM只有CPU、想要极简部署选llama.cpp。实际项目中我经常在开发阶段用Ollama上线之前切到vLLM两者对接同一套模型文件迁移成本并不高。3.2 微调绕不开 LLaMA Factory从数据准备到 LoRA 训练部署解决的是“怎么跑起来”微调解决的是“怎么让模型更懂你的业务”。目前社区用得最多的一站式微调工具就是LLaMA Factory。它的名字虽然带“LLaMA”但实际支持Qwen、GLM、Llama、Mistral、DeepSeek等一大堆模型。如果你想微调一个7B级别的模型它基本是首选。微调的完整流程大概四步第一步准备数据集。LLaMA Factory默认支持JSONL格式以指令微调SFT为例每条数据长这样{instruction: 请总结以下内容, input: 商品到货后发现外壳有划痕联系客服后已办理换货, output: 客户反映商品到货有划痕客服已处理换货。}数据质量比数量重要太多。宁可只准备3000条高水平的业务问答也不要拿10万条乱七八糟的数据凑数后者很容易让模型学坏。第二步选择基座模型。比如用Qwen/Qwen2.5-7B-Instruct。基座模型的选择决定了你的模型能力上限7B模型适合垂直任务和资源有限的场景如果要更强的通用推理上14B或更大。第三步选择参数高效微调方法。日常最常用的是LoRA和QLoRA。LoRA的做法是不动原始模型全部参数只训练一小部分低秩矩阵显存占用大幅降低。QLoRA则在此基础上把基座模型量化到4bit进一步节省显存。对大多数个人开发者QLoRA是性价比最高的。第四步配置训练参数并启动。我用LLaMA Factory的命令行举一个实际例子llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset alpaca_zh_demo \ --stage sft \ --finetuning_type lora \ --lora_rank 8 \ --learning_rate 2e-4 \ --num_train_epochs 3.0 \ --output_dir outputs/qwen-lora这里lora_rank决定LoRA矩阵的秩一般8到16就够learning_rate建议从2e-4左右起步太高容易导致灾难性遗忘把模型原本的能力冲掉num_train_epochs通常2到5轮可以根据验证集的表现调整。训练完成后你可以用它的导出命令把LoRA权重合并回原模型也可以单独保存LoRA adapter推理时动态加载。我个人使用中的最大心得是先做一个小规模实验比如用100条数据跑2轮看loss曲线和生成效果再上全量数据。不要一上来就全量微调浪费时间和显存不说出了问题还不好排查。3.3 Attention 机制和高频参数理解模型为什么“聪明”很多人学大模型时听到Attention就头疼。其实你用生活经验就能理解你在嘈杂的聚会里和朋友聊天虽然周围全是声音但你自动屏蔽了无关噪音只关注朋友说的话这就是注意力机制。模型中的Attention也是这个道理。当模型生成某个词的时候它不能把输入序列里的每个词都当同样的重要程度看待而是要给不同位置分配不同的权重。比如“我喜欢吃巧克力因为它很甜”模型在生成“甜”时会重点参考“糖”或“巧克力”而不是盯着“我”和“喜欢”。这种动态加权机制让模型能捕捉长距离依赖是大语言模型具备强大理解能力的关键。在推理时有几个参数你需要心里有数max_tokens控制生成的最大长度注意它通常包含输出token数超长上下文需要更大显存。temperature控制随机性。越低越保守适合事实问答越高越发散适合创意写作。top_p本质是概率截断。保留累计概率达到p的那些token和temperature配合调节多样性。context_length/session_length上下文窗口长度。窗口越长模型记得的信息越多但显存和计算量也随之上升。我实测过一个7B模型把上下文从2K加到8K生成速度大约下降30%以上。所以不是上下文越长越好要按实际业务裁剪。3.4 并发请求、吞吐与量化上线前必须想清楚的几件事当你把本地模型跑起来准备接业务时就会遇到“并发请求”和“吞吐”这些词。它们分别是什么意思并发请求同时有多少个用户或服务在向模型发请求。比如你做一个小助手工具同时在线50人那模型服务就要能承载50个并发连接。吞吐Throughput单位时间内模型处理的总token数常见单位是tokens/s。它决定了你服务的最大承载能力。TTFTTime To First Token用户发出请求到收到第一个token的时间影响“响应快不快”的感知。TPOTTime Per Output Token每个输出token的生成时间影响“回答流畅不流畅”。举个实际计算的例子。7B模型FP16精度权重显存大约14GB推理时KV Cache会额外占显存假设上下文长度4K、并发8路KV Cache可能要额外占几GB。所以一张24GB的消费级显卡跑7B模型做并发服务是比较稳的。如果显存不够可以量化到INT8或INT4效果会有小幅损失但显存占用能砍到一半甚至更少量化等级7B模型显存占用参考质量损失适用场景FP16约14GB无高质量服务、有显卡资源INT8约7-8GB很小兼顾质量与资源INT4GGUF约4-5GB有可感知损失低显存、边缘设备上线前我建议做一次基础压测先用脚本模拟10路并发请求观察TTFT和吞吐如果内存溢出或延迟飙升再逐步降低并发数或改用vLLM的连续批处理。不要等到用户反馈卡顿才去排查那时你已经处于被动局面了。4. 场景化选型指南什么时候该说“大模型”什么时候该说“大语言模型”4.1 聊天、写作、代码补全场景LLM 足够如果你的需求就是做文本对话、内容生成、代码辅助那直接用大语言模型就行不需要刻意追“多模态”。这听起来像废话但我在帮人做方案时常常遇到为了选型而选型的情况明明业务只需要纯文本非要多模态加图像识别结果成本和复杂度翻倍。纯LLM应用是当前最成熟、可复用性最高的方向。像写作助手、翻译工具、代码Review、日志分析、合同审查底层都是LLM。技术栈也简单调API或本地部署一个模型外面套一层Prompt模板和业务逻辑。这个场景下你完全可以说“我们用的是大语言模型”这比笼统说“大模型”更精确也更能体现你的技术判断力。4.2 图片理解、视频分析、跨模态场景多模态大模型才行需求一旦涉及图片、视频、音频就必须切换到多模态大模型。比如用户上传照片分类、检测图片中的文字、分析视频中的异常事件等。这类任务我建议优先考虑成熟的商业API比如GPT-4o、Gemini、Qwen-VL系列因为这些模型在多模态对齐上已经做得比较成熟自己部署同样的效果非常难。如果你有隐私要求需要本地部署可以选择Qwen-VL、LLaVA、InternVL这类开源多模态模型。它们在视觉编码器加LLM的结构上做了很多优化配合vLLM也能跑出不错的吞吐。多模态模型出图的质量很依赖输入稳定性。实际项目中图像分辨率压缩太狠、文字区域过小都会导致识别效果直线下降。我在做票据识别时就吃过亏原图4000x3000直接压缩到512x512模型完全看不清小字后来改成分段切片处理效果立刻上来了。4.3 企业知识库与 RAGLLM 是引擎但架构才是关键RAGRetrieval-Augmented Generation检索增强生成是当前企业落地大语言模型最重头的场景。很多人问“RAG怎么读”其实就是三个字母R-A-G全称的意思是先检索再生成。它的核心流程是这样的把企业文档PDF、Word、Markdown做切块每块几百到上千字。用Embedding模型把每块文本向量化存入向量数据库。用户提问时把问题也向量化到向量库中检索最相关的TopK文本块。把检索结果和用户问题拼成一段Prompt交给LLM生成回答。用Dify加Ollama可以快速搭一套本地RAG系统把Ollama作为本地大语言模型服务再接一个向量库比如Milvus、Chroma、Weaviate整个链路十分钟就能跑通。RAG的好处有两个一是降低幻觉模型回答有检索结果做依据二是知识更新方便换文档就行不用重新训练模型。我做RAG项目最大的体会是RAG的效果瓶颈往往不在模型而在检索。切块粒度太粗检索回来一堆无关内容切块太细语义又容易被截断。建议先用500字左右的窗口加少量重叠试起再根据召回效果调整。热词里提到的“大模型知识抽取框架OneKE”就是帮助你在构建知识库时做知识抽取的工具配合RAG使用效果不错。4.4 从免费 API 到本地部署成本与效果的权衡热词里有一条很真实“哪个大语言模型API还有免费使用”。很多个人开发者和学生朋友确实有免费调用的需求。各家厂商经常提供免费额度或限时体验但免费API通常有几个限制调用次数上限、并发限制、上下文长度限制、数据不用于训练的承诺可能有限。如果只是做Demo、跑通流程、写课程作业免费API完全够用。但如果你要做正式产品或者业务数据涉及隐私免费API就不靠谱了。这时候你有两条路付费商业API或者本地私有化部署。付费商业API省心效果稳定按量计费适合追求上线速度的团队。本地部署更复杂但数据可控、长期成本可能更低适合对数据安全有硬性要求的项目。我的建议是分阶段决策原型阶段用免费API快速验证确认产品方向后再用本地模型做私有化验证。如果你的业务量不大本地一张消费级显卡加Ollama或vLLM就能扛住业务量大了再考虑多卡或商业API。5. 常见问题与排查技巧实录5.1 本地部署后生成速度慢这是被问得最多的问题之一。模型跑起来了但一个字一个字蹦体验很差。排查顺序是这样的先确认模型是否真的加载到了GPU。看任务管理器或nvidia-smi如果显存有占用说明在GPU上如果显示CPU在高负载而GPU空闲多半是部署命令没加GPU参数或驱动有问题。再检查模型精度。FP16的7B模型和INT4的量化模型推理速度能差一倍以上。资源紧张就换量化版本。然后看上下文长度。上下文越长每个token的KV Cache计算量越大。如果只是做短问答没必要把历史对话全塞给模型。最后看部署框架。个人测试用Ollama没问题但生产级高并发建议切vLLM。它的连续批处理能让同一次GPU推理同时处理多个请求吞吐提升非常明显。5.2 微调后效果变差微调后效果变差通常有几个原因数据质量差。指令和回答不匹配、格式混乱模型学不到规律。建议先用现成的开源指令集做一次验证确认流程没问题再换自己的业务数据。学习率过高。微调时把learning_rate设成1e-3甚至更大很容易把预训练学到的通用知识冲掉。LoRA训练建议从2e-4起步全量微调从1e-5起步。数据集过小且重复度高。模型反复看同样几条数据过拟合到只会复读。这种情况要扩充数据多样性减少训练轮数。LoRA的rank设置不合理。rank太高可训练参数多容易过拟合rank太低表达力不足。7B模型从8开始试效果不够再加到16或32。出现效果变差时先不要怀疑模型垃圾先检查是不是数据混入脏数据。我有一次微调客服模型效果突然乱七八糟查了半天发现数据里有几行是历史旧版答案删除后正常了。5.3 显存不足显存不够是本地玩模型最常见的拦路虎。解决办法按优先级排序启用8bit/4bit量化加载。用load_in_8bitTrue或load_in_4bitTrue这类参数能大幅降低权重显存占用。减小批次大小。微调时把per_device_train_batch_size从2降到1并开启梯度累积显存压力会小很多。缩短上下文长度。把max_length或max_seq_len从4096降到2048KV Cache的显存占用能降一半。升级到QLoRA。如果全量微调或普通LoRA放不下直接用4bit基座加LoRA是目前个人开发者低成本微调的主流方案。显存计算有一个粗略的公式模型参数占的显存约等于参数量乘以单参数字节数。7B模型FP16大约14GBINT4大约4GB。再加上优化器状态、梯度、KV Cache训练时还要乘一个系数。所以我常说消费级显卡做推理有余、训练不足新手练手先跑推理再慢慢上微调。5.4 概念混淆带来的实际问题最后再说一个容易被忽略的坑概念混淆不只是知识问题会直接造成沟通和项目层面的麻烦。我在一次评审会上见过产品经理说“我们要接入大模型”结果他期望的是多模态图片理解而后端同学理解的“大模型”是文本LLM。两边讨论半小时才发现根本不是同一个东西。还有一次看招聘JD某岗位写“大模型研发”面试者准备的是一套LLM推理和微调经验结果实际工作要碰图像分割面试现场就崩了。避免这类问题的办法特别简单凡是涉及方案、接口、需求的地方都用更精确的说法。纯文本模型就叫“大语言模型”或“LLM”带图片视频的说明“多模态大模型”做图像的说明“视觉大模型”。术语精确不丢人反而能提升沟通效率。我自己写技术文档时也严格要求自己遵循这个口径能大大减少后期的扯皮。最后再分享一点个人体会。不管是“大语言模型”还是“大模型”概念本身不是重点重点是你能不能准确判断自己面对的是哪种需求以及用哪套方案去解决它。我见过太多人先把框架堆得花里胡哨最后发现连输入输出都定错了。把模型当成解决问题的工具先想清楚任务边界再对齐术语和选型这才是这个领域里真正值钱的能力。
大语言模型与大模型：从概念到部署微调的完整指南
“大语言模型 vs 大模型”这个题目一摆出来内行人的第一反应多半是这有什么好比的但我做了这么多年大模型相关的工作发现真有不少人把这两个词混着用甚至包括一些已经摸爬滚打一两年的从业者。简历上写“熟悉大模型”细问只会调大语言模型的API方案里写“大模型应用开发”实际做的是RAG加向量库。如果连这两个概念都没掰扯清楚后面的选型、部署、微调、面试处处都是坑。这篇文章就是为了把“大语言模型”和“大模型”的关系彻底讲透再带你从概念落地到实操本地部署怎么选工具、微调怎么入门、Attention到底怎么回事、并发请求和量化怎么权衡。不管你是刚入门的新人还是想系统补齐知识的老手这篇都能给你一个清晰的坐标系。1. 先搞清楚大语言模型和大模型到底差在哪1.1 大模型是家族大语言模型是其中重要的分支先说结论大模型是一个更宽泛的概念大语言模型是它下面最重要、也最出名的一个子集。大模型英文常叫Large Model或Foundation Model指的是参数规模很大、在海量数据上预训练、具备较强通用能力的模型总称。它是个“家族”。这个家族里有擅长写字的、有擅长画画的、有擅长看图的也有跨着玩的。而大语言模型也就是Large Language Model简称LLM是家族里专心搞“语言理解和生成”的那一支。我用一个生活化的类比大模型像一所综合性大学里面有文学院、美术学院、理学院大语言模型就是文学院专门训练语言文字能力。平时大家口里的ChatGPT、GLM、Qwen、Llama、DeepSeek都是LLM这个文学院出来的学生。但你千万别以为文学院就代表整个大学因为大学里还有一堆不碰文字的学院对应到模型里就是视觉大模型、多模态大模型、科学计算大模型这些东西。这个区分不是文字游戏。我见过不少人开会时说“我们用大模型做客服”结果需求只是文本问答也见过有人说“用LLM做图片理解”结果跑不起来因为很多纯LLM根本不吃图片输入。概念不清楚选型一定翻车。1.2 为什么这个区分会影响你的技术选型理解了概念紧接着就是技术选型。你自己做项目时第一个要回答的问题就是我的输入和输出是什么形态如果你只需要处理文本比如写文章、改邮件、生成代码、做语义检索那纯大语言模型完全够用没必要为了追“大模型”三个字去上多模态方案。多模态模型往往需要额外的视觉编码器推理更慢、显存占用更高、API也更贵反而拖后腿。但如果你需要让模型“看懂”用户上传的截图、识别商品图片、分析视频帧那纯LLM帮不了你必须选视觉语言模型或多模态大模型。举个例子ChatGPT早期版本是纯LLM只能聊天后来GPT-4系列加入了视觉理解能力输入图像也能处理这就是从“大语言模型”升级到了“多模态大模型”的典型变化。同样是“大模型”这个词能力边界完全不同。部署层面的差异也很明显。纯LLM跑文本推理用Ollama、vLLM这类工具就能搞定量化和显存规划相对简单多模态模型往往要同时加载文本模型和图像编码器显存占用和框架适配都要重新考虑。所以搞清楚“大语言模型 vs 大模型”不是学院派抠概念而是直接影响你接下来的每一行配置命令。1.3 从参数、训练目标到产出形态的对比我整理了一张表方便你一眼看明白两者的核心差异对比维度大语言模型LLM大模型广泛概念核心能力文本理解、生成、推理视分支而定文本、图像、视频、音频、科学计算典型代表GPT系列、GLM、Qwen、Llama、DeepSeek涵盖LLM还包括ViT、SAM、Stable Diffusion、AlphaFold等训练目标自回归语言建模、掩码语言建模等对比学习、扩散建模、自回归、掩码重建等输入输出形态文本进、文本出图文进、图文出多模态组合主要任务问答、写作、代码、翻译、摘要图像分类、生成、跨模态检索、科学预测、视频生成部署复杂度相对低可能要求多编码器、多模态融合复杂度更高一句话总结所有大语言模型都是大模型但所有大模型不都是大语言模型。这个集合关系考试、面试、做方案时都很实用。再补充一个面试里常见的坑对方说“我们做的是大模型”你要先问清楚到底是纯语言模型还是视觉大模型、多模态大模型。很多时候面试官自己口语上把“大模型”当成了“大语言模型”的代称但招聘需求里写的任务却涉及图文数据如果你是求职者建议直接问“具体输入是纯文本还是包含图像音频”否则方向很容易搞偏。2. 大模型家族图谱除了语言还有哪些庞然大物2.1 语言之外视觉、多模态、科学计算大模型既然大模型是家族那家族里除了LLM到底还有哪些成员我把常见的几类列出来第一类是视觉大模型。它专门处理图像信息核心任务是看懂图片里的内容。经典代表有ViTVision Transformer、SAMSegment Anything Model、DINOv2、Florence等。ViT是把图片切成一个个patch然后用Transformer结构处理和LLM用token处理文本的思路很像只是处理的对象变成了图像块。SAM则是能做像素级分割你给它一张图它能帮你把前景背景、物体边界都切出来这在图像编辑和标注工具里用得很多。第二类是多模态大模型。它们不满足于单一模态而是把文本、图像、音频、视频等信息融合起来。热门代表有GPT-4o、Gemini、Qwen-VL、LLaVA、InternVL。这类模型通常以LLM为“大脑”外面接上视觉编码器、音频编码器让模型既能理解文字也能看图听声。多模态大模型是当前最活跃的方向很多智能客服、内容审核、辅助驾驶场景用的就是它。第三类是生成式大模型偏图像视频生成方向。比如Stable Diffusion、Flux、AnimateDiff、Sora。它们主要做文生图、图生图、文生视频。我们常说的AI绘画就是这类模型。虽然它们也算大模型但和“大语言模型”完全不是一个技术路线训练目标从“预测下一个token”变成了“逐步去噪生成图像”或“生成视频帧”。第四类是科学计算大模型。比如AlphaFold预测蛋白质结构、盘古气象大模型用于天气预测、还有各种材料、金融领域的行业大模型。它们的价值不在“聊天”而在解决特定专业问题。2.2 为什么多模态成为当前的主战场现在你打开任何一个大模型公司的产品页几乎都在强调多模态。为什么因为真实世界的业务需求本来就是混合形态的。举个例子客服机器人如果只能处理文字用户发了张商品损坏的截图它啥也看不出来但如果接入了多模态能力模型能直接读懂图片再结合文字背景生成处理方案问题解决率会提升不少。医疗场景也一样医生需要结合影像和病历文本来辅助诊断单靠纯LLM做不了。多模态大模型的核心技术是“跨模态对齐”。说白了就是让模型明白“猫”这个字、猫的图片、猫的叫声指的是同一个概念。模型通过海量的图文对数据训练把不同模态的信息映射到同一个向量空间里然后再通过LLM这个“大脑”统一理解和生成。这也是为什么很多多模态模型都叫“视觉语言模型”——它们本质上是语言模型加视觉编码器的组合。热词里提到的“视觉大语言模型”恰恰就是介于纯LLM和多模态大模型之间的过渡产物。它的结构与多模态模型相似通常用统一的生成框架处理图文任务但侧重点在于让语言模型拥有“视觉理解能力”。如果你要做的项目涉及图片输入加文本输出视觉大语言模型或成熟的多模态API往往是最优解。2.3 用“家族图谱”梳理大模型全景不用画图我用文字给你梳理一张家族图谱方便你建立框架语言大模型LLMGPT、GLM、Qwen、Llama、DeepSeek、Mistral、Phi视觉理解大模型ViT、SAM、DINOv2、Florence、CLIP多模态大模型GPT-4o、Gemini、Qwen-VL、LLaVA、InternVL、Moondream文生图/视频大模型Stable Diffusion、Flux、Sora、AnimateDiff、可灵科学计算与行业大模型AlphaFold、盘古气象、金融大模型、蛋白质结构模型建议你把这张图存到脑子里。以后听到“大模型”一词先归个类对方说的是家族还是某个具体成员说的是语言、视觉、还是多模态这样你的思路不会乱选型也不会被一句模糊的概念带着走。3. 从概念到落地部署、微调与推理的完整链路3.1 本地部署怎么选Ollama、vLLM、llama.cpp 的适用场景概念讲再多不跑通一次本地部署等于白学。这里我给你梳理三个最常见的本地部署工具以及它们各自的定位。Ollama适合个人电脑和开发环境快速体验。你只需要装好Ollama拉模型、跑服务都是几行命令的事# 拉取模型 ollama pull qwen2.5:7b # 运行模型进入交互式对话 ollama run qwen2.5:7b它最大的优点是简单适合新手验证模型效果、在本地玩玩。Ollama还能在后台启动HTTP服务默认端口11434这样Dify、Open WebUI这类应用可以直接对接。vLLM适合线上推理服务和高并发场景。它的核心优势是PagedAttention和Continuous Batching能在显存有限的情况下支持很高的并发吞吐。如果你要做一个生产级的APIvLLM是绕不开的选择vllm serve Qwen/Qwen2.5-7B-Instruct --port 8000启动后它会提供一个兼容OpenAI格式的接口直接POST /v1/chat/completions就能用。它比较吃显存但换来的是高吞吐和低首Token延迟。llama.cpp则专攻CPU和边缘设备。它把模型量化成GGUF格式可以在没有独立显卡的机器上运行虽然速度不如GPU但胜在兼容性和轻量。AI大模型本地部署配置里如果你的机器性能一般优先考虑llama.cpp加GGUF量化模型。三个工具怎么选我直接给结论个人尝鲜、快速验证选Ollama要做服务化、面对多人并发选vLLM只有CPU、想要极简部署选llama.cpp。实际项目中我经常在开发阶段用Ollama上线之前切到vLLM两者对接同一套模型文件迁移成本并不高。3.2 微调绕不开 LLaMA Factory从数据准备到 LoRA 训练部署解决的是“怎么跑起来”微调解决的是“怎么让模型更懂你的业务”。目前社区用得最多的一站式微调工具就是LLaMA Factory。它的名字虽然带“LLaMA”但实际支持Qwen、GLM、Llama、Mistral、DeepSeek等一大堆模型。如果你想微调一个7B级别的模型它基本是首选。微调的完整流程大概四步第一步准备数据集。LLaMA Factory默认支持JSONL格式以指令微调SFT为例每条数据长这样{instruction: 请总结以下内容, input: 商品到货后发现外壳有划痕联系客服后已办理换货, output: 客户反映商品到货有划痕客服已处理换货。}数据质量比数量重要太多。宁可只准备3000条高水平的业务问答也不要拿10万条乱七八糟的数据凑数后者很容易让模型学坏。第二步选择基座模型。比如用Qwen/Qwen2.5-7B-Instruct。基座模型的选择决定了你的模型能力上限7B模型适合垂直任务和资源有限的场景如果要更强的通用推理上14B或更大。第三步选择参数高效微调方法。日常最常用的是LoRA和QLoRA。LoRA的做法是不动原始模型全部参数只训练一小部分低秩矩阵显存占用大幅降低。QLoRA则在此基础上把基座模型量化到4bit进一步节省显存。对大多数个人开发者QLoRA是性价比最高的。第四步配置训练参数并启动。我用LLaMA Factory的命令行举一个实际例子llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B-Instruct \ --dataset alpaca_zh_demo \ --stage sft \ --finetuning_type lora \ --lora_rank 8 \ --learning_rate 2e-4 \ --num_train_epochs 3.0 \ --output_dir outputs/qwen-lora这里lora_rank决定LoRA矩阵的秩一般8到16就够learning_rate建议从2e-4左右起步太高容易导致灾难性遗忘把模型原本的能力冲掉num_train_epochs通常2到5轮可以根据验证集的表现调整。训练完成后你可以用它的导出命令把LoRA权重合并回原模型也可以单独保存LoRA adapter推理时动态加载。我个人使用中的最大心得是先做一个小规模实验比如用100条数据跑2轮看loss曲线和生成效果再上全量数据。不要一上来就全量微调浪费时间和显存不说出了问题还不好排查。3.3 Attention 机制和高频参数理解模型为什么“聪明”很多人学大模型时听到Attention就头疼。其实你用生活经验就能理解你在嘈杂的聚会里和朋友聊天虽然周围全是声音但你自动屏蔽了无关噪音只关注朋友说的话这就是注意力机制。模型中的Attention也是这个道理。当模型生成某个词的时候它不能把输入序列里的每个词都当同样的重要程度看待而是要给不同位置分配不同的权重。比如“我喜欢吃巧克力因为它很甜”模型在生成“甜”时会重点参考“糖”或“巧克力”而不是盯着“我”和“喜欢”。这种动态加权机制让模型能捕捉长距离依赖是大语言模型具备强大理解能力的关键。在推理时有几个参数你需要心里有数max_tokens控制生成的最大长度注意它通常包含输出token数超长上下文需要更大显存。temperature控制随机性。越低越保守适合事实问答越高越发散适合创意写作。top_p本质是概率截断。保留累计概率达到p的那些token和temperature配合调节多样性。context_length/session_length上下文窗口长度。窗口越长模型记得的信息越多但显存和计算量也随之上升。我实测过一个7B模型把上下文从2K加到8K生成速度大约下降30%以上。所以不是上下文越长越好要按实际业务裁剪。3.4 并发请求、吞吐与量化上线前必须想清楚的几件事当你把本地模型跑起来准备接业务时就会遇到“并发请求”和“吞吐”这些词。它们分别是什么意思并发请求同时有多少个用户或服务在向模型发请求。比如你做一个小助手工具同时在线50人那模型服务就要能承载50个并发连接。吞吐Throughput单位时间内模型处理的总token数常见单位是tokens/s。它决定了你服务的最大承载能力。TTFTTime To First Token用户发出请求到收到第一个token的时间影响“响应快不快”的感知。TPOTTime Per Output Token每个输出token的生成时间影响“回答流畅不流畅”。举个实际计算的例子。7B模型FP16精度权重显存大约14GB推理时KV Cache会额外占显存假设上下文长度4K、并发8路KV Cache可能要额外占几GB。所以一张24GB的消费级显卡跑7B模型做并发服务是比较稳的。如果显存不够可以量化到INT8或INT4效果会有小幅损失但显存占用能砍到一半甚至更少量化等级7B模型显存占用参考质量损失适用场景FP16约14GB无高质量服务、有显卡资源INT8约7-8GB很小兼顾质量与资源INT4GGUF约4-5GB有可感知损失低显存、边缘设备上线前我建议做一次基础压测先用脚本模拟10路并发请求观察TTFT和吞吐如果内存溢出或延迟飙升再逐步降低并发数或改用vLLM的连续批处理。不要等到用户反馈卡顿才去排查那时你已经处于被动局面了。4. 场景化选型指南什么时候该说“大模型”什么时候该说“大语言模型”4.1 聊天、写作、代码补全场景LLM 足够如果你的需求就是做文本对话、内容生成、代码辅助那直接用大语言模型就行不需要刻意追“多模态”。这听起来像废话但我在帮人做方案时常常遇到为了选型而选型的情况明明业务只需要纯文本非要多模态加图像识别结果成本和复杂度翻倍。纯LLM应用是当前最成熟、可复用性最高的方向。像写作助手、翻译工具、代码Review、日志分析、合同审查底层都是LLM。技术栈也简单调API或本地部署一个模型外面套一层Prompt模板和业务逻辑。这个场景下你完全可以说“我们用的是大语言模型”这比笼统说“大模型”更精确也更能体现你的技术判断力。4.2 图片理解、视频分析、跨模态场景多模态大模型才行需求一旦涉及图片、视频、音频就必须切换到多模态大模型。比如用户上传照片分类、检测图片中的文字、分析视频中的异常事件等。这类任务我建议优先考虑成熟的商业API比如GPT-4o、Gemini、Qwen-VL系列因为这些模型在多模态对齐上已经做得比较成熟自己部署同样的效果非常难。如果你有隐私要求需要本地部署可以选择Qwen-VL、LLaVA、InternVL这类开源多模态模型。它们在视觉编码器加LLM的结构上做了很多优化配合vLLM也能跑出不错的吞吐。多模态模型出图的质量很依赖输入稳定性。实际项目中图像分辨率压缩太狠、文字区域过小都会导致识别效果直线下降。我在做票据识别时就吃过亏原图4000x3000直接压缩到512x512模型完全看不清小字后来改成分段切片处理效果立刻上来了。4.3 企业知识库与 RAGLLM 是引擎但架构才是关键RAGRetrieval-Augmented Generation检索增强生成是当前企业落地大语言模型最重头的场景。很多人问“RAG怎么读”其实就是三个字母R-A-G全称的意思是先检索再生成。它的核心流程是这样的把企业文档PDF、Word、Markdown做切块每块几百到上千字。用Embedding模型把每块文本向量化存入向量数据库。用户提问时把问题也向量化到向量库中检索最相关的TopK文本块。把检索结果和用户问题拼成一段Prompt交给LLM生成回答。用Dify加Ollama可以快速搭一套本地RAG系统把Ollama作为本地大语言模型服务再接一个向量库比如Milvus、Chroma、Weaviate整个链路十分钟就能跑通。RAG的好处有两个一是降低幻觉模型回答有检索结果做依据二是知识更新方便换文档就行不用重新训练模型。我做RAG项目最大的体会是RAG的效果瓶颈往往不在模型而在检索。切块粒度太粗检索回来一堆无关内容切块太细语义又容易被截断。建议先用500字左右的窗口加少量重叠试起再根据召回效果调整。热词里提到的“大模型知识抽取框架OneKE”就是帮助你在构建知识库时做知识抽取的工具配合RAG使用效果不错。4.4 从免费 API 到本地部署成本与效果的权衡热词里有一条很真实“哪个大语言模型API还有免费使用”。很多个人开发者和学生朋友确实有免费调用的需求。各家厂商经常提供免费额度或限时体验但免费API通常有几个限制调用次数上限、并发限制、上下文长度限制、数据不用于训练的承诺可能有限。如果只是做Demo、跑通流程、写课程作业免费API完全够用。但如果你要做正式产品或者业务数据涉及隐私免费API就不靠谱了。这时候你有两条路付费商业API或者本地私有化部署。付费商业API省心效果稳定按量计费适合追求上线速度的团队。本地部署更复杂但数据可控、长期成本可能更低适合对数据安全有硬性要求的项目。我的建议是分阶段决策原型阶段用免费API快速验证确认产品方向后再用本地模型做私有化验证。如果你的业务量不大本地一张消费级显卡加Ollama或vLLM就能扛住业务量大了再考虑多卡或商业API。5. 常见问题与排查技巧实录5.1 本地部署后生成速度慢这是被问得最多的问题之一。模型跑起来了但一个字一个字蹦体验很差。排查顺序是这样的先确认模型是否真的加载到了GPU。看任务管理器或nvidia-smi如果显存有占用说明在GPU上如果显示CPU在高负载而GPU空闲多半是部署命令没加GPU参数或驱动有问题。再检查模型精度。FP16的7B模型和INT4的量化模型推理速度能差一倍以上。资源紧张就换量化版本。然后看上下文长度。上下文越长每个token的KV Cache计算量越大。如果只是做短问答没必要把历史对话全塞给模型。最后看部署框架。个人测试用Ollama没问题但生产级高并发建议切vLLM。它的连续批处理能让同一次GPU推理同时处理多个请求吞吐提升非常明显。5.2 微调后效果变差微调后效果变差通常有几个原因数据质量差。指令和回答不匹配、格式混乱模型学不到规律。建议先用现成的开源指令集做一次验证确认流程没问题再换自己的业务数据。学习率过高。微调时把learning_rate设成1e-3甚至更大很容易把预训练学到的通用知识冲掉。LoRA训练建议从2e-4起步全量微调从1e-5起步。数据集过小且重复度高。模型反复看同样几条数据过拟合到只会复读。这种情况要扩充数据多样性减少训练轮数。LoRA的rank设置不合理。rank太高可训练参数多容易过拟合rank太低表达力不足。7B模型从8开始试效果不够再加到16或32。出现效果变差时先不要怀疑模型垃圾先检查是不是数据混入脏数据。我有一次微调客服模型效果突然乱七八糟查了半天发现数据里有几行是历史旧版答案删除后正常了。5.3 显存不足显存不够是本地玩模型最常见的拦路虎。解决办法按优先级排序启用8bit/4bit量化加载。用load_in_8bitTrue或load_in_4bitTrue这类参数能大幅降低权重显存占用。减小批次大小。微调时把per_device_train_batch_size从2降到1并开启梯度累积显存压力会小很多。缩短上下文长度。把max_length或max_seq_len从4096降到2048KV Cache的显存占用能降一半。升级到QLoRA。如果全量微调或普通LoRA放不下直接用4bit基座加LoRA是目前个人开发者低成本微调的主流方案。显存计算有一个粗略的公式模型参数占的显存约等于参数量乘以单参数字节数。7B模型FP16大约14GBINT4大约4GB。再加上优化器状态、梯度、KV Cache训练时还要乘一个系数。所以我常说消费级显卡做推理有余、训练不足新手练手先跑推理再慢慢上微调。5.4 概念混淆带来的实际问题最后再说一个容易被忽略的坑概念混淆不只是知识问题会直接造成沟通和项目层面的麻烦。我在一次评审会上见过产品经理说“我们要接入大模型”结果他期望的是多模态图片理解而后端同学理解的“大模型”是文本LLM。两边讨论半小时才发现根本不是同一个东西。还有一次看招聘JD某岗位写“大模型研发”面试者准备的是一套LLM推理和微调经验结果实际工作要碰图像分割面试现场就崩了。避免这类问题的办法特别简单凡是涉及方案、接口、需求的地方都用更精确的说法。纯文本模型就叫“大语言模型”或“LLM”带图片视频的说明“多模态大模型”做图像的说明“视觉大模型”。术语精确不丢人反而能提升沟通效率。我自己写技术文档时也严格要求自己遵循这个口径能大大减少后期的扯皮。最后再分享一点个人体会。不管是“大语言模型”还是“大模型”概念本身不是重点重点是你能不能准确判断自己面对的是哪种需求以及用哪套方案去解决它。我见过太多人先把框架堆得花里胡哨最后发现连输入输出都定错了。把模型当成解决问题的工具先想清楚任务边界再对齐术语和选型这才是这个领域里真正值钱的能力。
