经常有人后台私信我手头一台老电脑、或者刚买的带独立显卡的机器到底能不能本地跑大模型到底该用哪个工具什么Ollama、LM Studio、vLLM、本地装上DeepSeek、Qwen到底差在哪每次回这种问题我都要打好几百字索性把2026年这个时间点上的完整方案整理成一篇长文——从工具选型、优缺点对比到一步步实操流程再到踩坑记录一次讲清楚。先说结论本地部署大模型在今天已经不是“极客专属”了硬件门槛被量化和推理引擎压得很低很多配置一般的机器也能跑起来。难的不是“跑起来”而是知道“怎么选、为什么这么选、怎么根据自己机器的情况调到能用”。这篇文章就是围绕这三件事展开的适合刚入门的开发者、有数据安全需求的技术人员也适合只是想在本地体验大模型的小白用户。1. 先别急着装工具判断自己到底需不需要本地部署很多人的第一反应是“我为什么要本地部署用网页版ChatGPT或者国产API不就行了吗”这个问题问得非常好。本地部署不是目的它是解决特定问题的手段。如果你没有下面任何一个需求说实话直接用云端API完事没必要折腾本地。1.1 数据敏感内容不能出内网这是本地部署最硬核的理由。医疗记录、财务数据、公司内部代码、客户资料这些东西如果通过云端API传过去对方到底存不存、拿不拿来做训练你根本无从查证。尤其在一些合规要求严格的行业业务数据连公网都不能出更别说进大模型推理服务了。我的实际经验是这类需求往往不是技术问题而是管理问题。有一次帮一家小型团队部署本地模型技术本身半小时就搞定了但他们内部反复论证了一个多星期数据留存在哪、日志怎么办、模型载体怎么维护、谁有访问权限。所以如果你是因为“数据隐私”来决定本地部署提前把这些非技术环节想清楚比你先装哪个工具重要得多。1.2 API调用成本居高不下本地高频推理更划算如果你只是偶尔用大模型写点东西API费用完全可以忽略。但如果你是做批量文本处理、大量调用做内容抽取、频繁做对话测试那账单金额真不是闹着玩的。假设每天调用几百上千次、每次输出几百个token月底一看费用这钱都够买一块中端显卡了。本地部署之后推理一次的成本几乎就是电费。一台推理机器一天24小时跑耗电几十度和按token计费比起来一个天上一个地下。这还不算API限流、并发限制这些附加成本。所以“高频调用成本敏感”是本地部署最典型的经济学场景。1.3 学习和调优想拆开看看今天的大模型到底怎么工作纯粹为学习而部署也是一条很正经的路。很多开发者第一次接触大模型是在API层面对token怎么切、上下文窗口怎么影响记忆、显存怎么被KV Cache吃掉、量化到底损失多少精度完全没有体感。这些东西用API是感知不到的。本地部署之后你才能真正理解为什么模型上下文越长显存占用越高为什么同样一个模型在不同量化等级下输出质量差那么多为什么推理速度主要被显存带宽卡住。这些认知对后面做大模型应用开发、微调、性能优化都特别重要。所以不懂底层的人先去部署一次比看十篇理论文章都管用。1.4 硬件速查表你的机器到底能不能跑在进入工具选型之前先用一张粗糙但实用的表判断自己的机器能否满足基本门槛。这张表基于2026年主流量化模型和推理引擎的常见表现以显存/内存为核心指标配置级别显存/内存规模可流畅运行的模型规模典型速度参考入门办公/老独显6-8GB 显存7B-8B 模型 Q4量化10-30 token/s中端主流游戏卡12-16GB 显存13B-14B 模型 Q4量化15-40 token/s高端专业卡或新旗舰24GB 显存32B 模型 Q4量化20-50 token/sMac统一内存16-32GB与GPU共享7B-32B视内存总量15-40 token/s纯CPU无GPU靠内存7B-13B Q4量化非常慢1-5 token/s这个表只是初判量化等级、上下文长度、推理引擎优化都会影响实际表现。但至少可以帮你建立一个基本认知绝大多数近几年的电脑就算没有独立显卡也能跑7B级别的量化模型只是速度和体验的差异很大。下面就从工具选型开始聊。2. 2026年主流本地部署工具选型对比各有各的脾气很多人上来就问“用什么工具好”其实这个问题的正确问法是“我的场景更适合哪个工具”。2026年的本地部署生态已经比较成熟不同工具的定位差异非常明显。我分成几类说每类都有明确的适用场景和局限性。2.1 Ollama无脑入门首选实用度爆表Ollama从发布到现在一直是本地部署工具里的“国民级”存在。它的设计哲学就是“一键搞定”——安装完命令行一个ollama pull qwen2.5:7b就能把模型拉下来ollama run qwen2.5:7b就能直接对话。模型文件、量化等级、上下文都帮你处理好了不需要操心GGUF格式转换、命令行编译这些事。它内置了一个兼容OpenAI格式的API服务默认监听http://localhost:11434。这意味着你用Python、Node.js或者任何支持OpenAI SDK的工具改一下base_url就能从云端API切到本地模型。我在做快速原型验证的时候几乎都是用Ollama起步的。但Ollama也有明显短板默认配置下高并发能力有限很多高级参数被“封装”掉了想要精细控制调度策略、量化细节、并行采样这类底层行为它给你留的口子不够。我的建议是个人使用、小团队内部试用、快速原型优先选它追求极致吞吐的多人服务还是要看vLLM这类重型推理引擎。2.2 llama.cpp想要极致控制和背锅能力就选它llama.cpp是个特别纯粹的项目纯C/C实现最早就是为了能在Mac和CPU上把Llama跑起来而生的。它支持GGUF格式的量化模型也是Ollama、LM Studio这些工具的底层大脑。如果你的场景是需要对推理过程颗粒度级别控制、希望理解推理引擎本身的工作方式或者是部署到没有NVIDIA GPU的机器上那llama.cpp就是你的主力。llama.cpp的启动方式非常“程序员”编译好后一条llama-server -m model.gguf --host 0.0.0.0 --port 8080然后一个返回JSON的HTTP服务就起来了。它暴露了非常多参数比如--ctx-size控制上下文长度、--n-gpu-layers控制多少层GPU offload、--threads控制CPU并发线程数。想要调出一台“最合适”的推理机器这些参数你早晚得学会。它对NVIDIA GPU的支持是通过CUDA的也支持AMD的ROCm和Apple的Metal。不过如果你是纯新手直接碰llama.cpp会遇到很多“坑”——模型来源要自己找GGUF文件、量化版本要看清楚、编译步骤在不同平台上有差异。所以我的定位是有一定技术基础愿意折腾或者有特定的性能调优需求再直接上llama.cpp。简单说它是一把好刀但用的好坏全在刀工。2.3 LM Studio和Jan图形界面党的舒适区如果你完全不想碰命令行LM Studio和Jan是很好的选择。它们都是本地安装的桌面应用支持图形化下载模型、调整参数、查看推理日志也提供OpenAI兼容API。LM Studio对GGUF模型的管理非常方便模型文件放在哪里、什么量化等级、显存占用多少都一目了然Jan则更强调隐私保护用不到网络的东西默认全关。这类工具的优点是“零门槛”缺点是“上限有限”——它们本质上还是调用llama.cpp这一类引擎想做高级调优界面里给不了你那么多控制项。而且年份久了以后各个大版本的更新节奏不一样有些功能会滞后。我的建议是给非技术人员演示、或者自己不想折腾命令行用这类图形工具一旦项目进入服务化阶段还是要回归命令行系工具。2.4 vLLM高并发服务化部署的专业选择如果你的目标是“把本地模型当成一个正式的API服务供多个用户或业务系统调用”那vLLM是2026年的主流答案之一。它的核心杀手锏是PagedAttention和Continuous Batching通俗说就是能在显存里同时管理多个请求的KV Cache把GPU利用率拉到很高并发吞吐量比朴素方案高出好几倍。vLLM适合跑HuggingFace格式的模型Safetensors格式对主流开源模型比如Qwen系列、Llama系列、DeepSeek蒸馏系列都有成熟的适配。启动方式是一条命令vllm serve Qwen/Qwen2.5-7B-Instruct --tensor-parallel-size 1 --max-model-len 8192然后用OpenAI SDK指向它就行。但vLLM对硬件要求也高最好有24GB显存以上的NVIDIA卡显存不够的话强烈不建议硬跑那不是它的主战场。2.5 LocalAI等“套壳工具”我的使用态度市面上有不少项目把自己包装成“OpenAI API的本地替代品”LocalAI是其中比较有名的。这类工具能做也偶尔能捡起来应急但它们的问题是工程成熟度跟第一梯队有明显差距——依赖多、文档更新滞后、兼容性要看版本心情。我的经验是除非有具体原因比如某个项目只支持LocalAI否则不建议把生产业务押在上面。本地部署的“地基”现在很成熟了选成熟生态而非小众包装能省下大量排查时间。当然如果你只是玩一玩装个LocalAI尝鲜也无妨我这里只是提醒你别在产品环境里赌它。2.6 Dify本地部署的上层应用编排不是推理引擎很多热搜词里都有“dify本地部署教程”。这一点必须厘清Dify不是推理引擎不负责把模型“跑起来”它是本地部署生态之上的应用编排平台——做知识库/RAG、Agent工作流、可视化对话流程。它的定位是把Ollama、vLLM这些底层推理服务“接进来”然后让你在上层搭应用。本地部署一个Dify搭配一个Ollama或vLLM服务是你构建私有知识库助手、私有Agent的标准组合。Dify提供容器化部署方式docker compose一键拉起然后把模型供应商配置成你本地的推理服务API地址就能在界面里搭一个“基于私有文档问答”的应用。实际跑起来后你会发现真正费时间的反而不是Dify本身而是文档切分策略、Embedding模型和检索参数调试这些在后面实操部分我会展开提一下。2.7 工具选型速查总结工具本质适合场景上手难度一句话评价Ollama推理引擎封装个人、小团队、快速原型低首选没理由不用llama.cpp底层推理引擎深度调优、CPU/Mac、嵌入式高性能天花板自己掌握LM Studio / JanGUI封装非技术演示、图形化体验低好看但上限有限vLLM高吞吐服务框架多人并发服务化高生产环境的主力LocalAI兼容层封装特定兼容需求中我一般不用在生产Dify上层应用编排RAG、工作流、Agent中不是引擎是“副驾驶”3. 完整实操用Ollama从零跑通一个本地模型工具再多不如一条能落地的链路。这一节我以Ollama为例带你走完“安装-下载模型-对话-开放API”的完整流程。为什么选Ollama因为它是2026年绝大多数人进入本地部署的第一站先把链路跑通再去根据需求升级到其他工具。3.1 第一步确认基础环境先看系统。Ollama支持Windows、macOS、Linux三大平台Windows版本是图形安装包macOS是pkg安装包Linux直接用官方脚本安装。安装之前先确认两件事第一磁盘空间够不够一个7B模型Q4量化大约4-6GB14B模型大约8-12GB32B模型至少20GB第二有没有可用GPUWindows下会优先用NVIDIACUDA和AMDROCmmacOS用Metal没有GPU也能走CPU推理但速度会让人比较急。很多人忽略的一点装Ollama之前先更新显卡驱动。驱动太旧会导致推理时CUDA初始化失败报错信息往往模棱两可很劝退。我的经验是NVIDIA驱动保持最近一年内的版本比折腾各种依赖库有效得多。3.2 第二步安装并验证Windows直接下载安装包Linux一条命令curl -fsSL https://ollama.com/install.sh | sh安装完先验证是否正常ollama --version ollama listollama list用来查看已下载的模型。初次安装是为空的。Windows和macOS装完一般会自动加入PATHLinux如果提示找不到命令多半需要把Ollama的二进制目录加进环境变量或者重新登录一下shell。3.3 第三步选择并下载合适的模型选模型是个关键决策。我的建议是2026年直接选这几个主流开源系列中文综合场景Qwen2.5系列7B、14B、32B中文能力、指令遵循都很好Ollama官方标签直接拉取。代码/推理场景DeepSeek-R1蒸馏版1.5B、7B、14B、32B、70B数学和代码逻辑强适合本地做编码辅助。英文生态/工具调用Llama 3.1 8B或者Llama 3.2系列对英文任务优秀且生态适配广。轻量部署低配机器Qwen2.5 0.5B~3B、Gemma 2 2B 甚至Phi系列作为快速测试和嵌入式场景足够用。下载命令很简单ollama pull qwen2.5:7bollama pull会从Ollama模型仓库拉取默认量化版本。Ollama仓库里的模型基本上都是GGUF量化格式对本地友好。下载完成后运行ollama run qwen2.5:7b会进入交互式对话界面。在这里可以直接输入中文提问退出用/bye查看帮助输入/?。如果你机器显存只有6GB左右强烈建议选qwen2.5:3b或者量化更低的版本。与其硬跑一个跑不动的7B模型频繁OOM不如选个小模型丝滑对话。硬上大模型导致卡死体验极其劝退这一步非常重要。3.4 第四步调整上下文长度和生成参数很多人下载完模型直接对话发现“模型不记得早前聊了什么”这大概率是默认上下文长度太小导致的。Ollama默认的上下文长度一般是2048或4096在交互对话里可以用/set parameter num_ctx 8192调整。更稳定的是在运行前直接把参数写好ollama run qwen2.5:7b --num-ctx 8192上下文长度越大KV Cache占用显存越多。以7B模型为例从4096升到8192显存占用会多出1-2GB需要量力而行。常用参数还有temperature温度越低越保守、越高越发散、top_p、repeat_penalty等可调的基本就那几个建议先在默认值上跑再按输出质量微调。这里有一个容易踩的坑在某个会话里/set parameter只在当次会话生效。要让参数长期生效可以在模型配置里改或者在启动时带参数。我自己一般直接用启动参数简单直接。3.5 第五步把本地模型变成一个可调用的API服务对话式体验只是第一步大多数实际应用场景是要把模型作为后端服务来调用。Ollama自带API服务在模型跑起来的前提下用一条命令启动ollama serve默认监听0.0.0.0:11434Windows/macOS安装后默认后台启动。然后就可以用任何HTTP客户端调用它。最常用的创建对话接口curl http://localhost:11434/api/chat -d { model: qwen2.5:7b, messages: [ {role: user, content: 用一句话解释什么是KV Cache} ] }返回结果就是JSON格式的模型回复流。更关键的一点Ollama提供了OpenAI兼容端点curl http://localhost:11434/v1/chat/completions -d { model: qwen2.5:7b, messages: [ {role: user, content: 你好} ] }这意味着你在Python里可以把base_url从https://api.openai.com/v1替换成本地地址http://localhost:11434/v1代码几乎不用改。我在做应用接入的时候最常用的做法就是在环境变量里设置OPENAI_API_BASE一套代码本地云上通用。3.6 额外技巧多模型共存与模型目录管理Ollama允许同时下载多个模型用ollama list查看用ollama rm删除不用的模型。模型文件默认存在~/.ollama/models目录如果你机器的系统盘空间紧张可以通过设置OLLAMA_MODELS环境变量把模型目录指到其他磁盘。这个技巧在给一台办公电脑部署的时候特别管用系统盘全是塞满的不关心的人往往等到下载到一半没空间才开始抓狂。修改环境变量需要重启Ollama服务Windows用户可以在系统环境变量里设置Linux用户在启动脚本里 export。模型文件可以整体迁移直接复制目录后修改指向即可实测迁移后不需要重新拉取。4. 性能与显存怎么判断自己能跑多大的模型很多人的终极困惑是“我到底能跑多大的模型”。这个问题不能只看参数数量要拆开来看。4.1 显存占用的五个部分推理时显存占用主要由五块构成模型权重、KV Cache、激活内存、CUDA上下文、碎片开销。很多人以为7B模型4.7GB权重文件6GB显存就够了实际跑起来经常爆显存因为你忘算了KV Cache和CUDA上下文。KV Cache和上下文长度直接相关粗略估算公式约为GPU层权重数 × 每token显存 × 上下文长度。以7B模型为例如果权重占4.5GBQ4量化上下文长度从2048加到8192KV Cache可能从几百MB涨到2-3GB再加上CUDA上下文和激活内存实际占用轻松超过8GB。这就是为什么有些评测说7B Q4模型最低要8GB显存才稳而纯CPU跑则只看内存大小和速度。4.2 推理速度的核心瓶颈是显存带宽模型推理过程中每一轮生成token都需要把整个模型的权重从显存读一遍准确说是对所有层前向计算一遍。所以速度的上限由显存带宽决定。一张普通NVIDIA游戏卡显存带宽大约300-500GB/s跑7B Q4模型理论上每秒可以扫描约100次权重再考虑计算开销实际生成速度约20-50 token/s。而CPU方案的内存带宽通常只有几十GB/s所以速度会一下掉到个位数。Mac统一内存的优势是带宽非常高M系列芯片带宽几百GB/s而且CPU和GPU共享内存可以跑比显存更大的模型。但代价是用户态内存被吃掉且速度受限于Metal生态优化程度。一台32GB内存的MacBook Pro跑32B Q4量化模型是可以的但token速度基本在10-20左右属于“能用但不够爽”。4.3 量化的本质与选择量化说白了就是把模型权重从高精度FP16/BF16压缩到低精度INT8/INT4/INT3用极小的精度损失换显存占用减半甚至更多。GGUF格式支持的q4_K_M、q5_K_M、q8_0这些标签就是不同量化策略。K-quants系列是llama.cpp社区推出的“智能量化”比朴素4bit量化质量更好是2026年本地部署的主流默认。实际选择建议7B模型用q4_K_M性价比最高显存紧张用q3_K_M或q2_K追求质量且显存充足可以上q6_K或q8_0。上下文长度再折中调。很多人会反复对比“是不是量化损失了就用不了”实测结果显示q4_K_M在日常对话、文本总结、代码生成上跟原版差距非常小但显存占用少了一半以上。这个交易是划算的。4.4 混合推理CPUGPU分工如果你的显卡显存刚好差一点可以利用--n-gpu-layers参数做“部分层跑GPU、部分层跑CPU”。比如7B模型有32层显存只装得下20层剩下12层丢给CPU这样整体能跑起来速度介于纯GPU和纯CPU之间。llama.cpp、LM Studio、Ollama通过OLLAMA_GPU_LAYERS环境变量都支持这种混合模式。我的经验是显存不够时优先把“靠近输入端”的层放GPU还是把“靠近输出端”的层放GPU对性能有细微影响但大多数场景下不重要。真正重要的是不要让CPU和GPU之间的传输成为瓶颈——每次前向传播都会切一次数据如果层切得太碎效率反而更差。所以混合模式更多是“应急方案”不是最优解。5. 常见问题排查从OOM到“乱说话”本地部署工具都帮你把繁琐的操作简化了但真正让人头疼的是运行中出现的问题。这里把我踩过的一些坑和解决思路整理出来做成一张速查表再挑几个重点展开。症状典型原因排查/解决建议CUDA Out of Memory显存不足加载过大的模型或上下文太长缩小模型量化等级、降低num_ctx、关其他占显存程序启动后速度极慢走的是CPU而非GPU或GPU层数不足确认驱动/ROCm/Metal状态用--n-gpu-layers增加GPU层数输出中文乱码/质量差模型选错中文本地化差、温度太高换Qwen等中文模型temperature调低到0.5-0.7API调用连不上服务未启动、端口被占用、防火墙拦截ollama serve先跑起来换端口或用127.0.0.1测试回复说“我无法访问本地文件”模型没有内置外部工具本地知识库要配合RAG/Agent工具模型自身没有联网或读文件能力模型“一本正经胡说八道”温度偏高、上下文不足、模型能力不够降低temperature增加相关上下文换更大/更专的模型5.1 显存溢出OOM怎么办这个问题在低显存机器上几乎一定会出现。三步走先看当前显存占用Windows任务管理器Linux下nvidia-smi再决定是减小上下文还是换更低的量化。我的经验是优先减小上下文长度因为它对显存的影响立竿见影其次再换量化等级。如果都还不够直接换小一号的模型。还有一个很容易被忽略的因素模型启动时会预分配大量显存。Ollama和llama.cpp都有“按需分配”机制但有些工具的默认配置会一次性申请较多显存。如果你在显存很紧张的情况下运行优先用Ollama默认设置别急着开一堆参数往往有意外的“省显存”效果。5.2 为什么输出速度奇慢无比最可能的原因就是“模型其实跑在CPU上”。检查方法很简单推理时打开系统监控看GPU利用率是不是接近0CPU利用率是不是爆满。如果是就是没有走GPU推理。解决路径更新GPU驱动确认Ollama的GPU支持Windows下ollama run会打印使用GPU的信息llama.cpp需要编译时有CUDA/Metal支持或者用--n-gpu-layers 99强制多放几层到GPU。另一个原因是模型本身太大即便部分层在GPU每token生成时间也压不下去。这种时候要看你的期望值7B模型 30 token/s 是舒服的14B模型能到15-20已经算不错32B模型能到10以上已经值得高兴了。不要拿本地推理速度去对标云端两者不是同一个级别的算力。5.3 本地模型“不会说话”或者回答质量太差很多用户第一次本地部署后抱怨“为什么不如ChatGPT聪明”。这里要认清现实7B、8B量级的本地模型能力上限就是比大参数云端模型差这不是工具问题是模型规模的物理规律。但如果你发现输出质量出奇差先看两个参数temperature是不是太高了默认值如果偏高输出容易发散还有模型本身没设系统提示词。我一般在对话上下文中加一段System Prompt明确模型角色、回答风格、长度约束。文件内容抽取场景我会加一句“你是一个精准的中文信息抽取助手只输出JSON”编程场景我会加“你是一个资深的Python开发工程师先解释思路再给代码”。很多本地模型对系统提示很敏感加了和没加完全是两个体验。5.4 “接不上API”的排查路径Ollama的API服务默认只监听本机回环地址如果你要从另一台机器访问需要设置OLLAMA_HOST0.0.0.0。注意Windows防火墙默认会拦截外部访问要么在防火墙放行要么用内网穿透/端口转发方案。我试过最稳的做法是在同一台机器上部署应用和推理避免网络层面的麻烦确需跨机访问先确认curl http://目标IP:11434/api/tags能通再排查应用代码。端口冲突也需要留意。11434这个端口偶尔会被其他服务占用报错信息是“Failed to connect”。解决方法是换端口修改OLLAMA_PORT环境变量服务启动后应用里的base_url同步改。这个坑不算多但遇上了就卡很久提前知道能省不少事。6. 进阶玩法本地部署之后上层应用能干些什么本地模型跑通只是第一层。真正有价值的是围绕本地模型搭建出上层应用。2026年的本地部署生态里最实用的三个方向分别是知识库RAG、可视化聊天界面、微调训练。6.1 知识库RAG让本地模型结合私有文档回答问题大概所有人部署完本地模型后的下一个需求都是“我能让它基于我的文档回答问题吗”这就是RAG检索增强生成。核心流程是把文档切片、用Embedding模型转成向量、把向量存进向量数据库、用户提问时检索最相关片段、拼进Prompt里让大模型回答。本地部署组合是Ollama推理对话 一个Embedding模型Ollama里有bge-m3、nomic-embed-text等 向量数据库Chroma、Qdrant、Milvus都行。Dify这个平台把上面这些都封装成了可视化配置你只需要在界面上传文档、选Embedding模型、连接本地推理服务地址就能搭出一个带知识库的问答应用。踩过的坑文档切分策略比模型本身更影响回答质量。一块文档切成多大、重叠多少字符、要不要按结构切都得根据实际文档类型调。切得太碎上下文片段缺失回答东拼西凑切得太大检索命中率下降且Token费用高。我的经验是先按照章节标题、段落自然切分每个片段控制在300-500字再根据测试效果迭代。6.2 用Open WebUI把Ollama包装成ChatGPT一样的界面命令行对话不适合给非技术用户使用Open WebUI原Ollama WebUI就是解决这个问题的。它提供一个类似ChatGPT的前端界面支持多轮对话、会话管理、Markdown渲染、模型切换还能接入知识库。Docker一键启动docker run -d -p 3000:8080 --add-hosthost.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main启动后浏览器访问http://localhost:3000在设置里把OpenAI API Base URL填成http://host.docker.internal:11434/v1就能把Ollama接进去。这套方案我推荐给所有要给团队内部做演示的人——命令行切换到Web UI观感完全不一样用户接受度也高很多。6.3 微调本地部署的下一个层次最后说一句热词里反复出现的“大模型微调”。本地部署和微调是两个层面的事情部署是把模型跑起来微调是拿自己的数据去改变模型行为。2026年微调工具的主流就是LlaMA-Factory、Unsloth、Axolotl这几类其中LlaMA-Factory对新手最友好支持LoRA/QLoRA能够在消费级显卡上微调7B模型。如果想试试微调建议先明确一个概念微调的目标不是“教会模型新知识”而是“改变模型的输出风格和行为模式”。想让模型按照特定格式输出结果、模仿特定角色说话微调有效想让它知道2026年发生的新闻事件、你的私有文档内容那是RAG的活微调干不了。这个认知错误是很多人微调失败的根源。硬件方面7B模型的QLoRA微调大约需要10-12GB显存如果关闭某些优化可能更低14B模型需要16-24GB32B模型基本要32GB以上。微调完的模型权重要导出成GGUF格式Way归到Ollama/llama.cpp就能像普通模型一样本地推理。这一套“本地微调本地部署”的链路在消费级硬件上跑通是个人开发者最实际的工作流。最后再分享一个我个人的经验本地部署的起步阶段不要追求一步到位去上大模型、上复杂框架。先用Ollama跑通一个7B模型把基本原理吃透再逐步根据需求去接触llama.cpp、vLLM、Dify这些上层工具。这个过程通常两三天就能完成但带来的认知提升比看十个教程都值。踩过几次坑之后你才会真正明白本地部署这件事门槛真的不高难的只是在各种取舍之间找到适合自己场景的那条路。