企业官网建设流程全解析

上周有个前同事来找我，说他照着一篇教程在公司的台式机上装了Ollama，十五分钟就拉下来一个7B模型，兴奋得不行。结果第二天把接口接到内部系统里，三个人同时用就开始转圈，他跑过来问我：是不是显卡买小了？

我说先别急着怪显卡。大模型本地部署在2026年已经不是稀奇事了，随便搜一篇文章都能跑通，但跑通和跑好是两码事。工具选型选错了，再贵的卡也白搭；量化方案选错了，模型答非所问，你会以为是它笨，其实是你在部署环节就埋了雷。这篇文章算是我这几年做本地化部署的完整总结，从"到底要不要本地部署"的账，到Ollama、llama.cpp、vLLM、SGLang这些主流工具的优缺点对比，再到显存怎么算、实操链路怎么走、踩坑怎么排，尽量一次讲透。

适合谁看？个人玩家想在自己电脑上跑模型、中小企业技术负责人想把私有知识库和Agent落到内网、以及刚接触部署的AI应用开发同学。如果你只是想尝鲜，看前两章就够了；如果你想把它接到业务系统里，建议全文看完再动手。

1. 动手之前先算清三笔账：隐私、成本和场景

1.1 数据隐私：本地部署不是可选项而是合规项

很多人觉得本地部署的理由是"省钱"，我在实际项目里看到的真实理由恰恰相反——绝大多数是数据出不去。

医疗机构的病历数据、金融系统的交易流水、企业内部未公开的研发文档，这些东西哪怕打上马赛克也不敢往云端API里发。调用云厂商的大模型API，本质上是把文本数据交给了第三方服务，就算对方承诺不用于训练，合规审计这一关也过不去。2026年很多行业对数据出域的监管比前几年更细，企业内部连"打字到网页里"都要审批，更别提结构化地批量调用外部接口了。

所以我的第一个建议是：如果你的数据有保密要求，本地部署不是技术选型问题，是合规底线问题。这时候不用纠结"该不该部署"，要纠结的只是"用什么工具、怎么部署"。

1.2 算经济账：本地部署到底贵不贵

再说省钱这件事，我得泼一盆冷水：本地部署不是省钱神器，甚至很多时候更贵。

云API按token计费，2026年的价格已经被卷到很低了。一个中等规模的模型，日常批量调用一千次任务，一年算下来可能就是几千块钱的事。但你买一张顶级显卡，两万多起步，加上机器、电源、散热、电费，回本周期往往以年计。更别提模型更新换代，你年初部署的模型，年中可能就有新版本，要不要再掏钱升级硬件？

那什么情况下本地部署才划算？我把账拆开看：

• 调用量大且持续：每天上万次推理调用，云端API的token成本会明显高于硬件摊薄成本；
• 推理延迟敏感：云端接口的网络往返和排队等待不可控，本地部署可以稳定压低首token延迟；
• 数据进出量大：比如要批量处理几十万份文档做离线分析，先把数据传到云端再等结果，网络带宽和存储成本都很难看。

如果你只是每天偶尔问几个问题，说真的，用API体验更好，别折腾本地部署。

1.3 2026年还在本地部署的，都是哪些人

结合我接触过的项目和社区里的反馈，2026年本地部署的用户画像大概分四类：

第一类是个人玩家。手上有一张消费级显卡，跑Qwen或DeepSeek的蒸馏版模型，用来做本地写作辅助、翻译、代码补全，或者接一个Home Assistant做家庭智能中枢。这类人追求的是隐私和可玩性，模型不用太大，7B到14B就够。

第二类是中小企业的技术负责人。他们的诉求很明确：把私有知识库、内部工单系统、客服助手接到一个本地大模型上，流程用Dify这类编排工具串起来，模型藏在内网，数据不出机房。这类部署对稳定性和并发有一定要求，通常会用vLLM+SGLang配合Dify。

第三类是边缘计算和硬件厂商。在Jetson Orin这类嵌入式设备上部署端侧模型，做检测、OCR、离线语音交互，功耗和体积是核心约束。

第四类是科研和微调团队。他们对模型权重有完全掌控的需求，要能反复加载、训练、导出，甚至要自己改推理代码，本地部署是实验环境的一部分。

如果你不属于任何一类，只是想"给电脑装上AI"，那我劝你先别装了，容易三分钟热度。

2. 工具选型硬核对比：六大方案挨个过堂

