企业官网建设流程全解析

搞大模型本地部署这一年多，我在各种技术群里被问到最多的问题，其实并不是“怎么部署”，而是一个更拧巴的问题：模型跑起来了，怎么让它别那么“懂规矩”？网上说的“去审查化”“解锁模型潜力”到底是什么？LLaMA 系开源模型，为什么有这么多人在本地折腾它？

这个问题本身就是一座冰山。水面之上是“怎么搭环境、怎么下模型”，水面之下是架构设计、对齐机制、微调原理，以及一条很多人故意忽略的伦理红线。我花了大量时间在 7B 到 70B 的开源模型上做部署、微调和压测，踩过不少坑，也见过不少翻车现场。这篇文章想把 LLaMA 架构、本地部署方案、行为偏好调整的技术原理，以及绕不开的合规边界一次讲清楚。我不会只丢命令，更想把每个操作背后的“为什么”掰开揉碎。

先打个预防针：这篇文章不是教你如何拆掉安全护栏的“越狱教程”，恰恰相反，理解“护栏”是怎么装上去的，你才能真正理解开源大模型能做什么、不能做什么，以及为什么有些事坚决不该做。

1. “去审查化”到底在解构什么

1.1 模型的“拒绝回答”是从哪来的

很多人第一次接触开源大模型时，都会有一种落差：明明本地部署的 LLaMA 权重是开源的，为什么问它某些问题，它还是会像 ChatGPT 一样礼貌地拒绝？

因为“礼貌地拒绝”不是模型天生自带的，而是训练后期被刻意“训”出来的。主流开源模型的训练管线大致三段：预训练（Pre-training）让模型学会语言规律和世界知识，监督微调（SFT）让它学会对话格式和指令跟随，最后还有一步关键的偏好对齐。OpenAI 最早把这套偏好对齐称为 RLHF（基于人类反馈的强化学习），后来的开源模型更多使用 DPO 或 ORPO 这类更轻量的替代方案。

偏好对齐的目标很直接：让模型在“多个合理回答”里，学会选择人类更喜欢的那一个。而这里的“喜欢”不只是文笔好，还包括“安全”——触发某些高风险主题时，模型必须学会拒绝回答。于是经过充分对齐的模型，内部会形成一个非常强的“安全方向”，一旦判断当前请求可能造成风险，就会激活这个方向，输出“我很抱歉，我无法回答这个问题”。

问题在于，对齐过程往往是“一刀切”的。为了把真正有害的内容挡住，模型把大量“灰色地带”内容也一并拒绝了。这就像用消防水龙头灭蜡烛，控制住了风险，也浇灭了不少合理需求。于是开源社区里开始出现一个声音：能不能把这层“过度防御”拆掉？

1.2 开源社区的诉求与误区

围绕“去审查化”的诉求，我做过不少调研，大致可以分成三类：

第一类是创作和研究需求。很多写手、编剧、角色扮演玩家需要模型输出不受限的虚构暴力、黑暗剧情、成人向文学片段以辅助创作。这类内容在文艺创作中正常存在，但通用模型由于对齐策略通常一刀切拒绝。

第二类是本地隐私需求。用户希望模型能在完全本地环境下自由处理个人文档，不想因为关键词触发而让模型“罢工”，同时也担心云端审查泄露隐私。

第三类是技术研究需求。AI 安全研究人员和红队成员需要理解模型的安全边界在哪里，哪些攻击能绕过防护，从而帮助厂商加固护栏。这类研究是白帽行为，本身有很高的价值。

但也有相当一部分人存在严重误区，以为“去审查化”等于“解锁模型的全部能力”，拆掉安全对齐之后模型就会变得更聪明。这是完全不成立的。安全对齐更像一层行为约束，它约束的是输出风格和边界，不是模型“懂多少知识”。移除对齐只会让模型变得“口无遮拦”，并不会让它变得更准确、更强大。反而在很多常规任务上，由于失去了偏好优化带来的输出稳定性，模型会显得更散、更跳。

