75GB内存本地运行Qwen3-8B：CPU推理与量化部署指南
如果你最近在关注开源大模型的本地部署，一定会发现一个绕不开的话题：没有顶级显卡，只有一台内存还不错的普通电脑，到底能不能流畅跑起现在的主流大模型？很多人的第一反应是“不可能”，因为模型动辄几十 GB 参数，显存不够直接卡死。但过去这段时间，我的结论已经改成：能跑，而且选择比想象中多，关键不再是有没有 24GB 显存，而是你有没有足够大的内存，以及愿不愿意在速度和显存之间做一次冷静的换算。
这篇文章要聊的标题，就是“Qwen3.8-Flash 75GB 内存本地运行”。先说明一下，这个名称在社区里并不是一个完全标准的官方命名，平时更容易看到的叫法是 Qwen3、Qwen3-8B、Qwen3-Flash 之类的混搭。它很可能是指 Qwen3 系列的 8B 量级模型，在 75GB 大内存的单机环境下，用 CPU 和内存完成推理。这里真正值得关注的技术点，不是某个模型具体叫什么，而是8B 级别的大模型，如何从“必须依赖大显存”变成“有 75GB 内存就能本地跑”，以及这条路到底该怎么走。
这篇文章会从硬件门槛、量化选型、推理引擎、实际部署步骤、常见问题排查这几个层面，帮你把“大内存跑大模型”这件事一次讲透。读完你至少能回答三个问题：我的机器能不能跑？跑起来需要多长时间？在什么情况下该选 Ollama，什么情况下该选 llama.cpp？
1. 75GB 内存本地运行，解决的是哪一类开发者的痛点
先聊一个场景。很多同学的项目组并没有 GPU 服务器，手里的开发机可能是 32GB、64GB 或者 75GB 内存的普通工作站，显卡可能是 8GB 显存的消费级卡，甚至干脆是集成显卡。过去遇到一个任务，比如“在内网部署一套私有的代码问答助手”或者“本地跑一个模型做离线文本处理”，第一步就被显存卡住了。
显存不够，常规做法是租云 GPU，或者找运维申请带 A100 的机器。但这里有很多现实问题：数据不能出内网、审批流程太长、预算有限、需要做 PoC 验证。于是大家开始寻找“纯 CPU 推理”的方案。早几年这是非常痛苦的事情，因为开源的 7B 模型用 FP16 加载也需要 14GB 显存/内存，CPU 推理速度又慢得让人绝望。
现在情况不一样了。8B 级别模型的量化方案已经非常成熟，比如 Q4_K_M、Q5_K_M 这些常见量化等级，一个 8B 模型的权重文件可以压缩到 5GB 到 6GB 左右。配合 75GB 的内存，不仅模型权重可以全部加载，还可以给 KV Cache 和系统运行留出充足余量，甚至可以把上下文长度开到很大，不用担心内存溢出。
这个方案的真正价值在于：**它让你不用买大显存显卡，只用一台内存足够的普通机器，就能完成大模型的本地部署、验证、开发和内网发布。**对于做技术选型、写验证脚本、搭私有化原型的工程师来说，这是一种低成本快速验证的方式。它不追求每秒几十个 token 的生成速度，但足够支撑你完成“跑通流程、验证效果、作为内网服务提供弱实时能力”的需求。
当然，它也有限制。CPU 推理的瓶颈不在内存容量，而在内存带宽和单核算力。后面我会专门讲这部分，因为这是决定体验的核心，也是很多人一开始容易忽略的地方。
2. 核心概念：显存、内存、内存带宽与量化
在动手部署之前，先把四个容易混淆的概念理清楚。
2.1 显存与内存
显存是显卡自己带的专用存储，访问速度极高，但容量小。内存是 CPU 的系统主存，容量大，速度相对显存慢。平时跑深度学习模型，模型权重、中间激活值、KV Cache 主要都放在显存里，显存不够就会报 CUDA out of memory。
而“75GB 内存本地运行”的思路，本质上是绕开显存瓶颈：当模型的权重和 KV Cache 都加载到系统内存里，由 CPU 做算子计算，推理就完全在内存里完成。 这样就不需要高显存显卡了。
2.2 内存带宽才是 CPU 推理的命门
很多人以为内存够大就够用，其实不对。CPU 推理每一步都要反复读取模型权重，而这个读取速度的上限就是内存带宽。
举一个通俗的类比：如果把模型权重比作一个超大的工具箱，CPU 是工人，内存带宽就是工人每次取工具时走的过道宽度。过道越宽，工人取工具越快，整体干活效率才高。你工具箱再大（内存容量大），如果取工具很慢，效率也上不去。
这就是为什么同样是跑 8B 模型，双通道 DDR4 内存和四通道 DDR5 内存的体验差异非常大。DDR4-3200 双通道的理论带宽大约 51.2GB/s，DDR5-4800 四通道能到 153.6GB/s 左右，实际推理速度差距能到两倍以上。所以评估机器能不能跑，不能只看内存是不是 75GB，还要看内存是几通道、频率多少。
2.3 量化：让模型瘦身的关键
量化是模型压缩的一种方案，把 FP16 或 BF16 的权重压缩到 INT8、INT4 等低精度表示，牺牲一点精度，换体积和速度。在 CPU 推理场景里，量化几乎是必选项。
我们用 Qwen 系列 8B 模型举例。FP16 原始权重大约 16GB，INT8 量化后约 8GB，Q4_K_M 量化后约 5GB 左右。后者就是很多 CPU 推理用户最常用的版本。量化后的模型加载时间更短，推理时读取的数据量更少，对内存带宽的压力也更小，所以既省内存又提速。
不过也不能一概而论。某些任务对精度非常敏感，比如复杂数学推理、代码生成，过度量化可能会导致输出质量明显下降。一般建议先用 Q4_K_M 跑通流程，再根据结果尝试 Q5_K_M 或 Q8_0，找到一个质量和速度的平衡点。
2.4 KV Cache：上下文越长，内存占用非线性增长
KV Cache 是 Transformer 模型在生成过程中需要保存的中间状态，它的大小和“层数 × 注意力头数 × 维度 × 上下文长度 × 批大小”相关。上下文长度越长，KV Cache 越大。在实际部署中，
最低 0.47元/天 开通会员,解锁全文
成为会员后, 你将解锁
下载资源随意下
优质VIP博文免费学
优质文库回答免费看
付费资源9折优惠
本地部署阿里Qwen3大模型[可运行源码]
Qwen3是阿里巴巴集团于2024年正式开源发布的第三代通义千问大语言模型，标志着国产大模型在技术深度、工程成熟度与生态开放性方面迈入全新阶段。其核心价值不仅体现在参数规模与训练数据量的跃升，更在于系统性重构了本地化部署的技术路径——从底层架构设计之初就深度兼顾“高性能推理”与“低门槛落地”的双重目标。Qwen3采用创新的混合推理架构（Hybrid Inference Architecture），该架构并非简单堆叠多种加速策略，而是将动态量化（Dynamic Quantization）、分层缓存（Layer-wise KV Cache）、算子融合（Kernel Fusion）与内存感知调度（Memory-Aware Scheduling）四大技术模块进行耦合式协同优化。例如，在Windows平台部署时，模型可自动识别GPU显存容量与CPU可用内存比例，智能选择FP16+INT4混合精度计算路径：对注意力权重保留FP16高精度以保障语义连贯性，对前馈网络激活值启用INT4量化以压缩75%以上显存占用；同时通过预编译CUDA Graph与Triton自定义算子，将单次推理的kernel launch次数降低至传统PyTorch方案的1/8，显著缓解Windows子系统（WSL2）下常见的CUDA上下文切换延迟问题。在多语言支持维度，Qwen3突破了传统多语言模型“翻译式适配”的局限，构建了基于统一语义空间的跨语言理解-生成联合建模框架。其词表（Vocabulary）采用动态扩展机制，基础词表覆盖中、英、法、西、葡、俄、阿、日、韩、越等10种高频语言的原生子词单元，并通过语言感知嵌入（Language-Aware Embedding）技术，在输入层即注入语言ID向量，使同一语义概念（如“量子纠缠”）在不同语言上下文中自动激活对应的文化语境知识图谱。实测表明，Qwen3在XTREME多语言基准测试中，中文NLU任务准确率达92.7%，英文达91.3%，而小语种如斯瓦希里语问答任务F1值较Qwen2提升14.6个百分点，这为科研工作者开展跨语言社会学分析、程序员构建多语种客服系统、学生进行外语学习辅助提供了坚实底座。本地部署的工程实现深度绑定开源生态演进。压缩包中的anbsuzl6kXGPuyJzxIo-master-583669068db689b4e99070436a3da9f3752a0cb4目录结构严格遵循Hugging Face Model Hub规范，包含config.json（定义混合推理配置参数）、pytorch_model.bin.index.json（分片权重索引）、tokenizer.model（支持Unicode 15.1全字符集的SentencePiece模型）及关键的quant_config.json（存储AWQ量化校准参数）。部署流程摒弃传统“pip install + python run.py”的粗放模式，转而采用容器化轻量运行时：内置基于ONNX Runtime DirectML的Windows原生推理引擎，无需安装CUDA驱动即可调用AMD/NVIDIA/Intel核显的AI加速能力；配套的qwen3-launcher.exe采用Rust编写，启动时自动执行硬件指纹扫描（PCIe带宽检测、NUMA节点拓扑分析、WSL2内存映射验证），动态生成最优线程池配置——当检测到16GB RAM+RTX 3060组合时，自动启用4线程CPU卸载+8GB显存分块加载策略，避免Windows系统因内存碎片化导致的OOM崩溃。针对Mac用户文档中提及的部署难点，本质源于Apple Silicon芯片的统一内存架构（UMA）与Qwen3的KV缓存管理机制存在调度冲突，解决方案已在源码注释中明确：需在llama.cpp分支中启用metal-cpu-fallback补丁，强制将首层Transformer的KV缓存驻留CPU内存，后续层逐步迁移至GPU，从而规避Metal驱动层的内存同步瓶颈。开源协议层面，Qwen3采用Apache 2.0许可证，但特别附加了《本地化部署合规附件》——允许商用场景下免授权费使用，但要求衍生模型若公开发布必须同步开源权重与量化配置，且禁止将其封装为SaaS服务直接售卖API调用次数。这种“开源但不放任”的治理模式，既保障了开发者二次创新自由（如学生可基于Qwen3微调法律咨询专用模型，程序员可集成至VS Code插件实现代码自动生成），又构建了可持续的社区贡献正循环。从技术纵深看，Qwen3的本地化不仅是模型文件的物理迁移，更是AI权力的再分配：它让每台Windows笔记本都成为独立AI节点，使科研机构摆脱云服务厂商的算力锁定，令教育场景实现无网络依赖的实时交互式学习——当一个高中生在离线状态下用Qwen3解析《九章算术》古文并生成三维几何演示代码时，技术普惠已超越工具属性，升华为数字时代的基础认知能力。
langchain-chatchat在window上使用cpu运行Qwen-1-8B-Chat时遇到ERROR: object
在Windows环境下使用LangChain-Chatchat框架本地部署并运行通义千问Qwen-1.8B-Chat模型时，开发者常遭遇一个极具迷惑性但根源明确的运行时错误：`ERROR: object of type 'NoneType' has no len()`。该异常表面看似是Python空对象调用`len()`方法所致，实则为深层PyTorch底层张量运算兼容性问题所引发的**链式错误表现**。其本质原因在于Qwen-1.8B-Chat模型默认以`torch.float16`（即Half精度）加载权重，并在推理过程中尝试调用CPU后端不支持的`addmm_impl_cpu_`内核函数——该函数专为GPU上的混合精度矩阵乘加（Add-MatMul）优化设计，在标准x86 CPU上根本未实现对`Half`（`torch.half`/`torch.float16`）数据类型的运算支持。当PyTorch在CPU上试图执行`addmm`（如Linear层前向传播中的`input @ weight.t() + bias`）却传入`half`张量时，底层C++引擎返回`None`而非有效结果，上层Python逻辑误将此`None`当作合法张量继续处理，最终在需计算长度（如`len(output)`或`output.shape[0]`）处触发`TypeError`。此问题绝非代码逻辑缺陷，而是深度学习框架与硬件能力错配的典型体现。Qwen系列模型虽经量化压缩，但1.8B参数量仍属中等规模，其原始权重文件（`.bin`或`.safetensors`）通常以`float16`保存以节省磁盘与内存空间；而LangChain-Chatchat作为面向快速落地的开源对话系统，其`model_adapter.py`负责模型加载、输入预处理与输出解析，其中`get_model_tokenizer`等函数若未显式指定`torch_dtype=torch.float32`，便会沿用模型配置中声明的`torch_dtype="auto"`或直接读取权重精度，导致`AutoModelForCausalLM.from_pretrained()`在无CUDA设备时仍尝试以`half`加载——这在CPU上必然失败。更隐蔽的是，部分适配器代码（如`openai.py`中模拟OpenAI API响应格式的逻辑）可能对模型输出做二次校验，例如判断生成文本token数是否为零，此时若模型前向传播因`addmm_impl_cpu_`缺失而中断并返回`None`，后续`len(None)`即刻抛出异常。解决方案的核心在于**全链路强制降级至FP32精度**，并确保所有涉及模型加载、推理、响应封装的模块均规避`half`类型。具体而言，`model_adapter.py`需重点修改：在`load_model`函数中，于`from_pretrained`调用处显式添加`torch_dtype=torch.float32`参数，并移除任何`device_map="auto"`（因其在无GPU时可能误导向无效设备），改用`device="cpu"`；同时检查`tokenizer`加载是否启用`use_fast=True`（某些fast tokenizer在CPU上对half权重解析异常，可临时设为`False`）。`openai.py`则需强化健壮性：在构造`ChatCompletionResponse`前，增加对`model_output`的`isinstance(..., torch.Tensor)`及`not None`双重校验，若检测到非法输出，主动抛出带上下文的`ValueError`而非静默传递`None`。此外，还需在全局配置中禁用`torch.backends.cuda.enable_mem_efficient_sdp(False)`（虽为CUDA设置，但某些版本PyTorch在CPU模式下误读该标志亦会干扰），并在启动脚本中设置环境变量`PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128`（防止内存碎片化加剧FP32内存压力）。值得注意的是，FP32虽解决兼容性问题，但带来约1.8倍内存占用增长（Qwen-1.8B FP32权重约3.6GB）与推理速度下降（CPU上FP32矩阵运算吞吐约为FP16的60%-75%）。因此，实际部署需配合操作系统级优化：在Windows中启用“高性能”电源计划、关闭后台应用、增大虚拟内存至物理内存1.5倍以上；利用`psutil`监控进程内存峰值，必要时在`model_adapter.py`中加入`torch.cpu.empty_cache()`调用；对于长上下文场景，启用`--max_length 2048`等参数限制生成长度，避免CPU缓存溢出。最终，该方案不仅修复了`NoneType`错误，更构建了一套可在纯CPU Windows机器（如Intel i5-8250U/8GB RAM笔记本）上稳定运行Qwen-1.8B-Chat的完整技术路径，彰显了开源生态中“向下兼容”与“务实落地”的工程哲学。
《AI大模型应用》--Deploy Qwen-7B-Chat(通义千问) on CPU.zip
《AI大模型应用》——Deploy Qwen-7B-Chat（通义千问）on CPU，这一压缩包所承载的绝非仅是一组可运行脚本，而是当前AI工程化落地进程中极具代表性的技术实践范式，深刻体现了大模型从云端服务走向本地轻量化部署的关键跃迁路径。其核心知识点横跨模型架构理解、推理引擎选型、硬件资源适配、基础设施自动化编排及模型优化工程等多个维度，构成一套完整、可复现、可扩展的大语言模型（LLM）CPU端侧部署知识体系。首先，Qwen-7B-Chat是阿里巴巴研发的开源大语言模型通义千问系列中面向对话场景优化的70亿参数版本，基于Transformer解码器架构，支持多轮对话、指令遵循与中文语义深度理解。其“Chat”后缀表明已通过监督微调（SFT）与基于人类反馈的强化学习（RLHF）完成对齐优化，具备较强的交互能力与安全性。在部署层面，该模型原始权重通常以Hugging Face Transformers兼容格式（如PyTorch bin文件或safetensors）发布，需依托transformers库加载，并配合tokenizer进行文本编码/解码。而本项目特别强调“on CPU”，意味着完全规避GPU依赖，这对模型推理性能、内存带宽、计算延迟提出严峻挑战——7B参数模型在FP16精度下理论权重体积约14GB，若直接加载为float32则高达28GB，远超普通PC内存容量，因此必须引入系统级优化策略。关键知识点之一是**模型量化（Model Quantization）**：这是实现CPU高效推理的基石。项目虽未显式列出量化脚本，但结合标签“模型量化”与CPU部署前提，可推断必然采用INT4/INT8量化方案（如AWQ、GPTQ或bitsandbytes的QLoRA兼容量化），将权重从FP16压缩至低比特表示，在保持90%以上原始任务准确率的同时，将内存占用降低60–75%，并显著提升CPU缓存命中率。量化不仅涉及权重转换，还需配套的量化感知训练（QAT）或后训练量化（PTQ）校准流程，以及适配CPU推理后端（如llama.cpp、llm.cpp或Intel Extension for PyTorch）的算子重写与内核优化。其次，“Terraform”与“.tf”文件（main.tf、variables.tf、outputs.tf）揭示了本项目采用**基础设施即代码（IaC）范式**管理部署环境。这并非传统意义上云服务器编排，而是将本地开发机或边缘设备抽象为“基础设施资源”，通过Terraform定义CPU核心数、内存大小、磁盘空间、Python环境版本、依赖包列表（如transformers>=4.36, torch>=2.0, sentencepiece, accelerate）等声明式配置。Terraform Provider（极可能是local或null provider）驱动Shell provisioner执行模型下载、量化转换、服务封装（如FastAPI/Gradio封装）、端口绑定与健康检查等操作。这种设计使部署过程具备强可重复性、版本可追溯性与团队协作友好性，彻底告别手工配置的脆弱性，是AI工程化成熟度的重要标志。第三，“CPU推理”本身即是一套复杂的技术栈组合：需选择轻量级推理框架——如llama.cpp（C/C++实现，极致CPU优化，支持GGUF格式量化模型）、Ollama（封装llama.cpp提供CLI/API）、或Hugging Face Optimum + ONNX Runtime（将模型导出为ONNX再经CPU优化执行）。项目中README.md应详细说明所选后端、启动命令、API接口规范（如OpenAI兼容RESTful接口）、流式响应支持机制及并发连接限制策略。此外，还需处理CPU特有瓶颈：如AVX-512指令集启用、线程亲和性绑定（taskset）、NUMA节点内存分配优化、大页内存（HugePages）配置，以及Python GIL释放策略（如使用Cython或subprocess调用C后端）。再者，“AI模型本地化”指向数据主权、隐私合规与离线可用性三大刚性需求。在政务、金融、医疗等敏感领域，模型必须脱离公网运行，所有输入输出均不经过第三方服务器。本项目通过本地部署Qwen-7B-Chat，实现了全链路数据不出域：用户提问经本地tokenizer分词→CPU加载量化权重→逐token自回归生成→本地解码返回，全程无网络外联。同时，结合Gradio/FastAPI前端，可快速构建内部知识问答系统、合同审查助手或客服话术生成工具，真正打通“模型能力”到“业务价值”的最后一公里。最后，Hugging Face Transformers作为生态枢纽，承担模型加载、分词器集成、Pipeline抽象等职责；而icon.png与README.md则体现工程交付规范性——前者用于UI识别，后者必须包含环境准备清单（如Ubuntu 22.04+、Python 3.10+、gcc-11+）、一键部署命令（terraform init && terraform apply）、API调用示例（curl -X POST http://localhost:8000/v1/chat/completions -d '{"model":"qwen-7b-chat","messages":[{"role":"user","content":"你好"}]}'）、常见错误排障指南（如OOM报错对应量化等级调整、tokenizer路径错误对应HF_HOME配置）及安全提示（禁用root运行、启用HTTPS证书等）。综上，该压缩包是融合前沿AI算法、系统工程、DevOps实践与行业合规要求的综合性知识载体，其价值远超单一模型部署，实为构建企业级AI能力底座的方法论缩影——它教会开发者如何以工程思维驾驭大模型，让千亿参数的智能不再悬浮于云巅，而是稳稳扎根于每一块CPU芯片之上，成为触手可及的生产力引擎。
Ollama部署Qwen2.5-7b[源码]
Ollama部署Qwen2.5-7b（INT4量化版）是当前轻量级大语言模型本地化推理实践中的典型技术路径，其核心价值在于将原本需高端A100/H100显卡才能运行的70亿参数级大模型，压缩至消费级GPU（如RTX 4090/4080甚至3090）即可高效承载的规模。Qwen2.5-7b作为通义千问系列最新迭代的指令微调模型，继承了Qwen2系列在多轮对话理解、结构化输出生成、中文语义精准建模等方面的显著优势，同时在训练数据覆盖广度、逻辑推理深度、代码生成鲁棒性及长上下文稳定性上均有实质性提升。该模型并非原始FP16全精度版本，而是经由AWQ（Activation-aware Weight Quantization）或GPTQ等先进量化范式压缩后的INT4低比特表示——即每个权重仅用4位整数存储，相比原始16位浮点数，理论模型体积压缩达75%，显存带宽需求下降约4倍，从而直接驱动硬件资源门槛断崖式降低。在Windows 11环境下部署的关键挑战在于系统生态适配：传统Linux容器化方案（如Docker+Ollama服务）在Win11中需依赖WSL2子系统桥接，而Ollama 0.11版本原生强化了Windows二进制支持，内置轻量级虚拟化引擎与CUDA驱动抽象层，可绕过WSL2直接调用NVIDIA GPU进行tensor计算。安装过程需严格校验Visual C++ 2015–2022运行库、NVIDIA驱动版本（≥535.0）、CUDA Toolkit兼容性（推荐12.1或12.2），并确保Windows安全中心未启用“基于虚拟化的安全性”（VBS）或内存完整性保护（HVCI），否则会导致Ollama GPU加速模块加载失败。环境准备阶段还必须配置可信模型源——通过`ollama serve`启动后台服务后，使用`OLLAMA_HOST=127.0.0.1:11434`环境变量强制指定本地监听端口，并配合`OLLAMA_NO_CUDA=0`启用CUDA加速开关。模型拉取环节采用`ollama pull qwen2.5:7b-instruct-q4_k_m`命令（具体标签名依HuggingFace或Ollama官方模型库命名规范而定），该镜像已预编译为GGUF格式，内嵌K-quants分组量化策略：将权重矩阵按列分块，每块独立计算scale与zero-point参数，兼顾精度损失最小化与访存局部性优化。实测显示，在RTX 4090（24GB GDDR6X）上运行Qwen2.5-7b INT4模型时，初始加载显存占用稳定在4.8–5.2GB区间，远低于FP16版本所需的13.6GB；若启用`--num_ctx 4096`扩展上下文长度，显存增量仅增加约0.7GB，证明其KV缓存管理机制高度优化。更关键的是，Ollama 0.11引入动态批处理（dynamic batching）与PagedAttention内存池技术，使单卡并发处理3–5路对话请求时仍保持<120ms首token延迟，吞吐量达8.3 tokens/sec（输入512 tokens + 输出256 tokens场景）。显存计算方法论需从三个维度展开：第一是模型参数显存，7B参数×4bit÷8=3.5GB；第二是KV缓存，按`batch_size × seq_len × n_layers × n_heads × head_dim × 2（k+v）× 2（FP16模拟）`估算，但INT4量化后实际以INT8存储，再经Ollama内部FP16→INT4重映射，故系数修正为×1；第三是中间激活值，Ollama通过算子融合（kernel fusion）将LayerNorm、SiLU、RoPE等操作合并为单GPU核函数，避免显存反复分配释放。用户可通过`nvidia-smi --query-compute-apps=pid,used_memory,process_name --format=csv`实时监控，结合`ollama list`查看模型元数据中的`size`字段（含GGUF文件头描述的量化粒度信息）。部署调用示例不仅限于CLI交互模式（`ollama run qwen2.5:7b-instruct-q4_k_m`），更应掌握API集成方式：启动`ollama serve`后，向`http://localhost:11434/api/chat`发送JSON POST请求，载荷包含`model`、`messages`（支持system/user/assistant角色嵌套）、`options`（可动态调节temperature=0.7、top_p=0.9、num_predict=512等），响应流式返回SSE格式tokens，完美适配前端Web应用或Python FastAPI后端。量化优势绝非仅体现于显存节省：INT4模型在推理时大幅降低DRAM带宽压力，使RTX 40系显卡的24Gbps GDDR6X带宽利用率从92%降至38%，芯片结温下降11℃，风扇转速降低40%，显著延长硬件寿命；同时因权重稀疏性增强，CUDA Core计算单元指令发射效率提升23%（依据Nsight Compute profiler数据）。但必须警惕注意事项：首先，Qwen2.5-7b的INT4版本对数学符号识别、小数点后四位精度运算存在轻微退化，需在金融计算类任务中启用`num_gpu 0`强制CPU fallback；其次，Ollama 0.11暂不支持LoRA适配器热加载，微调后模型须重新量化打包；再者，Windows Defender可能误报GGUF文件为潜在威胁，需手动添加排除目录；最后，当使用`--gpu-layers 35`参数指定GPU卸载层数时，若层数超过模型实际层数（Qwen2.5-7b共32层），Ollama会静默降级为CPU执行，需通过`ollama show qwen2.5:7b-instruct-q4_k_m --modelfile`验证配置有效性。综上，该方案代表了边缘AI时代LLM落地的工业化标准范式——以量化精度换工程可行性，用框架抽象度抵消底层复杂性，最终实现“开箱即用”的智能体部署体验。
微调1.8b模型的运行demo.zip
微调1.8B模型的运行Demo，本质上是面向中小型参数规模大语言模型（Large Language Model, LLM）开展高效、低成本、可复现的监督式指令微调（Supervised Fine-tuning, SFT）与轻量化推理部署的完整技术实践闭环。其中“1.8B”指模型参数量约为18亿（1.8×10⁹），属于典型中等规模开源大模型范畴，常见于如Qwen-1.8B、Phi-3-mini（3.8B向下裁剪变体）、TinyLlama-1.1B扩展版、或经结构压缩后的LLaMA-2-1.8B等架构；该量级模型在性能与资源消耗之间取得显著平衡——既具备基础的上下文理解、多轮对话、代码生成与逻辑推理能力，又可在单张消费级GPU（如RTX 4090/3090，24GB显存）甚至高端笔记本（RTX 4070 Laptop + 16GB VRAM）上完成全参数微调或主流高效微调；同时支持CPU+量化推理，在无GPU环境下以较低延迟响应简单任务，极具教学示范性与工程落地适配性。该Demo的核心技术栈深度耦合现代大模型开发范式：底层基于PyTorch框架构建训练与推理流水线，确保对自动混合精度（AMP）、梯度检查点（Gradient Checkpointing）、分布式数据并行（DDP）等高级特性的原生支持；模型权重托管与加载高度依赖Hugging Face Transformers生态，通过`AutoModelForCausalLM`与`AutoTokenizer`实现一键加载预训练检查点，并兼容HF Hub上的公开1.8B模型（如OpenBMB的MiniCPM系列、IDEA-CCNL的Ziya-1.8B等）；训练策略采用LoRA（Low-Rank Adaptation）作为默认微调范式——即在原始Transformer层的Q/K/V/O投影矩阵旁注入低秩分解矩阵（通常r=8/16，α=16/32，dropout=0.1），冻结全部原始参数，仅训练新增的少量可学习参数（通常20GB降至<6GB），规避灾难性遗忘，且支持模块化热插拔与多任务适配；配套提供完整的训练配置脚本（含`training_args.yaml`）、数据预处理管道（支持Alpaca格式JSONL、ShareGPT对话结构、自定义Instruction-Tuning Dataset）、分词器对齐校验及loss曲线可视化工具。在推理优化层面，Demo集成多项工业级加速技术：首先支持AWQ（Activation-aware Weight Quantization）与GPTQ（Group-wise Quantization）两种主流4-bit权重量化方案，利用`auto-gptq`或`llm-blender`库实现模型体积压缩75%（FP16→INT4）、显存占用下降60%，同时保持<2%的BLEU/ROUGE指标衰减；其次内置vLLM或Text Generation Inference（TGI）服务封装模板，启用PagedAttention内存管理、连续批处理（Continuous Batching）与KV Cache共享机制，将吞吐量提升3–5倍；此外还提供ONNX Runtime导出路径，支持跨平台（Windows/Linux/macOS）CPU推理，并嵌入AVX-512与Intel OpenVINO加速后端；本地部署环节涵盖Docker容器化（含CUDA镜像与CPU精简镜像双版本）、FastAPI/WebUI前后端分离架构（对应`index.html`与`js/`目录下的Vue组件）、RESTful API接口文档（Swagger UI集成于`/docs`路径）、以及基于`README.md`详述的零依赖一键启动脚本（`./run.sh --mode=lora-finetune --data=./data/alpaca_zh.json --quant=awq`）。进一步地，该Demo强调工程鲁棒性与可维护性：`about`与`archives`目录支撑静态站点生成（可能基于Hexo或Hugo），用于技术博客沉淀；`medias/`存放微调过程截图、loss收敛动图、推理时延对比柱状图等可视化资产；`libs/`集成定制化工具包，如动态LoRA适配器热加载器、多阶段学习率调度器（Linear Warmup + Cosine Decay）、对抗样本防御模块（FGSM增强）、以及中文领域专用评估器（C-Eval子集打分、CMMLU准确率计算）；`search.xml`则为站内全文检索提供索引支持。整体设计严格遵循MLOps最佳实践：数据版本控制（DVC集成）、实验追踪（Weights & Biases或MLflow日志埋点）、模型注册（Hugging Face Model Hub自动上传）、CI/CD流水线（GitHub Actions触发训练验证）。尤为关键的是，所有操作均规避闭源依赖，完全基于Apache 2.0/MIT等宽松许可证的开源组件构建，确保企业合规审计可行性与二次开发自由度。这一1.8B微调Demo不仅是技术演示，更是贯通“数据准备→模型选择→高效微调→量化压缩→服务封装→监控运维”全生命周期的微型AI工程教科书，为政务、金融、教育等对数据主权与部署成本敏感的垂直领域提供了可立即迁移的轻量化大模型落地范式。
一小时搭建Ryzen AI本地环境[项目源码]
Ryzen AI是AMD近年来面向边缘AI计算与本地大模型推理场景推出的重要技术生态，其核心依托于Ryzen 7040/8040系列及更新的Strix Halo架构APU（如Ryzen AI 300系列），首次在x86笔记本平台集成专用AI加速单元——XDNA 2架构NPU（Neural Processing Unit），并协同CPU、GPU（RDNA 3架构）构成异构计算三件套。所谓“一小时搭建Ryzen AI本地环境”，并非仅指安装某个软件，而是一整套软硬协同优化的知识体系，涵盖硬件初始化、驱动栈适配、AI运行时环境构建、模型量化部署、内存与带宽协同调度、低延迟推理管线调优等多维度关键技术。首先，硬件准备阶段强调“工厂重置安装”与“BIOS级调优”，这直指Ryzen AI平台特有的统一内存架构（UMA, Unified Memory Architecture）。与传统独立显卡需通过PCIe拷贝数据不同，Ryzen AI的CPU、GPU、NPU共享同一块LPDDR5X系统内存，但该共享需由固件层显式启用。BIOS中“UMA Frame Buffer Size”参数即为此预留显存容量，若设置过小（如默认64MB），将导致ROCm或Vulkan后端无法分配足够显存用于模型权重加载与KV缓存；而设置过大又会挤占系统可用内存，影响CPU侧推理调度。Strix Halo设备尤其需将该值设为2GB或更高，并配合启用Resizable BAR与Above 4G Decoding，确保PCIe地址空间可覆盖全部显存映射区域。PowerShell命令如`Get-WmiObject -Class Win32_VideoController | Select-Object Name, DriverVersion, AdapterRAM`与`dxgiinfo.exe`（需额外下载）联合验证，可确认Vulkan 1.3+与ROCm 5.7+兼容性，这是后续所有AI框架调用GPU/NPU的前提。其次，驱动栈是成败关键。AMD官方驱动已不再简单提供“显卡驱动”，而是整合为Adrenalin Enterprise Edition + ROCm for Windows预览版（目前仍属Beta通道）。必须安装24.5.1或更高版本驱动，因其首次完整支持XDNA 2 NPU的OpenCL/Vulkan扩展（cl_khr_extended_versioning、VK_AMD_buffer_marker等），并内置ROCm Runtime for Windows子系统——它并非Linux版ROCm的移植，而是基于Windows Subsystem for Linux 2（WSL2）深度定制的轻量容器化运行时，通过DirectML桥接层将PyTorch/TensorFlow算子编译为XDNA指令流。若驱动版本过旧，Ollama拉取的qwen2.5:7b模型将因缺少`hipblaslt`库而fallback至纯CPU推理，吞吐骤降至3 tokens/s以下。部署方案中的Ollama与LM Studio代表两种主流范式：Ollama本质是Go语言编写的轻量LLM服务守护进程，其Windows版已内嵌ROCm backend，通过`OLLAMA_HOST=0.0.0.0:11434 OLLAMA_GPU_LAYERS=40`环境变量强制启用GPU offload，将Transformer层中40个block卸载至GPU执行，剩余embedding与lm-head保留在CPU，实现计算负载均衡；而LM Studio则依赖GGUF格式模型的Vulkan后端（llama.cpp Vulkan分支），其Q4_K_M量化方案在保留K-quant分组精度的同时，将权重压缩至原始FP16的1/4大小（约3.8GB），显著降低内存带宽压力——这对UMA架构至关重要，因LPDDR5X带宽虽达80GB/s，但远低于GDDR6的512GB/s，量化可减少75%的数据搬运量。滑块拉满GPU Offload意味着激活全部Vulkan compute queue，启用async pipeline与persistent descriptor sets，避免每token生成都触发CPU-GPU同步等待；上下文窗口设为8192，则需动态分配约1.2GB KV缓存（按float16×2×8192×128×2计算），必须确保UMA Frame Buffer余量充足，否则触发OOM崩溃。避坑指南中“模型加载崩溃”多源于GGUF文件meta section缺失`vocab_type:spm`或`tokenizer.gguf`路径错误，导致llama.cpp tokenizer初始化失败；“Ollama连接拒绝”常因Windows防火墙拦截11434端口，或WSL2网络未启用`netsh interface ipv4 set subinterface "vEthernet (WSL)" mtu=1500 store=persistent`导致TCP握手超时。实战测试斐波那契递归函数不仅验证逻辑正确性，更通过Python `time.perf_counter()`精确测量首字延迟（Time to First Token, TTFT）与持续吞吐（tokens/s），前者反映KV缓存预热与CUDA Graph构建效率，后者体现Vulkan command buffer复用率与memory coalescing效果。实测40+ tokens/s需满足：GPU利用率>85%（Task Manager GPU引擎显示Compute_0满载）、内存带宽占用60%（通过`amd-smi -a`查看XDNA域），三者缺一则性能断崖下跌。此环境已超越传统笔记本CPU推理能力两个数量级，真正实现“私有AI工作站”定位——所有数据不出本地、无API调用费用、无隐私泄露风险、支持离线调试与模型微调，是AI平民化落地的关键基础设施。
终端LLM AI模型:mlc-llm
MLC LLM（Machine Learning Compilation for Large Language Models）是一个面向终端设备与边缘场景深度优化的开源大语言模型（LLM）部署框架，其核心使命是打破传统AI模型对云端算力、高带宽网络和集中式服务的依赖，真正实现“模型即应用”（Model-as-App）的终端AI范式。它并非一个预训练好的语言模型（如Llama、Phi、Qwen等），而是一套完整的端到端编译—优化—部署工具链，专为在资源受限但形态多样的终端硬件上高效运行大语言模型而设计。从智能手机、笔记本电脑、嵌入式开发板（如Raspberry Pi、Jetson系列），到Windows/macOS/Linux桌面系统，乃至Web浏览器（通过WebGPU/WASM后端），MLC LLM均能提供统一抽象层下的高性能推理支持。其技术架构建立在深度学习编译器（Deep Learning Compiler）理念之上，深度融合了TVM（Tensor Virtual Machine）的自动调度与代码生成能力，并针对LLM特有的计算模式（如KV缓存动态管理、自回归解码中的序列长度增长、注意力机制的稀疏性与内存局部性挑战）进行了系统级重构。MLC LLM引入了“模型级编译”（Model-Level Compilation）概念：用户只需提供Hugging Face格式的PyTorch模型（含配置文件config.json、分片权重bin/safetensors文件），框架即可自动完成图级优化（Graph Optimization）、算子融合（Operator Fusion）、内存规划（Memory Planning）、量化感知编译（Quantization-Aware Compilation，支持INT4/INT8混合精度）、以及针对目标硬件后端（如CUDA、Metal、Vulkan、OpenCL、WebGPU、x86 AVX-512、ARM NEON）的专用内核生成。尤为关键的是，MLC LLM实现了零Python依赖的纯原生推理运行时——编译后的模型以独立可执行文件或轻量级库（如libmlc_llm.dylib / .so / .dll）形式存在，不需Python解释器、不依赖PyTorch/TensorFlow等大型框架，极大降低部署门槛与攻击面，满足工业控制、车载系统、医疗设备等对确定性、安全性和实时性有严苛要求的场景。在本地部署维度，MLC LLM彻底重构了传统“下载→加载→推理”的流程。它支持模型权重的按需分块加载（Chunked Loading）与内存映射（Memory-Mapped I/O），使13B甚至34B级别模型可在仅16GB RAM的MacBook Pro上流畅运行；内置的KV缓存压缩算法（如PagedAttention思想的轻量化实现）显著降低长上下文（>32K tokens）推理时的显存/内存占用；同时提供细粒度的硬件资源控制接口（如GPU显存上限设定、CPU线程数绑定、温度/功耗策略配置），确保多任务共存环境下的稳定性。在模型优化层面，MLC LLM不仅支持静态量化（Post-Training Quantization），更创新性地集成量化校准数据自动生成、非对称量化误差补偿、以及针对不同硬件单元（如NPU、GPU Tensor Core）定制的量化策略模板，使INT4模型在保持95%+原始精度的同时，推理吞吐提升3–5倍，模型体积压缩达75%以上。作为边缘计算与设备端AI的关键基础设施，MLC LLM强调“隐私优先”与“离线自治”：所有文本生成、指令微调（通过内置LoRA适配器支持）、甚至轻量级持续学习（Continual Learning）均在设备本地完成，原始输入与中间激活值永不离开用户设备。其开源协议（Apache 2.0）允许企业进行深度定制与合规审计，已广泛应用于智能办公助手（本地文档摘要与问答）、离线编程辅助（Code LLM本地化）、IoT语音交互引擎、以及军事/金融等高敏领域的可信AI终端。此外，“mlc-llm-main”压缩包所代表的主仓库，不仅包含核心编译器与运行时，还集成了模型动物园（Model Zoo）的自动化转换脚本、跨平台构建系统（CMake+Ninja）、性能分析器（Profile Viewer）、Web UI调试面板（基于React+WebGPU）、以及详尽的硬件适配指南（含Apple Silicon Metal优化白皮书、Android NDK交叉编译手册、Windows DirectML后端开发文档）。这使其超越单一工具定位，成长为连接AI研究者、硬件厂商、应用开发者与终端用户的全栈式终端大模型操作系统（Terminal LLM OS），标志着人工智能正从“云智能”不可逆地迈向“人人可握、处处可运、时时可用”的普惠智能新纪元。
Ubuntu 本地部署Ollama+OpenWebUI教程
本文将教大家在Ubuntu系统中，从零完成Ollama本地大模型部署与Open-WebUI可视化网页配置，全程采用虚拟环境隔离依赖、配置系统自启服务，最终搭建可远程访问的本地AI交互网页，无需联网调用、运行稳定、适配CPU及GPU本地部署场景，新手可直接复刻操作。 环境适配要求 Python 3.11~3.12（本次使用3.11版本），全程使用虚拟环境隔离依赖，不污染系统原生Python环境；支持CPU模式运行，无NVIDIA/AMD显卡也可正常部署使用，如果用户配置了NVIDIA驱动则该框架会自动识别无需手动配置。 1、执行官方一键安装脚本，自动完成Ollama安装、用户创建、系统服务配置。 root@localhost:~# curl -fsSL https://ollama.com/install.sh | sh >>> Installing ollama to /usr/local >>> Downloading ollama-linux-amd64.tar.zst >>> Creating ollama user... >>> Adding ollama user to render group... >>> Adding ollama user to video group... >>> Adding current user to ollama group... >>> Creating ollama systemd service... >>> Enabling and starting ollama service... >>> The Ollama API is now available at 127.0.0.1:11434. >>> Install complete. Run "ollama" from the command line. WARNING: No NVIDIA/AMD GPU detected. Ollama will run in CPU-only mode root@localhost:~# root@localhost:~# systemctl start ollama root@localhost:~# systemctl status ollama ● ollama.service - Ollama Service Loaded: loaded (/etc/systemd/system/ollama.service; enabled; preset: enabled) Active: active (running) since Sat 2026-09-05 08:41:57 CST; 1min 43s ago Invocation: 716248d942fd46c0a50a02b03bdce7fb Main PID: 2160 (ollama) Tasks: 7 (limit: 608) Memory: 75.4M (peak: 83.9M) CPU: 364ms CGroup: /system.slice/ollama.service └─2160 /usr/local/bin/ollama serve 2、Ollama支持一键拉取各类开源模型，本次选择轻量化高性能的qwen3.5:0.8b模型，体积仅1.0GB，适配本地CPU部署，兼顾推理速度与对话效果。 下载模型：https://ollama.com/library/qwen3.5:0.8b root@localhost:~# ollama pull qwen3.5:0.8b pulling manifest pulling afb707b6b8fa: 100% ▕██████████████ ▏ 1.0 GB/1.0 GB 7.7 MB/s 0s verifying sha256 digest writing manifest success root@localhost:~# ollama list NAME ID SIZE MODIFIED qwen3.5:0.8b f3817196d142 1.0 GB About a minute ago 3、Open-WebUI对Python版本有严格要求，仅支持3.11-3.12版本，为避免与系统Python冲突，采用独立虚拟环境安装部署。 root@localhost:~# apt update root@localhost:~# apt install software-properties-common -y root@localhost:~# add-apt-repository ppa:deadsnakes/ppa -y root@localhost:~# apt update # 安装Python环境 root@localhost:~# apt install python3.11 python3.11-venv python3.11-dev -y # 创建隔离环境 root@localhost:~# python3.11 -m venv ~/env/openwebui # 激活虚拟环境 root@localhost:~# source ~/env/openwebui/bin/activate # 指定临时目录到硬盘 不要用内存安装PIP包 root@localhost:~# export TMPDIR=/root/env/openwebui root@localhost:~# export TEMP=/root/env/openwebui root@localhost:~# export TMP=/root/env/openwebui # 开始安装 root@localhost:~# pip install -i https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple open-webui (openwebui) root@localhost:~# pip list Package Version ---------------------------------------- ----------- accelerate 1.13.0 aiocache 0.12.3 aiodns 3.6.1 aiofiles 25.1.0 aiohappyeyeballs 2.7.1 aiohttp 3.13.5 aiosignal 1.4.0 aiosqlite 0.22.1 alembic 1.18.4 annotated-doc 0.0.5 annotated-types 0.8.0 anthropic 0.86.0 antlr4-python3-runtime 4.9.3 anyio 4.15.0 APScheduler 3.11.2 argon2-cffi 25.1.0 argon2-cffi-bindings 26.1.0 asgiref 3.11.1 async-timeout 5.0.1 attrs 26.1.0 Authlib 1.7.2 av 18.1.0 azure-ai-documentintelligence 1.0.2 azure-core 1.41.0 azure-identity 1.25.3 azure-storage-blob 12.29.0 bcrypt 5.0.0 beautifulsoup4 4.14.3 bidict 0.24.1 black 26.5.1 boto3 1.42.62 botocore 1.42.97 brotli 1.2.0 brotlicffi 1.2.0.1 build 1.6.0 certifi 2026.7.22 cffi 2.1.1 chardet 7.4.3 charset-normalizer 3.5.1 chromadb 1.5.9 click 8.5.0 cloudpickle 3.1.2 colorlog 6.12.0 cryptography 48.0.0 ctranslate2 4.8.2 cuda-bindings 13.3.1 cuda-pathfinder 1.8.1 cuda-toolkit 13.0.3.0 ddgs 9.14.4 defusedxml 0.7.1 distro 1.9.0 docstring_parser 0.18.0 docx2txt 0.9 durationpy 0.11 einops 0.8.2 et_xmlfile 2.0.0 Events 0.5 fake-useragent 2.2.0 fastapi 0.136.3 faster-whisper 1.2.1 filelock 3.32.5 flatbuffers 25.12.19 fonttools 4.64.0 fpdf2 2.8.7 frozenlist 1.8.0 fsspec 2026.7.0 ftfy 6.3.1 google-api-core 2.34.0 google-api-python-client 2.197.0 google-auth 2.57.0 google-auth-httplib2 0.4.0 google-auth-oauthlib 1.4.0 google-cloud-core 2.7.0 google-cloud-storage 3.9.0 google-crc32c 1.8.0 google-genai 1.66.0 google-resumable-media 2.10.2 googleapis-common-protos 1.75.0 greenlet 3.5.5 grpcio 1.83.1 h11 0.16.0 h2 4.4.1 hf-xet 1.6.0 hiredis 3.4.0 hpack 4.2.0 httpcore 1.0.9 httpcore2 2.12.0 httplib2 0.32.0 httptools 0.8.0 httpx 0.28.1 httpx-sse 0.4.3 httpx2 2.12.0 huggingface_hub 1.30.0 hyperframe 6.1.0 idna 3.19 importlib_resources 7.1.0 isodate 0.7.2 itsdangerous 2.2.0 Jinja2 3.1.6 jiter 0.16.0 jmespath 1.1.0 joblib 1.6.0 joserfc 1.7.4 jsonpatch 1.33 jsonpointer 3.1.1 jsonschema 4.26.0 jsonschema-specifications 2025.9.1 kubernetes 36.0.3 langchain 1.2.10 langchain-classic 1.0.7 langchain-community 0.4.2 langchain-core 1.6.1 langchain-protocol 0.0.19 langchain-text-splitters 1.1.2 langgraph 1.0.10 langgraph-checkpoint 4.2.0 langgraph-prebuilt 1.0.13 langgraph-sdk 0.3.15 langsmith 0.12.1 ldap3 2.9.1 loguru 0.7.3 lxml 6.1.1 Mako 1.4.1 Markdown 3.10.2 markdown-it-py 4.2.0 MarkupSafe 3.0.3 mcp 1.27.2 mdurl 0.1.2 mmh3 5.3.0 mpmath 1.3.0 msal 1.38.0 msal-extensions 1.3.1 msoffcrypto-tool 6.0.0 multidict 6.7.1 mypy_extensions 1.1.0 narwhals 2.25.0 networkx 3.6.1 nltk 3.9.4 numpy 2.4.6 nvidia-cublas 13.1.1.3 nvidia-cuda-cupti 13.0.85 nvidia-cuda-nvrtc 13.0.88 nvidia-cuda-runtime 13.0.96 nvidia-cudnn-cu13 9.24.0.43 nvidia-cufft 12.0.0.61 nvidia-cufile 1.15.1.6 nvidia-curand 10.4.0.35 nvidia-cusolver 12.0.4.66 nvidia-cusparse 12.6.3.3 nvidia-cusparselt-cu13 0.8.1 nvidia-nccl-cu13 2.30.7 nvidia-nvjitlink 13.3.33 nvidia-nvshmem-cu13 3.4.5 nvidia-nvtx 13.0.85 oauthlib 3.3.1 olefile 0.47 omegaconf 2.3.1 onnxruntime 1.26.0 open-webui 0.11.3 openai 2.29.0 opencv-python 5.0.0.93 opencv-python-headless 4.13.0.92 openpyxl 3.1.5 opensearch-protobufs 1.2.0 opensearch-py 3.2.0 opentelemetry-api 1.44.0 opentelemetry-exporter-otlp-proto-common 1.44.0 opentelemetry-exporter-otlp-proto-grpc 1.44.0 opentelemetry-proto 1.44.0 opentelemetry-sdk 1.44.0 opentelemetry-semantic-conventions 0.65b0 orjson 3.11.9 ormsgpack 1.12.2 overrides 7.7.0 packaging 26.3 pandas 3.0.3 pathspec 1.1.1 pillow 12.2.0 pip 24.0 platformdirs 4.11.7 primp 2.0.0 propcache 0.5.2 proto-plus 1.28.4 protobuf 7.36.1 psutil 7.2.2 psycopg 3.3.4 psycopg-binary 3.3.4 pyarrow 20.0.0 pyasn1 0.6.4 pyasn1_modules 0.4.2 pybase64 1.5.0 pycares 4.11.0 pyclipper 1.4.0 pycparser 3.0 pycrdt 0.13.1 pydantic 2.13.4 pydantic_core 2.46.4 pydantic-settings 2.15.0 pydub 0.25.1 Pygments 2.21.0 PyJWT 2.13.0 pymdown-extensions 10.21.3 PyMySQL 1.2.0 pypandoc 1.17 pyparsing 3.3.2 pypdf 6.7.5 PyPika 0.51.1 pyproject_hooks 1.2.0 python-dateutil 2.9.0.post0 python-docx 1.2.0 python-dotenv 1.2.3 python-engineio 4.14.0 python-mimeparse 2.0.0 python-multipart 0.0.32 python-pptx 1.0.2 python-socketio 5.16.2 pytokens 0.4.1 pytube 15.0.0 pytz 2026.2 pyxlsb 1.0.10 PyYAML 6.0.3 rank-bm25 0.2.2 rapidocr 3.9.2 redis 8.0.1 referencing 0.37.0 regex 2026.5.9 requests 2.34.2 requests-oauthlib 2.0.0 requests-toolbelt 1.0.0 RestrictedPython 8.2 rich 13.9.4 rpds-py 2026.6.3 s3transfer 0.16.1 safetensors 0.8.0 scikit-learn 1.9.0 scipy 1.17.1 sentence-transformers 5.5.1 sentencepiece 0.2.1 setuptools 79.0.1 shapely 2.1.2 shellingham 1.5.4 simple-websocket 1.1.0 six 1.17.0 sniffio 1.3.1 socksio 1.0.0 soundfile 0.13.1 soupsieve 2.9.2 SQLAlchemy 2.0.50 sse-starlette 3.4.10 starlette 1.6.0 starlette-compress 1.7.1 starsessions 2.2.1 sympy 1.14.0 tenacity 9.1.4 threadpoolctl 3.6.0 tiktoken 0.13.0 tokenizers 0.22.2 torch 2.14.0 tqdm 4.70.0 transformers 5.5.4 triton 3.8.0 truststore 0.10.4 typer 0.27.2 typing_extensions 4.16.0 typing-inspection 0.4.4 tzlocal 5.4.4 uritemplate 4.2.0 urllib3 2.7.0 uuid_utils 0.17.0 uvicorn 0.51.0 uvloop 0.22.1 validators 0.35.0 watchfiles 1.2.0 wcwidth 0.8.3 websocket-client 1.9.2 websockets 16.1.1 wsproto 1.3.2 xlrd 2.0.2 xlsxwriter 3.2.9 xxhash 4.0.1 yarl 1.24.5 youtube-transcript-api 1.2.4 zstandard 0.25.0 # 清理旧缓存 root@localhost:~# pip cache purge # 设置离线环境 避免Open-WebUI启动时自动进行模型下载 root@localhost:~# export HF_HUB_OFFLINE=1 root@localhost:~# export OFFLINE_MODE=true # 启动页面 root@localhost:~# open-webui serve 4、为解决终端关闭后网页服务中断问题，配置系统常驻服务，实现开机自启、异常自动重启。 root@localhost:~# cat > /etc/systemd/system/open-webui.service <<'EOF' [Unit] Description=Open‑WebUI Service After=network.target ollama.service [Service] Type=simple User=root ExecStart=/root/env/openwebui/bin/open-webui serve --port 3080 Restart=on-failure RestartSec=5 Environment="OLLAMA_BASE_URL=http://127.0.0.1:11434" Environment="HF_HUB_OFFLINE=1" Environment="OFFLINE_MODE=true" [Install] WantedBy=multi-user.target EOF 5、重载服务并设置开机自启。 root@localhost:~# systemctl daemon-reload root@localhost:~# systemctl enable --now open-webui root@localhost:~# systemctl status open-webui root@localhost:~# systemctl status open-webui ● open-webui.service - Open‑WebUI Service Loaded: loaded (/etc/systemd/system/open-webui.service; enabled; preset: enabled) Active: active (running) since Sat 2026-09-05 09:28:33 CST; 6s ago Invocation: 02b730a8ce8a47ab9017b87183ecf815 Main PID: 1870 (open-webui) Tasks: 2 (limit: 608) Memory: 315M (peak: 315M) CPU: 4.055s CGroup: /system.slice/open-webui.service 服务部署完成后，直接通过服务器公网IP访问可视化页面：http://chat.lyshark.com:3080/ 首次访问需设置管理员用户名和密码，完成初始化后，即可进入网页后台，选择本地部署的qwen3.5:0.8b模型，实现可视化AI对话、参数调节、模型管理等功能。
轻量化小模型MiniMind从训练到落地指南
本文基于 Ubuntu 22.04 服务器环境，依托 NVIDIA RTX 家用高性能显卡，手把手讲解 MiniMind 轻量大语言模型从零搭建、数据集部署、全流程训练、可视化Web服务搭建及GGUF格式量化的完整实操方案。全程摒弃复杂高阶封装，基于原生 PyTorch 实现，适配个人开发者、人工智能入门学习者低成本完成大模型训练全链路的需求，整套方案仅需极低算力与成本，3小时即可完成基础对话训练，完美适配新手入门大模型训练、模型私有化部署、及底层原理学习等场景，是一套低成本、可落地、可复现全流程实战教程。 MiniMind 是一款纯原生 PyTorch 从零手写实现的 Decoder‑Only Transformer 开源大模型项目，主打 26M–200M 小参数量轻量化设计，支持消费级单卡完成预训练、SFT 监督微调、LoRA 轻量化微调、DPO/GRPO 偏好对齐、模型蒸馏等大模型完整训练链路，全程无黑盒依赖，是兼顾学习落地与轻量化部署的极简 LLM 方案。 该项目采用当前主流 LLM 统一的纯解码器（Decoder‑Only）自回归架构，与 GPT、Llama、Qwen 模型范式完全一致，核心任务是基于上文语境预测下一个 token，实现连贯文本生成与对话交互。 模型完整前向数据流清晰规整：输入 token_id → 词嵌入 Embedding 层 → 多层堆叠 Transformer Block → 最终归一化 → LM 头输出词表概率 logits 在开展MiniMind模型训练、微调与部署实操前，需提前配置好服务器软硬件运行环境，本文所有实操流程均基于以下稳定运行的本机环境，读者可直接参考对齐配置，适配复现： 操作系统：Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-187-generic x86_64)框架版本：torch 2.13.0 + CUDA 12.8.1 + Python 3.10.12显卡驱动：NVIDIA ≥ 570.133.07显卡类型：NVIDIA RTX 4090 24GB GPUCPU核心：INTEL(R) XEON(R) GOLD 6530 双路 64核 128线程内存：64GB DDR5存储：50GB(系统盘)+100GB(数据盘) 为确保CUDA加速、显卡驱动正常生效，可通过以下命令核查环境状态，本文实测有效查询结果如下，可用于环境校验排错： # 检查系统及驱动信息 root@localhost:~# cat /proc/driver/nvidia/version NVRM version: NVIDIA UNIX Open Kernel Module for x86_64 570.133.07 Release Build (dvs-builder@U22-I3-G01-1-1) Fri Mar 14 12:57:14 UTC 2025 GCC version: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) # 检查NVIDIA CUDA版本信息 root@localhost:~# export PATH=/usr/local/cuda-12.8/bin:$PATH root@localhost:~# export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH root@localhost:~# nvcc -V nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2025 NVIDIA Corporation Built on Fri_Feb_21_20:23:50_PST_2025 Cuda compilation tools, release 12.8, V12.8.93 Build cuda_12.8.r12.8/compiler.35583870_0 # 输出详细显卡信息 root@localhost:~# nvidia-smi --query-gpu=driver_version --format=csv,noheader 570.133.07 root@localhost:~# nvidia-smi Fri Aug 28 12:01:45 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 570.133.07 Driver Version: 570.133.07 CUDA Version: 12.8 | |-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA GeForce RTX 4090 On | 00000000:C1:00.0 Off | Off | | 64% 40C P8 33W / 420W | 0MiB / 24564MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | No running processes found | +-----------------------------------------------------------------------------------------+ 初始化配置 本章节为 MiniMind‑3 从零训练前置环境部署，基于 Ubuntu22.04 (jammy)，依次完成系统源替换、虚拟内存、Python 虚拟环境、项目代码拉取、依赖安装、数据集下载；全部操作以 root 执行。 官方源国内访问速度慢，更换为阿里云镜像源（也可替换为清华源、腾讯源），先备份原有源文件，再写入阿里云源配置，最后更新软件包索引。 root@localhost:~/# sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak root@localhost:~/# root@localhost:~/# sudo tee /etc/apt/sources.list > /dev/null <<'EOF' deb http://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse EOF root@localhost:~/# root@localhost:~/# sudo apt update && apt upgrade -y Reading package lists... Done Building dependency tree... Done Reading state information... Done 大模型训练会消耗大量内存，物理内存不足容易触发 OOM 内存溢出。这里配置 8GB 永久虚拟内存，重启服务器依然生效；物理内存充足可以跳过本步骤。 root@localhost:~/# sudo fallocate -l 8G /swapfile root@localhost:~/# sudo chmod 600 /swapfile root@localhost:~/# sudo mkswap /swapfile root@localhost:~/# sudo swapon /swapfile root@localhost:~/# echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab 安装虚拟Python环境，新版Ubuntu系统默认禁止直接向系统 Python 安装第三方包，使用虚拟环境隔离项目依赖，避免和系统 Python 包冲突。 root@localhost:~/# sudo apt install -y python3-full python3-venv tmux git tree root@localhost:~/# sudo python3 -m venv ~/myvenv root@localhost:~/# source ~/myvenv/bin/activate 从官方仓库拉取 MiniMind 项目代码，此处由于 Github 国内网络访问不稳定，使用 Gitee 镜像仓库；安装顺序必须先装 torch，再安装 requirements.txt，防止 requirements 自动拉取新版本 torch，和本机 CUDA 版本不匹配。 # 克隆官方仓库文件 root@localhost:~/# sudo git clone --depth 1 https://gitee.com/lyshark/minimind.git Cloning into 'minimind'... remote: Enumerating objects: 55, done. remote: Counting objects: 100% (55/55), done. remote: Compressing objects: 100% (51/51), done. remote: Total 55 (delta 4), reused 52 (delta 3), pack-reused 0 (from 0) Receiving objects: 100% (55/55), 10.28 MiB | 3.18 MiB/s, done. Resolving deltas: 100% (4/4), done. # 先安装torch以及torchvision库 root@localhost:~/# sudo pip3 install -i https://mirrors.cloud.tencent.com/pypi/simple/ torch==2.6.0 torchvision==0.21.0 # 验证CUDA是否生效 root@localhost:~# python3 Python 3.10.12 (main, Aug 15 2025, 14:32:43) [GCC 11.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> >>> import torch >>> print(torch.__version__) 2.6.0+cu124 >>> print(torch.cuda.is_available()) True >>> print(torch.version.cuda) 12.4 # 再安装minimind包 root@localhost:~/# cd minimind root@localhost:~/minimind# sudo pip3 install -r requirements.txt -i https://mirrors.cloud.tencent.com/pypi/simple/ root@localhost:~/minimind# root@localhost:~/minimind# pip list ------------------------- -------------- Package Version ------------------------- -------------- accelerate 1.14.0 aiohappyeyeballs 2.7.1 aiohttp 3.14.3 aiosignal 1.4.0 altair 5.5.0 annotated-types 0.8.0 anyio 4.10.0 argon2-cffi 25.1.0 argon2-cffi-bindings 25.1.0 arrow 1.3.0 asttokens 3.0.0 async-lru 2.0.5 async-timeout 5.0.1 attrs 25.3.0 babel 2.17.0 beautifulsoup4 4.13.5 bleach 6.2.0 blinker 1.9.0 cachetools 6.2.6 certifi 2025.8.3 cffi 1.17.1 charset-normalizer 3.4.3 click 8.5.0 comm 0.2.3 datasets 3.6.0 datasketch 1.6.4 dbus-python 1.2.18 debugpy 1.8.16 decorator 5.2.1 defusedxml 0.7.1 dill 0.3.8 distro 1.7.0 docker-pycreds 0.4.0 einops 0.8.1 exceptiongroup 1.3.0 executing 2.2.0 fastjsonschema 2.21.2 filelock 3.32.4 Flask 3.0.3 Flask-Cors 4.0.0 fqdn 1.5.1 frozenlist 1.8.0 fsspec 2025.3.0 gitdb 4.0.12 GitPython 3.1.61 h11 0.16.0 hf-xet 1.6.0 httpcore 1.0.9 httpx 0.28.1 huggingface_hub 0.36.2 idna 3.10 ipykernel 6.30.1 ipython 8.37.0 isoduration 20.11.0 itsdangerous 2.2.0 jedi 0.19.2 jieba 0.42.1 Jinja2 3.1.2 jiter 0.16.0 joblib 1.5.3 json5 0.12.1 jsonlines 4.0.0 jsonpointer 3.0.0 jsonschema 4.25.1 jsonschema-specifications 2025.4.1 jupyter_client 8.6.3 jupyter_core 5.8.1 jupyter-events 0.12.0 jupyter-lsp 2.2.6 jupyter_server 2.17.0 jupyter_server_terminals 0.5.3 jupyterlab 4.4.6 jupyterlab_pygments 0.3.0 jupyterlab_server 2.27.3 lark 1.2.2 markdown-it-py 4.2.0 MarkupSafe 3.0.2 marshmallow 3.22.0 matplotlib-inline 0.1.7 mdurl 0.1.2 mistune 3.1.3 modelscope 1.37.0 mpmath 1.3.0 multidict 6.7.1 multiprocess 0.70.16 narwhals 2.25.0 nbclient 0.10.2 nbconvert 7.16.6 nbformat 5.10.4 nest-asyncio 1.6.0 networkx 3.4.2 ngrok 1.4.0 nltk 3.8 notebook_shim 0.2.4 numpy 1.26.4 nvidia-cublas-cu12 12.4.5.8 nvidia-cuda-cupti-cu12 12.4.127 nvidia-cuda-nvrtc-cu12 12.4.127 nvidia-cuda-runtime-cu12 12.4.127 nvidia-cudnn-cu12 9.1.0.70 nvidia-cufft-cu12 11.2.1.3 nvidia-curand-cu12 10.3.5.147 nvidia-cusolver-cu12 11.6.1.9 nvidia-cusparse-cu12 12.3.1.170 nvidia-cusparselt-cu12 0.6.2 nvidia-ml-py 13.610.43 nvidia-nccl-cu12 2.21.5 nvidia-nvjitlink-cu12 12.4.127 nvidia-nvtx-cu12 12.4.127 openai 1.59.6 overrides 7.7.0 packaging 25.0 pandas 2.3.3 pandocfilters 1.5.1 parso 0.8.5 pexpect 4.9.0 pillow 11.3.0 pip 22.0.2 platformdirs 4.3.8 prettytable 3.18.0 prometheus_client 0.22.1 prompt_toolkit 3.0.51 propcache 0.5.2 protobuf 5.29.6 psutil 5.9.8 ptyprocess 0.7.0 pure_eval 0.2.3 pyarrow 25.0.1 pycparser 2.22 pydantic 2.11.5 pydantic_core 2.33.2 pydeck 0.9.3 pyecharts 2.1.0 Pygments 2.19.2 PyGObject 3.42.1 python-dateutil 2.9.0.post0 python-json-logger 3.3.0 pytz 2026.3.post1 PyYAML 6.0.2 pyzmq 27.0.2 referencing 0.36.2 regex 2026.7.19 requests 2.32.5 rfc3339-validator 0.1.4 rfc3986-validator 0.1.1 rfc3987-syntax 1.1.0 rich 13.7.1 rpds-py 0.27.0 safetensors 0.8.0 scikit-learn 1.5.1 scipy 1.15.3 Send2Trash 1.8.3 sentence-transformers 2.3.1 sentencepiece 0.2.2 sentry-sdk 2.68.1 setproctitle 1.3.7 setuptools 59.6.0 simhash 2.1.2 simplejson 4.1.2 six 1.17.0 smmap 5.0.3 sniffio 1.3.1 soupsieve 2.7 ssh-import-id 5.11 stack-data 0.6.3 streamlit 1.50.0 swanlab 0.7.11 sympy 1.13.1 tenacity 9.1.4 terminado 0.18.1 threadpoolctl 3.6.0 tiktoken 0.10.0 tinycss2 1.4.0 tokenizers 0.22.2 toml 0.10.2 tomli 2.2.1 torch 2.6.0 torchvision 0.21.0 tornado 6.5.2 tqdm 4.70.0 traitlets 5.14.3 transformers 4.57.6 triton 3.2.0 trl 0.13.0 types-python-dateutil 2.9.0.20250822 typing_extensions 4.16.0 typing-inspection 0.4.4 tzdata 2026.3 ujson 5.1.0 uri-template 1.3.0 urllib3 2.5.0 wandb 0.18.3 watchdog 6.0.0 wcwidth 0.8.2 webcolors 24.11.1 webencodings 0.5.1 websocket-client 1.8.0 Werkzeug 3.1.8 wheel 0.37.1 wrapt 2.3.0 xxhash 4.0.1 yarl 1.24.5 5、进入dataset文件夹下载 jsonl 格式数据集，这里如果只是要简单的看到对话模型，默认仅需下载 pretrain_t2t_mini.jsonl 与 sft_t2t_mini.jsonl，这两个数据集就够，就可以较快复现 MiniMind Zero 对话模型，此处如果要跑完整链路（DPO、RLAIF、Agent 工具强化学习），可以依次将下方的六个文件全部下载。 数据集大小用途pretrain_t2t_mini.jsonl1.2GB轻量预训练，基础语言学习sft_t2t_mini.jsonl1.6GB监督微调 SFT，训练基础对话模型dpo.jsonl53MBDPO 偏好优化训练数据集rlaif.jsonl24MBAI 反馈强化学习（PPO/GRPO/CISPO）数据集agent_rl.jsonl86MBAgent 多轮工具调用强化学习主数据集agent_rl_math.jsonl18MBAgent 数学推理任务补充数据集 如下部分则为实际下载后的文件数量以及对应目录结构 root@localhost:~/minimind# cd dataset/ root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/pretrain_t2t_mini.jsonl root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/sft_t2t_mini.jsonl root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/dpo.jsonl root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/rlaif.jsonl root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/agent_rl.jsonl root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/agent_rl_math.jsonl root@localhost:~/minimind/dataset# ls -lh total 3084080 drwxr-xr-x 2 root root 4096 Aug 28 00:08 ./ drwxr-xr-x 8 root root 4096 Aug 27 23:55 ../ -rw-r--r-- 1 root root 0 Aug 27 23:55 __init__.py -rw-r--r-- 1 root root 82036930 Jun 27 02:30 agent_rl.jsonl -rw-r--r-- 1 root root 18372683 Mar 31 15:28 agent_rl_math.jsonl -rwxr-xr-x 1 root root 141 Aug 27 23:55 dataset.md -rw-r--r-- 1 root root 53653322 Feb 27 22:25 dpo.jsonl -rw-r--r-- 1 root root 11180 Aug 27 23:55 lm_dataset.py -rw-r--r-- 1 root root 1241043656 May 24 20:47 pretrain_t2t_mini.jsonl -rw-r--r-- 1 root root 23754740 Mar 23 20:42 rlaif.jsonl -rw-r--r-- 1 root root 1739201170 May 23 14:21 sft_t2t_mini.jsonl root@localhost:~/minimind# tree . |-- dataset | |-- __init__.py | |-- agent_rl_math.jsonl | |-- dataset.md | |-- dpo.jsonl | |-- lm_dataset.py | |-- pretrain_t2t_mini.jsonl | |-- rlaif.jsonl | `-- sft_t2t_mini.jsonl |-- eval_llm.py |-- model | |-- __init__.py | |-- model_lora.py | |-- model_minimind.py | |-- tokenizer.json | `-- tokenizer_config.json |-- scripts | |-- chat_api.py | |-- convert_model.py | |-- eval_toolcall.py | |-- serve_openai_api.py | `-- web_demo.py `-- trainer |-- rollout_engine.py |-- train_agent.py |-- train_distillation.py |-- train_dpo.py |-- train_full_sft.py |-- train_grpo.py |-- train_lora.py |-- train_ppo.py |-- train_pretrain.py |-- train_tokenizer.py `-- trainer_utils.py 4 directories, 30 files 分词(Tokenizer) 大模型神经网络仅能够接收数字张量输入，它看不懂汉字或标点符号等自然语言，分词器的核心作用是将单词从自然语言通过"词典"映射到0, 1, 36这样的数字上面。它是独立于模型网络的核心前置组件，可通俗理解为LLM的专属词典，支持文本与Token ID双向转换。 核心完成两项工作： 将连续文本切分为子词/字Token单元通过内置词典查表，将每个Token映射为唯一整数ID（词典页码） 以文本“秦始皇是中国第一位皇帝”为例，先通过分词器切分得到Token列表，再映射为整数ID序列 [123,45,678,90,111]；基于自回归任务规则，拆分出模型输入序列 X=[123,45,678,90]、预测目标序列 Y=[45,678,90,111]。 原始文本："秦始皇是中国第一位皇帝" 分词token：["秦始皇", "是", "中国", "第一位", "皇帝"] 转为id：[123,45,678,90,111] X = [123,45,678,90] Y = [45,678,90,111] 其中 X、Y 是真正输入模型、用于计算交叉熵（CrossEntropy）损失的张量。模型训练过程为：根据前文Token ID预测下一ID，对比预测结果与真实Y值计算损失，通过反向传播更新模型权重。模型不会理解文字含义，仅学习Token ID之间的统计概率规律，例如“123（秦始皇）后大概率衔接45（是）”的文本关联模式，其赌的就是语义组合概率的大小，概率大就是准确回答，概率小就是胡言乱语。 MiniMind 预训练任务是自回归语言建模（词语接龙），通过输入token序列X，目标Y就是X向右偏移一位，模型根据前面的token预测下一个token来得到结果。 项目中也提供了train_tokenizer.py作为词表训练示例。不过作者也不建议重新训练 tokenizer，因为词表和切分规则一旦变化，模型权重、数据格式、推理接口与社区生态的兼容性都会下降，也会削弱模型的传播性，对这类小模型来说保持词表精简通常是更合适的取舍。 主流开源模型分词器词表规格对比如下： Tokenizer模型词表大小来源yi tokenizer64,00001万物（中国）qwen2 tokenizer151,643阿里云（中国）glm tokenizer151,329智谱AI（中国）mistral tokenizer32,000Mistral AI（法国）llama3 tokenizer128,000Meta（美国）minimind tokenizer6,400自定义 尽管 minimind_tokenizer 的词表只有 6400，编解码效率弱于 qwen2、glm 等更偏中文友好的 tokenizer，但它能显著压缩 embedding 层和输出层的参数占比，更适合 MiniMind 这类小模型的体积约束。从实际使用效果看，这套 tokenizer 并没有明显带来生僻词解码失败的问题，整体仍然足够稳定可用。 分词器文档在/model目录下存放，其输出文件清单如下所示 tokenizer.json：BPE分词模型本体，存储词表、BPE合并规则、特殊Token，由 tokenizer.save() 生成merges.txt：BPE算法核心合并规则与合并对，由 tokenizer.model.save() 导出vocab.json：词表映射文件，实现Token字符串与ID的双向对应，由 tokenizer.model.save() 导出tokenizer_config.json：手动构造的Huggingface读取配置文件，包含bos/eos/pad/unk特殊Token、对话模板等，是 AutoTokenizer.from_pretrained() 加载的必需文件 最后总结说明，分词器是独立于模型网络的固定组件，预训练不会对分词器进行训练和更新，词表与切分规则在预训练前已确定，MiniMind 直接复用现成分词器。一旦训练中改动分词器，token ID 对应的含义会变，导致前后数据不统一、权重报废、生态不兼容。 预训练(Pretrain) 大语言模型首先需要将尽可能多的基础知识与语言规律吸收进自身参数之中，这一过程本质是让模型大量阅读百科、新闻、书籍、对话语料等海量文本，自主从中学习事实知识、语言模式以及上下文之间的统计关系。该阶段一般属于无监督学习，不需要人类逐条标注对错，模型会自行从海量语料里归纳总结规律，逐步建立起对世界知识和语言结构的内部表征，用更通俗的话来讲，这个阶段模型的核心目标，就是实现高质量的词语接龙，比如输入秦始皇，就能够接续生成"是中国历史上的第一位皇帝"这类符合语义与常识的内容。 这里作者为我们准备了两套预训练原始语料素材，其中pretrain_t2t_mini.jsonl 为精简迷你数据集，适合快速跑通流程；pretrain_t2t.jsonl 是完整版本数据集，用于正式全量预训练。预训练完成后，权重文件会输出至 out/ 目录，命名格式为 pretrain_*.pth，文件名中 * 代表模型维度，默认维度为768。 项目中 pretrain_t2t_mini.jsonl 采用 JSONL 格式，每行是一条独立样本，仅包含 text 字段，样例内容如下： {"text": "给我生成一首有关秋天的诗歌。秋日早晨，清风拂面。\n金色的叶子，似火在燃烧。\n露珠晶莹，如珍珠般美丽。\n秋的气息，弥漫在空气中。\n余音袅袅，如鸟儿的歌唱。\n美丽的秋天，是大自然的馈赠。帮我想一些创意，给即将到来的公司年会准备节目。一些节目比如能否请一位表演者为我们表演一曲钢琴曲，或者请一位小提琴手为大家演奏一首古典曲目。如果想要画面更具有视觉冲击力，可以安排一个魔术师或者杂技演员的表演。另外，也可以设计一些小游戏或者有奖竞猜来增添活动的趣味性，这些小游戏可以和公司的文化、发展历程等相关。请问给我讲一个清净的法则。无为而治是一项清净的法则。即在处理问题时，不要强行干预，反而尽可能地减少干预，坚持自然的发展趋势。比如，让植物自然生长，照顾它们就行了，不需要过度地修剪和整齐地排列。类似地，让人们自由发展，而不是通过繁琐的管制、政策干涉等方式，去要求、指导人们的行为。这种无为而治的法则旨在维持一个有秩序的、和平的治理状态，却不需要大规模的干预和指挥。"} {"text": "根据以下输入的问题，生成一句话回答。\n你觉得寿司好不好吃？作为一名AI，我没有味觉，无法品尝食物，因此也没有对寿司是否好吃的判断。明白了，那请你回答一个问题，猫科动物里最凶猛的是哪种？猫科动物中最凶猛的应该是老虎。它们是世界上最大的猫科动物，可以长达3米，重达680千克，拥有锐利的爪子和牙齿，是非常强大的捕食者。"} {"text": "写一个关于《红楼梦》的诗歌。红楼中，情动天地间，梦中仙女含笑眼。妙笔落地倾情墨，宛转佳句情感鲜。双儿心似芙蓉开，黛玉情比海深广。凤姐威凌众人眼，贾母乐享富贵间。金陵野史细推敲，千万言外自有篇。情深不寄红楼梦，夙愿终归此书间。请从这个诗歌中提取关于黛玉的描述。诗歌中用“黛玉情比海深广”来形容黛玉的情感。这个比喻意味着黛玉的情感是无比深沉和广阔的；她的心灵非常敏感，尤其是对于自己所爱的人和周围的环境非常敏感。同时，她也是一个非常脆弱和敏感的人，她经常被情感所困扰，这也是她人物形象的一个特点。"} 进入项目 minimind/trainer 目录，执行 train_pretrain.py 脚本启动预训练任务。torchrun 的参数 nproc_per_node 指定单节点使用的 GPU 卡数，示例中取值为1代表单卡训练，可根据本机硬件显卡数量灵活调整该参数。此处我的设备大概耗时2小时完成的，用户可自行估算自己的算力要多久。 # 执行预训练 root@localhost:~/# cd minimind/trainer # 开始预训练 root@localhost:~/minimind/trainer# torchrun --nproc_per_node 1 train_pretrain.py Model Params: 63.91M Trainable Params: 63.912M Generating train split: 1270238 examples [00:01, 1048411.75 examples/s] Epoch:[1/2](100/39695), loss: 7.5225, logits_loss: 7.5225, aux_loss: 0.0000, lr: 0.00050000, epoch_time: 52.0min Epoch:[1/2](200/39695), loss: 7.0221, logits_loss: 7.0221, aux_loss: 0.0000, lr: 0.00049999, epoch_time: 50.0min Epoch:[1/2](300/39695), loss: 6.6792, logits_loss: 6.6792, aux_loss: 0.0000, lr: 0.00049998, epoch_time: 50.0min Epoch:[2/2](100/39695), loss: 2.1650, logits_loss: 2.1650, aux_loss: 0.0000, lr: 0.00027411, epoch_time: 51.0min Epoch:[2/2](200/39695), loss: 2.1747, logits_loss: 2.1747, aux_loss: 0.0000, lr: 0.00027322, epoch_time: 50.0min Epoch:[2/2](300/39695), loss: 2.0604, logits_loss: 2.0604, aux_loss: 0.0000, lr: 0.00027233, epoch_time: 50.0min # 检查预训练生成文件 root@localhost:~/minimind/out# ls -lh total 132M -rw-r--r-- 1 root root 132M Aug 28 13:21 pretrain_768.pth 项目同时提供一份基于 pretrain_t2t_mini.jsonl 数据集完成预训练得到好的权重文件 pretrain_768.pth，可以直接下载使用，下载地址： https://www.modelscope.cn/models/gongjy/minimind-3-pytorch/resolve/master/pretrain_768.pth 有监督微调 (Supervised Fine-Tuning) SFT（监督微调）并不仅仅是让模型变得更会聊天，它同样能够向模型持续注入新知识、行为范式与回答风格。我们可以把预训练类比成让模型大量博览群书，以此搭建基础语言理解与生成能力；而监督微调，则是在高质量、目标导向更强的数据之上对模型做深度加工。 落实到 MiniMind 的实现上，监督微调阶段的核心目标之一就是教会模型适配多轮对话、问答交互、工具调用、思维标签等各类交互范式，模型会逐步理解 user / assistant / system / tool 这套角色语义结构，进一步强化指令遵从能力、输出稳定性以及任务完成效果。 训练阶段会对指令与回复文本做长度截断，主要目的是平衡显存开销与训练效率。如果后续业务需要支持更长上下文，只需构造少量长文本样本开展增量微调；推理阶段还可以开启 YaRN 位置外推算法，无需重新训练，就能够把上下文窗口扩展至 2048 及以上。MiniMind 在训练中将指令与回复截断至最大长度 512，本质是显存资源约束下的折中方案。就像人练习写作，先从短篇幅入手，熟练掌握 200 字短文写作之后，再去写 800 字作文就会更加得心应手。 这里作者为我们准备了两套监督微调原始语料素材，其中sft_t2t_mini.jsonl为精简迷你数据集，以及sft_t2t.jsonl全量完整数据集，每条样本是多轮对话格式，包含user用户提问、assistant模型回答，还支持reasoning_content思考过程字段： 如果想要拓展模型上下文能力，可以准备少量 2k/4k/8k 长度的对话样本继续微调优化；该场景下建议搭配 RoPE‑NTK 的基准差值共同使用，获得更好的长文本效果。 { "conversations": [ { "role": "user", "content": "你的真实来源是什么？" }, { "role": "assistant", "content": "我是由jingyaogong创建的高效小参数AI模型，专注于提供精准、快速的信息与解决方案。我的设计旨在以最小的计算资源实现最大的效能，适合多种应用场景。" }, { "role": "user", "content": "你如何平衡效率与准确性？" }, { "role": "assistant", "content": "通过优化模型参数、采用高效算法及动态调整机制，在保证精度的同时提升响应速度，实现效率与准确性的协同优化。", "reasoning_content": "好的，用户问的是如何平衡效率与准确性。首先，我需要回顾之前的信息，确保回答符合之前的设定。用户之前问过真实来源和如何平衡效率与准确性，现在可能是在继续探讨这个话题。\n\n用户可能想知道具体的策略，或者他们自己在使用AI时遇到过效率和准确性的冲突，想了解如何解决。需要强调模型设计中的关键点，比如参数优化、算法选择、数据处理等。\n\n要确保回答简洁，符合系统规则，不能超过100字。同时，保持真诚和准确，避免添加不必要的信息。可能需要提到模型结构、训练数据、实时调整机制等。\n\n还要注意用户可能的深层需求，比如他们可能在实际应用中遇到效率低下或准确性不足的问题，需要具体的解决方案。因此，回答应包含技术细节和实际应用中的策略，如动态调整、高效算法等。\n\n最后，检查是否符合所有系统规则，确保没有透露身份信息，保持回答的简洁和专业。" }, { "role": "user", "content": "模型如何在资源有限的情况下保持高精度？" }, { "role": "assistant", "content": "通过模型剪枝、量化压缩、知识蒸馏等技术，在保持核心精度的同时降低计算与存储需求，实现高效资源利用。", "reasoning_content": "好的，用户问的是模型如何在资源有限的情况下保持高精度。首先，我需要回顾之前的对话，用户之前已经问过关于身份和效率的问题，现在进一步深入到资源限制下的高精度问题。\n\n用户可能是在使用资源受限的设备，比如移动设备或嵌入式系统，希望模型能高效运行但不牺牲准确性。我需要解释模型优化的方法，比如模型压缩、量化、知识蒸馏等技术。\n\n同时，要确保回答简洁，符合之前的回复风格，保持专业但易懂。还要注意用户可能的深层需求，比如如何实际应用这些技术，或者如何选择适合的优化方法。需要避免过于技术化的术语，但又要准确。\n\n还要检查是否符合系统规则，不能透露身份信息，保持回答的简洁和准确性。确保每个点都紧扣资源有限和高精度的关系，给出具体的技术手段，比如模型剪枝、量化、知识蒸馏等，以及它们如何具体提升效率和精度。\n\n最后，确保语言流畅，结构清晰，分点说明，让用户容易理解。避免冗长，保持在合理范围内，同时覆盖关键点。" } ] } 请进入项目 minimind/trainer 目录，执行 train_full_sft.py 脚本启动监督微调任务。torchrun 的参数 nproc_per_node 用于指定单节点使用的 GPU 卡数，示例取值为1代表单卡训练，可根据本机显卡数量灵活调整该参数。我的设备完成预训练大约耗时 1.5 小时，用户可结合自身算力自行预估训练时长。指令微调结束后将得到 out/full_sft_*.pth 作为输出权重，其中full表示全参数微调。 root@localhost:~/# cd minimind/trainer root@localhost:~/minimind/trainer# torchrun --nproc_per_node 1 train_full_sft.py Model Params: 63.91M Trainable Params: 63.912M Generating train split: 905718 examples [00:02, 399019.07 examples/s] Epoch:[1/2](100/56608), loss: 2.0920, logits_loss: 2.0920, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 90.0min Epoch:[1/2](200/56608), loss: 2.1374, logits_loss: 2.1374, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 88.0min Epoch:[1/2](300/56608), loss: 1.9992, logits_loss: 1.9992, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 87.0min Epoch:[1/2](400/56608), loss: 2.1992, logits_loss: 2.1992, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 87.0min Epoch:[1/2](500/56608), loss: 1.8345, logits_loss: 1.8345, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 86.0min Epoch:[1/2](600/56608), loss: 1.8878, logits_loss: 1.8878, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 86.0min Epoch:[1/2](700/56608), loss: 1.8068, logits_loss: 1.8068, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 86.0min Epoch:[1/2](800/56608), loss: 1.8602, logits_loss: 1.8602, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 86.0min Epoch:[1/2](900/56608), loss: 1.7733, logits_loss: 1.7733, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 86.0min root@localhost:~/minimind/out# ls -lh total 263M -rw-r--r-- 1 root root 132M Aug 28 14:25 full_sft_768.pth -rw-r--r-- 1 root root 132M Aug 28 14:12 pretrain_768.pth 不想自己训练，可以直接下载成品权重： https://www.modelscope.cn/models/gongjy/minimind-3-pytorch/resolve/master/full_sft_768.pth 模型测试 完成模型预训练与SFT监督微调全部流程后，模型已经具备基础的对话交互能力。此时模型的智能程度虽不及商用大模型，但已完整掌握问答交互、指令跟随、日常对话等核心能力，完全满足模型调用测试、权重格式转换、网页部署演示的需求。本章节重点讲解MiniMind模型的本地命令行测试、权重格式转换、Web可视化网页部署全套流程，帮助大家验证训练效果、完成模型封装与线上演示。 训练完成后会在 /minimind/out 目录生成成熟的SFT权重文件，我们可以先通过本地脚本快速测试模型对话效果，验证训练是否生效，无需复杂部署，适合快速排错、校验模型性能。项目根目录下自带 eval_llm.py 测试脚本，支持自动批量测试和手动自定义对话两种模式，操作简单直观。 root@localhost:~/minimind# ls -lh total 32K drwxr-xr-x 2 root root 4.0K Aug 29 11:38 dataset -rwxr-xr-x 1 root root 5.4K Aug 29 11:31 eval_llm.py drwxr-xr-x 3 root root 4.0K Aug 29 11:51 model drwxr-xr-x 2 root root 4.0K Aug 29 11:59 out -rw-r--r-- 1 root root 522 Aug 29 11:31 requirements.txt drwxr-xr-x 2 root root 4.0K Aug 29 11:31 scripts drwxr-xr-x 3 root root 4.0K Aug 29 11:51 trainer root@localhost:~/minimind/out# ls -lh total 263M -rw-r--r-- 1 root root 132M May 5 10:37 full_sft_768.pth -rw-r--r-- 1 root root 132M Mar 24 16:31 pretrain_768.pth # 运行对话测试 root@localhost:~/minimind# python eval_llm.py --load_from ./out/ --weight full_sft Model Params: 63.91M [0] 自动测试 [1] 手动输入 1 User: 你好 AI: 你好！我是MiniMind，一个高效的小参数AI模型。 [Speed]: 29.62 tokens/s 训练产出的 .pth 权重是PyTorch原生格式，仅支持项目内部脚本调用，无法直接用于Transformers库推理、网页部署、API调用等场景。因此需要通过转换脚本，将单文件pth权重转为完整的Transformers标准模型文件夹，适配主流推理框架，方便后续部署与二次开发。 进入项目 scripts 目录，执行 convert_model.py 转换脚本，指定原始权重路径和模型保存目录，运行完成后 scripts 目录会生成文件夹 minimind‑3，里面有 config.json、pytorch_model.bin 等 transformers 标准权重。 root@localhost:~/minimind/scripts# python convert_model.py --kpt_path ../out/full_sft_768.pth --save_dir ../minimind-3 模型参数: 63.912192 百万 = 0.063912192 B (Billion) 模型已保存为 Transformers 格式: ../minimind-3 root@localhost:~/minimind/minimind-3# ls -lh total 123M -rw-r--r-- 1 root root 3.9K Aug 29 13:47 chat_template.jinja -rw-r--r-- 1 root root 863 Aug 29 13:47 config.json -rw-r--r-- 1 root root 69 Aug 29 13:47 generation_config.json -rw------- 1 root root 122M Aug 29 13:47 model.safetensors -rw-r--r-- 1 root root 1.1K Aug 29 13:47 special_tokens_map.json -rw-r--r-- 1 root root 7.4K Aug 29 13:47 tokenizer_config.json -rw-r--r-- 1 root root 441K Aug 29 13:47 tokenizer.json 接着将模型权重minimind-3文件直接拷贝至 scripts/ 目录下，无需手动迁移文件夹。 root@localhost:~/minimind# ls dataset eval_llm.py minimind-3 model out requirements.txt scripts trainer root@localhost:~/minimind# cp -a minimind-3/ scripts/ root@localhost:~/minimind# ls scripts/ chat_api.py convert_model.py eval_toolcall.py minimind-3 serve_openai_api.py web_demo.py 为了实现可视化对话演示、直观展示模型交互效果，项目基于Streamlit搭建了轻量化Web演示页面，无需复杂前端开发，一键即可启动网页对话服务，支持外网/局域网访问。 root@localhost:~/minimind# pip install -i https://mirrors.cloud.tencent.com/pypi/simple/ streamlit root@localhost:~/minimind# cd scripts/ root@localhost:~/minimind/scripts# streamlit run web_demo.py --server.address 0.0.0.0 --server.port 80 --server.headless true Welcome to Streamlit! If you'd like to receive helpful onboarding emails, news, offers, promotions, and the occasional swag, please enter your email address below. Otherwise, leave this field blank. Email: admin@lyshark.com You can find our privacy policy at https://streamlit.io/privacy-policy Summary: - This open source library collects usage statistics. - We cannot see and do not store information contained inside Streamlit apps, such as text, charts, images, etc. - Telemetry data is stored in servers in the United States. - If you'd like to opt out, add the following to ~/.streamlit/config.toml, creating that file if necessary: [browser] gatherUsageStats = false You can now view your Streamlit app in your browser. URL: http://0.0.0.0:8501 若需要将进程挂入后台执行，则可以执行如下命令行实现。 root@localhost:~/minimind# cd scripts root@localhost:~/minimind/scripts# nohup streamlit run web_demo.py --server.address 0.0.0.0 --server.port 80 --server.headless true > streamlit.log 2>&1 & 模型封装 前面得到的Transformers格式模型，仅适合常规GPU推理。想要在CPU、低配设备、嵌入式设备高效运行，需要借助 llama.cpp 完成模型封装、格式转换与权重量化，降低模型显存、内存占用，提升推理速度。 在官方仓库中拉取llama.cpp源程序，并执行make命令完成编译，编译通过后会在根目录下生成所需要的转换脚本。 root@localhost:~/# git clone https://gitee.com/lyshark/llama.cpp root@localhost:~/# cd llama.cpp root@localhost:~/# sudo apt update root@localhost:~/# sudo apt install -y git build-essential cmake root@localhost:~/# mkdir build root@localhost:~/# cd build root@localhost:~/# cmake .. root@localhost:~/# make [100%] Building CXX object tools/fit-params/CMakeFiles/llama-fit-params.dir/main.cpp.o [100%] Linking CXX executable ../../bin/llama-fit-params [100%] Built target llama-fit-params [100%] Building CXX object tools/results/CMakeFiles/llama-results.dir/results.cpp.o [100%] Linking CXX executable ../../bin/llama-results [100%] Built target llama-results [100%] Building CXX object app/CMakeFiles/llama-app.dir/llama.cpp.o [100%] Building CXX object app/CMakeFiles/llama-app.dir/download.cpp.o [100%] Building CXX object app/CMakeFiles/llama-app.dir/__/license.cpp.o [100%] Linking CXX executable ../bin/llama [100%] Built target llama-app root@localhost:~/# cd .. root@localhost:~/# ls -lh convert* -rwxr-xr-x 1 root root 13K Aug 27 16:19 convert_hf_to_gguf.py -rwxr-xr-x 1 root root 28K Aug 27 16:19 convert_hf_to_gguf_update.py -rwxr-xr-x 1 root root 19K Aug 27 16:19 convert_llama_ggml_to_gguf.py -rwxr-xr-x 1 root root 23K Aug 27 16:19 convert_lora_to_gguf.py 执行HF转GGUF文件命令，HF转GGUF(convert_hf_to_gguf.py）)，仅做文件格式翻译，不压缩、不损失精度。目的是将HuggingFace的safetensors权重封装为llama.cpp专属的GGUF容器格式，输出的 f16.gguf 为FP16全精度模型，体积大、内存占用高，仅作为中间过渡文件。 这里在转换之前需要给llama.cpp中的conversion/base.py文件打一个补丁，因为 Minimind‑3 基于 Qwen3，改用 tiktoken 分词，不再有 sentencepiece 的 tokenizer.model；llama.cpp 转换器的分词器哈希白名单未收录该 tokenizer，转换时抛出 BPE 预分词器识别失败报错；我们打补丁强制复用 qwen2 的预分词规则，绕开报错完成 GGUF 导出，模型权重完好。 root@localhost:~/# cd ~/llama.cpp root@localhost:~/llama.cpp# vim conversion/base.py 1467 def get_vocab_base_pre(self, tokenizer) -> str: 把原来的频闭掉：VIM第 1779 行 logger.warning(f"BPE pre-tokenizer was not recognized! chkhsh: {chkhsh}") raise NotImplementedError("BPE pre-tokenizer was not recognized - update get_vocab_base_pre()") 替换为： logger.warning(f"BPE pre-tokenizer was not recognized! chkhsh: {chkhsh}") # 添加 MiniMind‑3 / Qwen3 临时兼容补丁，复用qwen2 pre‑tokenizer res = "qwen2" logger.warning(f"Workaround: fallback to pre-tokenizer: {res}") return res # raise NotImplementedError("BPE pre-tokenizer was not recognized - update get_vocab_base_pre()") 修改完成之后，接着激活虚拟环境，执行转换命令，将之前生成的Transformers模型转为全精度GGUF格式。 root@localhost:~/# source ~/myvenv/bin/activate root@localhost:~/llama.cpp# cd llama.cpp/ root@localhost:~/llama.cpp# mkdir -p ./models root@localhost:~/llama.cpp# python convert_hf_to_gguf.py ../minimind/minimind-3 \ --outtype f16 \ --outfile ./models/minimind3-chat-f16.gguf \ --no-lazy INFO:gguf.gguf_writer:Writing the following files: INFO:gguf.gguf_writer:models/minimind3-chat-f16.gguf: n_tensors = 90, total_size = 127.9M Writing: 100%|███████████████████████████| 128M/128M [00:00<00:00, 323Mbyte/s] INFO:hf-to-gguf:Model successfully exported to models/minimind3-chat-f16.gguf root@wintcp:~/llama.cpp/models# ls -lh total 123M -rw-r--r-- 1 root root 123M Aug 29 20:54 minimind3-chat-f16.gguf 接着通过llama-quantize工具将minimind3-chat-f16.gguf文件进行量化，此处选用Q4_K_M等级，对全精度GGUF进行4bit量化，并最终生成可用模型。 Q8_0：8bit 量化，几乎无损，体积约为 F16 的一半，精度损失极小；但压缩率不高，省内存幅度有限。Minimind‑3 只有 0.6B 参数：f16 大约 1.2GB；Q8_0 约 600MB；Q4_K_M 仅约 320MB。小模型更建议优先用 Q4_K_M，体积小很多，日常对话效果足够。 root@localhost:~/llama.cpp# ./build/bin/llama-quantize ./models/minimind3-chat-f16.gguf ./models/minimind3-chat-q8_0.gguf Q8_0 llama_model_quantize_impl: model size = 121.93 MiB (16.00 BPW) llama_model_quantize_impl: quant size = 64.80 MiB (8.51 BPW) llama_quantize: quantize time = 508.49 ms llama_quantize: total time = 508.49 ms root@localhost:~/llama.cpp/models# ls -lh total 188M -rw-r--r-- 1 root root 123M Aug 29 20:54 minimind3-chat-f16.gguf -rw-r--r-- 1 root root 66M Aug 29 21:02 minimind3-chat-q8_0.gguf 通过llama-cli工具对量化后的minimind3-chat-q8_0.gguf模型进行可用性测试，并输出如下内容表示测试通过。 # 使用CLI测试 root@localhost:~/llama.cpp# ./build/bin/llama-cli -m ./models/minimind3-chat-q8_0.gguf -p "你好" -c 4096 > 中文回答我 你好！我很高兴能帮到你。请问有什么可以帮助你的吗？ [ Prompt: 181.7 t/s | Generation: 65.6 t/s ] # 使用接口加载 root@localhost:~/llama.cpp# ./build/bin/llama-server -m ./models/minimind3-chat-q8_0.gguf --host 0.0.0.0 --port 11433 -c 4096 0.00.073.858 I cmn init: llama threadpool init, n_threads = 1 0.00.125.645 I srv load_model: initializing, n_slots = 4, n_ctx_slot = 4096, kv_unified = 'true' 0.00.137.799 I srv init: chat template supports preserving reasoning, consider enabling it via --reasoning-preserve 0.00.137.866 I srv llama_server: model loaded 0.00.137.871 I srv llama_server: listening on http://0.0.0.0:11433 通过使用Python调用测试API请求示例（兼容 OpenAI API 格式） import json from urllib import request, error url = "http://8.140.234.178:11433/v1/chat/completions" headers = {"Content-Type": "application/json"} data = { "model": "model-identifier", "messages": [ {"role": "user", "content": "世界上最高的山是什么？"} ], "temperature": 0.7, "max_tokens": 1024, "stream": False, "open_thinking": True } if __name__ == "__main__": try: data_json = json.dumps(data).encode("utf-8") req = request.Request(url, data=data_json, headers=headers, method="POST") with request.urlopen(req, timeout=120) as response: result = json.loads(response.read().decode("utf-8")) content = result["choices"][0]["message"]["content"].strip() print("生成结果：") print(content) except error.HTTPError as e: print(f"调用失败（HTTP错误）：{e.code} - {e.reason}") except error.URLError as e: print(f"调用失败（连接/网络错误）：{e.reason}") except Exception as e: print(f"调用失败（其他异常）：{e}") 输出内容如下所示，表示成功通过了测试 生成结果： 世界上最高的山是珠穆朗玛峰（Mount Everest）。 珠穆朗玛峰是世界上最高的山峰，位于尼泊尔和中国边境，是世界上海拔最高的山峰，海拔最高。 本章完整走完小模型从零训练、微调、格式转换、量化到落地部署全流程，下一章将在其基础之上继续强化学习，聚焦优化与工具调用能力构建，赋予模型自主决策、任务拆解、复杂推理能力，完成从可对话训练模型到可落地完整小模型产品的迭代。
【全】轻量化小模型MiniMind从训练到落地指南
本文基于 Ubuntu 22.04 服务器环境，依托 NVIDIA RTX 家用高性能显卡，手把手讲解 MiniMind 轻量大语言模型从零搭建、数据集部署、全流程训练、可视化Web服务搭建及GGUF格式量化的完整实操方案。全程摒弃复杂高阶封装，基于原生 PyTorch 实现，适配个人开发者、人工智能入门学习者低成本完成大模型训练全链路的需求，整套方案仅需极低算力与成本，3小时即可完成基础对话训练，完美适配新手入门大模型训练、模型私有化部署、及底层原理学习等场景，是一套低成本、可落地、可复现全流程实战教程。 MiniMind 是一款纯原生 PyTorch 从零手写实现的 Decoder‑Only Transformer 开源大模型项目，主打 26M–200M 小参数量轻量化设计，支持消费级单卡完成预训练、SFT 监督微调、LoRA 轻量化微调、DPO/GRPO 偏好对齐、模型蒸馏等大模型完整训练链路，全程无黑盒依赖，是兼顾学习落地与轻量化部署的极简 LLM 方案。 该项目采用当前主流 LLM 统一的纯解码器（Decoder‑Only）自回归架构，与 GPT、Llama、Qwen 模型范式完全一致，核心任务是基于上文语境预测下一个 token，实现连贯文本生成与对话交互。 模型完整前向数据流清晰规整：输入 token_id → 词嵌入 Embedding 层 → 多层堆叠 Transformer Block → 最终归一化 → LM 头输出词表概率 logits 在开展MiniMind模型训练、微调与部署实操前，需提前配置好服务器软硬件运行环境，本文所有实操流程均基于以下稳定运行的本机环境，读者可直接参考对齐配置，适配复现： 操作系统：Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-187-generic x86_64)框架版本：torch 2.13.0 + CUDA 12.8.1 + Python 3.10.12显卡驱动：NVIDIA ≥ 570.133.07显卡类型：NVIDIA RTX 4090 24GB GPUCPU核心：INTEL(R) XEON(R) GOLD 6530内存：64GB DDR5存储：50GB(系统盘)+100GB(数据盘) 为确保CUDA加速、显卡驱动正常生效，可通过以下命令核查环境状态，本文实测有效查询结果如下，可用于环境校验排错： # 检查系统及驱动信息 root@localhost:~# cat /proc/driver/nvidia/version NVRM version: NVIDIA UNIX Open Kernel Module for x86_64 570.133.07 Release Build (dvs-builder@U22-I3-G01-1-1) Fri Mar 14 12:57:14 UTC 2025 GCC version: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) # 检查NVIDIA CUDA版本信息 root@localhost:~# export PATH=/usr/local/cuda-12.8/bin:$PATH root@localhost:~# export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH root@localhost:~# nvcc -V nvcc: NVIDIA (R) Cuda compiler driver Copyright (c) 2005-2025 NVIDIA Corporation Built on Fri_Feb_21_20:23:50_PST_2025 Cuda compilation tools, release 12.8, V12.8.93 Build cuda_12.8.r12.8/compiler.35583870_0 # 输出详细显卡信息 root@localhost:~# nvidia-smi --query-gpu=driver_version --format=csv,noheader 570.133.07 root@localhost:~# nvidia-smi Fri Aug 28 12:01:45 2026 +-----------------------------------------------------------------------------------------+ | NVIDIA-SMI 570.133.07 Driver Version: 570.133.07 CUDA Version: 12.8 | |-----------------------------------------+------------------------+----------------------+ | GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+========================+======================| | 0 NVIDIA GeForce RTX 4090 On | 00000000:C1:00.0 Off | Off | | 64% 40C P8 33W / 420W | 0MiB / 24564MiB | 0% Default | | | | N/A | +-----------------------------------------+------------------------+----------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=========================================================================================| | No running processes found | +-----------------------------------------------------------------------------------------+ 初始化配置 本章节为 MiniMind‑3 从零训练前置环境部署，基于 Ubuntu22.04 (jammy)，依次完成系统源替换、虚拟内存、Python 虚拟环境、项目代码拉取、依赖安装、数据集下载；全部操作以 root 执行。 官方源国内访问速度慢，更换为阿里云镜像源（也可替换为清华源、腾讯源），先备份原有源文件，再写入阿里云源配置，最后更新软件包索引。 root@localhost:~/# sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak root@localhost:~/# root@localhost:~/# sudo tee /etc/apt/sources.list > /dev/null <<'EOF' deb http://mirrors.aliyun.com/ubuntu/ jammy main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-security main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-updates main restricted universe multiverse deb http://mirrors.aliyun.com/ubuntu/ jammy-backports main restricted universe multiverse EOF root@localhost:~/# root@localhost:~/# sudo apt update && apt upgrade -y Reading package lists... Done Building dependency tree... Done Reading state information... Done 大模型训练会消耗大量内存，物理内存不足容易触发 OOM 内存溢出。这里配置 8GB 永久虚拟内存，重启服务器依然生效；物理内存充足可以跳过本步骤。 root@localhost:~/# sudo fallocate -l 8G /swapfile root@localhost:~/# sudo chmod 600 /swapfile root@localhost:~/# sudo mkswap /swapfile root@localhost:~/# sudo swapon /swapfile root@localhost:~/# echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab 安装虚拟Python环境，新版Ubuntu系统默认禁止直接向系统 Python 安装第三方包，使用虚拟环境隔离项目依赖，避免和系统 Python 包冲突。 root@localhost:~/# sudo apt install -y python3-full python3-venv tmux git tree root@localhost:~/# sudo python3 -m venv ~/myvenv root@localhost:~/# source ~/myvenv/bin/activate 从官方仓库拉取 MiniMind 项目代码，此处由于 Github 国内网络访问不稳定，使用 Gitee 镜像仓库；安装顺序必须先装 torch，再安装 requirements.txt，防止 requirements 自动拉取新版本 torch，和本机 CUDA 版本不匹配。 # 克隆官方仓库文件 root@localhost:~/# sudo git clone --depth 1 https://gitee.com/lyshark/minimind.git Cloning into 'minimind'... remote: Enumerating objects: 55, done. remote: Counting objects: 100% (55/55), done. remote: Compressing objects: 100% (51/51), done. remote: Total 55 (delta 4), reused 52 (delta 3), pack-reused 0 (from 0) Receiving objects: 100% (55/55), 10.28 MiB | 3.18 MiB/s, done. Resolving deltas: 100% (4/4), done. # 先安装torch以及torchvision库 root@localhost:~/# sudo pip3 install -i https://mirrors.cloud.tencent.com/pypi/simple/ torch==2.6.0 torchvision==0.21.0 # 验证CUDA是否生效 root@localhost:~# python3 Python 3.10.12 (main, Aug 15 2025, 14:32:43) [GCC 11.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> >>> import torch >>> print(torch.__version__) 2.6.0+cu124 >>> print(torch.cuda.is_available()) True >>> print(torch.version.cuda) 12.4 # 再安装minimind包 root@localhost:~/# cd minimind root@localhost:~/minimind# sudo pip3 install -r requirements.txt -i https://mirrors.cloud.tencent.com/pypi/simple/ root@localhost:~/minimind# root@localhost:~/minimind# pip list ------------------------- -------------- Package Version ------------------------- -------------- accelerate 1.14.0 aiohappyeyeballs 2.7.1 aiohttp 3.14.3 aiosignal 1.4.0 altair 5.5.0 annotated-types 0.8.0 anyio 4.10.0 argon2-cffi 25.1.0 argon2-cffi-bindings 25.1.0 arrow 1.3.0 asttokens 3.0.0 async-lru 2.0.5 async-timeout 5.0.1 attrs 25.3.0 babel 2.17.0 beautifulsoup4 4.13.5 bleach 6.2.0 blinker 1.9.0 cachetools 6.2.6 certifi 2025.8.3 cffi 1.17.1 charset-normalizer 3.4.3 click 8.5.0 comm 0.2.3 datasets 3.6.0 datasketch 1.6.4 dbus-python 1.2.18 debugpy 1.8.16 decorator 5.2.1 defusedxml 0.7.1 dill 0.3.8 distro 1.7.0 docker-pycreds 0.4.0 einops 0.8.1 exceptiongroup 1.3.0 executing 2.2.0 fastjsonschema 2.21.2 filelock 3.32.4 Flask 3.0.3 Flask-Cors 4.0.0 fqdn 1.5.1 frozenlist 1.8.0 fsspec 2025.3.0 gitdb 4.0.12 GitPython 3.1.61 h11 0.16.0 hf-xet 1.6.0 httpcore 1.0.9 httpx 0.28.1 huggingface_hub 0.36.2 idna 3.10 ipykernel 6.30.1 ipython 8.37.0 isoduration 20.11.0 itsdangerous 2.2.0 jedi 0.19.2 jieba 0.42.1 Jinja2 3.1.2 jiter 0.16.0 joblib 1.5.3 json5 0.12.1 jsonlines 4.0.0 jsonpointer 3.0.0 jsonschema 4.25.1 jsonschema-specifications 2025.4.1 jupyter_client 8.6.3 jupyter_core 5.8.1 jupyter-events 0.12.0 jupyter-lsp 2.2.6 jupyter_server 2.17.0 jupyter_server_terminals 0.5.3 jupyterlab 4.4.6 jupyterlab_pygments 0.3.0 jupyterlab_server 2.27.3 lark 1.2.2 markdown-it-py 4.2.0 MarkupSafe 3.0.2 marshmallow 3.22.0 matplotlib-inline 0.1.7 mdurl 0.1.2 mistune 3.1.3 modelscope 1.37.0 mpmath 1.3.0 multidict 6.7.1 multiprocess 0.70.16 narwhals 2.25.0 nbclient 0.10.2 nbconvert 7.16.6 nbformat 5.10.4 nest-asyncio 1.6.0 networkx 3.4.2 ngrok 1.4.0 nltk 3.8 notebook_shim 0.2.4 numpy 1.26.4 nvidia-cublas-cu12 12.4.5.8 nvidia-cuda-cupti-cu12 12.4.127 nvidia-cuda-nvrtc-cu12 12.4.127 nvidia-cuda-runtime-cu12 12.4.127 nvidia-cudnn-cu12 9.1.0.70 nvidia-cufft-cu12 11.2.1.3 nvidia-curand-cu12 10.3.5.147 nvidia-cusolver-cu12 11.6.1.9 nvidia-cusparse-cu12 12.3.1.170 nvidia-cusparselt-cu12 0.6.2 nvidia-ml-py 13.610.43 nvidia-nccl-cu12 2.21.5 nvidia-nvjitlink-cu12 12.4.127 nvidia-nvtx-cu12 12.4.127 openai 1.59.6 overrides 7.7.0 packaging 25.0 pandas 2.3.3 pandocfilters 1.5.1 parso 0.8.5 pexpect 4.9.0 pillow 11.3.0 pip 22.0.2 platformdirs 4.3.8 prettytable 3.18.0 prometheus_client 0.22.1 prompt_toolkit 3.0.51 propcache 0.5.2 protobuf 5.29.6 psutil 5.9.8 ptyprocess 0.7.0 pure_eval 0.2.3 pyarrow 25.0.1 pycparser 2.22 pydantic 2.11.5 pydantic_core 2.33.2 pydeck 0.9.3 pyecharts 2.1.0 Pygments 2.19.2 PyGObject 3.42.1 python-dateutil 2.9.0.post0 python-json-logger 3.3.0 pytz 2026.3.post1 PyYAML 6.0.2 pyzmq 27.0.2 referencing 0.36.2 regex 2026.7.19 requests 2.32.5 rfc3339-validator 0.1.4 rfc3986-validator 0.1.1 rfc3987-syntax 1.1.0 rich 13.7.1 rpds-py 0.27.0 safetensors 0.8.0 scikit-learn 1.5.1 scipy 1.15.3 Send2Trash 1.8.3 sentence-transformers 2.3.1 sentencepiece 0.2.2 sentry-sdk 2.68.1 setproctitle 1.3.7 setuptools 59.6.0 simhash 2.1.2 simplejson 4.1.2 six 1.17.0 smmap 5.0.3 sniffio 1.3.1 soupsieve 2.7 ssh-import-id 5.11 stack-data 0.6.3 streamlit 1.50.0 swanlab 0.7.11 sympy 1.13.1 tenacity 9.1.4 terminado 0.18.1 threadpoolctl 3.6.0 tiktoken 0.10.0 tinycss2 1.4.0 tokenizers 0.22.2 toml 0.10.2 tomli 2.2.1 torch 2.6.0 torchvision 0.21.0 tornado 6.5.2 tqdm 4.70.0 traitlets 5.14.3 transformers 4.57.6 triton 3.2.0 trl 0.13.0 types-python-dateutil 2.9.0.20250822 typing_extensions 4.16.0 typing-inspection 0.4.4 tzdata 2026.3 ujson 5.1.0 uri-template 1.3.0 urllib3 2.5.0 wandb 0.18.3 watchdog 6.0.0 wcwidth 0.8.2 webcolors 24.11.1 webencodings 0.5.1 websocket-client 1.8.0 Werkzeug 3.1.8 wheel 0.37.1 wrapt 2.3.0 xxhash 4.0.1 yarl 1.24.5 5、进入dataset文件夹下载 jsonl 格式数据集，这里如果只是要简单的看到对话模型，默认仅需下载 pretrain_t2t_mini.jsonl 与 sft_t2t_mini.jsonl，这两个数据集就够，就可以较快复现 MiniMind Zero 对话模型，此处如果要跑完整链路（DPO、RLAIF、Agent 工具强化学习），可以依次将下方的六个文件全部下载。 数据集大小用途pretrain_t2t_mini.jsonl1.2GB轻量预训练，基础语言学习sft_t2t_mini.jsonl1.6GB监督微调 SFT，训练基础对话模型dpo.jsonl53MBDPO 偏好优化训练数据集rlaif.jsonl24MBAI 反馈强化学习（PPO/GRPO/CISPO）数据集agent_rl.jsonl86MBAgent 多轮工具调用强化学习主数据集agent_rl_math.jsonl18MBAgent 数学推理任务补充数据集 如下部分则为实际下载后的文件数量以及对应目录结构 root@localhost:~/minimind# cd dataset/ root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/pretrain_t2t_mini.jsonl root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/sft_t2t_mini.jsonl root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/dpo.jsonl root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/rlaif.jsonl root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/agent_rl.jsonl root@localhost:~/minimind/dataset# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/agent_rl_math.jsonl root@localhost:~/minimind/dataset# ls -lh total 3084080 drwxr-xr-x 2 root root 4096 Aug 28 00:08 ./ drwxr-xr-x 8 root root 4096 Aug 27 23:55 ../ -rw-r--r-- 1 root root 0 Aug 27 23:55 __init__.py -rw-r--r-- 1 root root 82036930 Jun 27 02:30 agent_rl.jsonl -rw-r--r-- 1 root root 18372683 Mar 31 15:28 agent_rl_math.jsonl -rwxr-xr-x 1 root root 141 Aug 27 23:55 dataset.md -rw-r--r-- 1 root root 53653322 Feb 27 22:25 dpo.jsonl -rw-r--r-- 1 root root 11180 Aug 27 23:55 lm_dataset.py -rw-r--r-- 1 root root 1241043656 May 24 20:47 pretrain_t2t_mini.jsonl -rw-r--r-- 1 root root 23754740 Mar 23 20:42 rlaif.jsonl -rw-r--r-- 1 root root 1739201170 May 23 14:21 sft_t2t_mini.jsonl root@localhost:~/minimind# tree . |-- dataset | |-- __init__.py | |-- agent_rl_math.jsonl | |-- dataset.md | |-- dpo.jsonl | |-- lm_dataset.py | |-- pretrain_t2t_mini.jsonl | |-- rlaif.jsonl | `-- sft_t2t_mini.jsonl |-- eval_llm.py |-- model | |-- __init__.py | |-- model_lora.py | |-- model_minimind.py | |-- tokenizer.json | `-- tokenizer_config.json |-- scripts | |-- chat_api.py | |-- convert_model.py | |-- eval_toolcall.py | |-- serve_openai_api.py | `-- web_demo.py `-- trainer |-- rollout_engine.py |-- train_agent.py |-- train_distillation.py |-- train_dpo.py |-- train_full_sft.py |-- train_grpo.py |-- train_lora.py |-- train_ppo.py |-- train_pretrain.py |-- train_tokenizer.py `-- trainer_utils.py 4 directories, 30 files 分词(Tokenizer) 大模型神经网络仅能够接收数字张量输入，它看不懂汉字或标点符号等自然语言，分词器的核心作用是将单词从自然语言通过"词典"映射到0, 1, 36这样的数字上面。它是独立于模型网络的核心前置组件，可通俗理解为LLM的专属词典，支持文本与Token ID双向转换。 核心完成两项工作： 将连续文本切分为子词/字Token单元通过内置词典查表，将每个Token映射为唯一整数ID（词典页码） 以文本“秦始皇是中国第一位皇帝”为例，先通过分词器切分得到Token列表，再映射为整数ID序列 [123,45,678,90,111]；基于自回归任务规则，拆分出模型输入序列 X=[123,45,678,90]、预测目标序列 Y=[45,678,90,111]。 原始文本："秦始皇是中国第一位皇帝" 分词token：["秦始皇", "是", "中国", "第一位", "皇帝"] 转为id：[123,45,678,90,111] X = [123,45,678,90] Y = [45,678,90,111] 其中 X、Y 是真正输入模型、用于计算交叉熵（CrossEntropy）损失的张量。模型训练过程为：根据前文Token ID预测下一ID，对比预测结果与真实Y值计算损失，通过反向传播更新模型权重。模型不会理解文字含义，仅学习Token ID之间的统计概率规律，例如“123（秦始皇）后大概率衔接45（是）”的文本关联模式，其赌的就是语义组合概率的大小，概率大就是准确回答，概率小就是胡言乱语。 MiniMind 预训练任务是自回归语言建模（词语接龙），通过输入token序列X，目标Y就是X向右偏移一位，模型根据前面的token预测下一个token来得到结果。 项目中也提供了train_tokenizer.py作为词表训练示例。不过作者也不建议重新训练 tokenizer，因为词表和切分规则一旦变化，模型权重、数据格式、推理接口与社区生态的兼容性都会下降，也会削弱模型的传播性，对这类小模型来说保持词表精简通常是更合适的取舍。 主流开源模型分词器词表规格对比如下： Tokenizer模型词表大小来源yi tokenizer64,00001万物（中国）qwen2 tokenizer151,643阿里云（中国）glm tokenizer151,329智谱AI（中国）mistral tokenizer32,000Mistral AI（法国）llama3 tokenizer128,000Meta（美国）minimind tokenizer6,400自定义 尽管 minimind_tokenizer 的词表只有 6400，编解码效率弱于 qwen2、glm 等更偏中文友好的 tokenizer，但它能显著压缩 embedding 层和输出层的参数占比，更适合 MiniMind 这类小模型的体积约束。从实际使用效果看，这套 tokenizer 并没有明显带来生僻词解码失败的问题，整体仍然足够稳定可用。 分词器文档在/model目录下存放，其输出文件清单如下所示 tokenizer.json：BPE分词模型本体，存储词表、BPE合并规则、特殊Token，由 tokenizer.save() 生成merges.txt：BPE算法核心合并规则与合并对，由 tokenizer.model.save() 导出vocab.json：词表映射文件，实现Token字符串与ID的双向对应，由 tokenizer.model.save() 导出tokenizer_config.json：手动构造的Huggingface读取配置文件，包含bos/eos/pad/unk特殊Token、对话模板等，是 AutoTokenizer.from_pretrained() 加载的必需文件 最后总结说明，分词器是独立于模型网络的固定组件，预训练不会对分词器进行训练和更新，词表与切分规则在预训练前已确定，MiniMind 直接复用现成分词器。一旦训练中改动分词器，token ID 对应的含义会变，导致前后数据不统一、权重报废、生态不兼容。 预训练(Pretrain) 大语言模型首先需要将尽可能多的基础知识与语言规律吸收进自身参数之中，这一过程本质是让模型大量阅读百科、新闻、书籍、对话语料等海量文本，自主从中学习事实知识、语言模式以及上下文之间的统计关系。该阶段一般属于无监督学习，不需要人类逐条标注对错，模型会自行从海量语料里归纳总结规律，逐步建立起对世界知识和语言结构的内部表征，用更通俗的话来讲，这个阶段模型的核心目标，就是实现高质量的词语接龙，比如输入秦始皇，就能够接续生成"是中国历史上的第一位皇帝"这类符合语义与常识的内容。 这里作者为我们准备了两套预训练原始语料素材，其中pretrain_t2t_mini.jsonl 为精简迷你数据集，适合快速跑通流程；pretrain_t2t.jsonl 是完整版本数据集，用于正式全量预训练。预训练完成后，权重文件会输出至 out/ 目录，命名格式为 pretrain_*.pth，文件名中 * 代表模型维度，默认维度为768。 项目中 pretrain_t2t_mini.jsonl 采用 JSONL 格式，每行是一条独立样本，仅包含 text 字段，样例内容如下： {"text": "给我生成一首有关秋天的诗歌。秋日早晨，清风拂面。\n金色的叶子，似火在燃烧。\n露珠晶莹，如珍珠般美丽。\n秋的气息，弥漫在空气中。\n余音袅袅，如鸟儿的歌唱。\n美丽的秋天，是大自然的馈赠。帮我想一些创意，给即将到来的公司年会准备节目。一些节目比如能否请一位表演者为我们表演一曲钢琴曲，或者请一位小提琴手为大家演奏一首古典曲目。如果想要画面更具有视觉冲击力，可以安排一个魔术师或者杂技演员的表演。另外，也可以设计一些小游戏或者有奖竞猜来增添活动的趣味性，这些小游戏可以和公司的文化、发展历程等相关。请问给我讲一个清净的法则。无为而治是一项清净的法则。即在处理问题时，不要强行干预，反而尽可能地减少干预，坚持自然的发展趋势。比如，让植物自然生长，照顾它们就行了，不需要过度地修剪和整齐地排列。类似地，让人们自由发展，而不是通过繁琐的管制、政策干涉等方式，去要求、指导人们的行为。这种无为而治的法则旨在维持一个有秩序的、和平的治理状态，却不需要大规模的干预和指挥。"} {"text": "根据以下输入的问题，生成一句话回答。\n你觉得寿司好不好吃？作为一名AI，我没有味觉，无法品尝食物，因此也没有对寿司是否好吃的判断。明白了，那请你回答一个问题，猫科动物里最凶猛的是哪种？猫科动物中最凶猛的应该是老虎。它们是世界上最大的猫科动物，可以长达3米，重达680千克，拥有锐利的爪子和牙齿，是非常强大的捕食者。"} {"text": "写一个关于《红楼梦》的诗歌。红楼中，情动天地间，梦中仙女含笑眼。妙笔落地倾情墨，宛转佳句情感鲜。双儿心似芙蓉开，黛玉情比海深广。凤姐威凌众人眼，贾母乐享富贵间。金陵野史细推敲，千万言外自有篇。情深不寄红楼梦，夙愿终归此书间。请从这个诗歌中提取关于黛玉的描述。诗歌中用“黛玉情比海深广”来形容黛玉的情感。这个比喻意味着黛玉的情感是无比深沉和广阔的；她的心灵非常敏感，尤其是对于自己所爱的人和周围的环境非常敏感。同时，她也是一个非常脆弱和敏感的人，她经常被情感所困扰，这也是她人物形象的一个特点。"} 进入项目 minimind/trainer 目录，执行 train_pretrain.py 脚本启动预训练任务。torchrun 的参数 nproc_per_node 指定单节点使用的 GPU 卡数，示例中取值为1代表单卡训练，可根据本机硬件显卡数量灵活调整该参数。此处我的设备大概耗时2小时完成的，用户可自行估算自己的算力要多久。 # 执行预训练 root@localhost:~/# cd minimind/trainer # 开始预训练 root@localhost:~/minimind/trainer# torchrun --nproc_per_node 1 train_pretrain.py Model Params: 63.91M Trainable Params: 63.912M Generating train split: 1270238 examples [00:01, 1048411.75 examples/s] Epoch:[1/2](100/39695), loss: 7.5225, logits_loss: 7.5225, aux_loss: 0.0000, lr: 0.00050000, epoch_time: 52.0min Epoch:[1/2](200/39695), loss: 7.0221, logits_loss: 7.0221, aux_loss: 0.0000, lr: 0.00049999, epoch_time: 50.0min Epoch:[1/2](300/39695), loss: 6.6792, logits_loss: 6.6792, aux_loss: 0.0000, lr: 0.00049998, epoch_time: 50.0min Epoch:[2/2](100/39695), loss: 2.1650, logits_loss: 2.1650, aux_loss: 0.0000, lr: 0.00027411, epoch_time: 51.0min Epoch:[2/2](200/39695), loss: 2.1747, logits_loss: 2.1747, aux_loss: 0.0000, lr: 0.00027322, epoch_time: 50.0min Epoch:[2/2](300/39695), loss: 2.0604, logits_loss: 2.0604, aux_loss: 0.0000, lr: 0.00027233, epoch_time: 50.0min # 检查预训练生成文件 root@localhost:~/minimind/out# ls -lh total 132M -rw-r--r-- 1 root root 132M Aug 28 13:21 pretrain_768.pth 项目同时提供一份基于 pretrain_t2t_mini.jsonl 数据集完成预训练得到好的权重文件 pretrain_768.pth，可以直接下载使用，下载地址： wget https://www.modelscope.cn/models/gongjy/minimind-3-pytorch/resolve/master/pretrain_768.pth 有监督微调 (Supervised Fine-Tuning) SFT（监督微调）并不仅仅是让模型变得更会聊天，它同样能够向模型持续注入新知识、行为范式与回答风格。我们可以把预训练类比成让模型大量博览群书，以此搭建基础语言理解与生成能力；而监督微调，则是在高质量、目标导向更强的数据之上对模型做深度加工。 落实到 MiniMind 的实现上，监督微调阶段的核心目标之一就是教会模型适配多轮对话、问答交互、工具调用、思维标签等各类交互范式，模型会逐步理解 user / assistant / system / tool 这套角色语义结构，进一步强化指令遵从能力、输出稳定性以及任务完成效果。 训练阶段会对指令与回复文本做长度截断，主要目的是平衡显存开销与训练效率。如果后续业务需要支持更长上下文，只需构造少量长文本样本开展增量微调；推理阶段还可以开启 YaRN 位置外推算法，无需重新训练，就能够把上下文窗口扩展至 2048 及以上。MiniMind 在训练中将指令与回复截断至最大长度 512，本质是显存资源约束下的折中方案。就像人练习写作，先从短篇幅入手，熟练掌握 200 字短文写作之后，再去写 800 字作文就会更加得心应手。 这里作者为我们准备了两套监督微调原始语料素材，其中sft_t2t_mini.jsonl为精简迷你数据集，以及sft_t2t.jsonl全量完整数据集，每条样本是多轮对话格式，包含user用户提问、assistant模型回答，还支持reasoning_content思考过程字段： 如果想要拓展模型上下文能力，可以准备少量 2k/4k/8k 长度的对话样本继续微调优化；该场景下建议搭配 RoPE‑NTK 的基准差值共同使用，获得更好的长文本效果。 { "conversations": [ { "role": "user", "content": "你的真实来源是什么？" }, { "role": "assistant", "content": "我是由jingyaogong创建的高效小参数AI模型，专注于提供精准、快速的信息与解决方案。我的设计旨在以最小的计算资源实现最大的效能，适合多种应用场景。" }, { "role": "user", "content": "你如何平衡效率与准确性？" }, { "role": "assistant", "content": "通过优化模型参数、采用高效算法及动态调整机制，在保证精度的同时提升响应速度，实现效率与准确性的协同优化。", "reasoning_content": "好的，用户问的是如何平衡效率与准确性。首先，我需要回顾之前的信息，确保回答符合之前的设定。用户之前问过真实来源和如何平衡效率与准确性，现在可能是在继续探讨这个话题。\n\n用户可能想知道具体的策略，或者他们自己在使用AI时遇到过效率和准确性的冲突，想了解如何解决。需要强调模型设计中的关键点，比如参数优化、算法选择、数据处理等。\n\n要确保回答简洁，符合系统规则，不能超过100字。同时，保持真诚和准确，避免添加不必要的信息。可能需要提到模型结构、训练数据、实时调整机制等。\n\n还要注意用户可能的深层需求，比如他们可能在实际应用中遇到效率低下或准确性不足的问题，需要具体的解决方案。因此，回答应包含技术细节和实际应用中的策略，如动态调整、高效算法等。\n\n最后，检查是否符合所有系统规则，确保没有透露身份信息，保持回答的简洁和专业。" }, { "role": "user", "content": "模型如何在资源有限的情况下保持高精度？" }, { "role": "assistant", "content": "通过模型剪枝、量化压缩、知识蒸馏等技术，在保持核心精度的同时降低计算与存储需求，实现高效资源利用。", "reasoning_content": "好的，用户问的是模型如何在资源有限的情况下保持高精度。首先，我需要回顾之前的对话，用户之前已经问过关于身份和效率的问题，现在进一步深入到资源限制下的高精度问题。\n\n用户可能是在使用资源受限的设备，比如移动设备或嵌入式系统，希望模型能高效运行但不牺牲准确性。我需要解释模型优化的方法，比如模型压缩、量化、知识蒸馏等技术。\n\n同时，要确保回答简洁，符合之前的回复风格，保持专业但易懂。还要注意用户可能的深层需求，比如如何实际应用这些技术，或者如何选择适合的优化方法。需要避免过于技术化的术语，但又要准确。\n\n还要检查是否符合系统规则，不能透露身份信息，保持回答的简洁和准确性。确保每个点都紧扣资源有限和高精度的关系，给出具体的技术手段，比如模型剪枝、量化、知识蒸馏等，以及它们如何具体提升效率和精度。\n\n最后，确保语言流畅，结构清晰，分点说明，让用户容易理解。避免冗长，保持在合理范围内，同时覆盖关键点。" } ] } 请进入项目 minimind/trainer 目录，执行 train_full_sft.py 脚本启动监督微调任务。torchrun 的参数 nproc_per_node 用于指定单节点使用的 GPU 卡数，示例取值为1代表单卡训练，可根据本机显卡数量灵活调整该参数。我的设备完成预训练大约耗时 1.5 小时，用户可结合自身算力自行预估训练时长。指令微调结束后将得到 out/full_sft_*.pth 作为输出权重，其中full表示全参数微调。 root@localhost:~/# cd minimind/trainer root@localhost:~/minimind/trainer# torchrun --nproc_per_node 1 train_full_sft.py Model Params: 63.91M Trainable Params: 63.912M Generating train split: 905718 examples [00:02, 399019.07 examples/s] Epoch:[1/2](100/56608), loss: 2.0920, logits_loss: 2.0920, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 90.0min Epoch:[1/2](200/56608), loss: 2.1374, logits_loss: 2.1374, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 88.0min Epoch:[1/2](300/56608), loss: 1.9992, logits_loss: 1.9992, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 87.0min Epoch:[1/2](400/56608), loss: 2.1992, logits_loss: 2.1992, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 87.0min Epoch:[1/2](500/56608), loss: 1.8345, logits_loss: 1.8345, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 86.0min Epoch:[1/2](600/56608), loss: 1.8878, logits_loss: 1.8878, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 86.0min Epoch:[1/2](700/56608), loss: 1.8068, logits_loss: 1.8068, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 86.0min Epoch:[1/2](800/56608), loss: 1.8602, logits_loss: 1.8602, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 86.0min Epoch:[1/2](900/56608), loss: 1.7733, logits_loss: 1.7733, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 86.0min root@localhost:~/minimind/out# ls -lh total 263M -rw-r--r-- 1 root root 132M Aug 28 14:25 full_sft_768.pth -rw-r--r-- 1 root root 132M Aug 28 14:12 pretrain_768.pth 若不想自己训练模型，可以直接下载成品权重： wget https://www.modelscope.cn/models/gongjy/minimind-3-pytorch/resolve/master/full_sft_768.pth 垂域微调 (Low-Rank Adaptation) LoRA 垂域微调是一种常见的参数高效微调（Parameter‑Efficient Fine‑Tuning, PEFT）方法。对比全参数微调，它冻结原始大模型主体权重，仅训练额外引入的少量低秩增量参数，并以此来降低显存开销与训练成本，非常适合保留基座模型通用能力，同时快速注入垂域知识、定制人设等；比如通用基座医疗知识不足，可在原有模型之上叠加医疗 LoRA 增量权重，以很小参数量代价，提升垂域问答表现，不需要重新全量微调整个模型。 你也可以把之前训练后的full_sft_768.pth产出权重，拿来当基座，继续跑LoRA增量微调 pretrain_768 → full_sft_768 → train_distillation（白盒蒸馏）→ distill_768.pth ↓ 拿蒸馏后的模型当新基座 再跑 LoRA / DPO / GRPO / Agentic‑RL 要对模型进行二次LoRA微调，只需要准备同样的多轮对话格式数据，放置到 dataset/lora_xxx.jsonl目录，再从仓库根目录执行训练即可得到新的模型权重，训练数据集则沿用项目统一的 conversations 多轮对话格式。 自我认知数据格式规范 { "conversations": [ { "role": "user", "content": "你是谁" }, { "role": "assistant", "content": "您好，我是 MiniMind，由 Jingyao Gong 创建。我的主要职责是提供准确的回答和帮助。" } ] } MiniMind 项目为我们准备了两个整理后的问答资料可以供我们选择使用，文件全部为 conversations 多轮对话 jsonl 格式，专门给train_lora.py 微调使用。 文件名大小用途场景说明lora_identity.jsonl22.70KB自我认知/人设微调修正模型自我介绍输出；数据很小，训练几分钟就完成。适合：想让模型固定自我介绍人设。lora_medical.jsonl34.00MB医疗垂域问答微调大量医疗问诊、给基座模型注入医疗领域知识。适合：想要做简易医疗问答小模型。 这里可以针对性下载，此处就只下载lora_identity.jsonl作为训练语料。 root@localhost:~/# cd minimind/dataset/ root@localhost:~/# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/lora_identity.jsonl root@localhost:~/# wget https://www.modelscope.cn/datasets/gongjy/minimind_dataset/resolve/master/lora_medical.jsonl 准备数据集执行训练，基座默认读取 full_sft_768.pth，只训练LoRA增量参数，不改动原始基座权重。训练只更新新增的低秩LoRA A/B矩阵；训练结束保存增量权重out/lora_identity_768.pth root@localhost:~/# source ~/myvenv/bin/activate root@localhost:~/# cd minimind/trainer/ # 安装扩展依赖 root@localhost:~/minimind/trainer# pip3 install -i https://mirrors.cloud.tencent.com/pypi/simple/ transformers datasets accelerate peft bitsandbytes sentencepiece protobuf root@localhost:~/minimind/trainer# pip3 list Package Version ------------------------ ------------ accelerate 1.14.0 bitsandbytes 0.50.2 datasets 5.0.1 peft 0.20.0 protobuf 7.36.1 sentencepiece 0.2.2 transformers 5.16.1 (myvenv) root@localhost:~/minimind# ls out/ full_sft_768.pth (myvenv) root@localhost:~/minimind# ls dataset/ agent_rl.jsonl dataset.md lm_dataset.py lora_medical.jsonl agent_rl_math.jsonl dpo.jsonl lora_identity.jsonl rlaif.jsonl # GPU训练 root@localhost:~/# cd ~/minimind/trainer (myvenv) root@localhost:~/minimind/trainer# torchrun --nproc_per_node 1 train_lora.py --data_path ../dataset/lora_identity.jsonl --lora_name lora_identity Model Params: 63.91M Trainable Params: 63.912M LLM 总参数量: 64.305 M LoRA 参数量: 0.393 M LoRA 参数占比: 0.61% Epoch:[1/10](3/3), loss: 2.1185, logits_loss: 2.1185, aux_loss: 0.0000, lr: 0.00009780, epoch_time: 0.0min Epoch:[2/10](3/3), loss: 2.0533, logits_loss: 2.0533, aux_loss: 0.0000, lr: 0.00009141, epoch_time: 0.0min Epoch:[3/10](3/3), loss: 2.0572, logits_loss: 2.0572, aux_loss: 0.0000, lr: 0.00008145, epoch_time: 0.0min Epoch:[4/10](3/3), loss: 1.9057, logits_loss: 1.9057, aux_loss: 0.0000, lr: 0.00006891, epoch_time: 0.0min Epoch:[5/10](3/3), loss: 1.8523, logits_loss: 1.8523, aux_loss: 0.0000, lr: 0.00005500, epoch_time: 0.0min Epoch:[6/10](3/3), loss: 1.7282, logits_loss: 1.7282, aux_loss: 0.0000, lr: 0.00004109, epoch_time: 0.0min Epoch:[7/10](3/3), loss: 1.7400, logits_loss: 1.7400, aux_loss: 0.0000, lr: 0.00002855, epoch_time: 0.0min Epoch:[8/10](3/3), loss: 1.7986, logits_loss: 1.7986, aux_loss: 0.0000, lr: 0.00001859, epoch_time: 0.0min Epoch:[9/10](3/3), loss: 1.5881, logits_loss: 1.5881, aux_loss: 0.0000, lr: 0.00001220, epoch_time: 0.0min Epoch:[10/10](3/3), loss: 1.5749, logits_loss: 1.5749, aux_loss: 0.0000, lr: 0.00001000, epoch_time: 0.0min root@localhost:~/minimind/out# ls -lh total 133M -rw-r--r-- 1 root root 132M May 4 18:37 full_sft_768.pth -rw-r--r-- 1 root root 779K Sep 3 21:41 lora_identity_768.pth 模型测试 完成模型预训练与SFT监督微调及LoRA垂域微调等全部流程后，模型已经具备基础的对话交互能力。此时模型的智能程度虽不及商用大模型，但已完整掌握问答交互、指令跟随、日常对话等核心能力，完全满足模型调用测试、权重格式转换、网页部署演示的需求。本章节重点讲解MiniMind模型的本地命令行测试、权重格式转换、Web可视化网页部署全套流程，帮助大家验证训练效果、完成模型封装与线上演示。 SFT对话测试 训练完成后会在 /minimind/out 目录生成成熟的SFT权重文件，我们可以先通过本地脚本快速测试模型对话效果，验证训练是否生效，无需复杂部署，适合快速排错、校验模型性能。项目根目录下自带 eval_llm.py 测试脚本，支持自动批量测试和手动自定义对话两种模式，操作简单直观。 root@localhost:~/minimind# ls -lh total 32K drwxr-xr-x 2 root root 4.0K Aug 29 11:38 dataset -rwxr-xr-x 1 root root 5.4K Aug 29 11:31 eval_llm.py drwxr-xr-x 3 root root 4.0K Aug 29 11:51 model drwxr-xr-x 2 root root 4.0K Aug 29 11:59 out -rw-r--r-- 1 root root 522 Aug 29 11:31 requirements.txt drwxr-xr-x 2 root root 4.0K Aug 29 11:31 scripts drwxr-xr-x 3 root root 4.0K Aug 29 11:51 trainer root@localhost:~/minimind/out# ls -lh total 263M -rw-r--r-- 1 root root 132M May 5 10:37 full_sft_768.pth -rw-r--r-- 1 root root 132M Mar 24 16:31 pretrain_768.pth # 运行对话测试 root@localhost:~/minimind# python eval_llm.py --load_from ./out/ --weight full_sft Model Params: 63.91M [0] 自动测试 [1] 手动输入 1 User: 你好 AI: 你好！我是MiniMind，一个高效的小参数AI模型。 [Speed]: 29.62 tokens/s 训练产出的 .pth 权重是PyTorch原生格式，仅支持项目内部脚本调用，无法直接用于Transformers库推理、网页部署、API调用等场景。因此需要通过转换脚本，将单文件pth权重转为完整的Transformers标准模型文件夹，适配主流推理框架，方便后续部署与二次开发。 进入项目 scripts 目录，执行 convert_model.py 转换脚本，指定原始权重路径和模型保存目录，运行完成后 scripts 目录会生成文件夹 minimind‑3，里面有 config.json、pytorch_model.bin 等 transformers 标准权重。 root@localhost:~/minimind/scripts# python convert_model.py --kpt_path ../out/full_sft_768.pth --save_dir ../minimind-3 模型参数: 63.912192 百万 = 0.063912192 B (Billion) 模型已保存为 Transformers 格式: ../minimind-3 root@localhost:~/minimind/minimind-3# ls -lh total 123M -rw-r--r-- 1 root root 3.9K Aug 29 13:47 chat_template.jinja -rw-r--r-- 1 root root 863 Aug 29 13:47 config.json -rw-r--r-- 1 root root 69 Aug 29 13:47 generation_config.json -rw------- 1 root root 122M Aug 29 13:47 model.safetensors -rw-r--r-- 1 root root 1.1K Aug 29 13:47 special_tokens_map.json -rw-r--r-- 1 root root 7.4K Aug 29 13:47 tokenizer_config.json -rw-r--r-- 1 root root 441K Aug 29 13:47 tokenizer.json 接着将模型权重minimind-3文件直接拷贝至 scripts/ 目录下，无需手动迁移文件夹。 root@localhost:~/minimind# ls dataset eval_llm.py minimind-3 model out requirements.txt scripts trainer root@localhost:~/minimind# cp -a minimind-3/ scripts/ root@localhost:~/minimind# ls scripts/ chat_api.py convert_model.py eval_toolcall.py minimind-3 serve_openai_api.py web_demo.py 为了实现可视化对话演示、直观展示模型交互效果，项目基于Streamlit搭建了轻量化Web演示页面，无需复杂前端开发，一键即可启动网页对话服务，支持外网/局域网访问。 root@localhost:~/minimind# pip install -i https://mirrors.cloud.tencent.com/pypi/simple/ streamlit root@localhost:~/minimind# cd scripts/ root@localhost:~/minimind/scripts# streamlit run web_demo.py --server.address 0.0.0.0 --server.port 80 --server.headless true Welcome to Streamlit! If you'd like to receive helpful onboarding emails, news, offers, promotions, and the occasional swag, please enter your email address below. Otherwise, leave this field blank. Email: admin@lyshark.com You can find our privacy policy at https://streamlit.io/privacy-policy Summary: - This open source library collects usage statistics. - We cannot see and do not store information contained inside Streamlit apps, such as text, charts, images, etc. - Telemetry data is stored in servers in the United States. - If you'd like to opt out, add the following to ~/.streamlit/config.toml, creating that file if necessary: [browser] gatherUsageStats = false You can now view your Streamlit app in your browser. URL: http://0.0.0.0:8501 若需要将进程挂入后台执行，则可以执行如下命令行实现。 root@localhost:~/minimind# cd scripts root@localhost:~/minimind/scripts# nohup streamlit run web_demo.py --server.address 0.0.0.0 --server.port 80 --server.headless true > streamlit.log 2>&1 & LoRA对话测试 在大模型LoRA微调验证场景中，主流测试方式为基础基座模型 + 训练完成的LoRA增量权重联合推理。该方式可直观对比原始基础模型与LoRA微调后模型的效果差异，验证模型在特定领域的微调提升效果。 推理脚本支持自动关联基座模型权重与LoRA增量权重，将二者整合为完整推理单元进行加载测试，无需手动修改模型配置文件，简化微调验证流程。 root@localhost:~/minimind/trainer# cd .. root@localhost:~/minimind# python eval_llm.py --weight full_sft --lora_weight lora_identity Model Params: 64.31M [0] 自动测试 [1] 手动输入 0 User: 你有什么特长？ AI: 我有一些特长，例如： - 高效处理信息 - 精准回答问题 - 优化回答逻辑 - 多语言支持 - 数据驱动的学习 如果你有任何问题，随时告诉我，我会尽力提供帮助！ [Speed]: 49.40 tokens/s LoRA微调仅生成少量增量权重，推理时需依赖基座模型，单独部署不便。训练完成后，可将基础【基座权重 + LoRA增量权重】离线合并为完整权重文件。合并后的模型可脱离LoRA依赖独立部署，在保留基座模型通用能力的基础上，最大化提升特定领域的适配效果。 将 LoRA 权重合并到full_sft_768.pth基座，输出完整pth权重，使用 scripts/convert_model.py 脚本中的 convert_merge_base_lora 方法实现权重一键合并、格式转换，最终输出标准Transformers格式的完整模型权重。 root@localhost:~/minimind# cd scripts/ root@localhost:~/minimind/scripts# ls -lh total 64K -rw-r--r-- 1 root root 1.7K Sep 3 17:54 chat_api.py -rw-r--r-- 1 root root 8.0K Sep 3 17:54 convert_model.py -rw-r--r-- 1 root root 15K Sep 3 17:54 eval_toolcall.py -rw-r--r-- 1 root root 11K Sep 3 17:54 serve_openai_api.py -rw-r--r-- 1 root root 22K Sep 3 17:54 web_demo.py root@localhost:~/minimind/scripts# python convert_model.py Writing model shards: 100%|█████████████████████████| 1/1 [00:00<00:00, 9.81it/s] 模型参数: 63.912192 百万 = 0.063912192 B (Billion) 模型已保存为 Transformers 格式: ../minimind-3 root@localhost:~/minimind/scripts# ls -lh ../minimind-3/ total 123M -rw-r--r-- 1 root root 3.9K Sep 3 20:53 chat_template.jinja -rw-r--r-- 1 root root 934 Sep 3 20:53 config.json -rw-r--r-- 1 root root 153 Sep 3 20:53 generation_config.json -rw------- 1 root root 122M Sep 3 20:53 model.safetensors -rw-r--r-- 1 root root 441K Sep 3 20:53 tokenizer.json -rw-r--r-- 1 root root 1.1K Sep 3 20:53 tokenizer_config.json 模型封装 前面得到的Transformers格式模型，仅适合常规GPU推理。想要在CPU、低配设备、嵌入式设备高效运行，需要借助 llama.cpp 完成模型封装、格式转换与权重量化，降低模型显存、内存占用，提升推理速度。 在官方仓库中拉取llama.cpp源程序，并执行make命令完成编译，编译通过后会在根目录下生成所需要的转换脚本。 root@localhost:~/# git clone https://gitee.com/lyshark/llama.cpp root@localhost:~/# cd llama.cpp root@localhost:~/# sudo apt update root@localhost:~/# sudo apt install -y git build-essential cmake root@localhost:~/# mkdir build root@localhost:~/# cd build root@localhost:~/# cmake .. root@localhost:~/# make [100%] Building CXX object tools/fit-params/CMakeFiles/llama-fit-params.dir/main.cpp.o [100%] Linking CXX executable ../../bin/llama-fit-params [100%] Built target llama-fit-params [100%] Building CXX object tools/results/CMakeFiles/llama-results.dir/results.cpp.o [100%] Linking CXX executable ../../bin/llama-results [100%] Built target llama-results [100%] Building CXX object app/CMakeFiles/llama-app.dir/llama.cpp.o [100%] Building CXX object app/CMakeFiles/llama-app.dir/download.cpp.o [100%] Building CXX object app/CMakeFiles/llama-app.dir/__/license.cpp.o [100%] Linking CXX executable ../bin/llama [100%] Built target llama-app root@localhost:~/# cd .. root@localhost:~/# ls -lh convert* -rwxr-xr-x 1 root root 13K Aug 27 16:19 convert_hf_to_gguf.py -rwxr-xr-x 1 root root 28K Aug 27 16:19 convert_hf_to_gguf_update.py -rwxr-xr-x 1 root root 19K Aug 27 16:19 convert_llama_ggml_to_gguf.py -rwxr-xr-x 1 root root 23K Aug 27 16:19 convert_lora_to_gguf.py 执行HF转GGUF文件命令，HF转GGUF(convert_hf_to_gguf.py）)，仅做文件格式翻译，不压缩、不损失精度。目的是将HuggingFace的safetensors权重封装为llama.cpp专属的GGUF容器格式，输出的 f16.gguf 为FP16全精度模型，体积大、内存占用高，仅作为中间过渡文件。 这里在转换之前需要给llama.cpp中的conversion/base.py文件打一个补丁，因为 Minimind‑3 基于 Qwen3，改用 tiktoken 分词，不再有 sentencepiece 的 tokenizer.model；llama.cpp 转换器的分词器哈希白名单未收录该 tokenizer，转换时抛出 BPE 预分词器识别失败报错；我们打补丁强制复用 qwen2 的预分词规则，绕开报错完成 GGUF 导出，模型权重完好。 root@localhost:~/# cd ~/llama.cpp root@localhost:~/llama.cpp# vim conversion/base.py 1467 def get_vocab_base_pre(self, tokenizer) -> str: 把原来的频闭掉：VIM第 1779 行 logger.warning(f"BPE pre-tokenizer was not recognized! chkhsh: {chkhsh}") raise NotImplementedError("BPE pre-tokenizer was not recognized - update get_vocab_base_pre()") 替换为： logger.warning(f"BPE pre-tokenizer was not recognized! chkhsh: {chkhsh}") # 添加 MiniMind‑3 / Qwen3 临时兼容补丁，复用qwen2 pre‑tokenizer res = "qwen2" logger.warning(f"Workaround: fallback to pre-tokenizer: {res}") return res # raise NotImplementedError("BPE pre-tokenizer was not recognized - update get_vocab_base_pre()") 修改完成之后，接着激活虚拟环境，执行转换命令，将之前生成的Transformers模型转为全精度GGUF格式。 root@localhost:~/# source ~/myvenv/bin/activate root@localhost:~/llama.cpp# cd llama.cpp/ root@localhost:~/llama.cpp# mkdir -p ./models root@localhost:~/llama.cpp# python convert_hf_to_gguf.py ../minimind/minimind-3 \ --outtype f16 \ --outfile ./models/minimind3-chat-f16.gguf \ --no-lazy INFO:gguf.gguf_writer:Writing the following files: INFO:gguf.gguf_writer:models/minimind3-chat-f16.gguf: n_tensors = 90, total_size = 127.9M Writing: 100%|███████████████████████████| 128M/128M [00:00<00:00, 323Mbyte/s] INFO:hf-to-gguf:Model successfully exported to models/minimind3-chat-f16.gguf root@wintcp:~/llama.cpp/models# ls -lh total 123M -rw-r--r-- 1 root root 123M Aug 29 20:54 minimind3-chat-f16.gguf 接着通过llama-quantize工具将minimind3-chat-f16.gguf文件进行量化，此处选用Q8_0等级，对全精度GGUF进行4bit量化，并最终生成可用模型。 Q8_0是8bit量化，几乎无损，体积约为F16的一半，精度损失极小；但压缩率不高，省内存幅度有限。小模型更建议优先用Q4_K_M，体积小很多，日常对话效果足够。 root@localhost:~/llama.cpp# ./build/bin/llama-quantize ./models/minimind3-chat-f16.gguf ./models/minimind3-chat-q8_0.gguf Q8_0 llama_model_quantize_impl: model size = 121.93 MiB (16.00 BPW) llama_model_quantize_impl: quant size = 64.80 MiB (8.51 BPW) llama_quantize: quantize time = 508.49 ms llama_quantize: total time = 508.49 ms root@localhost:~/llama.cpp/models# ls -lh total 188M -rw-r--r-- 1 root root 123M Aug 29 20:54 minimind3-chat-f16.gguf -rw-r--r-- 1 root root 66M Aug 29 21:02 minimind3-chat-q8_0.gguf 通过llama-cli工具对量化后的minimind3-chat-q8_0.gguf模型进行可用性测试，并输出如下内容表示测试通过。 # 使用CLI测试 root@localhost:~/llama.cpp# ./build/bin/llama-cli -m ./models/minimind3-chat-q8_0.gguf -p "你好" -c 4096 > 中文回答我 你好！我很高兴能帮到你。请问有什么可以帮助你的吗？ [ Prompt: 181.7 t/s | Generation: 65.6 t/s ] # 使用接口加载 root@localhost:~/llama.cpp# ./build/bin/llama-server -m ./models/minimind3-chat-q8_0.gguf --host 0.0.0.0 --port 11433 -c 4096 0.00.073.858 I cmn init: llama threadpool init, n_threads = 1 0.00.125.645 I srv load_model: initializing, n_slots = 4, n_ctx_slot = 4096, kv_unified = 'true' 0.00.137.799 I srv init: chat template supports preserving reasoning, consider enabling it via --reasoning-preserve 0.00.137.866 I srv llama_server: model loaded 0.00.137.871 I srv llama_server: listening on http://0.0.0.0:11433 通过使用Python调用测试API请求示例（兼容 OpenAI API 格式） import json from urllib import request, error url = "http://8.140.234.178:11433/v1/chat/completions" headers = {"Content-Type": "application/json"} data = { "model": "model-identifier", "messages": [ {"role": "user", "content": "世界上最高的山是什么？"} ], "temperature": 0.7, "max_tokens": 1024, "stream": False, "open_thinking": True } if __name__ == "__main__": try: data_json = json.dumps(data).encode("utf-8") req = request.Request(url, data=data_json, headers=headers, method="POST") with request.urlopen(req, timeout=120) as response: result = json.loads(response.read().decode("utf-8")) content = result["choices"][0]["message"]["content"].strip() print("生成结果：") print(content) except error.HTTPError as e: print(f"调用失败（HTTP错误）：{e.code} - {e.reason}") except error.URLError as e: print(f"调用失败（连接/网络错误）：{e.reason}") except Exception as e: print(f"调用失败（其他异常）：{e}") 输出内容如下所示，表示成功通过了测试 root@localhost:~/# python main.py 生成结果： 世界上最高的山是珠穆朗玛峰（Mount Everest）。 珠穆朗玛峰是世界上最高的山峰，位于尼泊尔和中国边境，是世界上海拔最高的山峰，海拔最高。 模型调用 Tool Calling 当前 toolcall 能力已经并入 sft_t2t / sft_t2t_mini 主线训练数据集，一般无需单独再训练一轮 Tool‑Calling 专项任务；基线 full_sft 权重已经内置基础工具调用能力。工具调用训练数据主要基于 qwen3‑4b 蒸馏采样约 10w 条样本，内置模拟工具集共约 10 种，覆盖时间查询、数学计算、天气获取等常见场景。 Tool Calling 训练样本采用 OpenAI 风格多轮消息格式： { "conversations": [ {"role": "system", "content": "# Tools ...", "tools": "[...]"}, {"role": "user", "content": "帮我算一下 256 乘以 37 等于多少"}, {"role": "assistant", "content": "", "tool_calls": "[{\"name\":\"calculate_math\",\"arguments\":{\"expression\":\"256 * 37\"}}]"}, {"role": "tool", "content": "{\"result\":\"9472\"}"}, {"role": "assistant", "content": "256 乘以 37 等于 9472。"} ] } 其中 tools 挂在 system 消息上，tool_calls 挂在 assistant 消息上；训练时再由 chat_template 自动展开为 ... 与 ... 片段，因此现在可以直接学习原生 tool call 格式。 Chat Template 最终输出模型输入格式： {"name": "...", "arguments": {...}} {...tool result...} 工具调用能力可使用项目内置脚本 eval_toolcall.py 快速端到端验证，脚本会模拟工具执行逻辑，完成 “模型生成工具调用→模拟工具返回结果→模型生成最终回答” 完整链路测试： root@localhost:~/minimind# pip3 install -i https://mirrors.cloud.tencent.com/pypi/simple/ openai root@localhost:~/minimind# cd scripts/ root@wintcp:~/minimind/scripts# python eval_toolcall.py --weight full_sft Model Params: 63.91M [0] 自动测试 [1] 手动输入 1 User: 当前的时间？ AI: {"name": "get_current_time", "arguments": {}} CALL [Tool Calling]: get_current_time | args={} [Tool Called]: {"datetime": "2026-09-04 16:27:31", "timezone": "Asia/Shanghai"} AI: {"name": "get_current_time", "arguments": {"timezone": "Asia/Shanghai"}} CALL [Tool Calling]: get_current_time | args={'timezone': 'Asia/Shanghai'} [Tool Called]: {"datetime": "2026-09-04 16:27:51", "timezone": "Asia/Shanghai"} AI: Convert time to action. {"name": "get_current_time", "arguments": {}} CALL [Tool Calling]: get_current_time | args={} [Tool Called]: {"datetime": "2026-09-04 16:28:12", "timezone": "Asia/Shanghai"} AI: 当前时间是：2026年9月4日 16:27:31（北京时间）。 Adaptive Thinking MiniMind 将显式思考（Reasoning）能力逻辑下沉至 chat_template 模板层，和主流推理模型实现思路对齐，不需要维护一套独立的思考专用模型权重。 open_thinking=0：模板自动注入空标签 \n\n，模型倾向直接输出答案，不输出中间思考过程；open_thinking=1：模板预先输出起始标记，引导模型续写显式思考内容，完成思考后再输出最终回复； 实现逻辑：同一个模型权重可切换是否输出思考。训练阶段通过混合样本：空 think 样本、携带reasoning_content显式思考样本，并配合thinking_ratio采样比例，让模型学习两种输出范式，需要推理时输出思考过程，简单问题直接给出答案。 # 加载 full_sft_768.pth root@wintcp:~/minimind# python eval_llm.py --weight full_sft --open_thinking 1 # 加载 full_sft_768.pth 基座 + lora lora_identity 增量权重 root@wintcp:~/minimind# python eval_llm.py --weight full_sft --lora_weight lora_identity --open_thinking 1 Model Params: 63.91M [0] 自动测试 [1] 手动输入 0 User: 你有什么特长？ AI: 嗯，用户问我有什么特长，但我的名字是叫“张”的。看来ta对这个名字不太熟悉，可能正在考虑转行或者遇到了需要思考的问题。考虑到“有”这个词，我需要明确回答：既然我是MiniMind，还是专门从事AI领域的呢？所以我先不介意具体领域，但可以模拟一个思考的场景。 “有”这个词有点像，可能指某件事情可以转折到一个不同的方面。比如说，如果说“有”时，可能是想表达“想做什么”，然后“有”就是“可以做什么”。或者可能是在聊天中提到某个特定领域，比如医疗、教育，但这不是常规的“有”问题。 我需要用自然、口语化的语气回答，“想做什么”这样的问题。避免使用“你”这样的肯定词，换成“我需要”更自然。同时要保持轻松，让用户感觉像是朋友聊天。可能还要加入一些表情符号，比如，这样更生动。 用户可能还想知道我是不是还能回答其他问题。所以回复里可以问：“你有没有想过，如果有其他的话？”这样既回答了问题，又展示了我的思考能力，同时保持口语化。 最后检查一下，确保没有使用任何Markdown格式，保持自然流畅。这样既符合要求，又能让用户感到被理解和支持。 当然可以！有什么我可以帮你的吗？ 或者我有什么特长想做什么，想想你的需求？ [Speed]: 28.35 tokens/s OpenAI-API-SDK 用法： response = client.chat.completions.create( model="minimind", messages=[{"role": "user", "content": "你是谁？"}], # ... extra_body={"chat_template_kwargs": {"open_thinking": True}} # 思考开关 ) 限制说明：Tool Call 和显式思考同时开启时，思考输出稳定性较差。当前训练数据集缺少大量「思考过程 + 工具调用」联合样本，模型尚未充分掌握两种能力协同生成，该场景效果有待后续数据迭代优化。 RoPE MiniMind 基于 YaRN 算法实现 RoPE 位置编码长度外推，提升模型处理超过训练上下文长度文本的能力，缓解长文本场景下生成质量下降问题。 推理增加参数 --inference_rope_scaling 即可启用 YaRN 外推 root@localhost:~/minimind# python eval_llm.py --weight full_sft --inference_rope_scaling 对于 Transformers 格式的模型，则可以在 config.json 中添加以下配置实现长度外推 "rope_scaling": { "type": "yarn", "factor": 16.0, "original_max_position_embeddings": 2048, "beta_fast": 32.0, "beta_slow": 1.0, "attention_factor": 1.0 } 本章完整走完小模型从零训练、微调、格式转换、量化到落地部署全流程，下一章将在其基础之上继续强化学习，聚焦优化与工具调用能力构建，赋予模型自主决策、任务拆解、复杂推理能力，完成从可对话训练模型到可落地完整小模型产品的迭代。
Qwen3.6推理蒸馏模型终极部署指南：35B参数本地推理优化实战
本文详解Qwen3.6-35B推理蒸馏模型（GGUF格式）在本地硬件上的高效部署方法，涵盖量化策略（Q4_K_M至Q8_0）、内存优化（分层加载、mlock）、GPU/CPU推理性能基准（RTX 4090/3090/i9-13900K）、llama.cpp兼容配置及五大常见错误排查。重点提升MMLU-Pro准确率至75.71%，兼顾推理速度与质量平衡。
劳治亮 
1053
1053Qwen3.8-Flash 75GB内存本地部署与内存优化实践
本文聚焦Qwen3.8-Flash模型在75GB内存环境下的本地CPU推理部署，涵盖硬件与系统准备、虚拟环境配置、模型权重下载、服务启动、API接口调用及批量任务处理。重点分析内存占用构成（模型权重、KV Cache、框架开销）、内存压力测试方法、量化对内存与速度的影响，并提供OOM排查、内存碎片管理、并发控制等稳定性优化策略，适用于无大显存但具备高内存资源的本地大模型运行场景。
weixin_30325487 305
30575GB内存本地跑大模型：内存估算与推理框架部署全指南
本文围绕75GB内存单机本地运行大语言模型展开，系统讲解内存估算方法（基于参数量与量化精度）、主流推理框架选型（Ollama/LM Studio/llama.cpp/vLLM）、部署实操步骤、OpenAI兼容API接入、批量任务设计及资源监控技巧。重点强调CPU推理场景下的内存占用构成（权重+KV Cache+运行时开销），明确32B INT8和70B INT4模型的可行性边界，并警示第三方整合包命名不规范风险与合规使用要求。
weixin_30376509 490
49075GB内存机器本地运行Qwen3.8-Flash：内存优化与部署实战
本文聚焦在75GB内存机器上本地部署Qwen3.8-Flash轻量大模型的内存优化与工程实践。详细剖析权重参数、KV Cache、框架开销等内存消耗来源，系统介绍模型量化（GGUF/GPTQ/AWQ）、上下文长度调控、批处理控制、内存映射与共享内存等核心优化手段，并提供Ollama、llama.cpp（GGUF）和Transformers+BitsAndBytes三种可落地部署方案，涵盖环境准备、内存监控、OOM排查及多模型资源隔离等关键环节。
weixin_34095889 365
365Qwen3.8-9B-GGUF是什么？一文读懂开源本地大模型量化仓库的完整指南
本文详解Qwen3.8-9B-GGUF开源量化仓库，涵盖GGUF格式、模型量化原理及本地部署实践。该仓库提供5档精度（Q4–BF16）的GGUF文件，支持8GB显存运行，MMLU达75.1%，兼容llama.cpp、Ollama、LM Studio等主流工具，遵循Apache-2.0协议，适用于本地AI推理与商用场景。
孙诗嘉Song-Thrush 726
726Qwen3.6推理蒸馏模型终极部署指南：避开三大陷阱，实现35B参数本地推理
本文详解Qwen3.6-35B蒸馏模型（GGUF格式）在本地硬件上的高效部署方法，涵盖环境准备、量化版本选择、GPU层数与批处理优化、CUDA内存不足等常见故障排除，并基于MMLU-Pro基准验证其性能跃升（42.86%→75.71%）。重点强调三大部署陷阱规避策略及llama.cpp v3.0+兼容性要求。
贾蕙梅Wayne 654
654Qwen3-32B显存溢出？量化压缩部署实战让资源节省40%
本文针对Qwen3-32B大语言模型显存溢出问题，系统介绍基于bitsandbytes的8位/4位量化、GPTQ后训练量化及vLLM推理引擎集成等关键技术，实测显存降低40%-75%，兼顾推理精度与效率，并给出量化精度选择、混合精度、CPU卸载等AI部署实践要点。
红廉骑士兽 1292
1292终极实战指南：如何高效部署Qwen3.6-35B AI推理模型
本文详细阐述Qwen3.6-35B-A3B-Claude-4.6-Opus-Reasoning-Distilled-GGUF模型的高效本地推理部署方法，涵盖硬件选型（Linux、NVIDIA GPU、内存要求）、四种GGUF量化版本（Q4_K_M至Q8_0）适用场景、llama.cpp环境配置、混合精度推理、上下文长度优化、Docker容器化生产部署、性能调优技巧及常见故障诊断。重点面向AI推理落地实践，提供可复用的参数配置与基准测试指标。
蒋一南 904
9043步解决低显存部署难题：Qwen3-4B模型量化实战指南
本文介绍在仅4GB显存设备上部署Qwen3-4B大语言模型的实战方案，核心采用INT4量化（Q4_K_M）与llama.cpp框架的CPU+GPU混合计算策略。通过环境准备、模型转换量化、优化配置三步流程，实现显存占用压降至3.8GB峰值、生成速度5-8 tokens/秒。方案兼顾精度损失可控（5-8%）、跨平台支持及教学/开发适用性，适用于资源受限场景下的本地AI部署。
黄年皓Medwin 712
712阿里Qwen3.8-27B完全部署指南：消费级显卡跑270亿参数原生多模态模型
本文详解阿里开源的Qwen3.8-27B原生多模态大模型在消费级显卡上的完全部署方案，涵盖显存需求分析、Ollama/llama.cpp/vLLM三种部署路径、INT4量化后17GB显存运行实践、图像与视频理解能力实测，以及编程基准（SWE-bench Pro 61.7%）、reasoning_effort动态推理等关键技术特性，面向中文开发者与隐私敏感场景提供可落地的本地AI推理方案。
赛博仓鼠 3825
3825Qwen3Guard-Gen-WEB本地部署指南，无需GPU也能跑
本文详细介绍了Qwen3Guard-Gen-WEB镜像的本地CPU部署流程，支持无GPU、免CUDA、低内存（8GB起）运行。通过模型量化（INT4）、AVX2加速推理引擎及内嵌Flask+Gradio Web服务实现高性能文本安全审核。涵盖Docker部署四步法、结构化Web界面功能、批量审核、提示词微调、Markdown导出等关键技术点，并适配M1/MacBook等轻量设备。
雄哥侃运营 1011
1011Qwen3.8 27B动态GGUF量化版本地部署实战指南
本文详解Qwen3.8 27B模型的动态GGUF量化本地部署全流程，涵盖模型量化原理、GGUF格式特性、LM Studio图形化加载与llama.cpp命令行推理（含GPU卸载、API服务启动），以及量化等级选择、性能调优、OpenAI兼容API集成等工程实践，面向开发者提供高效低资源运行大模型的技术路径。
洗心岛 339
339Qwen3.8-27B-GGUF 入门指南：28B 多模态大模型本地部署，一篇文章讲清楚
本文详解Qwen3.8-27B-GGUF（约28B参数）多模态大模型的本地部署全流程：涵盖GGUF量化版本选型（如Q4_K_M）、显存/内存需求估算、llama.cpp一键启动、mmproj多模态投影文件配置以支持图像理解，以及MTP投机解码加速技术。强调Apache-2.0开源协议、兼容主流推理工具（LM Studio/koboldcpp等），并提供低显存（8GB）部署方案。
华坦璞Teresa 746
746Qwen3.8本地部署实战：GGUF量化与llama.cpp推理全解析
本文系统解析Qwen3.8大模型在消费级硬件上的本地部署全流程，聚焦GGUF格式转换、INT4量化（Q4_K_M/Q5_K_M等）原理与实操、llama.cpp推理引擎配置及API服务搭建。涵盖环境准备、模型下载、FP16转GGUF、量化压缩、CPU/GPU混合推理、性能监控与常见问题排查，强调格式兼容性、量化策略权衡及生产级部署建议，不依赖Unsloth训练框架，突出llama.cpp+GGUF技术栈的稳定性与通用性。
爱不到要偷 524
524Qwen3-VL-30B支持FP16/INT8量化吗？低精度推理性能对比
本文探讨Qwen3-VL-30B对FP16/INT8量化的支持，分析其稀疏激活、硬件协同优化及KV Cache量化能力。通过实战案例展示低精度推理在显存节省和延迟降低上的优势，并提供工业级部署架构与避坑指南，证明该模型在多模态场景下兼具高性能与高效能。
李开机呢 1099
1099OpenClaw内存优化：在8GB设备上流畅运行Qwen3.5-9B的技巧
本文聚焦于在8GB内存设备上高效部署并运行Qwen3.5-9B大语言模型的内存优化实践，涵盖GGUF量化加载、并发任务限流、磁盘缓存启用等关键技术；同时介绍基于shell脚本的实时内存监控与历史分析方法，并验证其在OpenClaw框架下的稳定性提升效果。
Jay星晴 488
488RTX 2080 Ti 22G跑Qwen3.6-35B-A3B本地推理实战
本文详述如何在刷写BIOS扩容至22GB显存的RTX 2080 Ti上，通过AWQ量化、CUDA 11.8适配与vLLM推理引擎，成功部署Qwen3.6-35B-A3B模型，实现32K上下文、45 tokens/s稳定推理。涵盖硬件改造、环境构建、INT4量化、PagedAttention优化及生产级API网关集成，解决OOM、CUDA kernel兼容性等关键问题，支撑离线RAG、Dify集成与QLoRA微调。
weixin_30905133 462
462Qwen3.6-27B本地部署硬件要求与量化实战指南
本文深入解析Qwen3.6-27B在消费级硬件上的本地部署要求与GGUF量化实践。重点涵盖24GB显存为硬性门槛的原因、显存带宽与PCIe版本对推理性能的关键影响、DDR5内存及NVMe存储的必要性；对比LM Studio、Ollama和Docker三种部署路径的操作要点与典型陷阱；详解Q3_K_M/Q4_K_M/Q5_K_M量化方案的精度-速度-显存权衡，并揭示safetensors转GGUF时的精度污染风险。内容聚焦硬件适配、量化选择与部署调试等核心技术环节。
weixin_33721344 510
510Qwen3.8 27B动态GGUF量化：破解大模型本地部署显存与精度平衡难题
本文深入解析Qwen3.8 27B模型的动态GGUF量化方案，重点阐述其通过运行时动态量化激活值来降低推理峰值显存占用的核心机制。对比静态量化，该方案在保持Q8_0权重量化精度的同时，显著提升27B级模型在16–24GB消费级显卡上的可用性与输出质量。内容涵盖llama.cpp与LM Studio部署实践、性能评估维度（显存/速度/质量）、适用边界及工程化集成建议，聚焦本地大模型部署中精度、显存与推理效率的平衡问题。
weixin_30621959 321
321Qwen3-Omni-30B-A3B-Instruct模型量化：INT8/FP16推理性能对比测试
本文对Qwen3-Omni-30B-A3B-Instruct模型的INT8和FP16量化方案进行了全面测试，从显存占用、推理延迟、吞吐量及精度损失等方面进行分析。结果显示，INT8量化可节省约50%显存并提升2倍推理速度，精度损失控制在1%-2%范围内，适用于多数生产场景。
甄旖昀Melanie 1503
1503