2.1 Ollama：入门神器的真实上限

Ollama是现在绝大多数人本地部署的起点，原因很简单：一条命令装好，一条命令下载模型，跑起来就是一个OpenAI兼容的本地API。它对新手极度友好，内置了llama.cpp的推理引擎，GGUF模型格式也是社区最流行的。

但它的边界必须说清楚。Ollama的设计目标是"个人桌面跑模型"，不是"生产服务扛并发"。它的服务端对并发请求的处理方式是排队模型，默认情况下一个模型实例同时只能处理有限请求，多出来的请求只能排队等待。我用4090跑7B INT4模型实测，单人使用非常好，生成速度能到每秒90到120个token；但并发拉到4个以上，队列延迟会明显上升，体验断崖式下降。

另外Ollama的高级配置藏得比较深，靠环境变量控制，比如OLLAMA_NUM_PARALLEL可以调并行请求数，OLLAMA_MAX_LOADED_MODELS控制常驻模型数量。如果你只是自己用，默认配置就够了；如果你想给团队用，建议先做好压力测试。

我的结论：Ollama适合个人电脑、原型验证、以及并发不超过3到5的内部小范围使用。别一上来就指望它是生产环境。

2.2 llama.cpp / llama-server：极客和旧硬件的救星

llama.cpp是这个领域的老祖宗，最初的目标就是让大模型在普通CPU上跑起来，它定义了GGUF格式，也是各种量化方案的底层实现。到今天它依然是轻量级部署的首选引擎。

它的优势有三点：一是单二进制文件，没有Python依赖，没有Docker也能跑；二是CPU和GPU混合推理做得极好，显存不够时可以把一部分层放到内存，虽然慢但不崩；三是量化支持最完善，K-quants系列量化格式（Q4_K_M、Q5_K_M、Q8_0等）就是它家生态标准。

llama-server是llama.cpp自带的HTTP服务端，启动方式非常直白：

llama-server -m /models/qwen3-14b-q4_k_m.gguf \ --host 0.0.0.0 --port 8080 \ --n-gpu-layers 99 \ -c 8192

-c是上下文长度，--n-gpu-layers控制把多少层放到GPU。如果你显卡显存不够，把层数调小，剩下的层跑CPU，速度慢一点但不至于跑不起来。

它的短板也很明显：没有模型管理生态，下载模型、更新版本都得自己来；服务化能力弱，没有vLLM那套连续批处理机制，高并发撑不住。所以它适合的场景是：老旧机器、CPU推理、嵌入式设备，或者你想搞清楚底层原理自己折腾的情况。

2.3 vLLM：生产环境吞吐担当

如果你的目标是给多人提供稳定的API服务，vLLM几乎是绕不开的选项。它的核心是PagedAttention和Continuous Batching两个技术：PagedAttention把KV Cache像操作系统的虚拟内存一样分页管理，显存利用率大幅提升；Continuous Batching让不同请求可以在同一个批次里动态进出，吞吐量比朴素实现高出好几倍。

vLLM的启动方式通常是这样：

docker run --gpus all \ -v /models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen3-32B-Instruct \ --max-model-len 32768 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1

几个关键参数我要重点说：--max-model-len是上下文上限，直接影响显存占用；--gpu-memory-utilization控制模型最多吃多少显存，留一点给系统以免OOM；--tensor-parallel-size是多卡并行时用的，单卡写1。

vLLM对OpenAI接口的兼容性是最好的，这意味着你原来写的OpenAI SDK代码几乎可以原样改个base_url就能连上。它的缺点是配置项多，显存管理策略偏"激进预分配"，对不熟悉的人来说上手门槛比Ollama高不少。量化支持早期很弱，近两年才逐渐完善。

2.4 SGLang：前缀缓存和新架构激进派

SGLang是这两年成长最快的新锐推理框架，最大的卖点是RadixAttention前缀缓存。通俗讲，如果你的使用场景里大量请求共享同样的前置上下文——比如RAG场景中所有问题都先拼接同一段知识库内容，或者Agent场景里多轮对话反复携带系统提示词——SGLang会把这段公共前缀的KV Cache缓存复用起来，首token延迟能降一大截。同样的场景放在vLLM里，因为前缀没有专门优化，每次都要重新算一遍。