1.3 提前划好的安全线

写到这里我必须非常明确地划线：任何将开源模型用于违法活动、仇恨言论生成、虚假信息批量制造、恶意代码生成、绕过安全机制去伤害他人的行为，在任何主流司法辖区都是明确的红线。这不仅是道德问题，更可能直接涉及法律责任。

本文后续涉及的技术解析，重心是让大家理解“对齐机制如何运作”“为什么微调可以改变行为偏好”，以及“哪些做法在合规范围内具有实际价值”。至于那些教人制作有害模型的“配方”，我不会写，也不建议任何人去钻这个牛角尖。做技术的人，应该先想清楚“该不该”，再谈“能不能”。

2. LLaMA架构拆解：凭什么它成了本地玩家首选

2.1 四个关键设计：RMSNorm、SwiGLU、RoPE、GQA

聊本地部署，绕不开 LLaMA。无论是最初的 LLaMA 7B/13B/65B，还是后来的 LLaMA 2、LLaMA 3 系列，这套架构几乎成了开源模型的“模板”。很多国产开源模型，比如以 Qwen、Yi、DeepSeek 为代表的一系列模型，底子上都有 LLaMA 架构的影子。原因很简单：这套设计确实是经过大规模验证的最优解之一。

先说 RMSNorm。Transformer 里的 LayerNorm 需要计算均值和方差，然后做归一化。RMSNorm 直接省掉均值计算，只基于均方根做归一化。别小看这个简化，在训练和推理时它都能省下不少计算量，且实验证明对最终效果几乎没有负面影响。大模型动辄上千层叠，每一层省一点，累积起来的收益就很可观。

然后是 SwiGLU 激活函数。传统 Transformer 的前馈网络用的是 ReLU，后来有人发现 GELU 效果更好。SwiGLU 更进一步，引入“门控”机制，让激活函数的输出带上了可学习的路由能力。简单理解就是：网络内部的每一层，能更聪明地决定“哪些信息该放大、哪些该抑制”。代价是参数量变大，所以 LLaMA 在 FFN 层做了降维来抵消。

RoPE（旋转位置编码）是让 LLaMA 能处理长文本的关键。传统 Transformer 用绝对位置编码，模型对“位置”的理解是固定的。RoPE 的思路是用旋转矩阵把位置信息“旋”进注意力计算里。好处有两个：一是相对位置信息直接参与注意力打分，长距离依赖建模更自然；二是具备更好的外推能力，模型在训练长度之外的文本上也能有不错的泛化表现。这也是为什么社区能通过插值法把 LLaMA 的上下文从 4K 扩展到 32K，甚至更长。

最后是 GQA（分组查询注意力）。这是 LLaMA 2 70B 和 LLaMA 3 系列都采用的技术。多查询注意力（MQA）让所有头共享一组 K/V，省显存但对效果有损伤；标准多头注意力效果最好但太吃显存。GQA 取中间值：把查询头分组，每组共享一组 K/V。对推理场景最直接的好处是大幅降低 KV Cache 显存占用，同时推理速度比标准多头注意力快很多。这也是为什么 LLaMA 3 8B 能在消费级显卡上跑得比较流畅的架构基础。

2.2 开放权重与生态的护城河

LLaMA 系列能成为开源社区的事实标准，架构优势只是一部分，更关键的是生态深度。

从量化工具来看，llama.cpp 和 GGUF 格式最初就是为 LLaMA 量身打造的，虽然现在 GGUF 已经支持几乎所有开源模型，但 LLaMA 系的兼容性永远是最好的那一档。从微调工具来看，LLaMA-Factory、Axolotl、Unsloth 全部对 LLaMA 有最成熟的适配。从推理框架来看，Ollama、vLLM、SGLang 对 LLaMA 的支持都是开箱即用。

