企业官网建设流程全解析

简介：这份PDF资料源自北京大学DeepSeek原理与应用系列研讨讲座，聚焦DeepSeek与AIGC应用主题，面向不具备专业AI或IT背景的初学者、职场人士及对AIGC感兴趣的学习者。内容从DeepSeek-R1的概念、优势与历史地位切入，延伸至大模型与AIGC底层工作机制，并给出科学选择与高效使用AI工具的实操指导，帮助读者突破仅停留在工具应用层面的局限，理解其深层次价值。资源包内含1个PDF文件，大小约16.61MB，结构清晰、图文并茂，涵盖人工智能发展历程、大模型术语、生成模型与推理模型对比、DeepSeek公司背景及产品矩阵等模块，便于系统研读与查阅。目前已有208人学习下载，适合希望建立完整认知框架、规避概念误导并落地AI应用场景的读者参考。

1. DeepSeek 与 AIGC 应用：从模型选型到本地跑通的第一道坎

很多团队在 2024 年下半年开始把 AIGC 从「演示」推进到「生产」，结果第一周就卡在同一个地方：模型选型。DeepSeek 系列因为推理成本低、中文语料扎实、开源权重可自部署，成了不少公司内部知识库、文档摘要、代码补全场景的首选。但真正动手时你会发现，网上大量教程只告诉你「跑起来了」，没告诉你「为什么这么配」「显存不够怎么办」「输出不稳定怎么调」。这篇笔记面向的是已经决定用 DeepSeek 做 AIGC 落地、但还没跑通完整链路的工程师。我会按「模型怎么选 → 本地怎么起 → 接口怎么接 → 参数怎么调 → 坑在哪」的顺序，把每一步的命令、配置和判断依据写清楚。读完你应该能独立搭出一套可用的 DeepSeek 推理服务，并知道哪些参数动了会翻车。

2. DeepSeek 模型家族怎么选：参数规模、量化与硬件匹配

2.1 先看显存再选模型，别反过来

DeepSeek 系列目前常见的有多个参数档位，从轻量级到大规模 MoE 架构都有。选型的第一原则不是「哪个效果最好」，而是「你的推理卡能稳定跑哪个」。我一般按下面的顺序做排除法：

这张表是经验值，实际占用还受 batch size、上下文长度、KV Cache 影响。很多新手看到「7B 只要 14GB」就以为 16GB 卡稳了，结果上下文开到 8K 直接 OOM。血泪经验是：显存预算 = 权重 + KV Cache + 框架开销，后两项经常被忽略。

2.2 量化版本的选择逻辑

量化是让 DeepSeek 在消费级硬件上跑起来的关键手段。常见的有 GPTQ、AWQ、GGUF 几种格式。我的判断标准很简单：

• 如果追求推理速度和显存效率，优先选 AWQ 或 GPTQ 的 INT4 版本，精度损失在多数 AIGC 任务里可接受。
• 如果要在 CPU 或混合设备上跑，GGUF 格式配合 llama.cpp 更灵活。
• 如果做的是代码生成或数学推理，量化到 INT4 后要重点验证输出质量，这类任务对数值精度更敏感。

提示：量化版本不是「越小越好」。INT4 相比 INT8 显存省一半，但某些模型在长上下文任务上会出现明显的重复或截断，必须用你的真实业务数据做回归测试。

2.3 用一条命令确认模型能否加载

在正式写服务之前，先用最小脚本验证模型能加载并生成。以 Hugging Face 生态为例：

# check_load.py from transformers import AutoTokenizer, AutoModelForCausalLM import torch model_path = "your_local_deepseek_path" # 替换为实际权重目录 tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) # device_map="auto" 会自动分配显存，单卡不够时会尝试卸载到 CPU model = AutoModelForCausalLM.from_pretrained( model_path, torch_dtype=torch.float16, # 显存紧张时改为 torch.int8 或加载量化权重 device_map="auto", trust_remote_code=True ) prompt = "用一句话解释什么是 AIGC。" inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate(**inputs, max_new_tokens=64) print(tokenizer.decode(outputs[0], skip_special_tokens=True))

