企业官网建设流程全解析

1. 从一张白纸到跑通第一个本地推理：我的DeepSeek上手路径

第一次认真接触DeepSeek，不是因为看了什么评测榜单，而是被一个很现实的问题逼的：手头有一批内部文档需要做结构化抽取，走云端API按量计费算下来成本不低，而且数据不方便出内网。当时我的想法很简单——能不能把模型拉到本地，自己掌控推理链路。折腾了两周，从完全不知道从哪下手，到能在自己的机器上稳定跑起推理、接上自己的业务脚本，中间踩的坑比想象中多。这篇笔记就是把这整个过程拆开讲清楚，给同样想入门DeepSeek大模型的朋友一条相对平滑的路。

先说清楚这篇内容适合谁。如果你是大模型零基础，想搞明白"本地部署""API调用""微调"这些词到底指什么、彼此什么关系，那这篇能帮你建立一张完整的地图；如果你已经用过云端大模型，但想把它搬到自己的环境里、控制成本和数据流向，那这篇里的选型逻辑和踩坑记录能帮你少走弯路；如果你只是好奇DeepSeek和别的大模型有什么不一样，那前面几节的概念梳理也够你看明白。

我尽量不写成说明书。说明书你去看官方文档就行，我这里写的是文档里不会告诉你的东西——比如为什么你的显卡明明够大却还是爆显存，为什么量化版本跑出来的结果和预期差一截，为什么同样的模型在不同推理框架下速度能差好几倍。这些只有真正动手跑过才会遇到。

整篇内容围绕一条主线展开：先搞懂DeepSeek是什么、能干什么，再决定用哪种方式把它跑起来，然后解决跑起来之后的性能和质量问题，最后聊怎么把它接进真实业务。这条线走完，你基本就能独立完成一个从零到可用的本地大模型项目了。

2. DeepSeek到底是什么：把概念地图先铺开

2.1 大模型、LLM、DeepSeek三者的关系

很多人一上来就被一堆缩写搞晕。我用最直白的方式理一遍：大模型是一个统称，指的是参数量巨大、通过海量文本训练出来的神经网络；LLM（Large Language Model，大语言模型）是大模型里专门处理语言的那一类；DeepSeek则是众多LLM中的一个具体系列，由国内团队研发，特点是推理能力强、开源程度高、对中文支持好。

打个比方，大模型是"汽车"这个大类，LLM是"轿车"这个子类，DeepSeek就是某个具体品牌的某款车型。你买车的时候不会只说"我要买汽车"，你会关心具体是哪款、什么配置、油耗多少。用大模型也一样，光知道"我要用大模型"没用，得知道具体用哪个、多大参数、怎么部署。

DeepSeek系列里又有不同的规格，参数量从几B到几百B不等（B是Billion，十亿参数的意思）。参数越大，通常能力越强，但对硬件的要求也越高。这是你后面做所有决策的基础——先确定你要用哪个规格的模型，再倒推需要什么硬件和部署方式。

2.2 为什么DeepSeek值得单独拿出来学

市面上大模型不少，为什么我建议从DeepSeek入手？几个很实际的理由。

第一，中文场景表现扎实。很多开源模型是英文优先的，中文任务上会明显掉链子，DeepSeek在中文理解和生成上做得比较均衡，做国内业务不用额外折腾。

第二，开源生态完整。模型权重开放，意味着你可以下载到本地自己跑，不依赖任何外部服务。这对数据敏感的场景是刚需。

第三，社区活跃。遇到问题能搜到别人踩过的坑，各种部署工具、量化版本、微调脚本都有人维护，学习成本低很多。

第四，规格覆盖广。从小到能在消费级显卡上跑的版本，到大到需要多卡集群的版本都有，不管你什么硬件条件，基本都能找到能跑的那一档。

提示：选模型不要一上来就盯着最大的那个。参数量翻倍带来的能力提升，往往不如你把部署和调优做扎实带来的收益大。先用小规格跑通全流程，再考虑升级。

2.3 本地部署、API调用、微调，这三件事别搞混

新手最容易混淆的就是这三个概念，我用一个表格把它们摆清楚。

这三者是递进关系，不是替代关系。正常路径是：先用API调用快速验证想法，确认方向对了，再考虑本地部署控制成本，最后如果通用能力不够，才上微调。很多人一上来就想微调，结果连模型怎么跑起来都没搞明白，纯属浪费时间。