实际对比数据我记得很清楚：同样在A100上跑一个14B模型，RAG场景下SGLang的请求吞吐量能比vLLM高30%到50%，首token延迟优势更明显。如果你的核心应用是知识库问答或者Agent工作流，SGLang值得重点考虑。

它的缺点是文档更新太快，版本迭代激进，很多配置参数在不同版本里变来变去，踩坑了得去GitHub翻issue。团队如果没有一定技术能力，建议谨慎跟进。

2.5 Dify / Open WebUI：应用层不能缺的那块拼图

很多人部署完模型就卡住了：模型跑起来了，但怎么用？命令行敲太原始，浏览器页面没有，更别提做知识库和Agent了。这时候需要应用层工具。

Open WebUI是开箱即用的Web界面，长得像ChatGPT，支持多用户、聊天记录、文档上传，支持对接Ollama和OpenAI兼容API。个人或小团队部署一个，体验立刻提升一个档次。

Dify则更进一步，它不只是一个聊天界面，而是把模型接入、知识库、工作流、Agent编排、API发布串成一整条链。2026年做企业私有化AI应用，Dify基本是标配选择。它支持配置任意OpenAI兼容的模型API，你把本地部署的vLLM地址填进去，就能在Dify里搭一个带知识库的客服机器人。

我的建议是：部署模型是第一步，但大部分人真正要的其实是"一个能用的应用"。工具链要不要配齐，直接决定项目最后是demo还是产品。

2.6 一张选型表，三分钟定方向

选型逻辑很直接：先看你是个人还是团队，再看你是要demo还是要生产。个人和demo选Ollama，团队和生产直接上vLLM，RAG和Agent场景多就认真考虑SGLang，界面和应用层用Open WebUI和Dify补齐。

3. 显存算账：先搞清楚你的机器上限在哪

3.1 模型权重占用速算法

在做任何部署之前，先算显存。计算方法很简单：模型参数量乘以每个参数占用的字节数。

• FP16半精度：每个参数2字节
• INT8量化：每个参数1字节
• INT4量化（GGUF Q4系列）：每个参数约0.5到0.6字节

举例说明：

注意这只是权重本身的占用，推理时还有KV Cache、激活值、临时缓冲区等额外开销，所以实际显存需求建议在这个基础上再预留20%到30%。以7B FP16为例，理论权重14GB，跑起来通常要17GB到18GB才稳。

3.2 KV Cache是隐形大头

KV Cache是很多人部署翻车的第一原因，因为它不随模型固定，而是随你的输入上下文长度线性增长。

计算公式大致是：每token的KV Cache显存 = 2 × 层数 × KV头数 × 头维度 × 每元素字节数。

拿常见13B模型举例，假设32层、8个KV头（GQA分组查询注意力）、头维度128、FP16存储：

每token占用 = 2 × 32 × 8 × 128 × 2字节 = 131072字节，也就是128KB。

上下文长度4K时，KV Cache约512MB；上下文拉到32K时，直接变成4GB。一个7B模型FP16权重才14GB，KV Cache就可能吃掉4GB，这还没算激活值。所以为什么我一直强调别盲目开长上下文，你开32K上下文，等于变相把模型换成了一个大一号的版本。

选模型的时候注意看它是否用了GQA。GQA能显著减少KV头数量，把KV Cache压到原来的几分之一，这也是为什么现在的开源模型几乎都标配GQA。

3.3 显卡、Apple Silicon、Jetson Orin分别能跑到哪一步

以2026年的主流硬件，我按路线整理一下：

NVIDIA消费级显卡路线：

• RTX 4090 24GB：跑7B INT4非常轻松，14B INT4也能流畅，32B INT4勉强能跑但上下文得压到4K以内，生成速度会降到每秒20到30个token，体验一般。
• RTX 5090 32GB：比4090多了8GB显存和更高带宽，32B INT4可以稳定使用，14B FP16也能直接跑，是目前个人部署甜点级硬件。
• 多卡方案：两张24GB卡拼起来跑70B INT4是可行的，但要注意多卡推理有PCIe通信开销，速度比单卡下降不少，不是所有模型都能线性扩展。

Apple Silicon路线： M系列统一内存架构让"显存"很大，M系列顶配128GB甚至192GB内存都能给GPU用，跑70B量化模型是真实可行的。但瓶颈在内存带宽，M系列跑大模型的实际速度取决于带宽，而不是核心数量。128GB内存的机器跑70B Q4，生成速度大约每秒15到25个token，能接受但称不上快。好处是功耗低、安静、一体机，适合个人工作室。