这段代码的逻辑说明：trust_remote_code=True是因为部分 DeepSeek 模型仓库带有自定义建模文件，不加会报找不到类。torch_dtype决定加载精度，FP16 是默认推荐，显存不够再考虑量化权重。device_map="auto"让 accelerate 库自动切分，但自动切分不等于最优，多卡场景建议手动指定。

参数说明：max_new_tokens控制生成长度，调试阶段设小一点，避免一次生成几千 token 把显存吃满。如果这步就报 OOM，不要急着换模型，先把max_new_tokens降到 32、把输入长度压到 512 再试。

3. 本地起一个 DeepSeek 推理服务：从命令行到 HTTP 接口

3.1 用 vLLM 或 TGI 做服务化，别用裸 transformers

裸 transformers 适合验证，不适合并发。生产或团队共用场景，常见做法是上 vLLM 或 Text Generation Inference。vLLM 的 PagedAttention 对长上下文和并发更友好，我一般优先选它。

安装和启动的最小命令：

# 安装 vLLM，注意 CUDA 版本要和驱动匹配 pip install vllm # 启动 OpenAI 兼容服务 python -m vllm.entrypoints.openai.api_server \ --model /path/to/deepseek-weights \ --served-model-name deepseek-local \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --port 8000

逻辑说明：--max-model-len决定服务支持的最大上下文，设太大显存预留就多，设太小业务请求会被截断。--gpu-memory-utilization 0.90表示允许 vLLM 占用 90% 显存，留 10% 给系统和其他进程，这个值超过 0.95 容易在高峰期崩。

参数说明：--served-model-name是客户端调用时用的模型名，可以随便起，但一旦定了就别改，否则所有调用方都要跟着改。--dtype要和权重实际精度一致，加载量化权重时这里要换成对应类型。

3.2 用 curl 验证接口通不通

服务起来后，先别写业务代码，用 curl 打一发：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-local", "messages": [ {"role": "user", "content": "把下面这句话改写成正式邮件：明天下午开会"} ], "temperature": 0.3, "max_tokens": 128 }'

逻辑说明：temperature设 0.3 是因为改写类任务需要稳定输出，太高会每次不一样。max_tokens限制生成长度，防止模型啰嗦。如果返回 404，检查model字段是否和启动时的--served-model-name一致；如果返回 500，看服务端日志，多半是显存或上下文超限。

3.3 接入业务代码时的超时与重试

Python 客户端调用示例：

import requests def ask_deepseek(prompt, timeout=30): url = "http://localhost:8000/v1/chat/completions" payload = { "model": "deepseek-local", "messages": [{"role": "user", "content": prompt}], "temperature": 0.5, "max_tokens": 512 } try: resp = requests.post(url, json=payload, timeout=timeout) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] except requests.exceptions.Timeout: return "请求超时，请稍后重试" except requests.exceptions.HTTPError as e: return f"服务返回错误：{e}"

逻辑说明：超时时间要按业务最长生成时间设，一般 30 秒起步。重试不要无脑加，AIGC 请求重试可能造成重复生成和资源浪费，建议只在连接失败时重试一次，生成超时直接返回降级文案。

参数说明：temperature在问答场景 0.3~0.7 之间比较稳，创意写作可以到 0.9，但超过 1.0 输出会开始发散。max_tokens要结合业务上限，比如摘要任务 256 够用，长文生成再往上加。

4. AIGC 应用里 DeepSeek 的参数调优与提示词结构

4.1 三个必调参数：temperature、top_p、repetition_penalty

很多人只调 temperature，其实另外两个对输出质量影响很大。我的经验配置：

注意：top_p 和 temperature 不要同时往极端调。两个都高，输出会失控；两个都低，模型像复读机。

4.2 提示词结构：把系统提示当接口文档写

DeepSeek 对系统提示的遵循度不错，但前提是你写清楚。我一般按「角色 + 任务 + 约束 + 输出格式」四段式：

你是一个企业知识库助手。 任务：根据用户问题，从给定资料中提取答案。 约束： 1. 只使用资料中的信息，不要编造。 2. 如果资料中没有答案，回复「未找到相关信息」。 3. 回答控制在 200 字以内。 输出格式：直接输出答案，不要加「根据资料」等前缀。

