我第一次认真考虑在自己电脑上跑大模型，是去年秋天的事。当时我在调试一个内部工具，需要模型帮忙处理一批合同文本，可一算云端API的费用，再一想到要把客户资料传到别人服务器上，心里就犯嘀咕。那会儿我对本地部署几乎一无所知，只知道这事儿听起来挺硬核。后来花了大概三周时间，从一台带RTX 3060的旧主机开始折腾，才慢慢摸清楚门道。这一章我想把这些入门阶段该搞明白的事讲清楚，尤其是那些我踩过的坑和绕过的弯路。
1.1 本地部署大模型的定义与基本原理
本地部署大模型，说白一点，就是把模型文件下载到自己的机器上，用本地的算力去跑推理，整个过程不依赖外部的API接口。你问它问题，它在你的CPU或者GPU上算出答案，数据不出你的硬盘。这件事之所以能成立，是因为Meta、阿里、DeepSeek这些团队把训练好的模型权重公开了出来，任何人下载下来就能用。模型本身就是一个几百MB到几百GB不等的文件包，里面存着几十亿个参数，每个参数都是一串数字，决定了模型怎么理解你的输入、怎么生成回复。
原理层面，你不需要懂太多数学。可以把它想象成一个巨大的函数，输入一段文字，输出另一段文字。本地部署要做的，就是给这个函数准备好运行环境——足够的显存把参数装进去，合适的推理框架把计算调度起来，再加一个能跟你对话的界面。我第一次成功跑通的时候，看着终端里一行行跳出来的文字，那种感觉跟调用云端API完全不一样，像是自己家里突然多了一个能聊天的东西。
1.2 与云端API、私有云部署的差异对比
云端API是最省事的路子。OpenAI、Anthropic、百度、阿里都提供接口，你注册个账号，拿到key，几行代码就能用。缺点是每次请求都要走公网，数据要离开你的控制范围，费用按token算，用得多就贵。我有个朋友做法律咨询工具，每天要处理上千份文档，用云端API一个月账单能到好几千块，后来他咬牙换了本地部署，电费加上硬件折旧，成本直接砍掉一大半。
私有云部署是中间路线。你在自己的服务器或者租来的云主机上搭一套推理服务，数据在自己手里，但机器不在身边。这种方式适合团队协作，几个人共用一个端点，管理起来比每人本地跑一套要省心。跟纯本地部署比，私有云的好处是算力可以集中，坏处是你还是得维护服务器，网络断了也用不了。我现在的做法是混合着来：日常调试用本地，批量任务丢到私有云上跑。
1.3 选择本地部署的核心动机：隐私、成本、可控与离线能力
隐私是我最看重的点。我处理过一些医疗相关的文本，里面有人名、病历号、诊断细节，这些东西放在云端总让我不踏实。本地部署之后，数据从输入到输出全程在本地闭环，哪怕断网也不影响。有些行业对数据出境有硬性规定，本地部署几乎是唯一合规的选择。
成本这块要算长期账。买一张RTX 4090要一万多，听起来不便宜，可如果你每天调用云端API的费用超过二三十块，一年下来就回本了。电费确实要考虑，满载跑起来整机功耗能到四五百瓦，但大多数个人使用场景不会一直满载。可控性也很重要，云端API的模型版本、参数、限流策略都是别人定的，今天能用明天可能就变了。本地部署你想换哪个模型就换哪个，想调什么参数就调什么参数。离线能力算是附赠的惊喜，我出差在高铁上写过东西，没有网照样能让模型帮我改稿子。
1.4 本地部署大模型需要什么配置：先建立整体评估维度
很多人一上来就问“跑大模型要什么显卡”，这个问题其实没法直接回答。你得先想清楚三件事：你要跑多大的模型，你准备花多少钱，你对速度的要求有多高。模型参数量决定了显存下限，7B的模型量化后大概需要4到6GB显存，70B的模型就算量化到4bit也得40GB左右。预算决定了你能买什么级别的硬件，速度要求决定了你愿不愿意等。
我建议用三个维度来评估：显存容量、内存带宽、存储读写。显存是硬门槛，不够就是跑不起来。内存带宽影响推理速度，同样的模型在不同平台上跑，速度能差好几倍。存储读写主要影响模型加载时间，NVMe固态和机械硬盘的差距非常明显。这三个维度之外，CPU的核心数和指令集支持也会影响一部分场景，尤其是纯CPU推理的时候。
1.5 典型用户画像与场景：个人学习、团队研发、企业内网
我自己属于第一类，个人学习型。主要目的是搞明白大模型怎么工作，顺便用它辅助写作和编程。这类用户通常预算有限，一台带中端显卡的台式机或者一台MacBook就够用。我认识几个学生朋友，用16GB内存的笔记本跑量化后的7B模型，虽然慢点，但学习完全够。
团队研发型用户更在意协作和效率。他们需要统一的模型版本、共享的推理服务、方便集成的API接口。我参与过一个五人的小团队，在内部服务器上部署了Qwen的14B模型，大家通过局域网调用，省去了每人本地装环境的麻烦。企业内网型的场景最复杂，要考虑权限管理、审计日志、多模型调度、跟现有系统的对接。这类用户通常有专门的运维人员，对稳定性和安全性的要求远高于个人用户。
1.6 常见误区与不适用边界
我刚入门时最大的误区是以为“本地部署一定比云端好”。跑了一个月之后发现，有些任务云端确实更合适。比如需要最新知识的问题，本地模型的知识截止到训练数据的时间点，问它今天的新闻它只能瞎编。再比如需要极强推理能力的复杂任务，本地能跑动的模型规模有限，效果跟云端的大模型差距明显。
另一个误区是低估了维护成本。模型文件要更新，推理框架要升级，驱动和CUDA版本时不时闹别扭，这些都要花时间。如果你只是想快速验证一个想法，不想折腾环境，云端API可能是更明智的选择。本地部署真正的适用边界在于：你对数据隐私有要求，你有持续的使用需求，你愿意投入时间学习维护。三条缺一条，本地部署的性价比就会打折扣。
我刚开始折腾本地部署那会儿，看见网上到处在说Llama，就以为它是唯一的选择。下载了Llama 2的7B版本，兴冲冲跑起来，问它几个中文问题，回答得磕磕绊绊，像外国人刚学中文。那时候我才意识到，模型选型这件事，跟挑鞋一样，得看脚多大、走什么路。这一章我想把这几个月试过的模型、框架、量化格式都捋一遍，帮你在动手之前少走点弯路。
2.1 主流开源模型生态：Llama、Qwen、DeepSeek、Mistral等
Llama算是开源大模型的领头羊，Meta每隔一段时间就放出新版本，社区支持最广，教程最多。我最早用的就是Llama 2，后来升级到Llama 3，英文理解和生成确实强。它的短板在中文上，尤其是涉及成语、古诗词、本土化表达的时候，经常闹笑话。如果你主要处理英文内容，Llama系列很稳，生态里的工具链也最全。
Qwen是我现在的主力。阿里把这个系列做得挺用心，中文能力在开源模型里数一数二。我拿Qwen 2.5的7B版本试过写周报、改合同、回答技术问题，效果比同规模的Llama好不少。DeepSeek的特点是推理能力强，尤其是数学和代码任务，它家的MoE模型用起来很省显存。Mistral走的是轻量路线，7B模型在法语和欧洲语言上表现不错，英文也可以，中文就差一些。我个人的建议是：中文场景优先Qwen，英文通用选Llama，代码和数学多看看DeepSeek，追求轻量就试Mistral。
这几个模型各有各的脾气，没有哪个能通吃所有任务。我现在的机器上同时存着Qwen和DeepSeek，写作用前者，调代码用后者。模型文件加起来占了一百多GB，好在硬盘便宜，多存几个也无所谓。你刚开始不用贪多，挑一个主流的中文模型跑通，后面再按需添加。
2.2 参数规模与任务匹配：7B、13B、70B与MoE架构
7B模型是我最推荐新手起步的规模。量化之后大概4到6GB显存，一张RTX 3060 12GB就能跑得很舒服。它适合日常问答、文本摘要、简单翻译这些任务。我拿7B模型写过邮件、整理过会议纪要，速度够快，质量也过得去。碰到复杂推理或者长文档分析，7B就有点力不从心，容易漏掉关键信息。
13B到14B这个区间是个甜点。显存占用翻了一倍左右，但理解能力和逻辑连贯性提升明显。我试过Qwen 14B，处理三千字的技术文档时，它能抓住大部分要点，生成的摘要比7B版本更靠谱。70B模型是另一个世界，全精度需要一百多GB显存，量化到4bit也得40GB左右。我只在租来的A100上跑过几次，效果确实好，可普通玩家很难日常使用。MoE架构是个例外，像Mixtral 8x7B，总参数量大，但每次推理只激活一部分，显存需求比同总参的密集模型低不少。我拿它跑过一阵子，速度比70B密集模型快，质量也接近，算是个折中的选择。
选参数规模的时候，我一般会问自己三个问题：这个任务容错率高不高？我能不能接受等几秒钟？我的显卡能不能装下？日常聊天、草稿生成，7B完全够。正式文档、代码审查，14B更稳妥。需要深度推理、长链条思考，那就得上70B或者租云端。别为了追求大参数硬撑，跑不起来的模型再好也白搭。
2.3 量化格式与精度权衡：GGUF、GPTQ、AWQ、FP16
量化这个词听起来吓人，说白了就是把模型参数从高精度数字变成低精度数字，牺牲一点点准确率，换来显存和速度的大幅改善。GGUF是llama.cpp生态里的格式，对CPU和混合推理特别友好。我第一台机器没有独立显卡，就是靠GGUF格式在CPU上跑7B模型，虽然慢，但至少能跑。GGUF有好多量化等级，Q4_K_M是我最常用的，质量损失小，显存占用也合理。
GPTQ和AWQ是给GPU用的量化格式。GPTQ出现得早，兼容性好，很多模型都有现成的量化版本。AWQ在速度上通常更快一些，精度保持得也不错。这两个格式都需要显卡支持，加载的时候比GGUF稍微麻烦点，但推理速度快很多。FP16是原始精度，效果最好，显存占用也最大。我一般只在显存充足或者做对比测试的时候用FP16，平时都跑量化版。
我的经验是：先拿GGUF的Q4_K_M版本试水，跑通了再考虑换GPTQ或AWQ。量化等级别压得太狠，Q2、Q3虽然省显存，但模型容易变傻，回答里经常出现重复或者逻辑断裂。Q4到Q5之间是质量和资源的平衡点，大多数场景够用。如果你特别在意输出质量，可以试试Q6或Q8，显存够的话直接上FP16。
2.4 推理框架对比：Ollama、llama.cpp、vLLM、Transformers
Ollama是我逢人就推荐的入门工具。一条命令下载模型，一条命令启动服务，自带API接口，几乎不需要配置。我刚开始本地部署的时候，用Ollama半天就跑通了第一个模型，那种成就感让我坚持了下来。它的缺点是定制化程度低，想改底层参数不太方便。对新手来说，这个缺点可以忽略。
llama.cpp更底层，灵活度高。它支持GGUF格式，能在CPU、GPU、甚至苹果芯片上跑。我后来为了调优，花了一个周末研究llama.cpp的编译参数，虽然折腾，但对推理过程的理解深了很多。vLLM是给生产环境用的，吞吐量高，支持并发请求，适合团队共享。我在公司的服务器上部署过vLLM，同时处理十几个请求也没问题。Transformers是Hugging Face的库，适合做研究和微调，直接拿来部署有点笨重，启动慢，显存管理也不如专用框架。
选框架这件事，看你的阶段。刚入门，Ollama。想深入理解，llama.cpp。要服务多人，vLLM。做实验、改模型结构，Transformers。我现在是混合着用：日常测试用Ollama，性能调优用llama.cpp，给团队提供服务用vLLM。每个框架都装一遍不现实，先挑一个跑通，后面需要了再加。
2.5 部署路线图：先跑通、再优化、后集成
我踩过最大的坑，是一上来就想把整套东西搭完美。第一次部署，我花了三天时间研究vLLM的配置、CUDA版本、Docker网络，结果模型还没跑起来，人已经快崩溃了。后来一个朋友跟我说：你先用Ollama跑起来，能对话了再说。我照做，半小时就成功了。那一刻我才明白，先跑通有多重要。
跑通之后，优化才有意义。我第二步是换量化格式，从默认的Q4换到Q5，对比输出质量。接着调推理参数，温度、top_p、上下文长度，一个个试。速度不满意就换框架，显存不够就降量化。这个过程像调音，一点一点拧，直到模型在你的硬件上跑得顺。我当时花了大概一周，把7B模型的生成速度从每秒5个字提到了15个字，效果提升很明显。
集成是最后一步。模型能跑、速度能接受之后，再考虑接WebUI、接API、接知识库。我现在的流程是：Ollama提供后端，Open WebUI做界面，需要RAG的时候再挂一个向量数据库。别一开始就想着全都要，先把最核心的对话功能跑稳。集成环节出的问题通常跟模型无关，是网络、端口、权限这些琐事，放到后面处理心态会好很多。
2.6 本地部署大模型教程的选型决策清单
折腾了这么多模型和框架，我慢慢总结出一份自己的选型清单。每次要部署新东西，我会先问自己：主要任务是什么语言？中文优先选Qwen，英文优先选Llama，代码选DeepSeek。显存有多大？8GB以下看7B量化版，12GB到16GB看14B，24GB以上可以试试30B或者MoE。对速度要求高不高？要高就选GPU加GPTQ或AWQ，能接受慢就选GGUF跑CPU。
接着问：我准备花多少时间维护？只想点点鼠标就用Ollama，愿意折腾就用llama.cpp，要服务多人就上vLLM。需要界面吗？需要就装Open WebUI，不需要就用命令行。要不要接知识库？要的话提前规划好向量数据库和嵌入模型。这些问题没有标准答案，你的回答会决定最终的技术栈。
我见过不少人直接照搬网上的配置单，结果跑起来各种报错。每个人的硬件、网络、使用习惯都不一样，别人的最优解到你这里可能水土不服。我的建议是：从最简单的组合开始，Ollama加Qwen 7B GGUF，跑通之后按清单逐项调整。本地部署大模型这件事，选型不是一锤子买卖，而是随着你的需求和经验不断演化的过程。今天觉得够用的配置，下个月可能就想升级了。
我装第一台跑大模型的机器时，以为买张好显卡就万事大吉。结果模型加载到一半，屏幕一黑，重启了。查了半天，内存不够。后来换了主板，又发现电源带不动新显卡。硬件这东西，一环扣一环，少考虑一样就得多折腾好几天。这一章我想把我踩过的坑和后来总结的配置经验摊开聊聊，从CPU到GPU，从内存到硬盘，还有系统和驱动那些烦人的版本问题。
3.1 CPU、内存与主板要求
CPU在本地部署里不是最出风头的角色，但它绝对不能太寒酸。模型加载、数据预处理、还有把部分层卸载到CPU跑，这些活都得靠它。我早期用一台老至强E5，核心多但主频低，加载7B模型要等好几分钟。后来换成Ryzen 5 5600，六核十二线程，加载时间直接砍半。如果你打算纯CPU推理，核心数和AVX指令集就很重要，AVX2是底线，AVX512更好。我试过在支持AVX512的服务器CPU上跑llama.cpp，速度比老平台快不少。
内存容量比频率重要得多。7B模型用FP16精度加载，光权重就要吃掉14GB左右内存，加上系统和其他程序，16GB根本不够。我建议起步32GB，最好64GB。跑70B模型的话，128GB是门槛。有一次我帮朋友装机器，他只有16GB内存，跑7B量化模型，加载时直接爆内存，系统卡死。内存频率对推理速度影响很小，别在这上面花冤枉钱，容量拉满更实在。
主板的选择主要看扩展性。PCIe插槽数量决定了你能插几张显卡。消费级主板通常只有一条PCIe x16，想加第二张卡就没地方了。我第一块主板就是这个问题，后来换了一块支持双x8的主板。M.2插槽也很关键，模型文件越来越多，多几个NVMe插槽方便扩展。电源接口和供电相数也要留意，大功率显卡对电源要求高。我吃过亏，550W电源带RTX 3060还行，换3070 Ti就频繁重启。
3.2 GPU与显存：NVIDIA、AMD、Apple Silicon
NVIDIA显卡是目前最省心的选择。CUDA生态太成熟了，Ollama、llama.cpp、vLLM这些框架都优先支持它。显存大小直接决定你能跑多大的模型。8GB显存可以跑7B的Q4量化版，12GB能跑13B量化，24GB可以试试30B或者70B的低量化。我用的RTX 3060 12GB，性价比很高，跑Qwen 7B和14B量化模型都很流畅。40系显卡速度更快，但显存没怎么涨，RTX 4060 Ti有16GB版本，值得考虑。专业卡像A100、H100性能炸裂，价格也炸裂，个人玩家租着用更划算。
AMD显卡性价比诱人，软件生态却让人头疼。ROCm框架的兼容性不如CUDA，很多推理框架对AMD的支持要么缺失，要么需要手动编译。我试过RX 6800 XT跑llama.cpp，能跑，速度也还行，但换到vLLM就各种报错。如果你愿意花时间折腾，AMD能省不少钱。图省事的话，还是NVIDIA。Apple Silicon是另一条路。M系列芯片用统一内存，显存和内存共享，M2 Max 64GB版本跑70B量化模型居然能跑起来，虽然生成速度慢，但功耗低、噪音小。我借朋友的MacBook Pro试过，出差带着跑模型，挺方便。
选GPU的时候，显存是硬指标。我见过有人为了追求核心频率买了8GB显存的卡，结果14B模型都跑不了，后悔莫及。宁可核心弱一点，显存大一点。另外，显卡的散热和噪音也要考虑。我现在的机器放在书房，夜深人静时风扇声很明显。如果对噪音敏感，水冷或者开放式机箱会好一些。
3.3 存储空间、读写速度与模型仓库规划
模型文件占空间的速度超乎想象。一个7B模型FP16格式大约14GB，量化到Q4就只剩4GB左右。听起来不大，可你不可能只下一个模型。我机器上现在有Qwen 7B、14B、32B，DeepSeek 7B，还有几个Llama的版本，加起来超过200GB。70B模型更夸张，FP16要140GB，Q4量化也要40GB。我建议至少准备2TB的NVMe固态硬盘。机械硬盘虽然便宜，但加载模型时慢得让人想砸电脑。
读写速度对推理过程影响不大，模型加载完就常驻内存和显存了。加载速度倒是很关键。NVMe SSD读取速度能到3000MB/s以上，SATA SSD只有500MB/s左右。我从SATA换到NVMe后，70B模型的加载时间从五分钟缩短到一分多钟。如果你经常切换模型，这个提升很明显。
模型仓库的规划我走过弯路。一开始所有模型都堆在一个文件夹里，名字乱七八糟，后来自己都忘了哪个是哪个。现在我的习惯是按模型家族分目录，比如models/Qwen、models/Llama，每个模型下面再按量化等级分子文件夹。不同框架的模型格式不同，GGUF放一个区，GPTQ和AWQ放另一个区。用符号链接把常用模型链接到Ollama的模型目录，省得复制来复制去。Hugging Face的缓存目录也可以设置到数据盘，避免系统盘被撑爆。
3.4 操作系统、驱动与CUDA版本匹配
操作系统我用过Windows、Ubuntu和macOS。Windows上手容易，WSL2也能跑大模型，但性能有损失，显存调用不如原生Linux直接。我早期在Windows上跑Ollama，经常遇到端口冲突和路径问题。后来转投Ubuntu 22.04，世界清净了。Linux对NVIDIA驱动和CUDA的支持最好，大部分部署教程也基于Linux。macOS适合Apple Silicon芯片，开箱即用，但仅限苹果硬件。
驱动和CUDA版本是新手最容易栽跟头的地方。NVIDIA驱动版本决定了支持的最高CUDA版本。你装PyTorch或者vLLM的时候，它们又要求特定的CUDA版本。版本对不上，轻则警告，重则跑不起来。我的经验是：先用nvidia-smi看看驱动支持的CUDA版本，然后去框架官网查对应的CUDA要求。尽量用Docker镜像，官方镜像通常已经配好了驱动和CUDA的兼容组合。我一次手贱升级了驱动，结果Ollama突然不认显卡了，折腾一晚上才回滚。
Docker是个好东西，能隔离环境。但Docker里用GPU需要装nvidia-container-toolkit，配置有点繁琐。我建议新手先用裸机跑通，再考虑Docker。CUDA版本切换可以用update-alternatives，或者直接装多个版本然后改环境变量。我机器上现在有CUDA 11.8和12.1两个版本，不同的框架用不同的。听起来麻烦，熟悉了也就那回事。
3.5 不同预算配置清单：入门、进阶、专业
入门配置我推荐预算五千到八千。CPU选六核十二线程的Ryzen 5或者Intel i5，内存32GB DDR4，显卡用RTX 3060 12GB或者RTX 4060 Ti 16GB，硬盘1TB NVMe。这套配置跑7B到14B的量化模型没问题，日常问答、写草稿、简单翻译都够用。我自己就是从类似配置起步的，那时候跑Qwen 7B Q4，每秒能出十几个字，体验不错。电源选650W以上，机箱散热别太省。
进阶配置预算一万五到两万五。CPU升级到十二核以上，内存64GB，显卡上RTX 4070 Ti Super 16GB或者RTX 4090 24GB，硬盘2TB NVMe。这套能跑30B量化模型，或者70B的低比特量化。我现在的机器就是类似配置，跑Qwen 32B Q4很流畅，DeepSeek 70B Q3也能跑，速度慢点但能用。如果要做微调或者多人使用，内存最好加到128GB。电源要850W以上，散热用360水冷。
专业配置预算五万起。双RTX 4090或者专业卡如A6000，内存128GB到256GB，硬盘4TB NVMe。这套能跑70B FP16，或者多个模型同时服务。企业内网部署通常需要这样的配置。我帮公司配过一台双4090的机器，跑vLLM服务，同时处理十几个请求没问题。电费也是个考虑，双4090满载功耗接近900W，加上其他部件，一天下来电费不便宜。云服务器可以按需租用，但长期成本更高。
3.6 云服务器、本地工作站与边缘设备取舍
云服务器适合临时任务和测试。想试试70B模型的效果，租一张A100按小时计费，跑完就关，成本可控。我经常用云服务器做模型对比测试，省得自己买卡。云服务器的缺点是数据要上传，隐私敏感的场景不合适。网络延迟也会影响交互体验，特别是流式输出的时候。长期使用的话，云服务器总成本远超买一台本地工作站。
本地工作站是一次性投入，长期使用，数据完全在自己手里。离线可用是最大优势，停电断网都不影响。我现在的机器就是本地工作站，想什么时候跑就什么时候跑，不用看云服务商的脸色。电费和维护成本要考虑，但摊到几年里还能接受。适合每天都要用、对数据隐私要求高的用户。
边缘设备是另一个极端。Jetson Orin、树莓派这些设备算力有限，只能跑1B到3B的小模型。我试过在树莓派5上跑Qwen 1.8B，生成一句话要等十几秒，只能做实验玩。边缘设备适合嵌入式场景，比如智能家居、工业检测，模型小、响应快、功耗低。想用边缘设备跑大模型，目前还不现实。
取舍的关键问自己几个问题：我用模型的频率有多高？数据能不能上传到云？预算是一次性还是分期？我个人的选择是本地工作站为主，云服务器为辅。日常使用本地，偶尔测试大模型上云。这样既有隐私保障，又不用为偶尔的需求买昂贵的硬件。
上一章聊完硬件，我盯着自己那台拼凑起来的机器，心里只有一个念头：赶紧让模型跑起来。配置再豪华，环境装不好，照样白搭。这一章我想把从零到第一次成功运行的完整过程拆开讲，每一步都配上我踩过的坑和最后跑通的命令。你跟着走一遍，应该能少折腾几个晚上。
4.1 从零到一部署流程总览
部署大模型这件事，我把它拆成五步。第一步是环境准备，装系统、驱动、Python和CUDA。第二步是选一个推理框架装上。第三步下载模型权重。第四步加载模型跑起来。第五步调通接口或者界面。听起来线性，实际做的时候经常在第三步和第四步之间来回跳。我第一次部署时，环境装了三天，模型跑起来只花了十分钟。前面越乱，后面越快，这话反过来说也成立。
我现在的习惯是先跑通一个最小的模型，比如Qwen 1.8B或者TinyLlama。这个模型小到能在CPU上跑，下载快，加载快，报错也容易看懂。等最小模型能出字了，再换大模型。很多人一上来就下70B，结果环境问题和大模型加载问题混在一起，根本分不清是哪里出错。我吃过这个亏，后来学乖了，先用小模型验证链路，再逐步放大。
流程里最容易被低估的是依赖管理。Python版本、pip源、CUDA版本、框架版本，这四样东西有一个对不上，就可能卡住。我现在每个项目都用独立的虚拟环境，conda或者venv都行。系统Python只用来装基础工具，不直接跑模型。虚拟环境让我的机器上同时存在PyTorch 2.0和2.1两套环境，互不干扰。这个习惯救了我很多次。
4.2 Python、CUDA、Docker与依赖管理
Python版本选择上，我推荐3.10或者3.11。3.12有些库还没跟上，3.9又有点老。我第一台机器用的Ubuntu 22.04自带Python 3.10，正好够用。如果你用Windows，去Python官网下安装包，记得勾选“Add to PATH”。Linux上不要随便替换系统Python，系统工具依赖它。用update-alternatives管理多个版本，或者直接装miniconda，用conda创建独立环境。conda的好处是能同时管理Python版本和CUDA工具包，省得手动配。
CUDA的安装我走过不少弯路。NVIDIA官网的runfile安装方式看着直接，其实容易和系统驱动冲突。我现在优先用包管理器装，Ubuntu上就是apt install nvidia-cuda-toolkit，不过这个版本通常偏旧。想用新版本CUDA，去NVIDIA官网下载deb包，按官方文档一步步来。装完用nvcc --version确认。我遇到过nvcc显示12.1但PyTorch只认11.8的情况，那是PyTorch编译时绑定的CUDA版本问题，换PyTorch版本或者用conda装带CUDA的PyTorch能解决。
Docker在部署里是个双刃剑。官方镜像比如ollama/ollama、vllm/vllm-openai，开箱即用，省去环境配置。我一开始很排斥Docker，觉得多一层抽象。后来发现Docker里跑vLLM，比裸机装省心太多，镜像里CUDA、PyTorch、vLLM版本都配好了。Docker用GPU需要nvidia-container-toolkit，Ubuntu上装它的命令我背下来了：先加NVIDIA的apt源，再apt install nvidia-container-toolkit，然后systemctl restart docker。装完用docker run --gpus all nvidia/cuda:12.1-base nvidia-smi测试，能输出显卡信息就对了。
依赖管理的核心是隔离。我见过有人在系统环境里pip install了一堆包，后来想升级其中一个，结果把另一个搞坏了。虚拟环境是底线。conda环境用conda env export > environment.yml导出，换机器时conda env create -f environment.yml一键重建。pip用pip freeze > requirements.txt，不过pip freeze会把所有间接依赖都列出来，有时候版本锁得太死反而难装。我现在的习惯是只记录顶层依赖，具体版本让pip自己解析。
4.3 模型下载与权重管理：Hugging Face、ModelScope
模型下载的第一道坎是网络。Hugging Face在国内访问不稳定，我试过好几种办法。最省事的是用镜像站，hf-mirror.com是常用的一个，设置环境变量HF_ENDPOINT=https://hf-mirror.com就能用huggingface-cli从镜像下载。ModelScope是阿里的，国内速度快，很多国产模型在上面首发，比如Qwen系列。我下Qwen模型基本都从ModelScope下，命令简单：modelscope download --model Qwen/Qwen2.5-7B-Instruct。两个平台的模型格式基本通用，都是safetensors或者bin文件。
下载工具我推荐huggingface-cli和modelscope命令行。huggingface-cli login输入token后，huggingface-cli download可以断点续传，大模型下载中断了不用从头来。ModelScope的命令行工具类似。我下70B模型时用了整整一晚上，中间断了三次，续传功能救了命。如果你用Ollama，它自带下载器，ollama pull qwen2.5:7b直接从Ollama的仓库拉，走的是自己的CDN，国内速度还可以。不过Ollama的模型是GGUF格式，和Hugging Face的原版权重不一样。
权重管理我前面提过目录规划，这里补充几个细节。Hugging Face的默认缓存目录在~/.cache/huggingface，系统盘小的话很快撑爆。设置HF_HOME环境变量改到数据盘。ModelScope的缓存目录在~/.cache/modelscope，同样可以改。下载前先看模型页面的大小，比如Qwen2.5-7B-Instruct的safetensors文件大约15GB，确认硬盘空间够。下载完用sha256sum校验一下大文件的哈希，虽然慢，但能避免下载损坏导致的加载失败。我有一次偷懒没校验，加载时报了个莫名其妙的错，重新下载才好。
4.4 使用Ollama快速部署第一个模型
Ollama是我推荐给所有人的第一个框架。装起来太简单了，Linux上一条命令：curl -fsSL https://ollama.com/install.sh | sh。Windows和macOS直接下安装包，双击。装完ollama serve启动服务，默认监听11434端口。然后ollama run qwen2.5:7b，它会自动下载模型并加载，等一会儿就能在终端里对话了。我第一次跑通的时候，看着终端里模型一个字一个字往外蹦，那种成就感比装好一台机器还强。
Ollama默认用GPU，有NVIDIA卡的话自动调用。跑7B的Q4量化模型，显存占用大约5GB，速度很快。你可以用ollama ps看当前加载的模型，ollama list看本地已有的模型。Ollama的模型仓库里有各种量化版本，qwen2.5:7b是默认Q4_K_M量化，想用更高精度可以ollama pull qwen2.5:7b-instruct-q8_0。不过精度越高显存占用越大，Q8的7B模型要8GB左右显存。
Ollama的配置文件在/etc/systemd/system/ollama.service或者~/.ollama/config.json。常用的环境变量有OLLAMA_HOST改监听地址，OLLAMA_MODELS改模型存储路径，OLLAMA_NUM_PARALLEL改并发数。我一般把模型路径改到数据盘，系统盘留给其他东西。Ollama还提供OpenAI兼容的API，http://localhost:11434/v1，可以直接用OpenAI的Python库调用。这个后面章节会细讲，现在先确保ollama run能出字就行。
4.5 使用llama.cpp手动加载GGUF模型
llama.cpp比Ollama底层，也更灵活。它支持GGUF格式，CPU和GPU混合推理，还能精细控制卸载到GPU的层数。我装llama.cpp是从源码编译的，git clone之后make，有CUDA的话用make LLAMA_CUDA=1。编译完在build/bin目录下有一堆可执行文件，最常用的是llama-cli和llama-server。第一次编译可能缺依赖，Ubuntu上装build-essential和cmake基本够用。
GGUF模型文件从Hugging Face下，搜模型名加GGUF就能找到。我常下的是Qwen官方和bartowski的量化版本，质量稳定。下载完直接用llama-cli -m qwen2.5-7b-instruct-q4_k_m.gguf -p "你好" -n 128加载。-ngl参数控制卸载到GPU的层数，-ngl 99表示全部卸载到GPU。7B Q4模型全卸载到GPU，显存占用不到5GB，生成速度比纯CPU快十倍以上。我一开始不知道-ngl，纯CPU跑，每秒两个字，还以为是模型就这么慢。
llama.cpp的llama-server提供HTTP接口，比llama-cli更适合集成。llama-server -m model.gguf -c 4096 --host 0.0.0.0 --port 8080启动后，可以用curl测试。它的API格式和OpenAI不完全一样，但社区有转换层。llama.cpp的优点是不依赖Python，纯C++实现，部署轻量。缺点是模型格式必须是GGUF，要自己转换或者找现成的。我一般从Hugging Face直接下GGUF，省去转换步骤。转换工具convert_hf_to_gguf.py在llama.cpp的仓库里，需要Python环境，转换7B模型要十几分钟。
4.6 安装报错、依赖冲突与排查方法
报错是部署的常态。我遇到过最经典的报错是CUDA out of memory。模型太大，显存装不下。解决办法要么换小模型，要么用量化版，要么用-ngl少卸载几层到GPU。我一开始不理解，以为24GB显存什么都能跑，结果加载70B FP16直接爆了。后来明白显存要算权重加KV Cache加框架开销，70B FP16光权重就140GB，24GB显存连零头都不够。
依赖冲突的报错往往很隐蔽。ImportError: cannot import name 'xxx' from 'yyy'这种，通常是版本不匹配。PyTorch、transformers、tokenizers这几个库版本耦合很紧，升级一个可能带崩另一个。我的排查方法是先看报错里提到的库，用pip show查版本，然后去库的GitHub页面看release notes里的兼容性说明。实在搞不定就重建虚拟环境，把版本锁死。我有一次折腾了三个小时，最后发现是transformers 4.36和tokenizers 0.15不兼容，降回transformers 4.35就好了。
网络问题也经常伪装成依赖问题。pip install卡住或者报ConnectionError，换源能解决。国内用清华源或者阿里源，pip install -i https://pypi.tuna.tsinghua.edu.cn/simple。conda用conda config --add channels https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/。我见过有人pip install vllm下了两个小时，换源后五分钟装完。下载模型同理，Hugging Face连不上就换镜像，ModelScope连不上就检查网络代理。
排查问题的核心是缩小范围。报错信息从下往上看，最后一行通常是根因。日志里搜error、failed、exception这些关键词。我现在的习惯是每装一个新东西，先跑一个最小示例验证。装完PyTorch，跑import torch; print(torch.cuda.is_available())。装完vLLM，跑from vllm import LLM。每一步都验证，出问题时就知道是哪个环节的错。别把所有东西装完再一次性测试，那样报错会堆在一起，根本理不清。
第一次跑通模型的那一刻，前面所有的折腾都值了。看着终端里你的问题被模型接住，然后一个字一个字地吐出回答，那种感觉像是打开了一扇门。环境搭好了，框架跑通了，下一步就是把它变成一个随时能用的服务。下一章我们聊怎么把模型包装成API，怎么接上界面，怎么让它真正融入你的工作流。
模型能在终端里聊天，只是第一步。我真正想要的，是让它变成我每天顺手就能用的东西。打开浏览器能聊，代码里能调，知识库能查，自动化流程能接。这一章我把从“跑起来”到“用起来”的路径拆开，每个环节都配上我实际折腾过的命令和踩过的坑。
5.1 启动本地推理服务与OpenAI兼容API
我最早用Ollama跑通模型后，发现它默认就带了一个HTTP服务。ollama serve启动后，监听11434端口。这个端口背后有一套OpenAI兼容的API，地址是http://localhost:11434/v1。我试过用OpenAI的Python库直接连，base_url改成这个，api_key随便填一个字符串，就能像调GPT一样调本地模型。那一刻我觉得本地部署的门槛一下子降下来了。很多工具和框架只认OpenAI接口，有了这个兼容层，它们都能无缝接上本地模型。
vLLM的启动方式更偏向生产。我装好vLLM后，用vllm serve Qwen/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000就能拉起一个服务。它的吞吐量比Ollama高不少，适合并发请求。vLLM也提供OpenAI兼容接口，/v1/chat/completions这些端点都有。我拿Python的openai库测试，把base_url指向http://localhost:8000/v1，模型名写对，就能拿到回复。vLLM启动时会预分配显存，加载时间比Ollama长一点，但跑起来之后响应很快。
llama.cpp的llama-server也支持类似接口。我常用llama-server -m model.gguf -c 4096 --host 0.0.0.0 --port 8080，它自带一个简单的Web界面，也能处理/v1/chat/completions。不过它的兼容度不如Ollama和vLLM完整，有些参数不认。我一般用curl先测通，再接到脚本里。测API的时候我会先发一个最简单的请求，看返回结构里有没有choices字段。没有的话就是接口格式不对，需要换框架或者加一层转换。
5.2 部署Web UI：Open WebUI、Text Generation WebUI
终端聊天适合调试，日常使用还是图形界面舒服。Open WebUI是我现在的主力。它以前叫Ollama WebUI，用Docker部署最省事。我用的命令是docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui ghcr.io/open-webui/open-webui:main。跑起来后浏览器打开http://localhost:3000，第一次注册的账号就是管理员。它默认会去连host.docker.internal:11434的Ollama服务，我在设置里改成实际地址就能用。
Open WebUI的界面接近ChatGPT，支持多模型切换、对话历史、提示词预设。我特别喜欢它的“工作空间”功能，可以把系统提示词、知识库、工具绑定在一起，存成一个自定义模型。这样我点一下就能进入某个专用助手，不用每次手写提示词。它也支持上传文档做RAG，内置了向量化流程，底层可以选Ollama的嵌入模型或者OpenAI兼容的嵌入接口。我试过传一份PDF，问里面的细节，它能准确引用原文。对于个人和小团队，这个方案几乎零成本。
Text Generation WebUI是另一个选择，圈内叫oobabooga。它功能更杂，支持Transformers、llama.cpp、ExLlama等多种后端，适合做实验。安装它要clone仓库，跑start_linux.sh，脚本会自动建conda环境装依赖。我第一次装花了快一个小时，中间下了不少包。它的界面没有Open WebUI精致，但参数暴露得多，温度、top_p、重复惩罚都能实时调。我一般用它来对比不同量化版本的效果，正式用还是回到Open WebUI。
5.3 接入本地知识库与RAG问答
模型本身的知识有截止日期，也不懂我的私有文档。RAG是我用得最多的扩展方式。思路很简单：把文档切块，用嵌入模型转成向量，存进向量库；提问时先检索相关块，再把问题和检索结果一起塞给模型。我本地跑嵌入模型常用bge-m3或者nomic-embed-text，Ollama直接支持ollama pull nomic-embed-text。向量库我用Chroma，轻量，Python里几行代码就能跑起来。
具体搭建时我用过LangChain和LlamaIndex。LangChain的组件多，灵活性高，但版本更新快，API经常变。我有一份脚本隔了两个月再跑，报了一堆导入错误，后来锁死版本才稳定。LlamaIndex的抽象更简洁，做RAG的默认流程很顺。我的习惯是先用LlamaIndex快速验证效果，如果要做复杂的工作流再换LangChain。文档分块大小我试过256、512、1024，最后发现512字符加50重叠对中文文档比较合适。分块太大检索不精准，太小又丢上下文。
AnythingLLM和Dify这类工具把RAG做成了开箱即用的应用。AnythingLLM有桌面版和Docker版，上传文档后自动处理，还能选本地Ollama作为对话模型和嵌入模型。Dify更偏向工作流编排，可以拖拽节点，把知识库、模型、条件判断串起来。我在一台16GB内存的机器上跑AnythingLLM加Ollama 7B模型，整体流畅。知识库检索的准确率跟嵌入模型关系很大，换用更好的嵌入模型，召回质量提升明显。我拿同一份技术文档测试，bge-m3比默认的all-minilm能多找到三成相关段落。
5.4 连接Agent、插件与自动化工作流
Agent让模型不只是回答问题，还能调用工具。我最早用AutoGen做多Agent实验，两个模型互相对话，一个负责写代码，一个负责审查。本地7B模型在复杂Agent任务上容易跑偏，提示词要写得很细。后来我用Dify搭建了一个简单的客服Agent，它先查知识库，查不到再调用搜索插件。Dify里配置工具很方便，填入API地址和参数描述，模型就能在需要时发起调用。本地模型对工具调用的格式理解不如GPT-4稳，我加了 few-shot 示例才把成功率提上来。
插件方面，Open WebUI自带工具系统，可以写Python函数注册成工具。我写过一个查询本地天气的插件，模型判断用户问天气时自动调用。写插件的门槛不高，照着官方示例改就行。n8n是另一个自动化利器，它可以定时触发，也可以通过Webhook接收请求。我把n8n和Ollama连起来，做了一个每日摘要机器人：早上定时抓取RSS新闻，调用本地模型总结，再发到我的邮箱。整个流程跑在本机，数据不出内网。
自动化工作流的关键是错误处理。模型输出不稳定，API可能超时。我在n8n里给每个模型调用节点都加了重试和超时，失败时走备用分支。本地模型偶尔会返回空内容或者格式错乱，我在提示词里明确要求输出JSON，再用代码节点解析。解析失败就记录日志，人工检查。这套机制让我的自动化流程能稳定跑上几周不用管。本地部署的好处在这里体现得很明显：我可以随便改流程，不用考虑API费用和调用限制。
5.5 多模型管理与GPU资源调度
机器上装多了模型，管理就成了问题。Ollama的模型都存在~/.ollama/models，用ollama list看清单，ollama rm删掉不用的。它默认加载一个模型后会保持一段时间，OLLAMA_KEEP_ALIVE环境变量控制保持时长。我设成5分钟，不用的时候自动释放显存。Ollama同一时间只能加载一个模型到GPU，切换模型会有几秒延迟。如果频繁切换，我会用vLLM，它支持在一个服务里加载多个模型，不过显存占用也成倍增加。
GPU资源调度我踩过不少坑。24GB显存的卡，跑一个7B FP16模型占14GB左右，再跑一个嵌入模型就有点紧张。我现在的策略是错峰使用：对话模型用Q4量化，占5GB；嵌入模型用GPU跑，占2GB；剩下的显存留给KV Cache。vLLM的--gpu-memory-utilization参数可以控制显存占用比例，我一般设0.8，留一点余量给系统。nvidia-smi是我最常看的命令，每隔几秒刷新一次，观察显存和利用率。
多模型代理我用LiteLLM。它提供一个统一的OpenAI兼容接口，背后可以配置多个模型端点。我在配置文件里写上Ollama的7B、vLLM的14B、还有远程的API，LiteLLM根据模型名路由。它还支持负载均衡和失败重试。这样我的上层应用只需要连LiteLLM一个地址，换模型不用改代码。LiteLLM的日志功能也很实用，能看到每个请求走了哪个后端，花了多少token。对于多模型实验环境，这个代理层省了我很多配置时间。
5.6 端到端实战案例：从模型到可用应用
我拿最近搭的一个内部知识助手做例子。硬件是一台带RTX 4090的工作站，系统Ubuntu 22.04。模型选Qwen2.5-7B-Instruct，用vLLM启动服务，命令是vllm serve Qwen/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000 --gpu-memory-utilization 0.85。嵌入模型用bge-m3，通过Ollama跑在CPU上，避免和对话模型抢显存。向量库用Qdrant的Docker版，docker run -p 6333:6333 qdrant/qdrant。这三个服务起来后，基础能力就齐了。
界面层我用Open WebUI，Docker部署，后端指向vLLM的8000端口。知识库在Open WebUI里上传了公司的手册和常见问题文档，嵌入模型选Ollama的bge-m3。测试时我问了一个手册里的细节，它检索到了正确段落，回答里带了引用。我又试了多轮对话，上下文保持得不错。Open WebUI的“模型”设置里，我把系统提示词改成“你是一个内部技术支持助手，回答基于知识库，不确定时明确说不知道”。这样减少了模型胡编的情况。
最后一步是集成到团队的工作流。我用FastAPI写了一个简单的转发接口，接收企业微信的Webhook，把用户问题转发给vLLM，拿到回答后再返回。整个链路：企业微信→我的FastAPI→vLLM→返回。代码不到一百行。部署上线后，团队里十几个人开始用，日常问答基本能覆盖。偶尔有复杂问题答不上来，我会看日志，发现是知识库没覆盖到，补文档就行。这套系统跑在内网，数据不出门，维护成本就是电费。从模型到可用应用，我花了大概一个周末，大部分时间在调提示词和测试检索效果。现在它成了我们团队每天都会打开的工具。
6.1 推理速度与显存优化：量化、批处理、KV Cache
我一开始只关心模型能不能跑起来，跑起来之后才发现速度才是每天要面对的事。同一个7B模型，Q4量化版本和FP16版本，生成速度能差两三倍。显存占用也从14GB降到5GB左右。我试过Q4_K_M跑对话，回答质量够用。Q8_0更接近原版，但显存翻倍。我的选择是：日常聊天用Q4，需要严谨推理时切到Q8。量化不是万能药，有些小模型量化后逻辑能力下降明显，我会先拿一组固定问题测一遍。
批处理是另一个提速手段。vLLM的continuous batching让我印象深刻。我同时发十个请求，它会把它们拼成一批，GPU利用率从30%拉到80%以上。Ollama默认串行处理，并发一高就排队。我在vLLM启动时加--max-num-seqs 16，吞吐量提升明显。批处理会吃更多显存，KV Cache需要预留空间。我把--gpu-memory-utilization设成0.85，留一点余量。显存不够时vLLM会报错，日志里能看到具体是哪一步失败。
KV Cache是显存里的大头。长上下文对话，KV Cache可能比模型本身还占地方。llama.cpp有--cache-type-k和--cache-type-v参数，可以量化KV Cache到Q8或Q4。我试过Q8 KV Cache，显存省了三分之一，速度几乎没变。vLLM有--block-size和--swap-space，块大小影响内存碎片。我把swap-space设成4GB，碰到突发长上下文时能撑过去。这些参数没有标准答案，我每次换模型都会重新测一遍。调优的过程像给老车换零件，每个改动都能感觉到不同。
6.2 并发、吞吐与生产级部署
个人用和团队用是两个世界。我一个人聊，Ollama足够。十几个人同时提问，Ollama就卡了。我搭过一套vLLM加Nginx的组合。Nginx做反向代理和负载均衡，后面挂两个vLLM实例，各自占一张卡。请求进来按轮询分发。压测时我用locust模拟二十个并发用户，平均响应时间保持在两秒以内。vLLM自带的metrics端点能看排队请求数和token吞吐。我把它接到Prometheus和Grafana，做了一个简单的监控面板。
生产部署要考虑失败恢复。我用Docker Compose管理服务，每个容器配healthcheck。vLLM挂掉后，Docker自动重启。Nginx层加限流，单个IP每秒不超过五个请求。API鉴权用Nginx的auth_request模块，对接一个简单的token验证服务。日志统一收集到Loki，方便排查。这套配置跑了一个多月，中间遇到过显存泄漏，重启容器就好了。后来我把vLLM版本固定，泄漏问题没再出现。
并发不是越高越好。GPU算力有限，请求排队太长，用户体验反而差。我设置最大等待队列长度，超过就返回繁忙提示。流式输出能缓解等待焦虑，vLLM默认支持SSE。我在前端显示“正在思考”，同时开始流式返回token。用户感觉快很多，实际总时间没变。生产环境里，稳定性比峰值性能重要。我宁愿限制并发数，也不让服务崩溃。
6.3 数据隐私、权限与安全加固
本地部署的一大卖点是隐私。数据不出内网，听起来很安全。我最初也这么想，直到发现Ollama默认监听0.0.0.0，局域网里任何人都能调。我赶紧改成127.0.0.1，外面套一层Nginx做鉴权。API key我存在环境变量里，不写进代码。Open WebUI支持用户注册和角色管理，我关掉了公开注册，只允许管理员创建账号。每个人的对话历史相互隔离，普通用户看不到别人的记录。
安全加固还包括网络层。我把模型服务放在独立的内网VLAN，防火墙只放行特定端口。模型文件权限设成700，只有服务账户能读。Docker容器以非root用户运行，挂载卷只读。日志里如果出现用户问题，我会做脱敏处理，把邮箱、手机号替换成占位符。有一次我忘了关调试端口，扫描器报了警。从那以后我定期跑nmap检查开放端口。
权限控制要细到模型。团队里不同人能用不同模型。我用LiteLLM的虚拟key功能，给每个成员分配独立的key，限制可用模型和token额度。Open WebUI里可以设置模型可见性，把内部微调模型只开放给特定组。数据备份用restic加密后传到NAS，密钥离线保存。本地部署不等于零风险，安全习惯比工具更重要。我每个月会review一遍访问日志，看看有没有异常调用。
6.4 成本、功耗与长期维护
本地部署省钱是相对的。一张4090满载功耗450瓦，一天跑十小时，电费大概两度。按商业电价算，一个月不到一百块。同等调用量的云端API可能花几百上千。硬件本身要钱，折旧也要算。我算了笔账：一张卡一万二，用三年，每月折旧三百多。加上电费和散热，总成本跟中档云API差不多。好处是数据可控，想怎么用就怎么用。如果只是偶尔用，云API更划算。
功耗优化我试过限制GPU功耗墙。用nvidia-smi -pl 300把功耗压到300瓦，性能损失大概百分之十，电费省三分之一。量化模型也能降功耗，Q4版本比FP16少用一半电。晚上不用时，我设置定时任务把服务停掉。散热方面，机箱风扇曲线调好，温度控制在75度以下。长期高负载会缩短硬件寿命，我尽量避免连续跑满一周。维护上，我每季度更新一次驱动和推理框架，但不会追最新版。稳定比新功能重要。
长期维护需要文档。我写了一个Markdown文件，记录每个服务的启动命令、端口、依赖版本、模型路径。换机器时照着文档就能重建。模型文件太大，我保留量化版，原版删掉。磁盘空间用du和ncdu定期清理。备份策略是模型权重和配置文件分开，权重可以从Hugging Face重新下载，配置才是心血。有一次我误删了LiteLLM的配置文件，花了一下午重写。现在配置文件也纳入git管理。
6.5 常见问题与调优清单
本地部署的坑我踩过太多。最常遇到的是OOM，显存不够。排查第一步看nvidia-smi，确认是不是模型加载就爆了。如果是，换更小的量化或者减少上下文长度。第二步看系统内存，free -h。有时候是内存不够导致模型加载失败。第三步看磁盘，df -h。模型下载一半空间满了也会报奇怪的错。CUDA版本不匹配也很常见，我固定用CUDA 12.1，驱动版本对好。报错信息里出现“undefined symbol”通常是版本冲突，重装对应版本的torch和vllm能解决。
调优清单我放在一个文本文件里，每次新部署都过一遍。模型层面：选合适的量化格式，Q4_K_M适合大多数场景。推理层面：调整batch size，vLLM的--max-num-seqs从8开始试。显存层面：--gpu-memory-utilization 0.85，KV Cache量化开起来。系统层面：关掉不必要的后台进程，设置CPU性能模式。网络层面：如果走API，确保用HTTP/2或者gRPC。我还会用llama-bench测一下基础性能，有个基准心里有数。
问题排查要分层次。模型输出乱码，先看提示词模板对不对。速度突然变慢，看是不是其他进程占了GPU。API返回401，检查key和地址。服务启动失败，看日志最后二十行。我习惯把日志级别调到DEBUG，虽然信息多，但能定位到具体哪一行出错。有一次模型加载卡住，日志显示在下载某个文件，其实是网络问题。换用国内镜像源后解决了。遇到怪问题，重启服务能解决一半，重装环境能解决八成。
6.6 从本地部署到微调与持续迭代
部署稳定后，我开始想让它更懂我的业务。通用模型回答公司内部问题时，经常泛泛而谈。我试了LoRA微调。用LLaMA-Factory，准备了几百条问答对，格式化成JSON。7B模型QLoRA微调，显存占用不到10GB，一张4090跑得动。训练花了两个小时，损失降到0.8左右。合并LoRA权重后，用vLLM加载，回答风格明显更贴近内部文档。微调不是万能，数据质量比数量重要。我清洗了三遍数据，删掉重复和低质样本。
持续迭代是个闭环。我让团队在使用中标记不满意的回答，每周收集一次。这些bad case分两类：知识缺失和风格不对。知识缺失就补文档，进RAG库；风格不对就加入微调数据集。每两个月做一次增量微调，然后A/B测试。新模型和旧模型同时跑，随机分配用户，看满意度和回答长度。效果好就切换，不好就回滚。vLLM支持多模型加载，A/B测试很方便。我还会定期评估模型的幻觉率，用固定问题集测。
进阶玩法还有模型合并和蒸馏。我用mergekit把两个7B模型合并，得到一个在代码和中文上都还行的模型。蒸馏是用大模型生成数据，教小模型。我拿云端API生成了一批高质量问答，微调本地3B模型，效果接近7B的八成。量化新模型时，我会用校准数据集重新跑一遍AWQ，比直接量化原版好。本地部署的终点不是部署完成，而是让模型持续进化。每次迭代都能看到进步，这种感觉比调参更让人上瘾。