Jetson Orin路线： Orin NX和AGX是边缘部署的主流选择。AGX 64GB版本可以跑14B INT4模型，功耗控制在几十瓦，适合车载、巡检机器人、离线语音交互这类场景。它的推理引擎是TensorRT-LLM，性能优化很好，但配置复杂，需要专门学习。

3.4 CPU纯跑：速度换空间的备选路线

没有GPU就别部署了吗？也不一定。llama.cpp让纯CPU跑模型成为可能，关键是内存要够。

32GB内存跑7B INT4，大约每秒2到4个token，看文本还能忍，对话会显得很迟钝；64GB内存跑14B INT4，速度更慢，每秒1到2个token。这种速度能做什么？批量离线分析、文本分类、翻译任务可以，因为不要求实时交互。或者说你只是想在服务器上验证一个模型效果，不打算给人用，CPU路线也可以。

如果非要CPU实时对话，建议选4B或更小的模型，Q4量化后占用不到3GB内存，速度能到每秒8到12个token，勉强能聊天。

4. 从下载到上线：一条完整的本地部署实操链路

4.1 环境准备：驱动和容器检查

不管你选哪条路线，第一步永远是检查环境。NVIDIA显卡先确认驱动和CUDA可用：

nvidia-smi

看到显卡型号和驱动版本就OK。注意nvidia-smi显示的CUDA Version只是驱动支持的版本，不代表容器里的CUDA版本，别搞混。接下来建议直接用Docker，统一环境比在宿主机上堆Python依赖省心太多。确认Docker能调用GPU：

docker run --rm --gpus all nvidia/cuda:12.4-base-ubuntu22.04 nvidia-smi

能输出显卡信息就说明容器GPU环境正常。这一步如果过不了，后面全卡住，先排查NVIDIA Container Toolkit装没装。

4.2 选模型和量化，别下载回来才发现不对

模型选择上，2026年我日常推荐几款：通用对话和写作选Qwen系列的中小尺寸，比如8B、14B或32B；代码能力可以看DeepSeek系蒸馏模型；需要特定领域能力再看社区微调版。

下载渠道优先走两条：Ollama模型库适合个人快速拉取，一条命令搞定；ModelScope这类国内模型社区适合下载完整模型文件做精细化部署，我用它比较多，因为国内访问稳定且模型版本权威，下载体验好。

GGUF文件后缀里那串字符要认识：

一个容易踩的坑：同一个模型有Instruct版、Base版、Chat版之分。日常对话和API服务选Instruct版，它经过指令微调，会听话；Base版是预训练底座，只会续写，不会对话。看到模型名不带Instruct就直接拿来聊天的人不在少数，然后吐槽"模型太笨了"。

4.3 启动推理服务：Ollama和vLLM两条路线

个人路线，Ollama拉取并启动：

ollama pull qwen3:14b ollama run qwen3:14b

ollama run进入交互对话，确认效果没问题后，让它作为后台服务常驻：

ollama serve

服务默认监听11434端口，OpenAI兼容接口是http://localhost:11434/v1。

团队路线，vLLM启动：

docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen3-14B-Instruct \ --max-model-len 16384 \ --gpu-memory-utilization 0.9

启动日志里看到"Starting vLLM server"和Uvicorn监听8000端口的输出就说明服务起来了。第一次启动会加载模型权重，7B模型大概要等几十秒到一两分钟，别以为卡死了。

4.4 验证接口并接入Open WebUI/Dify

服务启动后用一条curl验证：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "/models/Qwen3-14B-Instruct", "messages": [{"role": "user", "content": "你好，介绍一下你自己"}], "max_tokens": 256 }'

能正常返回内容，接口就通了。接下来两种接法：

接Open WebUI，用Docker一条命令：

docker run -d -p 3000:8080 \ -e OPENAI_API_BASE_URL=http://host.docker.internal:8000/v1 \ -e OPENAI_API_KEY=empty \ ghcr.io/open-webui/open-webui:main

浏览器打开3000端口，就能在一个类ChatGPT界面里和你的本地模型对话了。

接Dify，进入控制台的模型供应商页面，填一个OpenAI API兼容的供应商配置，把API Base地址填成http://vllm-container-ip:8000/v1，API Key随便填一个占位符就行。之后就能在Dify里创建知识库、搭Agent工作流了。

