企业官网建设流程全解析

1. 大模型入门到底在学什么

1.1 先搞清楚“大模型”这三个字指代的范围

很多人一上来就问“大模型怎么入门”，这个问题其实没法直接回答，因为“大模型”这个词在不同语境下指的东西差别很大。有人说的是训练一个模型，有人说的是调用一个API，有人说的是在自己电脑上跑一个量化模型，还有人说的是把模型集成到自己的App里。这几件事需要的知识栈、时间投入、硬件条件完全不同。

我一般会把大模型相关的入门方向分成四个层次，你可以对照自己的目标看看落在哪一层：

绝大多数人问“入门”，其实目标是应用层和部署层。这两层的投入产出比最高，一两周就能看到实际效果。微调层需要你有明确的业务场景和标注数据，否则调了也没意义。训练层则是另一个世界的事情，不适合作为入门起点。

所以这篇内容我会把重心放在应用层和部署层，微调层给一个可落地的路径，训练层只做概念性说明。你如果是刚接触这个领域，先把前两层走通，再决定要不要往下走。

1.2 入门资料为什么这么乱

大模型这个领域从2023年开始爆发，到现在资料已经多到泛滥的程度。但你会发现一个很尴尬的现象：官方文档写得太简略，博客文章又太碎片化，视频教程往往只讲操作不讲原理，而论文又离工程实践太远。

更麻烦的是，很多资料的时效性极差。半年前还推荐的工具，现在可能已经停止维护；上个月还流行的框架，这个月可能已经被新的方案替代。我见过不少人跟着两年前的教程装环境，结果卡在依赖冲突上一整天。

还有一个隐性问题是：很多资料默认你已经具备某些前置知识。比如讲微调的教程，默认你懂PyTorch、懂Transformer结构、懂数据预处理；讲部署的教程，默认你懂Docker、懂CUDA、懂量化原理。但真正的新手往往卡在这些“默认”上。

我整理这套入门路径的思路是：先建立全局地图，再逐个击破关键节点，每个节点都给出可验证的最小实践。你不需要一开始就理解所有原理，但你需要知道每个环节在整个链条中的位置，以及它解决什么问题。

1.3 一条可执行的入门路线

基于我自己的学习和实践经历，我把入门路线拆成五个阶段，每个阶段都有明确的产出物：

1. 概念建立阶段：搞清楚Transformer、注意力机制、token、上下文窗口这些基础概念。不需要推导公式，但要知道它们是什么、影响什么。产出物是一张自己能讲清楚的概念图。

2. API调用阶段：选一个提供免费额度的平台，跑通对话、流式输出、多轮上下文管理。产出物是一个能用的命令行对话脚本。

3. 本地部署阶段：用Ollama或llama.cpp在本地跑一个7B级别的量化模型，理解量化、显存占用、推理速度之间的关系。产出物是一个本地可访问的模型服务。

4. 提示词与上下文工程阶段：学习如何设计系统提示词、如何管理长对话的上下文、如何做结构化输出。产出物是一套针对具体场景的提示词模板。

5. 微调入门阶段：用LoRA在一个小数据集上微调模型，理解数据格式、训练参数、效果评估。产出物是一个微调后的模型和对比测试报告。

这五个阶段走下来，快的话两到三周，慢的话一两个月。关键不是速度，而是每个阶段都要有实际动手的产出，否则看再多资料也是浮在表面。

2. 核心概念与知识框架拆解

2.1 Transformer架构：不需要推导但必须理解的部分

大模型的基础架构是Transformer，这个大家都知道。但入门阶段不需要你去推导注意力公式，你需要理解的是几个关键概念及其工程含义。

自注意力机制的核心作用是让模型在处理每个token时，能够“看到”序列中其他所有token的信息，并根据相关性分配权重。这个机制的工程含义是：计算量和内存占用随序列长度呈平方级增长。这就是为什么上下文窗口不能无限大，也是为什么长文本推理特别吃显存。

位置编码解决的是注意力机制本身不包含顺序信息的问题。早期的正弦位置编码到后来的旋转位置编码（RoPE），不同的编码方式直接影响模型处理长文本的能力。你在选模型时会看到“支持128K上下文”这样的描述，背后就是位置编码方案和训练策略的差异。

前馈网络占据了模型参数量的绝大部分。一个7B模型里，注意力层的参数可能只占三分之一，剩下都在前馈网络里。这解释了为什么量化主要针对这些权重矩阵，也解释了为什么模型大小和推理速度的关系不是线性的。

层归一化的位置和方式影响训练稳定性。现在主流用的是Pre-LN或者RMSNorm，后者计算更简单，在Llama系列里被广泛采用。

