大模型初探和本地部署

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

大语言模型概述

大语言模型（Large Language Model, LLM），通常简称为“大模型”，其本质是一种基于大规模文本数据训练而成的“概率生成模型”。它并不具备真正的语言理解或世界认知能力，而是通过学习人类书写中字符、词汇、Token等序列之间的统计规律，实现“在给定输入的前提下，生成符合常识与逻辑表达的输出”。

可以从以下三个维度深入理解大模型的核心机制：

底层架构：由海量参数构成的“统计映射网络”

当前主流的大语言模型多采用Transformer神经网络结构。其核心是由数十亿至万亿级规模的参数（即权重矩阵）所组成的复杂计算系统。这些参数并非存储了明确的知识条目，而是记录了从训练语料中提取出的语言序列共现规律。

在训练过程中，模型通过分析大量文本资源（如网页、书籍、学术论文等），不断优化对“某个Token在特定上下文中出现的可能性”的预测能力。例如，当输入为“成都的特色美食是”时，模型会依据历史数据中高频搭配关系，赋予“火锅”“串串”更高的输出概率。

值得注意的是，单个参数本身不具备语义含义，它们仅反映字符间的关联强度。然而，当这些参数以极高密度协同运作时，便能模拟出类似“理解”和“推理”的行为表现。

核心机制：基于上下文的“条件概率生成”

所有大模型的输出行为——无论是生成自然语言、编写代码还是进行逻辑推导——本质上都是一个逐个Token的概率采样过程：

1. 输入内容（如“解释什么是大模型”）首先被切分为一系列Token，并转换为数字编号传入模型；
2. 模型结合当前上下文（包括原始输入及已生成的部分），计算下一个最可能的Token在整个词表中的概率分布；
3. 根据设定策略（如temperature控制随机程度），从中选择一个Token作为输出结果；
4. 重复上述步骤，直至完成整个生成任务。

举例来说，在处理“1+1=?”这一请求时，模型并非执行数学运算，而是依赖于训练集中“1+1=2”这一表达形式的极高频率，使得“2”成为概率最高的候选输出。这种机制决定了模型的行为更多是“模式复现”而非“逻辑推演”。

外在表现：涌现的“类智能能力”

尽管大模型没有自我意识，也不具备真正意义上的逻辑思维能力，但当参数规模达到一定程度（一般超过数十亿）、且训练数据足够广泛时，会呈现出被称为“涌现”的高级能力：

• 语言理解：能够识别歧义句意、解析代词指代对象（如判断“他”“它”具体指向谁）；
• 逻辑推理：可完成基础算术、因果链推导（如“因为下雨，所以地面湿”）；
• 知识问答：回答涉及历史、科学等领域的问题，实则为对训练数据中信息的重组与再现；
• 创作与编程：撰写文章、诗歌或生成代码，源于对文本/代码语法结构的学习。

需要强调的是，这些能力本质上仍是统计拟合的结果。一旦面对训练数据未覆盖的情境，或需精确推理的任务，模型可能出现“看似合理却错误”的输出，即所谓的“幻觉”现象。

~/qwen-math-service/models$ tree
.
└── Qwen2.5-Math-1.5B-Instruct
    ├── config.json
    ├── generation_config.json
    ├── LICENSE
    ├── merges.txt
    ├── model.safetensors
    ├── README.md
    ├── tokenizer_config.json
    ├── tokenizer.json
    └── vocab.json

大模型的本质再认识

总结而言，大语言模型是利用超大规模参数来捕捉文本序列中统计规律的一种工具。它通过逐Token的概率生成方式，模仿人类的语言表达、知识呈现和推理过程，但其根本目标是“拟合已有数据”，而非“理解现实世界”。

可以将其类比为一位“超级背诵者”——此人记住了全球所有出版物的内容，能快速引用、组合信息，甚至通过关联不同知识点“推导”出新结论。然而，他始终无法真正理解“为什么”，也无法创造出完全脱离已有资料的新思想。

关于 Token 的说明

在自然语言处理领域，Token（词元）是大模型处理文本的基本单位。由于模型本身只能操作数值，原始文本必须先经过分词处理，拆解成若干Token，再由分词器映射为唯一的整数编号。

例如，“我喜欢阅读”这句话可能被拆分为[“我”, “喜欢”, “阅读”]，并分别映射为[101, 235, 568]这样的数字序列。模型通过对这些数字之间关系的建模来间接“理解”语义。