这一步做完，本地大模型就不再是命令行玩具，而是一个可以被业务系统调用的真正服务了。

5. 部署后必踩的坑：OOM、上下文爆炸与并发卡死

5.1 显存OOM的完整排查链路

本地部署翻车率最高的问题就是CUDA out of memory。我见过太多人第一反应是"模型太大了换小模型"，但真正常见的原因是配置不当。

排查顺序应该是这样的：

第一步，看显存到底被谁吃了：

nvidia-smi

重点看两个数：Memory-Usage和Processes那一栏到底哪个进程占显存。很多人本地跑着好几个模型常驻，新模型加载时自然OOM。

第二步，看模型权重加KV Cache是不是超了。我前面给的速算法在这里用得上：确认权重占用、计算上下文长度对应的KV Cache、再加上20%余量，三项加起来对比你的显存总量。

第三步，调整参数而不是换模型：

• vLLM的--gpu-memory-utilization从0.9降到0.7，强行留出缓冲；
• 把--max-model-len从32768降到8192，显存立刻释放几个GB；
• 把量化从Q8降到Q4，权重直接减半。

我经历过的典型案例：一台4090跑14B INT4模型，权重8GB，看起来24GB显存很充裕，但我把上下文开到了32K，KV Cache吃掉近10GB，再加激活值和CUDA context开销，直接OOM。把上下文降到8K之后，显存占用只有13GB左右，稳如老狗。所以遇到OOM先动上下文，这是最容易被忽视但最有效的解法。

5.2 上下文长度不是想开多大就多大

很多人有一个误解：模型宣称支持128K上下文，我就应该开128K。理论上没错，但物理上要看显存和速度。

前面算过KV Cache的账，长上下文直接吃显存。更麻烦的是，上下文越长，推理速度越慢。因为生成每个token时，模型都要重新计算和读取前面所有token的KV Cache。32K上下文比4K上下文慢不是一点半点，是好几倍。

我的经验数值：在4090上跑7B INT4，4K上下文时每秒能到100个token；拉到32K上下文，下降到每秒40左右，显存占用还多了几个GB。如果你只是日常聊天，8K绰绰有余；RAG场景建议先评估单次请求最长大概多少token，留20%余量就够了。

另外一个实用技巧：如果主流场景用不到长上下文，在--max-model-len或Ollama的OLLAMA_CONTEXT_LENGTH里把它写成实际需要值，而不是模型支持的最大值。这样等于把显存和速度都省下来了。

5.3 并发上不去，先分清瓶颈在哪

并发问题有三个常见表现，对应三种根因：

第一种表现：并发一高，请求排长队，但显存还有富余。这往往是Ollama的串行处理导致的。解决方向一个是调OLLAMA_NUM_PARALLEL增加并行数，另一个是干脆换vLLM，它天生为并发设计。

第二种表现：并发一高，直接OOM。这是并行请求各自分配KV Cache导致的，显存被多个请求的上下文瓜分。解决方向是限制并发数，或减小单请求上下文长度。

第三种表现：显存没满，并发也上去了，但每个请求都慢。这是算力瓶颈，说明GPU计算资源已经饱和，加并发解决不了问题，只能换更强的卡或更小的模型。

怎么快速判断是哪种？先看nvidia-smi的GPU-Util，如果跑满100%说明算力饱和；再看显存占用，如果接近上限说明是显存瓶颈；如果两项都没满但请求还是排队，就是服务端软件层面的并发机制限制。

vLLM里几个并发相关参数值得记一下：--max-num-seqs控制单批次最多处理多少请求，默认通常256，实际受显存约束；--max-num-batched-tokens限制单批次总token数，这两个参数要和上下文长度一起调，不能单独拉满。

5.4 量化质量损失：INT4到底行不行

量化是省显存的法宝，但省下来的显存是有代价的。INT4量化会把每个权重压缩到4bit左右，这期间必然有精度损失。问题在于：损失多大，以及你的场景能不能忍。

先说原理。量化相当于把连续的高精度数值映射到离散的低精度阶梯上。模型权重里大多数值分布在一个比较窄的范围内，但存在少量"极端离群值"，这些离群值对模型能力影响很大。Q4_K_M这类K-quants量化方案专门处理了离群值分布问题，用混合精度策略把重要的行、列保留更高精度，所以整体质量比早期朴素4bit量化好很多。