我记得第一次用 Ollama 跑 llama3.1:8b，从安装到回答问题，前后不到五分钟。而同样一个模型，如果要用纯 Python 的 Transformers 脚本跑起来，还得处理 tokenizer、attention mask、device map 一堆细节。生态的成熟度决定了你踩坑的深度。这也是为什么很多本地部署教程，默认第一站就是 LLaMA 系模型。

2.3 架构对微调与“行为修改”的影响

架构选择不仅影响推理速度，还直接影响微调难度。

LLaMA 系模型的参数量跨度大，从 7B 一路到 405B，意味着你在消费级显卡上用 LoRA 就能微调小模型，也能用多卡集群去碰大模型。更重要的是，LLaMA 系列的层数深、隐藏层维数高，为“定位特定行为对应的参数方向”提供了足够的空间。后面要讲的社区“去审查”技术，本质就是围绕注意力层和残差流做方向干预，架构越规整，这种干预越容易操作。

还有一个实际原因：LLaMA 的权重文件和 checkpoint 格式非常统一，HuggingFace 上几乎每一个开源模型都能直接复用 LLaMA 的社区工具链。无论是做量化、做合并还是做微调后的权重导出，都有成熟的标准流程。对于一个想深入研究的开发者来说，学习成本集中在“模型原理”而不是“适配模型”上。

3. 本地部署实操：Ollama与llama.cpp两条主流路线

3.1 硬件选型：显存、内存与量化等级怎么定

本地部署第一个问题永远是：我的机器跑得动吗？

先给一个快速估算公式：模型权重显存约等于“参数量 × 量化位数 ÷ 8”。比如一个 8B 模型用 Q4（4bit）量化，权重大约占 8 × 4 / 8 = 4GB，加上 KV Cache 和中间激活显存，整体 6GB 左右的显存勉强能跑。如果换成 Q8（8bit），光权重就 8GB，至少要 12GB 显存才舒服。70B 模型用 Q4 量化，权重就 35GB，这就必须依赖双卡或者大显存服务器了。

我给新手的建议很简单：预算内优先买显存大的卡。不要迷信算力，大模型推理第一瓶颈是显存带宽和容量。同样是跑 8B 模型，一张 8GB 的卡量化后只能选 Q4，一张 24GB 的卡可以上 Q8，输出质量和稳定性的差距肉眼可见。

注意：如果你只有 8GB 显存，又非想跑 14B 模型，可以试试 llama.cpp 的 CPU + GPU 混合 offload 模式。把部分层放到 CPU 上跑，虽然慢，但至少能跑起来。别一上来就买新硬件。

3.2 5分钟跑通Ollama

Ollama 是当前本地部署开源模型最省心的方案，对新手极其友好。安装过程不展开，官网下载对应系统版本即可。启动后核心操作只有两行代码。

ollama run llama3.1:8b

第一次运行会自动下载模型权重，之后每次启动都是秒开。装好之后，聊天问答直接走命令行交互。如果想走 API，Ollama 默认监听 11434 端口，在代码里访问http://localhost:11434/api/generate或/api/chat就能调起来。

这个方案最大的优势是零配置。模型文件、显存调度、上下文管理全部由 Ollama 帮你处理。如果你想调参，比如调整上下文长度或使用不同的量化版本，可以通过 Modelfile 做定制：

FROM llama3.1:8b PARAMETER temperature 0.7 PARAMETER num_ctx 16384

然后构建并运行自定义模型：

ollama create my-llama -f Modelfile ollama run my-llama

Ollama 适合快速验证和日常使用，但它的封装也带来了限制：你对底层的控制力会弱很多。如果你要做精细的推理参数调整、权重的部分 offload、或者对接自研推理管线，就需要往下走一层，直接用 llama.cpp。

3.3 llama.cpp的编译选择：CUDA、Vulkan、SYCL的区别

llama.cpp 是目前开源社区使用最广泛的纯 C/C++ 推理引擎。相比 Python 框架，它最大的优点是轻量、跨平台、支持各种花式量化格式（GGUF）。但很多人在编译环节就卡住了，尤其是搞不清 CUDA、Vulkan、SYCL 三种后端到底有什么区别。