模型规格中标注的4k、8k、32k等数值，表示该模型支持的最大Token处理长度。这一指标直接影响其处理长文本的能力——数值越大，越适合处理复杂文档、长对话或多轮上下文任务。

模型文件组成结构

完整的大模型通常包含三类关键文件：

• 模型权重文件
• 分词器文件
• 配置与辅助文件

其中，分词器负责将文字转化为模型可处理的数字编号，而权重文件则承载着模型进行推理和微调所需的核心参数。两者必须严格匹配——分词规则需与训练阶段一致，否则会导致解析错误或性能下降。

模型权重文件

作为整个模型体系中最核心的部分，模型权重文件保存了训练完成后神经网络的所有参数，包括连接权重、偏置项等。它是实现后续推理、部署与微调的基础。

不同框架和应用场景下存在多种主流格式，其中较为常见的是.safetensors格式，因其安全性高、加载速度快而被广泛采用。

分词器文件

分词器文件定义了如何将原始文本切分成Token，并建立从Token到ID的映射表。常见的类型包括BPE（Byte Pair Encoding）、WordPiece等。该文件必须与训练时使用的版本完全一致，否则将导致输入编码异常。

配置与辅助文件

此类文件包含模型结构配置（如层数、隐藏维度）、版本信息、Tokenizer配置路径、特殊Token定义等内容，用于指导模型正确加载和运行。典型文件如config.json、tokenizer_config.json等。

大模型相关框架与平台工具

围绕大模型的开发与应用，已形成较为完整的生态系统，主要包括底层推理部署框架、训练框架、轻量化微调方案以及上层应用平台。

底层框架分类

训练框架

专注于大规模分布式训练，支持千亿级以上参数模型的并行计算与优化。典型代表包括DeepSpeed、Megatron-LM等，提供数据并行、张量并行、流水线并行等多种策略，提升训练效率。

推理部署框架

针对模型上线服务设计，注重低延迟、高吞吐与资源利用率。常用工具有vLLM、TensorRT-LLM、HuggingFace Transformers + ONNX Runtime等，支持批量推理、缓存优化、量化压缩等功能。

轻量化微调框架

面向资源有限场景下的个性化适配需求，允许在不重新训练全量参数的情况下对模型进行调整。主流方法包括LoRA、Adapter、Prefix-Tuning等，配合PEFT库可高效实现低成本微调。

上层应用平台工具

为开发者提供可视化界面、API封装、流程编排等功能，降低使用门槛。适用于构建聊天机器人、智能客服、内容生成系统等实际应用。

常用平台工具对比

各类平台在功能侧重、易用性、扩展性方面各有差异。部分平台支持本地部署，适合数据敏感型业务；另一些则提供云端服务，便于快速集成与测试。选择时应综合考虑性能要求、部署成本与维护复杂度。

本地运行大模型实践指南

下载大模型

可通过公开模型仓库（如Hugging Face、ModelScope等）获取开源大模型。下载前需确认硬件条件是否满足模型运行需求（尤其是显存容量），并优先选择社区支持良好、文档齐全的版本。

模型文件说明

下载后的模型目录通常包含：

• pytorch_model.bin 或 model.safetensors —— 权重文件
• tokenizer.json / vocab.txt —— 分词器文件
• config.json —— 模型结构配置
• generation_config.json —— 生成参数默认设置

确保所有文件完整且版本匹配，方可正常加载。

代码测试大模型

使用Python脚本加载模型进行初步验证，常用库为HuggingFace的transformers。示例流程如下：

1. 导入必要的库模块；
2. 指定本地模型路径；
3. 调用AutoModelForCausalLM和AutoTokenizer加载模型与分词器；
4. 输入测试句子，观察输出效果。

此步骤可用于确认模型能否正确加载并生成合理响应。

部署服务

项目结构

标准部署项目通常包含以下目录结构：

/model
  /weights          # 存放模型权重
  /tokenizer        # 分词器相关文件
/config.py         # 配置参数
/app.py            # 主服务入口
/requirements.txt  # 依赖包列表

部署步骤

1. 准备运行环境，安装Python及相关依赖（如torch、transformers、fastapi等）；
2. 将模型文件放置于指定目录；
3. 编写API接口代码，封装模型加载与推理逻辑；
4. 启动服务进程，监听指定端口。

