通义千问1.5-1.8B-Chat-GPTQ-Int4 WebUI企业内网部署：保障网络安全的私有化方案

本文介绍了如何在星图GPU平台上自动化部署通义千问1.5-1.8B-Chat-GPTQ-Int4 WebUI镜像，为企业提供安全的私有化AI解决方案。该方案通过内网部署，确保数据不出域，适用于企业内部文档处理、智能问答等场景，满足金融、政务等行业的合规与安全需求。

蓉蓉蓉蓉

273人浏览 · 2026-03-14 00:14:28

蓉蓉蓉蓉 · 2026-03-14 00:14:28 发布

通义千问1.5-1.8B-Chat-GPTQ-Int4 WebUI企业内网部署：保障网络安全的私有化方案

最近和几个在金融和政务行业做技术的朋友聊天，大家不约而同地提到了同一个烦恼：想用大模型提升内部效率，但数据安全这根弦绷得紧紧的，谁也不敢把业务数据、客户信息甚至内部文档送到外部的AI服务上去。这就像想用一把好刀，但又怕它伤到自己。

其实，这个需求完全可以解决。今天，我就来详细聊聊，如何将通义千问1.5-1.8B-Chat这样的轻量级模型，通过GPTQ-Int4量化后，结合WebUI界面，完整地部署在企业内部网络中。这套方案的核心目标就一个：让所有数据，从模型推理到用户对话，全程都在你的内网里流转，一滴水都不漏出去。这对于有严格合规要求的行业来说，不是“锦上添花”，而是“雪中送炭”。

1. 为什么企业需要私有化AI部署？

你可能已经体验过各种在线AI助手，它们很方便，但当你处理的是公司的财务报表、未公开的产品设计图或是客户的个人信息时，这种“方便”就变成了巨大的风险。数据一旦离开企业边界，其安全性和合规性就完全不受控了。

私有化部署，就是把AI能力“请”到家里来。具体来说，它解决了几个核心痛点：

数据不出域，安全可控：所有的模型加载、推理计算、对话历史，都发生在企业内部的服务器或私有云上。从根本上杜绝了敏感数据泄露到公网的风险，满足GDPR、网络安全法等法规的合规要求。
网络隔离，访问可控：通过内网部署，你可以精细地控制谁能访问这个AI服务。可以把它集成到企业的统一身份认证（如LDAP/AD）里，只有授权员工才能使用，并且所有访问日志都可追溯。
性能稳定，不受公网波动影响：服务运行在内网，网络延迟极低且稳定，不会因为公网拥堵或服务商故障而中断，保障了关键业务场景的连续性。
模型定制化潜力：虽然今天我们部署的是通用模型，但私有化环境为后续基于企业内部知识库进行微调（Fine-tuning）提供了安全的基础设施。

通义千问1.5-1.8B-Chat这个版本，参数量相对较小，经过GPTQ-Int4量化后，对硬件资源（特别是GPU显存）的要求大大降低，使得它在普通的企业级服务器上也能流畅运行，降低了私有化部署的门槛。

2. 部署方案全景与核心组件

在动手之前，我们先理清整个方案的架构。它不是一个简单的单机软件安装，而是一套适应企业IT环境的小型系统。

整个方案可以概括为“一个核心，三道防线”：

一个核心：即通义千问1.5-1.8B-Chat-GPTQ-Int4模型及其WebUI交互界面。这是提供AI能力的本体。
三道防线：
1. 镜像私有化：将所需的Docker镜像从公网拉取后，推送到企业内部的镜像仓库（如Harbor、Nexus），后续部署均从内网仓库获取，切断与公网镜像源的直接依赖。
2. 网络隔离化：服务部署在内网特定网段或VPC中，通过防火墙策略严格限制，只允许来自企业内部特定地址段的访问，禁止任何外部互联网连接。
3. 访问认证化：在WebUI前端集成企业单点登录（SSO）或反向代理认证（如Nginx + auth_request），确保只有通过企业身份验证的用户才能使用服务。