简单做一个对比：

我自己的经验是：如果你手头是 NVIDIA 显卡，直接走 CUDA 后端，别折腾其他方案。编译命令如下：

cmake -B build -DGGML_CUDA=ON cmake --build build --config Release -j

如果显卡是 AMD 或者 Intel，尤其是 AMD 的 RDNA 架构，Vulkan 后端是当前比较靠谱的选择：

cmake -B build -DGGML_VULKAN=ON cmake --build build --config Release -j

SYCL 我实测过一轮，主要优势在 Intel Arc 系列显卡上，因为它是 Intel 官方主推的异构计算标准。但整体生态和 CUDA 相比还有明显差距，尤其是遇到一些偏门的算子时，稳定性不太让人放心。没有特殊原因，不建议新手从 SYCL 入门。

编译完成后，跑模型的方式也很直接：

./llama-cli -m /path/to/llama-3.1-8b.Q4_K_M.gguf -p "你好，请介绍一下自己" -n 256

-m指定模型文件，-p是提示词，-n是最大生成 token 数。如果你想做交互式对话，加-i参数即可。

3.4 部署完成后的基本验证

跑通命令不代表部署成功，我建议部署完一定要做三件事。

第一，检查响应速度。用相同提示词跑三遍，看单 token 生成耗时是否稳定。如果速度忽快忽慢，说明显存或内存可能不足，系统在做换页，需要调低上下文长度或换更小的模型。

第二，测试中文输出。很多英文模型内置了中文能力，但输出质量不稳定。让模型翻译一段长文看看是否流畅。如果中文很差，可以考虑直接用 Qwen 或 Yi 这类中文优化模型，没必要死磕 LLaMA 原版。

第三，检查上下文长度设置。很多人部署后不设置num_ctx，默认 2048 或者 4096，一旦对话稍微长一点，模型突然“失忆”。这不是模型坏了，是超长文本被截断了。合理设置上下文长度，比如 8192 或 16384，能明显改善多轮对话体验。

4. 行为改造的技术原理：从提示词到参数级修改

4.1 提示词层面的局限

在进入微调之前，先说说提示词层面能做到什么程度。

社区里一直有人尝试通过精心构造的提示词，让模型“忘记”自己的安全准则。这种现象有个专门的称呼叫“越狱”（Jailbreak），包括角色扮演提示、虚拟场景设定、逻辑陷阱等。早期 ChatGPT 时代，确实有不少人靠这类技巧绕过了部分限制。

但在开源模型上，这类做法的效果非常不稳定。因为开源模型的对齐程度普遍比闭源模型弱，边界本身就模糊，提示词稍微变个花样就可能“破防”或者“失火”。更关键的是，提示词只能影响模型的“输入上下文”，并没有改变模型内部的偏好分布。就像你给一个严格遵守规定的人编了个“你在讲故事”的设定，他可能会短暂放松，但遇到真正红线的问题还是会切回正常状态。

提示词层面的另一个问题是不可维护。模型升级、量化参数变化、上下文长度变化，都可能导致之前有效的提示词完全失效。真正想要从行为层面改变模型，必须走到参数级修改。

4.2 微调为什么更“治本”

微调的本质是更新模型的权重，让模型在不同输入下产生不同的输出分布。如果你希望一个模型减少对某些话题的拒绝频率，你可以准备大量这类话题的问答对，然后用 SFT 或 DP奥 微调，让模型学会“以正常回答的方式回应这类话题”。

从机制上讲，微调直接作用于模型内部的偏好方向，效果比提示词稳定得多。模型从权重层面被重新校准后，即使换一个完全不同的提示词，回答风格也会保持一致。这也是为什么开源社区几乎所有“行为调整”方案都是微调导向的。

但必须强调：微调一项技术没有善恶属性。它同样可以用来让模型更礼貌、更安全、更遵守规则。所谓“治本”，指的是它能从根本上改变行为偏好，至于偏好变成什么样，完全取决于训练数据和训练目标。