访问服务

服务启动后，可通过HTTP请求发送文本输入，接收模型返回的生成结果。推荐使用Postman或curl进行调试，也可开发前端页面实现交互式体验。

~/qwen-math-service/
├── docker-compose.yml
├── Dockerfile
├── requirements.txt
├── runserver.sh
├── models
│     └── Qwen2.5-Math-1.5B-Instruct (下载的大模型)
└── text-generation-webui
    ├── requirements
    ├── server.py
    ├── ...

模型权重文件的格式多种多样，不同格式在功能、安全性、兼容性与使用场景上各有特点。以下是几种常见格式的解析：

.safetensors：由 Hugging Face 主导推出的优选存储格式，仅保存模型权重而不包含可执行代码，从根本上规避了恶意代码注入的风险。该格式支持内存映射技术，加载速度快，并且能够无缝适配 PyTorch、TensorFlow 等主流深度学习框架。

.bin：常见于 PyTorch 生态中的二进制权重文件格式。对于大规模模型，通常会将权重拆分为多个分块文件，并通过索引文件记录各部分的位置信息。但由于缺乏统一标准，其结构和命名方式较为灵活，非规范化。

~/qwen-math-service/models$ tree
.
└── Qwen2.5-Math-1.5B-Instruct
    ├── config.json
    ├── generation_config.json
    ├── LICENSE
    ├── merges.txt
    ├── model.safetensors
    ├── README.md
    ├── tokenizer_config.json
    ├── tokenizer.json
    └── vocab.json

.ckpt：这一格式被 PyTorch 和 TensorFlow 共同采用，在 TensorFlow 中常配合 .index 文件使用以管理变量索引。然而，由于依赖 pickle 进行序列化操作，存在潜在的安全隐患，可能被用于注入并执行恶意代码。

.pt / .pth：PyTorch 的原生模型保存格式，两者在本质上没有区别。既可用于仅保存模型权重参数，也可完整保留模型结构、优化器状态等信息，广泛应用于训练过程中的检查点保存与调试阶段。

.gguf：专为本地高效推理设计的格式，支持多种量化级别，所有配置与权重均集成于单一文件中，便于部署和迁移。特别适合运行在边缘设备或资源受限环境，如移动终端、嵌入式系统等。

模型权重文件的大小与其类型、参数总量以及数值精度密切相关，体积跨度极大，从几十 KB 到上百 GB 不等。超大规模语言模型通常拥有数十亿乃至更多参数，导致其权重文件极为庞大；而轻量级模型则适用于低功耗场景，文件小巧。

分词器文件：自然语言的“翻译官”

分词器文件负责定义文本的“拆分规则”，将原始自然语言（如中文句子、英文单词）转换成模型可处理的数字序列，是连接人类语言与模型输入的关键桥梁，堪称模型的“语言翻译官”。

常见的分词器相关文件包括：tokenizer_config.json（配置信息）、vocab.txt（词汇表）和 special_tokens_map.json（特殊标记映射）等。这些文件通常以组合形式出现，共同构成完整的分词体系。

这类文件体积普遍较小，一般仅为几 MB 至几十 MB。尽管词汇表规模越大文件略大，但整体远小于模型权重文件，对存储压力影响极小。

配置与辅助文件的作用

配置文件用于明确定义模型的内部结构与推理行为，例如编码器层数、注意力头数量、隐藏层维度、激活函数类型、上下文窗口长度等关键参数。在加载模型时，必须确保配置文件与权重文件相匹配，否则可能导致加载失败或推理异常。

大模型框架与应用工具概述

大模型框架与平台工具是一套支撑大模型从训练、微调到推理、部署全流程的软件集合。它们有效应对了大模型开发中面临的高计算负载、显存占用大、部署复杂等挑战，显著降低了技术门槛，推动大模型的实际落地。

整体架构可分为两大类：底层推理部署框架与上层应用平台工具。

底层框架（如 Ollama、vLLM）专注于模型的计算执行与资源调度，直接决定模型能否稳定运行；而上层平台不参与底层运算，主要作为用户交互入口，提供界面化操作体验。

简而言之，底层框架解决“模型能不能跑起来”的问题，是“模型运行的引擎”；上层平台则聚焦于“跑起来之后如何方便地使用”，相当于“基于引擎搭建应用的工作台”。