3. 部署方式怎么选：一张决策表帮你定方向

3.1 先问自己三个问题

在动手之前，先回答这三个问题，答案直接决定你该走哪条路。

问题一：你的数据能不能出内网？如果涉及敏感信息、客户数据、内部文档，那基本只能本地部署。如果只是公开数据或者测试，API调用完全够用。

问题二：你的使用频率和量级多大？偶尔用用、每天几十次调用，API按量付费更划算。高频调用、每天成千上万次，本地部署的固定成本摊下来更便宜。

问题三：你手头有什么硬件？没有独立显卡，本地部署基本别想（除非用CPU推理，但速度慢到没法用）。有消费级显卡（比如显存8G到24G），能跑中小规格。有多卡或专业卡，才能考虑大规格。

3.2 三种主流部署路径对比

根据上面的答案，你会落到下面三条路径之一。

路径A：纯API调用。最省事，注册账号拿Key，写几行代码就能用。缺点是数据要出去、按量付费、受服务方限制。适合快速验证和轻量应用。

路径B：本地单机部署。在自己一台机器上跑。核心工具是推理框架，常见的有Ollama、vLLM、llama.cpp这几类。Ollama胜在简单，一条命令拉模型就能跑；vLLM胜在吞吐高，适合做服务；llama.cpp胜在轻量，CPU也能凑合跑。适合数据敏感、中等量级的场景。

路径C：私有化集群部署。多台机器、多张卡组成推理集群，对外提供统一服务。涉及容器编排、负载均衡、监控告警一整套。适合企业级、高并发场景。

对绝大多数个人学习者和中小团队来说，路径B是性价比最高的起点。下面重点讲这条。

3.3 硬件门槛到底在哪

很多人卡在第一步：我的机器到底能不能跑？关键看两个指标——显存和内存。

显存决定你能不能把模型装进显卡。粗略估算公式是：模型参数量 × 每参数字节数。比如一个7B模型，用16位精度（FP16）存储，每参数2字节，需要约14GB显存；用4位量化（INT4），每参数0.5字节，只需要约3.5GB。这就是为什么量化版本这么重要——它让消费级显卡也能跑起来。

内存决定你能不能把模型加载进系统。加载时模型会先读进内存再传到显存，所以内存至少要不小于模型文件大小，最好留一倍余量。

注意：这只是模型权重的显存占用，实际运行时还要加上上下文缓存（KV Cache）的开销。上下文越长、并发越多，这部分占用越大。所以实际需求往往比表格里的数字高出一截，选硬件时务必留足余量。

4. 手把手跑通本地推理：从装环境到出结果

4.1 用Ollama快速起步

如果你只想最快看到模型跑起来的效果，Ollama是最省心的选择。它的设计哲学就是"一条命令搞定"。

安装完成后，拉取并运行一个DeepSeek模型，命令大致是这样：

# 拉取模型（以某个量化版本为例） ollama pull deepseek-r1:7b # 运行模型，进入交互对话 ollama run deepseek-r1:7b

跑起来之后你会看到一个交互提示符，直接输入问题就能得到回答。这一步的意义在于先确认你的硬件能跑、模型能出结果，把环境问题排除掉，再去做更复杂的部署。

Ollama默认会自动选择适合你硬件的量化版本，省去了手动挑版本的麻烦。但它也有局限：并发能力弱，不适合做生产服务；可配置项少，深度调优空间有限。所以它适合起步验证，不适合最终落地。

4.2 用vLLM搭建可对外服务的推理接口

当你需要把模型做成一个能被其他程序调用的服务时，vLLM是更专业的选择。它的核心优势是吞吐量高——通过一种叫PagedAttention的显存管理技术，把显存利用率拉满，同样硬件能扛更多并发。

启动一个vLLM服务的基本命令：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/deepseek-model \ --served-model-name deepseek-local \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

几个参数值得解释。--dtype auto让框架自动选择精度，有显卡就用FP16，没有就降级。--max-model-len控制最大上下文长度，这个值直接吃显存，设太大容易爆。--gpu-memory-utilization 0.9表示允许vLLM使用90%的显存，留10%给系统和其他进程，这个比例很关键，设成1.0经常会导致OOM（显存溢出）。