这种结构比「请你帮我回答」有效得多。实测中，加上输出格式约束后，下游解析成功率明显提升。

4.3 长上下文场景的截断策略

DeepSeek 支持较长上下文，但不代表可以无限塞。我的做法是：

• 先按段落切分资料，每段不超过 512 token。
• 用检索或关键词匹配选出最相关的 3~5 段，拼进提示词。
• 总输入控制在模型最大长度的 70% 以内，留出生成空间。

如果直接把整本手册塞进去，不仅慢，还会因为中间信息被稀释导致回答质量下降。这是很多 RAG 系统翻车的地方。

5. 避坑与排查：DeepSeek 落地 AIGC 时最常见的 5 个问题

5.1 现象：服务启动报 CUDA out of memory

原因：权重加载精度太高、max-model-len设太大、gpu-memory-utilization超过实际可用显存。

解决：先降max-model-len到 4096，再把gpu-memory-utilization降到 0.85，还不行就换量化权重。不要一上来就加卡，先确认是不是参数问题。

5.2 现象：输出重复、循环、停不下来

原因：repetition_penalty太低，或者temperature和top_p组合不当。

解决：把repetition_penalty提到 1.1，temperature降到 0.5，top_p设 0.9。如果还重复，检查提示词里是不是有容易诱导重复的示例。

5.3 现象：接口返回 200 但内容为空

原因：max_tokens设得太小，模型还没生成有效内容就截断了；或者提示词触发了模型的拒答机制。

解决：先把max_tokens调到 256 以上，再看提示词是否包含敏感或矛盾指令。空返回在批量任务里很隐蔽，建议在客户端加空值检测和重试。

5.4 现象：并发一高就超时

原因：单实例 vLLM 的并发上限受显存和max-model-len限制，请求排队导致超时。

解决：先看服务端日志的排队情况，再考虑调大--max-num-seqs，或者起多个实例做负载均衡。不要盲目加超时时间，那只是把问题往后拖。

5.5 现象：量化后效果明显变差

原因：INT4 量化对某些任务损失较大，尤其是代码生成和数学推理。

解决：换 INT8 或 AWQ 版本对比，用业务测试集跑分。如果差距不可接受，宁可换小一号的 FP16 模型，也不要硬用量化大模型。

6. 进阶技巧：用 DeepSeek 做批量 AIGC 任务时的一个关键习惯

批量任务和在线对话是两回事。在线对话可以容忍偶尔慢，批量任务一旦某条卡住，整个队列都受影响。我踩过最深的坑是：用同步接口跑几千条摘要，结果第 300 条遇到一个超长输入，服务端 OOM，前面 299 条结果全丢。

后来我固定了一个习惯：批量任务必须做输入预检和结果落盘。输入预检包括长度检查、空值检查、编码检查；结果落盘是每处理完一条就写一条，不要攒在内存里最后统一写。

import json import os def batch_process(items, output_path): done = set() if os.path.exists(output_path): with open(output_path, "r", encoding="utf-8") as f: for line in f: done.add(json.loads(line)["id"]) with open(output_path, "a", encoding="utf-8") as f: for item in items: if item["id"] in done: continue if len(item["text"]) > 4000: result = "输入超长，跳过" else: result = ask_deepseek(item["text"]) f.write(json.dumps({"id": item["id"], "result": result}, ensure_ascii=False) + "\n") f.flush()

逻辑说明：先读已完成的 id，支持断点续跑。每条写完flush()，进程崩了也不丢已处理结果。长度检查放在调用之前，避免把超长请求打到服务端。

参数说明：长度阈值 4000 是经验值，要按你实际模型的上下文和业务输入分布调整。ensure_ascii=False保证中文正常写入，不加会变成转义字符。

另一个习惯是给批量任务加一个「小样本试跑」阶段：先跑 20 条，人工看输出质量，确认参数没问题再全量。这个动作花 10 分钟，能省掉几小时的返工。希望帮到你。

本文还有配套的精品资源，点击获取