底层（推理部署）框架详解

底层推理部署框架是实现大模型从“训练完成”迈向“实际可用”的核心技术支撑，涵盖模型加载、计算加速、显存管理、请求处理等多个核心环节，直接影响响应速度、吞吐能力、资源利用率及部署成本。

根据用途差异，可进一步划分为三类：

1. 训练框架

主要用于支持大规模参数模型的分布式训练任务，借助分布式计算与显存优化技术突破单设备算力瓶颈，满足千亿甚至万亿级参数模型的训练需求。

PyTorch：以其灵活性和易用性著称，采用动态计算图机制，调试便捷，与 Python 生态深度融合，广泛应用于学术研究及中小规模大模型的原型开发。

2. 推理部署框架

聚焦于模型训练完成后在各类环境中的高效部署，目标在于提升推理速度、降低延迟、增强吞吐量，适应云服务器、个人电脑、边缘设备等多种部署场景。

vLLM：核心创新在于引入 PagedAttention（分页注意力）机制，借鉴操作系统内存分页理念，使显存利用率提升至 95% 以上。同时支持连续批处理，能动态接收新请求并实时处理，在高并发场景下表现突出，适用于在线客服、智能文档分析等对企业级性能要求较高的应用。

TensorRT-LLM（NVIDIA）：由 NVIDIA 官方推出的专用高性能推理引擎，针对自家 GPU 架构进行了极致优化，充分发挥硬件算力优势。但其高度依赖 NVIDIA 的硬件生态，跨平台能力受限。

Llama.cpp：一款极简风格的开源推理框架，最大特点是支持纯 CPU 推理，无需 GPU 支持。架构简洁，部署方便，可在嵌入式设备、物联网终端等资源受限环境中运行，部署成本极低。不过推理速度相对较慢，仅适用于边缘侧的基础任务，如简单问答、本地指令响应等。

Ollama：主打轻量化与零配置部署，兼容 Windows、Mac、Linux 等主流桌面操作系统。开发者无需复杂设置即可在本地快速运行 Llama、Mistral 等主流开源大模型，非常适合个体开发者验证模型效果或进行小范围原型测试，但在大规模并发处理方面性能有限。

LMDeploy：针对国产 GPU 平台做了深度优化，具备良好的多模态处理能力，解决了国内企业在特定国产算力环境下模型部署适配难的问题，适用于政府机构及企业在国内自主可控平台上构建大模型应用。

3. 轻量化微调框架

传统的全量微调需要消耗大量计算资源和显存，成本高昂。轻量化微调框架通过参数高效微调技术（如 LoRA、Adapter），仅更新少量参数即可达到接近全量微调的效果，大幅降低训练开销，使得在消费级设备上完成模型定制成为可能。

PEFT（Parameter-Efficient Fine-Tuning）是Hugging Face推出的一个轻量级微调工具库，支持包括LoRA、IA?在内的多种主流参数高效微调方法，适用于在有限资源下对大模型进行有效优化。

Unsloth则专注于实现快速且低开销的模型微调，特别适配Llama、Mistral等当前广泛使用的开源大模型，显著提升训练效率并降低硬件需求。

上层应用平台类工具概述

此类工具不直接参与模型推理或训练过程中的性能加速，而是聚焦于构建基于大语言模型的复杂应用系统，解决模型与外部数据源、插件工具之间的集成问题。其核心目标在于降低开发和使用门槛，提供可视化交互界面及完整的应用搭建能力。

常用上层应用平台工具介绍

Open WebUI（Ollama Web UI）：本质上是为Ollama等本地推理框架设计的图形化前端界面，并非独立的推理引擎。它将原本依赖命令行的操作转化为浏览器中直观的交互体验，同时增强了用户功能，如对话管理、模型切换等。

Text-generation-webui：一个支持多后端推理引擎的本地Web交互工具，可对接llama.cpp、Transformers等多种底层运行环境。主要价值在于简化本地部署模型的操作流程，提供丰富的参数调节与插件扩展能力。

Dify：一款低代码的大模型应用开发平台，不仅支持接入各类底层推理服务，还涵盖从Prompt编排、知识库集成到应用发布的一站式开发流程，旨在帮助用户快速实现定制化AI应用的落地。