我建议你在这一阶段做一件事：找一个开源的模型结构图，对照着把每个模块的名字和功能标注一遍。不需要深入数学细节，但要能说清楚数据从输入到输出经过了哪些变换。

2.2 Token、上下文窗口与生成参数

Token是模型处理文本的基本单位。英文大致是1个token对应0.75个单词，中文大致是1个汉字对应1到2个token。这个换算关系直接影响你的成本估算和上下文管理策略。

上下文窗口指的是模型单次能处理的最大token数。这里有个容易混淆的点：上下文窗口包括输入和输出。如果一个模型支持8K上下文，你输入了7K的内容，那输出最多只有1K的空间。很多API平台会分别限制输入和输出的最大长度，需要看清楚。

生成参数里最需要理解的是三个：

• Temperature：控制输出的随机性。值越低输出越确定，适合事实性问答和代码生成；值越高输出越多样，适合创意写作。一般建议从0.7开始调。
• Top-p：也叫核采样，从累积概率达到p的最小token集合中采样。和Temperature配合使用，通常只调其中一个。
• Max tokens：限制输出长度。设置太小会导致回答被截断，设置太大在流式输出场景下会浪费等待时间。

这些参数没有“最优值”，只有针对具体场景的合适值。我的习惯是准备几组预设：事实问答用temperature=0.1，通用对话用0.7，创意生成用1.0，然后根据实际效果微调。

2.3 模型选择：参数规模、量化与能力权衡

选模型是入门阶段最容易纠结的环节。我见过有人在模型选择上花了一周时间，结果一个都没跑起来。这里给一个实用的决策框架。

首先看你的硬件条件。如果是纯CPU环境，7B量化模型是上限，推理速度大概每秒几个token。如果有8G显存的显卡，可以跑7B的4-bit量化模型，速度可以接受。如果有24G显存，可以跑14B甚至32B的量化模型。如果是多卡环境，那选择空间就大很多。

其次看你的任务类型。如果是通用对话和文本处理，7B级别的模型已经能给出不错的结果。如果是代码生成，需要选代码能力强的模型。如果是中文场景，要选中文语料占比高的模型。如果是多模态任务，需要选支持视觉输入的模型。

量化是本地部署的关键技术。简单说就是把模型权重从16位浮点数压缩到8位、4位甚至更低位宽，牺牲少量精度换取显存占用和速度的大幅优化。常见的量化格式有GGUF、GPTQ、AWQ等，不同格式适配不同的推理框架。

我的建议是：入门阶段先用4-bit量化跑通流程，确认整个链路没问题后，再根据实际效果决定是否升级精度或换更大的模型。

2.4 推理框架：Ollama、llama.cpp、vLLM的定位差异

推理框架的选择取决于你的使用场景，没有绝对的好坏。

Ollama的定位是“本地模型的一键运行工具”。它把模型下载、量化、服务化都封装好了，你只需要一条命令就能跑起来。适合快速验证和轻量级应用。缺点是定制化能力有限，不适合高并发场景。

llama.cpp是更底层的推理引擎，支持GGUF格式的量化模型，CPU推理效率很高，也支持部分GPU加速。它的优势是灵活，可以精细控制各种参数，适合需要深度定制的场景。缺点是需要自己处理模型转换和服务化。

vLLM面向的是高吞吐的服务端场景。它的PagedAttention技术大幅提升了显存利用率和并发能力，适合需要同时服务多个用户的场景。缺点是对硬件要求较高，部署复杂度也更高。

入门阶段的建议路径是：先用Ollama跑通，理解基本流程；然后尝试llama.cpp，理解量化模型和推理参数；如果有服务化需求，再上vLLM。

3. 实操过程与核心环节实现

3.1 环境准备：从零到能跑通第一个模型

环境准备是劝退新手的第一个关卡。我见过太多人在这里卡住，最后放弃。核心原则是：能用容器就用容器，能用预编译包就用预编译包，不要一上来就源码编译。

如果你用的是有显卡的机器，第一步是确认驱动和CUDA版本。在终端执行：

nvidia-smi

这个命令会显示显卡型号、驱动版本和CUDA版本。记下CUDA版本，后面装PyTorch的时候要对应。

然后是Python环境。强烈建议用conda或者venv创建独立环境，不要污染系统Python：

conda create -n llm python=3.10 conda activate llm

Python版本选3.10或3.11，这两个版本兼容性最好。3.12有些库还没跟上，3.9有些新特性不支持。

装PyTorch的时候，去官网的安装命令生成器选对应CUDA版本，不要直接pip install torch。比如CUDA 12.1对应的命令是：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

装完之后验证一下：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

如果输出True和显卡型号，说明环境没问题。

注意：如果你用的是Windows系统，建议在WSL2里操作。原生Windows的CUDA支持和各种依赖的兼容性都不如Linux环境，踩坑概率高很多。