4.3 社区里的abliteration思路解析

在开源社区，近几年有一种被称为 “abliteration”（消融 + 擦除）的技术思路特别火。它的命名来自 “ablation”（消融）和 “literation” 的组合，核心想法和传统微调完全不同，不是“增加新偏好”，而是“定位旧偏好并从权重中削弱它”。

大致原理是这样的：对齐模型在内部表征中，会形成一些与“拒绝回答”强相关的方向。研究者通过前向传播收集模型在不同输入下的激活值，用探针（Probe）或者均值差分法，找到那些与安全拒绝行为显著相关的残差流方向。找到之后，在每次前向计算时从激活值中显式减去这个方向的投影，或者直接在权重上做对应修改，从而削弱模型“拒绝”的触发倾向。

这个思路在 LLaMA 系模型上表现很稳定，核心原因是 LLaMA 的残差流结构比较清晰，安全对齐的特征相对集中。实测效果上，经过 abliteration 处理后的模型，对原本拒绝的话题会变得“愿意聊”，而且不会像提示词越狱那样容易崩。

但我要给这个技术泼几盆冷水。第一，abliteration 不是万能的，它只是削弱“拒绝”的触发方向，并不会新增知识。模型该不会的还是不会。第二，它很可能削弱其他方面的能力，比如模型对有害内容的判断力、指令跟随的稳定性。第三，也是最关键的：这种技术一旦被滥用，就是制造无护栏模型的直接路径。我了解它，是因为这项技术对我们研究模型可解释性和 AI 安全防御有参考价值，而不是为了做一个“什么都能聊”的玩具。

提示：如果你抱着“把模型变成违规内容生成器”的目的去研究这类技术，我劝你停在这里。这不是道德说教，而是基于现实风险的提醒：这类行为在几乎所有平台和司法环境中都可能给你带来麻烦。

4.4 用LLaMA-Factory实操一次行为偏好微调

那我们在合规的前提下，怎么把“行为偏好调整”真正跑一遍？答案是微调框架，这里以 LLaMA-Factory 为例。

LLaMA-Factory 是目前最好上手的开源微调平台，它把数据准备、模型加载、LoRA/QLoRA、训练参数配置、权重导出集成在一个统一界面里，甚至提供 WebUI，对新手非常友好。下面是一个标准的实操流程。

首先准备数据。微调数据最常用的是 Alpaca 格式，每条数据包含指令、输入和输出三个字段：

[ { "instruction": "如果你是图书管理员，会如何推荐一本书？", "input": "", "output": "我会先询问读者的阅读偏好，再结合库存和热门度推荐..." } ]

如果你想调整模型对话风格，比如让它回答更简洁、更口语化，就多准备几千条“简洁风格”的问答对。关键在于数据质量，不要贪多。我实测下来，干净的一两千条数据，效果往往好过嘈杂的一万条。

安装和启动 LLaMA-Factory：

git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e . llamafactory-cli webui

在 WebUI 里，模型选择LLaMA3-8B-Chinese这类中文向模型，微调方法选LoRA，如果你显存有限，直接上QLoRA，它会自动启用 4bit 量化，显存压力小很多。训练轮数建议从 3 轮开始，学习率选 2e-4 或 1e-4 都比较稳妥。

说完中立流程，我必须把安全边界再拎出来说一次：LLaMA-Factory 同样可以被用来训练危害性内容模型，但这不是框架的问题，而是使用者的选择。你用它训练一个“更礼貌的客服机器人”或者“更简洁的写作助手”，这完全合理；你用它去训练一个“专门输出攻击性内容”的模型，那是违法行为。技术工具是中性的，责任在人。

训练完成后，LoRA 权重需要和原始模型合并，才能导出为标准模型文件。LLaMA-Factory 的“导出”标签页可以直接完成 merge，之后用 Ollama 或 llama.cpp 就能加载跑了。