~/qwen-math-service/models$ tree
.
└── Qwen2.5-Math-1.5B-Instruct
    ├── config.json
    ├── generation_config.json
    ├── LICENSE
    ├── merges.txt
    ├── model.safetensors
    ├── README.md
    ├── tokenizer_config.json
    ├── tokenizer.json
    └── vocab.json

核心工具对比分析

对比维度	Ollama Web UI	Text-generation-webui	Dify	底层推理部署框架 （如vLLM、TensorRT-LLM、Ollama）
核心作用	提供本地模型的图形化交互界面	支持多格式模型的本地交互与轻量级管理	通过低代码方式构建并部署大模型应用	优化推理速度与显存利用率，支撑高并发模型运行
是否参与底层计算	否，依赖Ollama等外部框架	否，依赖所连接的推理工具	否，通过API调用底层模型	是，负责模型执行与资源调度
核心功能	对话交互、RAG检索增强、模型下载与管理	多模式对话、生成参数调节、插件扩展机制	Prompt工程编排、知识库集成、应用发布流程	量化压缩、批处理优化、并行计算支持
目标用户群体	个人用户或小团队（重视隐私与易用性）	AI爱好者、开发者（用于测试不同本地模型）	企业用户、业务人员、非技术背景开发者（追求快速上线）	算法工程师、运维团队（关注部署性能优化）

本地部署Qwen2.5-Math-1.5B-Instruct模型实践

本案例演示如何在无GPU环境下，使用Text-generation-webui作为图形化交互界面，通过Docker方式本地运行Qwen2.5-Math-1.5B-Instruct大模型。

硬件配置要求：
内存：32GB
CPU：8核AMD处理器
GPU：无

大模型获取方式

可通过以下任一平台下载Qwen2.5-Math-1.5B-Instruct模型文件：

• Hugging Face Hub
• Ollama社区镜像
• 阿里云OpenI平台

推荐使用git lfs进行模型下载以确保完整性：

# 检查Git LFS是否已安装
git-lfs --version

# 安装Git LFS（Ubuntu/Debian系统）
sudo apt-get install git-lfs -y

# 全局启用LFS跟踪
git lfs install --global

# 克隆模型仓库
git clone https://huggingface.co/Qwen/Qwen2.5-Math-1.5B-Instruct
    

注意：git lfs是Git的附加组件，需单独安装，不属于Git默认功能。

模型文件结构说明

下载后的模型包含多个关键配置与权重文件：

• model.safetensors：模型权重文件，包含训练好的参数，为核心组成部分。
• tokenizer.json：分词器主配置文件，定义词汇表、切分规则及特殊标记处理逻辑。
• tokenizer_config.json：分词器辅助配置，用于设定运行时行为和高级选项。
• config.json：模型架构描述文件，明确1.5B规模模型的网络结构参数。
• generation_config.json：文本生成配置，预设温度、top_p、最大输出长度等生成策略。
• vocab.json：补充性的词汇映射表，协助完成token与ID间的转换。

使用代码验证模型功能

可通过如下Python脚本加载模型并进行初步测试：

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

# 加载本地模型与分词器
model_path = "./Qwen2.5-Math-1.5B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_path)
model = AutoModelForCausalLM.from_pretrained(model_path, torch_dtype=torch.float16)

# 示例输入
input_text = "解方程：2x + 5 = 15"
inputs = tokenizer(input_text, return_tensors="pt").to(model.device)

# 生成结果
outputs = model.generate(**inputs, max_new_tokens=50)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))
    

注：AutoModelForCausalLM的from_pretrained方法会优先尝试从本地路径加载，若路径不存在则自动从Hugging Face Hub下载。

当您已将模型预先下载至本地时，可通过指定本地路径来加载模型。例如：

model = AutoModelForCausalLM.from_pretrained("./your_local_model_path")

首先，定义模型所在目录的路径（请根据实际情况修改）：

model_path = "/app/models/Qwen2.5-Math-1.5B-Instruct"  # 示例路径，如：Qwen/Qwen2.5-Math-1.5B

接着，加载对应的分词器（Tokenizer）：

tokenizer = AutoTokenizer.from_pretrained(model_path)

然后加载因果语言模型。注意：不同类型的模型应使用相应的加载类，例如 BERT 应使用 AutoModelForSequenceClassification 等。