3.2 用Ollama跑通第一个本地模型

Ollama的安装很简单，官网下载对应系统的安装包，一路下一步就行。装完之后在终端执行：

ollama run qwen2.5:7b

第一次执行会自动下载模型，大概4到5个G。下载完成后会进入交互界面，你可以直接输入问题测试。

Ollama默认用的是4-bit量化版本，在8G显存的机器上跑7B模型大概占用5到6G显存，推理速度在每秒20到40个token之间，体验相当流畅。

如果你想用API的方式调用，Ollama默认在11434端口提供HTTP服务：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "用一句话解释什么是大模型", "stream": false }'

流式输出的调用方式：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "用一句话解释什么是大模型", "stream": true }'

流式输出会逐token返回结果，适合做实时渲染的对话界面。前端处理的时候要注意，每个返回块是独立的JSON对象，需要逐行解析。

Ollama的模型文件默认存在用户目录下的.ollama文件夹里。如果你想换存储位置，可以设置环境变量OLLAMA_MODELS指向新的路径。这个在C盘空间紧张的时候很有用。

3.3 提示词工程的核心原则

提示词工程不是“玄学”，它有明确的原则可循。我总结下来最核心的三条：

第一条：明确角色和任务边界。不要上来就问问题，先告诉模型它是谁、要做什么、不做什么。比如：

你是一个专业的Python代码审查助手。你的任务是检查代码中的潜在bug和安全问题。 你只回答与代码审查相关的问题，其他问题一律回复“这不在我的职责范围内”。

第二条：给出具体的输出格式要求。模型很擅长遵循格式指令，但前提是你要说清楚。比如要求JSON输出：

请以JSON格式返回结果，包含以下字段： - summary: 一句话总结 - issues: 问题列表，每个问题包含line（行号）、severity（严重程度）、description（描述） - suggestion: 修改建议

第三条：提供示例。对于复杂的任务，给一两个输入输出示例比写一大段描述更有效。这就是few-shot prompting的思路。

上下文工程是提示词工程的延伸。当对话轮次多了之后，你不能把所有历史消息都塞进上下文，需要做管理。常见的策略有：

• 滑动窗口：只保留最近N轮对话，简单但会丢失早期信息。
• 摘要压缩：定期把历史对话总结成一段摘要，保留关键信息。
• 关键信息提取：从对话中提取结构化信息（如用户偏好、已确认的事实），单独维护。

我实际用下来，摘要压缩加关键信息提取的组合效果最好。每5到10轮做一次摘要，同时维护一个结构化的状态对象，这样既控制了上下文长度，又不会丢失重要信息。

3.4 微调实战：从数据准备到效果评估

微调是让通用模型适配垂直场景的关键手段。入门阶段推荐用LoRA，因为它对显存要求低、训练速度快、效果也够用。

数据准备是微调中最重要也最耗时的环节。数据格式通常是instruction-input-output的三元组：

[ { "instruction": "根据以下症状给出可能的诊断建议", "input": "患者男性，45岁，持续咳嗽两周，伴有低热", "output": "根据描述的症状，可能的方向包括：1. 呼吸道感染...2. 肺结核...建议进行胸部X光检查..." } ]

数据质量比数量重要得多。我试过用500条精心构造的数据微调，效果比用5000条粗糙数据好很多。关键点是：输出要准确、格式要统一、覆盖要全面。

训练参数方面，入门阶段可以先用这套配置：

training_args = { "per_device_train_batch_size": 4, "gradient_accumulation_steps": 4, "learning_rate": 2e-4, "num_train_epochs": 3, "lr_scheduler_type": "cosine", "warmup_ratio": 0.1, "logging_steps": 10, "save_steps": 100, "fp16": True, }

LoRA的配置：

lora_config = { "r": 16, "lora_alpha": 32, "target_modules": ["q_proj", "v_proj", "k_proj", "o_proj"], "lora_dropout": 0.05, "bias": "none", }

r是秩，控制LoRA矩阵的大小。16是一个比较通用的起点，数据量大或者任务复杂可以调到32或64。lora_alpha一般设为r的两倍。target_modules指定要适配的层，注意力层的投影矩阵是最常用的选择。

训练完成后，用之前没见过的测试集做对比评估。评估维度包括：格式正确率、内容准确率、幻觉率。我一般会准备50到100条测试数据，人工评估加自动指标结合。

注意：微调不是万能的。如果基座模型本身不具备某个能力，微调也很难让它学会。微调更适合“激发”和“对齐”，而不是“灌输”全新知识。对于知识注入场景，RAG（检索增强生成）往往是更合适的选择。

4. 常见问题与排查技巧实录

4.1 环境配置类问题

问题一：CUDA out of memory