我的实际体感：日常对话、文本总结、翻译这类生成任务，7B模型Q4_K_M和Q8_0的差距几乎感觉不出来，偶尔有措辞差异；但数学推理、代码生成、长文档精确提取这类任务，Q4的失误率会明显上升。比如让模型从合同里提取特定条款，Q4可能出现遗漏或幻觉，换Q8就稳定很多。

所以我的原则是：显存允许就上Q8，显存紧张用Q4_K_M，但凡是精度敏感的任务都要在正式上线前对一批测试集做人工或自动评估，别想当然。最稳的做法是同一个模型下载Q4和Q8两个版本，关键场景跑一遍对比，成本不高，效果直观。

6. 部署只是起点：微调、多模态与收尾建议

6.1 从本地部署走向本地微调

部署解决的是"能不能用"，微调解决的是"合不合用"。一个通用模型拿来做特定行业任务，效果往往停留在"能用但不够好"，这时候就该考虑微调了。

2026年的微调框架选型，我推荐优先看LLaMA-Factory。它支持LoRA、QLoRA、全参微调多种模式，Web界面操作，对数据和训练目标有图形化配置，新手也能一周内跑通。技术团队如果不喜欢图形界面，可以用Axolotl或Transformers TRL走脚本路线。

硬件上有个认知要纠正：微调比推理吃显存得多。因为训练时除了权重，还要保存梯度和优化器状态。LoRA是突破口，它只训练少量低秩适配参数，显存需求大幅下降。QLoRA更进一步，把基础模型以4bit加载，24GB显存就能微调14B模型，这对个人用户是重大利好。

一个最小可用的微调流程是这样：准备几百到几千条任务数据，格式是"问题-答案"或"输入-输出"；在LLaMA-Factory里加载模型、挂LoRA、设置学习率和训练轮数；训练完导出LoRA权重，再合并回基础模型；最后把合并后的模型部署回vLLM或Ollama。这套链路我跑过很多次，最大的经验是：数据质量远比数据量重要，几百条高质量样本的效果经常超过几万条噪音数据。

6.2 多模态模型本地部署的三个特殊点

2026年本地部署早就不仅限于纯文本模型了。视觉语言模型、语音识别、文生图都已经能跑在消费级硬件上，但多模态部署有三个特殊点容易踩坑。

第一，显存占用更大。视觉模型除了文本token，还要处理图像token，一张图会被切分成几百个patch，每个patch都要走一遍模型层，KV Cache占用暴涨。同样参数规模的视觉模型，实际显存需求比纯文本高30%到50%。

第二，推理链路更长。真实项目里很少只跑一个模型，往往是"语音识别模型把音频转成文字，再送大模型理解，最后走语音合成输出"。多个模型串联意味着显存要同时分配给好几个模型，调度复杂度上来了，很容易出现内存碎片化问题。

第三，框架支持度差异大。vLLM和SGLang对视觉模型的支持在近两年已经成熟，但如果用的冷门模型不能直接跑，就得回退到Transformers原生推理，性能损失明显。选模型之前，先查目标框架的官方文档确认支持列表，比买回来再折腾强多了。

我的建议是：多模态项目第一次跑通时，务必先把每个子模型单独验证一遍再串联，否则出了问题你根本不知道是哪一个环节崩的。

6.3 我最后想说的几句大实话

做了这么多年部署，我最深的体会是：部署不是一锤子买卖，而是一套需要持续维护的基础设施。

模型会更新，量化方案会改进，推理框架版本迭代飞快。你今年部署的Ollama配置，明年可能就有更好的默认参数；你今天用的vLLM镜像，过几个月就要升级。所以从第一天开始就把模型文件目录、推理服务的启动脚本、显存监控命令整理成文档，是非常值得的投资。

还有一件事：建立基线。把模型的响应延迟、显存占用、测试集准确率记录下来，每次升级模型或改参数前先看基线，改完对比基线，才能知道改动是变好还是变坏。我见过很多人靠感觉调参，调完也不知道自己改了什么、效果如何，全凭玄学。

最后分享一个实操建议：先跑小模型，再上大模型。不论你的目标最终是70B还是更大，第一步都先用一个7B或8B模型把全链路跑通——下载、部署、接界面、接业务API、做监控。小模型跑通了，换成大模型只是换一个文件和几个参数的事；小模型都跑不通，大模型只会更让你崩溃。这条路径我推荐给所有来找我问部署的人，基本没翻过车。