model = AutoModelForCausalLM.from_pretrained(
    model_path,
    dtype=torch.float16,           # 使用半精度以节省显存
    device_map="auto",             # 自动分配设备资源（支持多GPU），也可设为 cpu
    low_cpu_mem_usage=True         # 降低CPU内存消耗
)

设置待处理的问题内容：

question = "解方程: x + 2 = 5, 求x的值"

对输入文本进行编码，并转换为 PyTorch 张量格式：

inputs = tokenizer(question, return_tensors="pt").to(model.device)

调用模型生成回答结果：

outputs = model.generate(**inputs, max_length=200)
answer = tokenizer.decode(outputs[0], skip_special_tokens=True)
print(f"回答: {answer}")

输出示例：

回答: 解方程: x + 2 = 5, 求x的值.
要解方程 \( x + 2 = 5 \) 求 \( x \) 的值，我们需要将 \( x \) 隔离在方程的一边。以下是这样做的步骤：
1. 从给定的方程开始：
\[
x + 2 = 5
\]
2. 为了隔离 \( x \)，我们需要去掉方程左边的 \( +2 \)。我们可以通过从方程的两边减去2来实现这一点：
\[
x + 2 - 2 = 5 - 2
\]
3. 简化方程的两边：
\[
x = 3
\]
所以，\( x \) 的值是 \(\boxed{3}\)。

服务部署

项目结构

~/qwen-math-service/
├── docker-compose.yml
├── Dockerfile
├── requirements.txt
├── runserver.sh
├── models
│     └── Qwen2.5-Math-1.5B-Instruct (下载的大模型)
└── text-generation-webui
    ├── requirements
    ├── server.py
    ├── ...

Dockerfile

# Dockerfile

FROM python:3.11-slim

WORKDIR /app

# 安装系统依赖
RUN apt-get update && apt-get install -y build-essential

# 复制项目文件
COPY . .

# 安装 CPU 版本的 PyTorch
RUN pip install torch torchvision torchaudio \
    --index-url https://download.pytorch.org/whl/cpu

# 安装 text-generation-webui 依赖
RUN pip install -r text-generation-webui/requirements/full/requirements_cpu_only.txt

# 安装服务使用的额外 Python 依赖
RUN pip install -r requirements.txt

# 暴露端口
EXPOSE 7860

docker-compose.yml 配置文件

# docker-compose.yml
version: '3.8'
services:
  textgen-webui:
    image: qwen-math-cpu
    build:
      context: .
      dockerfile: Dockerfile
    container_name: qwen-math-cpu
    ports:
      - "7860:7860"
    volumes:
      - .:/app
    restart: no
    networks:
      - textgen-network
    command: /bin/sh -c "./runserver.sh"

networks:
  textgen-network:
    driver: bridge

volumes:
  model-data:
  log-data:

依赖文件 requirements.txt

# Qwen 模型特殊依赖, 流式生成支持
transformers_stream_generator

pyyaml

启动脚本 runserver.sh

cd text-generation-webui

# 运行 text-generation-webui 下的 serve.py 启动脚本
python server.py --listen --listen-host 0.0.0.0 --cpu --model-dir /app/models --model Qwen2.5-Math-1.5B-Instruct

部署流程说明

按照以下步骤完成服务的部署配置：

1. 创建项目目录并准备文件

   mkdir -p ~/qwen-math-service/models
   cd ~/qwen-math-service

   将上述代码片段中的各配置文件内容分别保存为对应名称的文件。

   Dockerfile

   docker-compose.yml

2. 克隆 Text Generation WebUI 源码

   git clone https://github.com/oobabooga/text-generation-webui.git .

3. 获取 Qwen2.5-Math-1.5B-Instruct 模型

   cd models
   git lfs install
   git clone https://huggingface.co/Qwen/Qwen2.5-Math-1.5B-Instruct
   cd ..

   若网络环境不稳定，也可手动从 Hugging Face 页面下载全部模型文件，并放入以下目录中：

   models/

4. 服务的构建与启动

使用以下命令启动服务，其中 -d 参数用于指定容器在后台运行：

docker-compose up -d

若需查看服务运行日志，可执行如下命令，获取最近的 100 条日志并持续输出：

docker logs -n 100 -f qwen-math-cpu

服务成功启动后，可通过浏览器进行访问。

http://localhost:7860

# 如果要从同一网络的其他设备访问，使用
http://你的主机IP:7860

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏0 回帖

关键词：Requirements Transformers Requirement Generation transform