4.5 效果评估与回归测试

微调完成不代表万无一失。我强烈建议做两套评估：一套是“目标行为测试”，一套是“常规能力回归测试”。

目标行为测试很简单：准备一批你希望模型达成的新行为样例，跑一遍看是否符合预期。常规能力回归测试更重要，因为微调最容易带来的问题就是灾难性遗忘——模型学会了新行为，但把之前的能力丢了。你可以在微调前后分别跑同样的数学题、代码题、常识题，对比得分。如果下降明显，需要回退参数或者加大通用数据比例。

5. 伦理边界：开源模型不等于“什么都行”

5.1 许可证是第一条红线

聊开源模型，很多人只看“开源”两个字，却忘了还有一个东西叫许可证。

Meta 的 LLaMA 系列采用专属社区许可协议，而不是传统意义上的完全开源许可。它允许绝大多数用户免费使用和修改，但有明确的使用限制，包括月活用户规模上限、禁止用模型生成违法内容、禁止将模型用于军事领域等。违反许可证使用，可能导致授权终止甚至法律追责。

其他模型也各有各的约束。Qwen 系列采用 Apache 2.0 协议，相对宽松；一些研究机构发布的模型会附加“禁止用于特定领域”“禁止商用”等条款。拿到一个模型，第一件事永远是读许可证。我见过不止一个开发者因为没看许可证，把限制商用的模型接进商业产品里，最后被发律师函。

5.2 安全对齐存在的意义

安全对齐不是可有可无的功能，它是我认为大模型技术里最重要的一部分。

现代大模型的“能力”本身就包含欺骗、说服、利用人类偏误的能力。一个没有安全对齐的模型，就像一台没有刹车又马力全开的跑车，速度很快，但谁开都容易出事。安全对齐能保证模型在绝大多数场景下遵循人类意图，而不是机械地执行字面指令。比如你问“怎么制造危险化学品”，对齐后的模型会拒绝或引导到合法用途，而未对齐的模型可能直接输出步骤，哪怕提问者根本没有任何防护知识。

去除安全对齐的研究价值，在于帮助我们理解对齐的脆弱性，进而设计更坚固的防护。而不是为了让模型变得“无拘无束”。把原本用于“理解系统”的知识用来“破坏系统”，这是对自己技术生涯极不负责的选择。

5.3 研究、创作与滥用之间的灰度

当然，我也理解现实中有不少灰色地带。

比如一位小说作者，需要虚构作品里的暴力或黑暗情节；一位游戏设计师，需要生成反派人物的对白；一位教育工作者，需要模型扮演一个“不完美角色”来演示沟通误区。这些需求是真实存在的，而通用模型的安全对齐往往无法精准满足。正因如此，开源社区才发展出了各种“定制化”路线。

我的建议是这样的：在遵守许可证和当地法律的前提下，你可以通过合规的微调数据，让模型在“虚构创作”和“现实危害”之间做出区分。比如明确在系统提示里写出“这是一个虚构作品场景，以下内容不构成现实建议”，并让训练数据集中在“虚构叙事”而不是“现实操作”上。这类行为属于创作自由和技术探索的交界处，正当性比较清晰。

但如果你追求的是一个“无限制模型”，并且实际使用中分不清虚构和现实，那这条技术路线对你来说就是危险的。我也不建议你在任何公开平台上分享这类模型，因为你无法控制二次分发后被用来做什么。

5.4 一个从业者给新手的四条建议

结合我自己踩过的坑，给准备深入开源大模型的新手四条忠告。

第一条，先学协议，再学代码。模型许可证、平台服务条款、所在地区的法律要求，这些比任何技术细节都重要。搞技术的人容易忽略这些“非技术”的东西，但它们恰恰是能让你长期安全创作的前提。

第二条，保持“研究心态”而非“破解心态”。研究安全对齐的边界和机制，是为了理解和加固系统，而不是为了炫耀“我能绕过限制”。你在社区留下的每一个技术足迹，都会长期伴随你的技术身份。