这是最常见的问题。排查思路是：先确认模型大小和显存是否匹配。7B模型4-bit量化大概需要4到5G显存，加上推理时的KV Cache和中间激活值，实际占用会更高。如果显存不够，可以尝试：降低量化位宽、减小上下文长度、减少batch size。

问题二：pip安装依赖冲突

大模型相关的库更新很快，依赖冲突很常见。我的做法是：先装PyTorch，再装transformers和accelerate，最后装其他库。如果还是冲突，用pip install --no-deps跳过依赖检查，手动装需要的版本。

问题三：模型下载慢或失败

国内下载HuggingFace模型经常超时。可以用镜像站，或者用huggingface-cli配合镜像环境变量。Ollama的模型下载一般比较稳定，如果失败可以重试。

4.2 推理效果类问题

问题一：模型回答质量差

先检查提示词是否清晰。很多时候不是模型不行，是问题没问对。然后检查生成参数，temperature太高会导致回答发散，太低会导致重复。最后确认模型是否适合当前任务，通用模型做专业任务效果有限。

问题二：输出被截断

检查max_tokens设置。如果用的是API，确认平台的输出长度限制。流式输出场景下，前端要正确处理结束标志。

问题三：中文回答夹杂英文

这是训练数据分布导致的。可以在系统提示词里明确要求“全部用中文回答”，或者在生成参数里加重复惩罚。如果还是不行，考虑换中文能力更强的模型。

4.3 微调类问题

问题一：loss不下降

检查数据格式是否正确，特别是特殊token的位置。检查学习率是否合适，太大导致震荡，太小导致不收敛。检查LoRA的target_modules是否覆盖了关键层。

问题二：过拟合

训练loss持续下降但验证loss上升，就是过拟合了。解决办法：减少训练轮数、增加数据量、增大dropout、减小LoRA的r值。

问题三：微调后通用能力下降

这是灾难性遗忘。解决办法：在训练数据里混入一定比例的通用数据，或者用更小的学习率和更少的训练轮数。

4.4 常见问题速查表

5. 学习资源与进阶方向

5.1 值得投入时间的资料类型

市面上的大模型资料大致分几类，我的建议是：

官方文档优先。Ollama、llama.cpp、transformers这些工具的官方文档是最准确的信息源。虽然有时候写得简略，但至少不会误导你。

动手类教程其次。带完整代码和数据的教程价值最高。判断标准很简单：你能不能跟着跑通。跑不通的教程，写得再漂亮也没用。

论文按需查阅。入门阶段不需要系统读论文，遇到具体问题的时候针对性查阅就好。比如不理解RoPE，就去找RoPE的论文看。

视频教程作为补充。视频适合建立直观理解，但不适合作为主要学习方式。看视频容易产生“学会了”的错觉，实际动手又是另一回事。

5.2 从入门到进阶的关键跨越

入门之后，往哪个方向走取决于你的目标。几个常见的进阶方向：

应用开发方向：学习如何把模型集成到实际产品里，包括流式输出、对话管理、工具调用、智能体框架。这个方向需要的前端和后端知识可能比模型知识还多。

部署运维方向：学习高并发推理、模型服务化、监控和扩缩容。vLLM、TGI这些框架是重点。

微调与对齐方向：学习更高级的微调技术，包括RLHF、DPO等对齐方法。需要更扎实的机器学习和数学基础。

多模态方向：学习视觉-语言模型、语音-语言模型的结构和训练方法。这个方向的数据处理和训练复杂度都更高。

不管选哪个方向，有一件事是共通的：持续动手。大模型这个领域变化太快，光看资料不实践，三个月就跟不上了。

5.3 我踩过的几个坑

最后分享几个我自己踩过的坑，希望能帮你省点时间。

第一个坑是过早追求大模型。刚开始总想跑最大的模型，结果显存不够、速度慢、体验差，反而打击信心。后来发现7B量化模型在大多数场景下够用，先把流程跑通比什么都重要。

第二个坑是忽视数据质量。微调的时候花大量时间调参数，结果发现瓶颈在数据上。后来我把80%的时间花在数据构造和清洗上，效果提升立竿见影。

第三个坑是不记录实验。调参的时候改来改去，最后忘了哪个配置效果最好。后来养成习惯，每次实验都记录配置、数据和结果，效率高了很多。

第四个坑是追新不追稳。看到新框架就想试，结果踩了一堆坑。后来学乖了，生产环境只用经过验证的稳定方案，新东西在测试环境玩。

这套入门路径和实操方法，我自己走了一遍，也带着几个人走过。核心体会就是：不要贪多，不要求快，每个环节都动手验证，遇到问题就查文档和源码。大模型没有那么神秘，它就是一个工具，用多了自然就熟了。