启动后，vLLM会暴露一个兼容OpenAI接口规范的服务，你可以用标准的HTTP请求去调用：

from openai import OpenAI client = OpenAI( base_url="http://localhost:8000/v1", api_key="dummy" # 本地服务不需要真实Key ) response = client.chat.completions.create( model="deepseek-local", messages=[ {"role": "user", "content": "用三句话解释什么是量化"} ] ) print(response.choices[0].message.content)

这套组合的好处是：接口规范和云端一致，代码几乎不用改就能在本地和云端之间切换。这对开发和调试非常友好。

4.3 量化版本的选择：精度和速度的权衡

量化是把模型参数从高精度（如FP16）压缩到低精度（如INT8、INT4）的过程，目的是减小显存占用、提升推理速度，代价是损失一点精度。

常见的量化等级和它们的取舍：

• FP16：原始精度，效果最好，显存占用最大。
• INT8：显存减半，效果几乎无损，是很多场景的甜点区。
• INT4：显存降到四分之一，效果有可感知的下降，但多数任务仍可用。
• 更低精度：显存进一步压缩，但效果下降明显，只适合对质量要求不高的场景。

我的经验是：如果显存够，优先用INT8；显存紧张再用INT4；除非实在跑不动，不要碰更低的精度。因为量化损失在简单问答上可能看不出来，但在需要精确推理、长链条逻辑的任务上会明显暴露。

提示：不同量化工具（GPTQ、AWQ、GGUF等）产出的模型格式不一样，对应不同的推理框架。选量化版本前先确认你的推理框架支持哪种格式，别下错了白忙活。

4.4 第一次跑通后必须验证的几件事

模型能出结果不代表部署成功。我每次部署完都会做这几项检查：

第一，测中文能力。随便问几个中文问题，看回答是否通顺、有没有乱码或夹杂英文。有些模型在中文上会突然抽风。

第二，测长上下文。丢一段几千字的文档进去，让它总结，看能不能正确处理。上下文长度是很多任务的硬需求。

第三，测并发。同时发几个请求，看响应时间和显存占用。单请求正常不代表并发正常，很多OOM都是并发时才暴露。

第四，测稳定性。连续跑一段时间，看会不会内存泄漏、服务崩溃。生产环境最怕跑着跑着挂了。

这几项都过了，才算真正跑通。

5. 性能调优：让模型跑得更快更稳

5.1 显存不够用时的排查顺序

显存溢出是最常见的报错。遇到OOM，按这个顺序排查：

第一步，降上下文长度。上下文缓存是显存大户，把max-model-len从8192降到4096，往往能立刻缓解。

第二步，降并发数。限制同时处理的请求数量，减少KV Cache的峰值占用。

第三步，换更低精度的量化版本。从INT8换到INT4，显存直接砍半。

第四步，调低显存利用率上限。把gpu-memory-utilization从0.9降到0.8，给系统留更多空间。

第五步，考虑模型并行。如果单卡实在装不下，用多卡把模型切开分布到不同显卡上。

这个顺序的逻辑是：从改动最小、代价最低的选项开始试。降上下文和并发几乎不影响部署结构，换量化版本要重新下载模型，模型并行则要改部署架构，成本递增。

5.2 推理速度上不去的几个原因

速度慢通常不是单一原因，我遇到过的情况有这么几类。

原因一：用了CPU推理。没有显卡或者框架没正确识别显卡时，会退化成CPU推理，速度慢几十倍。检查框架日志确认是否真的用上了GPU。

原因二：量化格式和框架不匹配。比如拿GGUF格式的模型去喂vLLM，框架可能无法高效利用，甚至报错。格式要对上。

原因三：上下文太长。上下文越长，每生成一个token都要重新计算注意力，速度线性下降。能短则短。

原因四：批处理没开。单请求单处理是浪费，开启连续批处理（continuous batching）能让多个请求共享计算，吞吐翻倍。

原因五：显存带宽瓶颈。大模型推理是显存带宽密集型任务，显卡的显存带宽不够，算力再强也白搭。这是硬件层面的限制，只能换卡。

5.3 上下文长度对成本和体验的双重影响

上下文长度是个容易被忽视但影响巨大的参数。它同时影响三件事：显存占用、推理速度、使用成本。

显存上，KV Cache的大小和上下文长度成正比，上下文翻倍，缓存占用翻倍。速度上，注意力计算量随上下文增长，长上下文下每个token的生成时间明显变长。成本上，如果是按token计费的API，输入越长费用越高。

所以我的建议是：按实际需求设上下文，不要盲目拉满。做文档问答，上下文设成能装下最长文档的长度就行；做短对话，2048甚至1024就够。把上下文当成一个需要精打细算的资源，而不是越大越好的参数。

6. 把模型接进真实业务：API调用与工程化

6.1 本地服务和云端API的代码统一

前面提到vLLM暴露的是OpenAI兼容接口，这意味着你可以写一套代码，通过改base_url就在本地和云端之间切换。这个设计极大降低了迁移成本。

import os from openai import OpenAI # 通过环境变量控制走本地还是云端 BASE_URL = os.getenv("LLM_BASE_URL", "http://localhost:8000/v1") API_KEY = os.getenv("LLM_API_KEY", "dummy") client = OpenAI(base_url=BASE_URL, api_key=API_KEY) def ask(prompt, system="你是一个严谨的助手"): resp = client.chat.completions.create( model=os.getenv("LLM_MODEL", "deepseek-local"), messages=[ {"role": "system", "content": system}, {"role": "user", "content": prompt} ], temperature=0.3 ) return resp.choices[0].message.content

这段代码的价值在于解耦。业务逻辑不关心模型跑在哪，只关心接口。哪天本地硬件不够了想切云端，改个环境变量就行，代码一行不动。

6.2 提示词工程：不训练也能提升效果

很多人以为要提升效果就得微调，其实大部分场景下，把提示词写好就够了。提示词工程是不改模型、不花算力就能显著提升输出质量的手段。

几个我实测有效的技巧：

明确角色和任务。开头就告诉模型"你是一个XX领域的专家，现在要完成XX任务"，比直接问效果好。

给输出格式示例。如果你要结构化输出（比如JSON），在提示词里给一个样例，模型会照着格式来。

分步骤引导。复杂任务拆成几步，让模型一步步想，比一步到位准确率高。这就是所谓的思维链。

限定输出范围。明确说"只输出XX，不要解释"，能避免模型啰嗦。

给反例。告诉模型"不要这样输出"，有时比正面描述更有效。

这些技巧不需要任何训练资源，改改提示词就能用，是性价比最高的优化手段。

6.3 数据标注：微调前的必要准备

如果你确定通用模型满足不了需求，要上微调，那第一步不是写训练脚本，而是准备数据。微调的效果，八成取决于数据质量，两成取决于训练技巧。

数据标注的核心是构造"输入-输出"对。比如你要让模型学会从合同里抽取关键条款，那每条数据就是一段合同文本加上对应的结构化抽取结果。

标注时注意几点：

• 数量：少则几百条，多则几千条，看任务复杂度。太少学不会，太多边际收益递减。
• 质量：宁可少而精，不要多而杂。一条错误标注的破坏力，可能需要十条正确数据来抵消。
• 多样性：覆盖各种边界情况，别只标简单样本，否则模型遇到难例就崩。
• 一致性：同一个任务，标注标准要统一，否则模型学到的规律是矛盾的。

提示：标注数据前先定一份标注规范文档，把各种情况的处理方式写清楚。没有规范直接开标，标到一半发现标准不一致，返工成本极高。

6.4 微调实战的关键参数

微调不是把模型从头训一遍，而是在预训练权重基础上做小幅调整。现在主流做法是参数高效微调，只训练一小部分参数，大幅降低算力需求。

最常用的方法是LoRA（Low-Rank Adaptation），它的思路是在原模型的某些层旁边挂一个小型可训练模块，训练时只更新这个小模块，原模型权重冻结。这样显存需求降到全量微调的几分之一，效果却接近。

LoRA的几个关键参数：

我的经验是：先用小rank快速试，效果不够再加大。rank从8开始，如果模型学不会任务，加到16、32。同时盯着验证集损失，一旦开始上升就是过拟合信号，该停了。

7. 踩坑记录：那些文档不会告诉你的事

7.1 显存明明够却还是OOM

这个坑我踩过不止一次。显卡24G，模型INT4量化后只要8G，按理说绰绰有余，结果一跑就OOM。排查半天发现是上下文长度设太大了。默认配置可能给了32K上下文，KV Cache一下子吃掉十几G，加上模型权重直接爆掉。

解决办法就是前面说的，把max-model-len降到实际需要的值。这个坑的教训是：显存占用 = 模型权重 + KV Cache + 框架开销，三者都要算，不能只看模型大小。

7.2 量化后效果断崖式下跌

有次为了在低配机器上跑，用了很激进的量化，结果模型回答开始胡言乱语，逻辑混乱。换回INT8立刻正常。这说明量化是有代价的，低精度不是免费的午餐。

经验是：量化到INT4基本是效果可接受的底线，再低就要慎重。而且不同任务对量化的敏感度不一样，简单分类可能INT4没问题，复杂推理可能INT8都嫌不够。上线前一定要用你的真实任务测一遍量化版本的效果，别只看benchmark分数。

7.3 并发一上来服务就崩

单请求测试一切正常，一上并发就各种报错。原因是并发会成倍放大显存占用，每个并发请求都有自己的KV Cache。10个并发，缓存占用就是单请求的10倍。

解决办法是限制并发数，或者用支持连续批处理的框架（如vLLM），让多个请求共享计算资源。同时监控显存占用，设置合理的并发上限，别让服务被压垮。

7.4 模型加载慢到怀疑人生

第一次加载模型可能要几分钟，这是正常的，因为要把几十G的权重从磁盘读进内存再传到显存。但如果每次都这么慢，就要检查了。

可能的原因：磁盘是机械硬盘（换成SSD）、内存不够导致频繁换页、模型格式没优化。有些框架支持模型缓存，第二次加载会快很多，确认这个功能开了没。

7.5 中文输出夹杂英文或乱码

这个通常和模型的tokenizer（分词器）有关。有些模型的中文词表覆盖不够，遇到生僻词会拆成字节处理，导致输出异常。DeepSeek在中文上做得比较好，但如果遇到这类问题，检查是不是用错了模型版本，或者提示词里混入了奇怪的字符。

8. 关于成本、选型和长期维护的几点体会

8.1 本地部署到底省不省钱

很多人以为本地部署就是省钱，其实要算总账。本地部署的成本包括：硬件采购（显卡是大头）、电费、维护时间、机会成本。如果只是偶尔用用，这些成本摊下来可能比API还贵。

本地部署真正省钱的场景是：高频调用 + 数据敏感 + 长期使用。调用量大到API费用超过硬件成本，且数据不能出去，这时候本地部署才划算。否则，老老实实用API更省心。

8.2 模型选型的动态思维

模型迭代很快，今天的最优解明天可能就过时了。所以选型要有动态思维：不要一次性投入太多在某个特定模型上，保持架构的可替换性。

具体做法是：把模型调用抽象成统一接口，模型本身当成可替换的组件。这样新模型出来，换个权重文件就能升级，不用重构整个系统。前面讲的OpenAI兼容接口就是这个思路的体现。

8.3 监控和日志不能省

本地部署最容易忽视的就是监控。模型跑起来就不管了，直到出问题才发现。建议至少监控这几项：显存占用、请求延迟、错误率、吞吐量。有异常能第一时间发现，而不是等用户投诉。

日志也要留好，尤其是出错的请求，把输入输出都记下来，方便复现和排查。这些工程化的东西看起来和模型无关，但决定了你的服务能不能稳定跑下去。

8.4 持续学习的心态

大模型这个领域变化太快，今天学的东西可能半年后就更新了。所以比起记住具体命令，更重要的是理解背后的原理——为什么这样部署、为什么这样调优、为什么这样选型。原理是稳定的，具体工具会变。

我自己保持学习的方式是：定期跑一遍新出的模型和工具，哪怕不用，也了解一下它解决了什么问题。这样当需求来的时候，脑子里有货，知道该往哪个方向找方案。

最后分享一个我自己的习惯：每次部署新模型，都写一份简短的记录，记下硬件配置、模型版本、关键参数、遇到的问题和解决办法。积累下来就是一份专属的踩坑手册，比任何通用文档都管用。下次遇到类似情况，翻出来一看就明白，省下大量重复排查的时间。