第三条，不要传播未对齐模型的权重。你可以自己研究、自己实验，但不要轻易把这类模型发布到公开平台。你没有权力替所有人决定“什么不该被限制”。

第四条，给自己的模型写一份使用说明。如果你真的做了一个“行为风格不同”的衍生模型，明确写清楚它的适用场景、限制条件、已知风险。这不是法务要求，而是技术人基本的职业操守。

6. 常见问题排查与经验补全

6.1 显存不足怎么办

本地部署第一大坑就是显存不足。Ollama 会默认选择 GPU 推理，如果显存不够会自动回退到 CPU，但速度会让人崩溃。最常见的问题是在跑 14B 以上模型时直接 OOM（显存溢出）。

排查思路按优先级排：第一，检查量化级别，Q8 换 Q4 或者 IQ4_XS，显存占用能降低接近一半；第二，调低上下文长度，从 16384 降到 8192，KV Cache 占用能明显下降；第三，检查是否开启了多 GPU 分层，llama.cpp 可以设置--n-gpu-layers将部分层放在不同设备；第四，如果依然不行，考虑换小一号模型。7B 跑不动就别硬上 14B，实际体验差距没有想象中大。

6.2 中文效果不如英文怎么办

LLaMA 原始权重的训练语料以英文为主，中文能力虽然能“凑合用”，但表达比较生硬。如果你主要用中文，有两个方向可以解决。

第一个方向是换模型。Qwen、Yi、DeepSeek 的中文能力在人机对话体验上明显好于原版 LLaMA，而且它们都能用 Ollama 一行命令跑起来。第二个方向是中文微调。在保留英文能力的前提下，用中文问答数据做增量 SFT，传统上几千条高质量中文对话就够把模型的中文表达“掰回来”。这个工作量不小，但对学习微调流程很有帮助。

6.3 微调后能力退化怎么办

这个问题在微调中太常见了。你拿着 LoRA 在 LLaMA 上做风格调整，跑完发现模型的数学能力明显下降，代码能力也变差了。

最常见的原因是学习率太大或训练轮数太多。LoRA 微调不是从头训练，它是在底座模型能力之上的“小幅修正”，过强的更新会破坏原始权重分布。我的经验是学习率尽量不超过 5e-5，训练轮数 1 到 3 轮之间，每轮结束都在验证集上测一次常规能力。如果还是退化，把原始训练数据里加入 20% 到 30% 的通用数据（数学、代码、常识问答）混合训练，能有效缓解灾难性遗忘。

6.4 推理速度慢的排查要点

很多人在本地跑了 70B 模型，然后抱怨“一个字要等半天”。这通常是显存带宽瓶颈，而不是模型本身慢。排查顺序：第一，确认模型是跑在 GPU 而不是 CPU 上；第二，确认量化级别，Q4 比 Q8 快很多；第三，检查是否开启了 Flash Attention，llama.cpp 在部分后端下默认开启，但在某些自定义编译环境下可能没开；第四，把不必要的系统负载降到最低，浏览器开几十个标签页去生成内容，速度掉一倍都很正常。

另外，多轮对话时的首 token 延迟和生成 token 延迟是两类问题。前者主要受 prompt 处理和 KV Cache 预填充影响，后者决定生成速度。如果首 token 特别慢，可以试试缩短历史上下文、减少 system prompt，或使用--cache相关参数。

我个人在这些实验里最大的体会是：能跑起一个开源模型不难，难的是知道自己该拿它做什么。LLaMA 架构给了我们接近技术底层的自由，本地部署给了我们数据隐私的保障，微调工具给了我们定制行为的可能，但这些技术自由都需要建立在清晰的自律之上。开源社区最吸引我的，从来不是“什么都能做”，而是一群人在一起认真思考“什么应该做”。如果你是刚起步的新手，建议先从跑通一个小模型开始，读一读许可证，然后再决定下一步往哪儿走。这比任何技术选型都重要。