下面是这个方案的简易架构图，帮助你理解各组件之间的关系：

[企业员工PC] ---(HTTPS + 企业认证)---> [反向代理 / 认证网关]
                                                    |
                                                    v
                                            [内部防火墙] (策略：仅允许内网IP)
                                                    |
                                                    v
                                        [Docker Host / K8s Node]
                                                    |
                                                    v
                                [通义千问 WebUI 容器] <--- [内网镜像仓库]
                                                    |
                                                    v
                                [模型文件（本地存储）]

接下来，我们分步拆解如何构建这个安全闭环。

3. 分步实施：构建内网安全闭环

假设你拥有内网服务器的基本操作权限，并且企业内已有或允许搭建简单的Docker环境。

3.1 第一步：准备模型与镜像——从外到内的“搬家”

首先，我们需要在一个能与公网临时通信的环境（如一台跳板机）完成初始下载。

# 1. 在可访问公网的机器上，拉取WebUI的Docker镜像（这里以流行的Ollama WebUI为例，需根据实际选择的WebUI调整）
docker pull ghcr.io/ollama-webui/ollama-webui:main

# 2. 下载通义千问1.5-1.8B-Chat-GPTQ-Int4的模型文件
# 通常可以从ModelScope或Hugging Face获取，例如使用modelscope库
pip install modelscope
python -c "from modelscope import snapshot_download; snapshot_download('qwen/Qwen1.5-1.8B-Chat-GPTQ-Int4', cache_dir='./qwen_model')"

# 3. 将下载好的镜像和模型文件“打包”
# 保存镜像为tar文件
docker save -o ollama-webui.tar ghcr.io/ollama-webui/ollama-webui:main
# 压缩模型目录
tar -czf qwen1.5-1.8b-chat-gptq-int4.tar.gz ./qwen_model/

# 4. 通过安全方式（如内部文件服务器、加密U盘）将tar和tar.gz文件传输到目标内网服务器。

在内网服务器上：

# 5. 导入镜像到内网服务器的Docker环境中
docker load -i ollama-webui.tar
# 给镜像打上内部标签，准备推送到私有仓库
docker tag ghcr.io/ollama-webui/ollama-webui:main internal.registry.com/ai/ollama-webui:secure-v1

# 6. 解压模型文件到内网服务器的持久化存储目录
mkdir -p /data/ai_models
tar -xzf qwen1.5-1.8b-chat-gptq-int4.tar.gz -C /data/ai_models/
# 假设最终模型路径为 /data/ai_models/qwen_model

3.2 第二步：搭建私有镜像仓库与推送

在内网搭建一个私有Docker镜像仓库（如使用Harbor或简单的Docker Registry）。

# 例如，快速启动一个Docker Registry（生产环境建议用Harbor）
docker run -d -p 5000:5000 --name registry -v /data/registry:/var/lib/registry registry:2

# 配置Docker客户端信任这个私有仓库（如果非HTTPS）
echo '{ "insecure-registries":["internal.registry.com:5000"] }' | sudo tee /etc/docker/daemon.json
sudo systemctl restart docker

# 推送我们打好标签的镜像到私有仓库
docker push internal.registry.com:5000/ai/ollama-webui:secure-v1

从此，内网中所有需要部署该WebUI的服务器，都可以从 internal.registry.com:5000 这个地址拉取镜像，完全不需要连接互联网。

3.3 第三步：编写与运行安全的Docker Compose配置

这是关键一步，通过配置定义服务运行方式、网络和卷映射。

创建一个 docker-compose.yml 文件：

version: '3.8'

services:
  ollama-webui:
    image: internal.registry.com:5000/ai/ollama-webui:secure-v1 # 使用内网镜像
    container_name: qwen-webui-secure
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080" # 仅绑定到本地回环地址，不对外暴露
    volumes:
      - /data/ai_models/qwen_model:/app/models/qwen1.5-1.8b-chat-gptq-int4 # 挂载本地模型
      - ./config:/app/config # 挂载自定义配置文件（可选）
    environment:
      - OLLAMA_API_BASE_URL=http://ollama:11434 # 假设后端服务名
      - ENABLE_MODEL_MANAGEMENT=false # 禁用从公网拉取模型
    networks:
      - ai-internal-net

  # 假设你需要一个Ollama后端来加载模型（根据WebUI实际需求调整）
  ollama:
    image: internal.registry.com:5000/ollama/ollama:latest # 同样使用内网镜像
    container_name: ollama-backend
    restart: unless-stopped
    volumes:
      - /data/ai_models/qwen_model:/root/.ollama/models # 将模型挂载到Ollama的模型目录
    command: serve
    networks:
      - ai-internal-net

networks:
  ai-internal-net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/24 # 使用一个固定的内网子网

关键安全配置解读：

image: 指定内网镜像仓库地址，确保运行时不会意外从公网拉取。
ports: “127.0.0.1:8080:8080”: 将容器端口映射到宿主机的127.0.0.1（本地回环），这意味着服务在宿主机上都无法通过IP直接访问，必须通过反向代理。
volumes: 将模型数据挂载为卷，数据持久化在宿主机，容器销毁也不会丢失模型。
networks: 使用自定义的Docker网络，可以将多个相关服务（如WebUI、后端、数据库）隔离在同一个内部网络中。
environment: 设置环境变量，这里示例禁用了从公网管理模型的功能。

启动服务：

docker-compose up -d

3.4 第四步：配置反向代理与网络访问控制

现在服务在宿主机本地跑起来了，我们需要让内网用户安全地访问它。使用Nginx作为反向代理和认证网关。

安装并配置Nginx：

# 在宿主机上安装Nginx
# Ubuntu/Debian
sudo apt update && sudo apt install nginx
# CentOS/RHEL
sudo yum install nginx

编辑Nginx配置文件，例如 /etc/nginx/conf.d/ai-assistant.conf：

server {
    listen 443 ssl http2;
    # 使用内部域名，如 ai-assistant.internal.company.com
    server_name ai-assistant.internal.company.com;

    # SSL证书（使用内部CA或自签名证书）
    ssl_certificate /etc/nginx/ssl/internal.crt;
    ssl_certificate_key /etc/nginx/ssl/internal.key;

    # 1. 集成企业认证（示例：使用auth_request模块与内部认证服务对接）
    location = /auth {
        internal;
        proxy_pass http://your-auth-service.internal/validate; # 你的认证服务端点
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
        proxy_set_header X-Original-URI $request_uri;
    }

    # 2. 保护WebUI应用
    location / {
        # 启用认证检查
        auth_request /auth;
        auth_request_set $auth_status $upstream_status;
        # 认证失败处理
        error_page 401 = @error401;

        # 代理到本地运行的Docker服务
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location @error401 {
        return 302 https://sso.internal.company.com?return=$request_uri; # 跳转到企业SSO登录页
    }

    # 静态资源缓存等优化配置...
}

配置系统防火墙（以firewalld为例），确保只有反向代理服务器（或特定内网IP段）能访问Docker服务：

# 假设Nginx和Docker在同一台主机
# 禁止所有外部IP访问8080端口（Docker服务端口）
sudo firewall-cmd --permanent --remove-port=8080/tcp
# 或者，更严格地，只允许本机访问
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="127.0.0.1" port port="8080" protocol="tcp" accept'
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="172.20.0.0/24" port port="8080" protocol="tcp" accept' # 允许Docker内部网络
sudo firewall-cmd --reload

最后，在内网的DNS服务器上，将 ai-assistant.internal.company.com 解析到这台Nginx服务器的内网IP地址。