1. 项目概述

最近在折腾一个叫 carefree-creator 的开源项目，它本质上是一个集成了多种AI模型（比如文生图、图生图、对话模型）的Web应用框架，方便开发者快速搭建自己的AI创作平台。项目本身功能挺全，但当你真的想把它部署到一台带GPU的服务器上，尤其是想用Docker来管理时，就会发现一堆“坑”在等着你。比如，怎么让Docker容器识别到宿主机上的GPU？怎么在多容器环境下公平、高效地分配有限的GPU算力？怎么优化镜像构建，让它又小又快？这些问题，官方文档可能一笔带过，但实际部署时，每一步都可能让你卡上半天。

我自己在把 carefree-creator 容器化并部署到多GPU服务器的过程中，踩遍了几乎所有能踩的坑。从最基础的 nvidia-docker 环境配置，到复杂的多容器GPU资源隔离与调度，再到针对AI应用特点的Dockerfile优化和性能调优，积累了一整套实战经验。这篇文章，我就把这些从零到一的部署优化过程，以及背后的原理和最佳实践，毫无保留地分享出来。无论你是刚接触Docker和GPU的运维新手，还是正在为团队AI服务寻找稳定部署方案的老手，相信都能从中找到可以直接“抄作业”的解决方案。

2. 核心需求与挑战分析

2.1 carefree-creator 的部署特点

carefree-creator 这类AI应用框架，和传统的Web服务部署有很大不同。它不是一个简单的“启动服务，监听端口”的应用。其核心挑战在于对异构计算资源的强依赖和动态的资源需求。

首先， 模型依赖复杂且庞大 。一个完整的 carefree-creator 实例可能需要加载Stable Diffusion、LLaMA等多个大模型。这些模型动辄几个GB甚至几十个GB，并且依赖特定版本的深度学习框架（如PyTorch、TensorFlow）及其对应的CUDA版本。在宿主机上手动配环境已是噩梦，在容器里更要确保所有依赖的版本完全匹配，否则一个 libcudart.so 版本错误就能让整个服务崩溃。

其次， GPU资源是生命线，也是瓶颈 。所有AI推理和训练任务都严重依赖GPU。部署时，我们必须解决几个关键问题：1) 如何让容器内的应用“看见”并使用宿主机GPU；2) 如何避免多个容器（或多个进程）争抢同一块GPU导致显存溢出（OOM）或计算卡死；3) 如何根据任务优先级动态分配GPU资源。

最后， 服务模式多样 。它可能同时提供HTTP API（用于前端调用）、WebSocket（用于实时生成进度推送）、后台任务队列（处理耗时长的生成任务）。这要求我们的部署架构不仅要支持GPU，还要能很好地处理网络、进程管理和服务发现。

2.2 Docker容器化带来的优势与待解决问题

选择Docker容器化部署 carefree-creator ，主要看中以下几点优势：

  • 环境一致性 ：将复杂的Python环境、CUDA驱动、模型文件全部打包进镜像，实现“一次构建，处处运行”，彻底解决“在我机器上是好的”这类问题。
  • 资源隔离 ：利用Docker的命名空间和控制组（cgroup）机制，可以为每个容器分配独立的GPU、CPU和内存资源，避免服务间相互干扰。
  • 快速部署与扩缩容 ：结合Docker Compose或Kubernetes，可以快速启动多个服务实例，轻松应对流量高峰。

但是，原生Docker并不直接支持GPU。这就需要我们引入 NVIDIA Container Toolkit （以前叫 nvidia-docker ）来搭建桥梁。而如何用好这个工具，实现精细化的GPU资源管理，就成了我们面临的核心技术挑战。此外，AI应用的镜像通常很大，如何优化Dockerfile的构建层，减少镜像体积和构建时间，也是一个需要深入研究的点。

3. 基础环境搭建：Docker与GPU支持

3.1 宿主机环境准备：驱动与CUDA

一切的前提是宿主机（你的物理服务器或云GPU实例）有一个正确配置的GPU环境。这一步没做好，后面全是徒劳。

第一步：确认GPU硬件与安装驱动 首先，用 lspci | grep -i nvidia 命令确认你的服务器上确实有NVIDIA显卡。然后，安装合适的驱动。我强烈建议在Ubuntu/Debian系统上使用系统仓库安装，避免手动下载run文件带来的依赖问题。 

# 添加显卡驱动PPA源（Ubuntu）
sudo add-apt-repository ppa:graphics-drivers/ppa -y
sudo apt update
# 自动安装推荐版本的驱动
sudo ubuntu-drivers autoinstall
# 或者手动指定版本，例如安装525版本
# sudo apt install nvidia-driver-525

安装完成后，重启系统，然后运行 nvidia-smi 。如果能看到GPU列表、驱动版本和CUDA版本信息，恭喜你，驱动安装成功。 nvidia-smi 是你的“GPU控制台”，后续监控和排查问题都离不开它。

第二步：安装CUDA Toolkit carefree-creator 依赖的PyTorch等框架需要CUDA。注意，这里安装的CUDA Toolkit是给应用程序用的 开发套件 ，和驱动是分开的。去NVIDIA官网下载对应版本的runfile或deb包。我通常选择runfile，因为它允许更自定义的安装。 

# 假设下载了 cuda_12.1.0_530.30.02_linux.run
sudo sh cuda_12.1.0_530.30.02_linux.run

在安装界面， 务必取消勾选Driver ，因为我们已经安装了驱动。只安装CUDA Toolkit。安装完成后，将CUDA路径加入环境变量： 

echo 'export PATH=/usr/local/cuda-12.1/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.1/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc
source ~/.bashrc

运行 nvcc --version 验证CUDA编译器是否可用。

注意 ：驱动版本和CUDA Toolkit版本有兼容性要求。NVIDIA官网有兼容性表格。一个简单的记忆方法是： nvidia-smi 命令输出的右上角会显示一个“CUDA Version”，这个版本号代表 此驱动支持的最高CUDA运行时版本 。你安装的CUDA Toolkit版本不能高于这个值。

3.2 安装与配置NVIDIA Container Toolkit

这是让Docker容器访问GPU的关键。它的原理是在容器启动时，通过一个“运行时钩子”（runtime hook），将宿主机的GPU设备文件和必要的驱动库（如 libcuda.so ）挂载到容器内部。

安装步骤： 

# 1. 添加仓库和GPG密钥
distribution=$(. /etc/os-release;echo $ID$VERSION_ID) \
   && curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \
   && curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | \
         sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
         sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

# 2. 更新并安装工具包
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

# 3. 配置Docker使用nvidia作为默认运行时（可选但推荐）
# 编辑 /etc/docker/daemon.json，如果文件不存在则创建
sudo tee /etc/docker/daemon.json <<EOF
{
    "runtimes": {
        "nvidia": {
            "path": "/usr/bin/nvidia-container-runtime",
            "runtimeArgs": []
        }
    },
    "default-runtime": "nvidia" // 设置nvidia为默认运行时，这样所有容器默认都能用GPU
}
EOF

# 4. 重启Docker服务
sudo systemctl restart docker

验证安装： 运行一个测试容器，看看GPU是否能在容器内被识别。 

docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu20.04 nvidia-smi

如果容器内成功输出了和宿主机类似的 nvidia-smi 信息，那么恭喜，你的Docker已经获得了GPU超能力。

实操心得 ：我遇到过在配置了 default-runtime 为 nvidia 后，一些不需要GPU的基础镜像（如 nginx , redis ）启动报错，提示找不到GPU设备。这是因为它们内部的某些检查逻辑可能不适应这个运行时。 更稳健的做法是不要设置全局默认运行时，而是在需要GPU的容器启动时，通过 --runtime=nvidia 参数显式指定 。这样隔离性更好。

4. 构建优化的carefree-creator Docker镜像

4.1 Dockerfile分层设计与构建优化

直接 pip install -r requirements.txt 会构建出一个巨大的镜像，而且每次修改代码都需要重装所有依赖，构建速度慢，镜像层也不利于缓存。我们需要一个更聪明的Dockerfile。

核心原则：利用Docker缓存机制，将变化频率低的层放在前面，变化频率高的层放在后面。

一个优化的Dockerfile示例： 

# 第一阶段：构建依赖
FROM pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime as builder

WORKDIR /app

# 1. 复制依赖声明文件（变化频率低，利于缓存）
COPY requirements.txt .
# 使用国内镜像源加速，并安装依赖
RUN pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple && \
    pip install --no-cache-dir -r requirements.txt

# 第二阶段：构建最终镜像
FROM pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime

WORKDIR /app

# 2. 从builder阶段复制已安装的Python包
COPY --from=builder /usr/local/lib/python3.9/site-packages /usr/local/lib/python3.9/site-packages
COPY --from=builder /usr/local/bin /usr/local/bin

# 3. 复制应用代码（变化频率最高）
COPY . .

# 4. 下载或准备模型文件（体积大，考虑是否放入镜像）
# 这里假设模型通过启动脚本从外部存储下载，不直接打包进镜像，以控制镜像体积。
# RUN python scripts/download_models.py

# 暴露端口
EXPOSE 7860

# 启动命令
CMD ["python", "app.py"]

优化点解析：

  1. 使用多阶段构建 ：第一阶段（ builder ）仅用于安装依赖。第二阶段基于同一个轻量级运行时镜像，只从第一阶段复制安装好的 site-packages 。这避免了将构建工具（如gcc）和缓存文件打包进最终镜像，显著减小体积。
  2. 分离依赖与代码 ：先单独复制 requirements.txt 并安装。只要依赖没变，这一层就会被缓存，后续构建代码时无需重复安装依赖，极大加快构建速度。
  3. 模型文件外置 ：模型文件通常很大（几个GB）。不建议直接打包进镜像，这会导致镜像臃肿且难以更新。更好的做法是：
    • 将模型存储在共享文件系统（如NFS）或对象存储（如S3/MinIO）。
    • 在容器启动时，通过初始化脚本或挂载卷的方式动态拉取或挂载到容器内指定路径。
    • 在 carefree-creator 的配置中，指定模型路径为这个挂载点。

4.2 依赖管理与镜像瘦身

除了分层设计，还有一些细节能进一步“瘦身”：

  • 使用Alpine或Slim版本的基础镜像 ：比如 python:3.9-slim 。但对于CUDA环境，官方 pytorch 镜像通常基于Ubuntu，我们可以选择 -runtime 版本而非 -devel 版本，后者包含了编译工具链，体积更大。
  • 清理APT缓存 ：在安装系统包后，执行 rm -rf /var/lib/apt/lists/* 。
  • --no-cache-dir ： pip install 时使用此参数，避免缓存包文件。
  • 合并RUN指令 ：将多个 RUN 命令用 && 连接成一个，减少镜像层数。但要注意可读性。

一个结合了上述技巧的复杂RUN指令示例： 

RUN apt-get update && apt-get install -y --no-install-recommends \
    git \
    openssh-client \
    && rm -rf /var/lib/apt/lists/* \
    && pip install --no-cache-dir some-package

5. GPU资源管理高级实践

5.1 容器级别的GPU资源限制

默认的 --gpus all 会把所有GPU都暴露给容器，这显然不适合多服务共享的场景。我们需要更精细的控制。

1. 指定使用特定GPU： 

# 只使用GPU 0
docker run --gpus '"device=0"' your-carefree-image
# 使用GPU 0和GPU 1
docker run --gpus '"device=0,1"' your-carefree-image

注意， device= 后面的参数是一个JSON字符串，所以在shell中需要多层引号。

2. 限制GPU显存和算力： NVIDIA Container Toolkit 目前主要通过 device 指定物理GPU，更细粒度的显存和算力限制需要在应用层或使用更高级的工具（如Kubernetes的扩展资源请求）来实现。但在Docker层面，我们可以通过环境变量给容器内的PyTorch/TensorFlow传递限制。

例如，对于PyTorch，可以在启动容器时设置环境变量： 

docker run --gpus '"device=0"' \
  -e CUDA_VISIBLE_DEVICES=0 \
  -e PYTORCH_CUDA_ALLOC_CONF=max_split_size_mb:128 \
  your-carefree-image
  • CUDA_VISIBLE_DEVICES=0 ：让容器内的应用只“看到”第0块GPU（虽然我们通过 --gpus 也只给了它一块，但这是双重保险）。
  • PYTORCH_CUDA_ALLOC_CONF ：可以调整PyTorch的CUDA内存分配器行为， max_split_size_mb 有助于缓解显存碎片化。

3. 使用NVIDIA运行时资源限制（实验性）： 较新版本的NVIDIA Container Toolkit支持通过环境变量 NVIDIA_VISIBLE_DEVICES 和 NVIDIA_DRIVER_CAPABILITIES 进行控制，但功能不如 --gpus 参数直接。通常还是推荐使用 --gpus 参数。

5.2 多容器共享GPU与隔离策略

当多个 carefree-creator 实例（或其他AI服务）需要运行在同一台服务器的多块GPU上时，我们需要一个调度和隔离策略。

场景一：一容器一GPU（物理隔离） 这是最简单、最稳定的方式。为每个服务实例分配一块独立的物理GPU。 

# 实例A使用GPU0
docker run -d --name creator-a --gpus '"device=0"' -p 7860:7860 your-image
# 实例B使用GPU1
docker run -d --name creator-b --gpus '"device=1"' -p 7861:7860 your-image

优点 ：绝对隔离，无资源争抢。 缺点 ：GPU利用率可能不高，如果某个实例负载低，它的GPU就闲置了。

场景二：多容器共享单GPU（时分复用） 通过进程级调度，让多个容器轮流使用同一块GPU。这需要容器内的应用本身支持良好的GPU释放（如任务完成后主动清空显存）。Docker本身不提供GPU的时分复用，这依赖于宿主机操作系统的进程调度和GPU驱动的上下文切换。通常不建议主动这样配置，容易导致显存冲突和性能下降。如果非要这么做，只能让所有容器都 --gpus '"device=0"' ，然后依靠应用自身的谦让，风险很高。

场景三：使用GPU虚拟化技术（MIG, vGPU） 对于NVIDIA A100、H100等高端GPU，可以使用MIG（Multi-Instance GPU）技术将一块物理GPU划分为多个具备独立显存和算力的GPU实例。每个MIG实例可以像一块独立的小GPU一样分配给一个容器。这是目前最理想的硬件级多租户隔离方案，但需要特定硬件和驱动支持。

更实际的方案：结合任务队列 对于 carefree-creator ，一个更普适的策略是： 部署一个主服务容器，独占1-2块GPU用于高优先级或实时推理任务；同时，使用Celery、RQ或Dramatiq等任务队列，将耗时的训练或批量生成任务提交到队列。工作节点（Worker）容器可以动态启动，从队列中拉取任务，并在完成后释放资源。 工作节点可以配置为使用特定的GPU，从而实现资源的动态分配和回收。

5.3 使用Docker Compose编排多服务

当 carefree-creator 需要与数据库（如Redis用于缓存或队列）、模型存储服务等一起部署时，Docker Compose是管理这些服务依赖关系的利器。

一个支持GPU的 docker-compose.yml 示例： 

version: '3.8'

services:
  redis:
    image: redis:alpine
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data
    command: redis-server --appendonly yes

  carefree-creator-web:
    build: .
    ports:
      - "7860:7860"
    runtime: nvidia # 关键：指定使用nvidia运行时
    deploy: # 使用deploy.resources限制资源（Docker Compose v3+）
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    environment:
      - REDIS_HOST=redis
      - CUDA_VISIBLE_DEVICES=0 # 指定容器内可见的GPU编号
    volumes:
      - model_cache:/app/models # 将模型目录挂载为卷，避免放入镜像
      - ./config.yaml:/app/config.yaml:ro # 挂载配置文件
    depends_on:
      - redis

  carefree-worker:
    build: .
    runtime: nvidia
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    environment:
      - APP_MODE=worker
      - REDIS_HOST=redis
      - CUDA_VISIBLE_DEVICES=1 # Worker使用另一块GPU
    volumes:
      - model_cache:/app/models
      - ./config.yaml:/app/config.yaml:ro
    depends_on:
      - redis
    command: ["python", "worker.py"] # 覆盖默认启动命令，启动worker进程

volumes:
  redis_data:
  model_cache:

关键配置说明：

  1. runtime: nvidia ：告诉Compose对此服务使用NVIDIA运行时。
  2. deploy.resources.reservations.devices ：这是Docker Swarm模式下声明资源的标准方式，但在Compose standalone模式下，它也能被识别并用于向 docker run 传递 --gpus 参数。 count: 1 表示申请1块GPU。
  3. CUDA_VISIBLE_DEVICES ：在容器内部环境变量中再次指定，确保应用层也遵守这个限制。
  4. 卷挂载 ： model_cache 是一个命名卷，用于在所有服务间共享下载好的模型文件，避免每个容器重复下载。

启动命令： docker-compose up -d 。使用 docker-compose logs -f carefree-creator-web 查看日志。

6. 监控、日志与故障排查

6.1 容器内GPU状态监控

在容器内部，你可以和宿主机一样使用 nvidia-smi ，但需要确保镜像里包含了这个工具。通常 nvidia/cuda 基础镜像里都有。

更进阶的做法是在宿主机上使用 nvidia-smi 的循环查询，并关联容器ID。 

# 使用 watch 命令实时监控
watch -n 1 nvidia-smi
# 或者使用更强大的工具，如 gpustat (需要pip安装)
pip install gpustat
gpustat -i 1 # 每秒刷新一次

gpustat 会以更清晰的格式显示每个GPU上运行的进程，包括进程的PID和命令，方便你定位是哪个容器在占用资源。

要查看某个特定容器对应的GPU进程，可以先进入容器找到进程PID，然后在宿主机上用 nvidia-smi 查找。但更直接的是在宿主机上，通过 ps 命令查看进程的 cgroup 信息，或者使用 docker stats 命令查看容器的整体资源使用情况（虽然不显示GPU细节）。

6.2 常见问题与解决方案实录

问题1：容器内运行 nvidia-smi 报错： Failed to initialize NVML: Driver/library version mismatch

  • 原因 ：这通常是因为宿主机重启后，NVIDIA内核模块（ nvidia.ko ）的版本与用户态驱动库（ libnvidia-ml.so ）的版本不一致。容器内挂载的是宿主机当前的驱动库，而内核模块可能是旧版本。
  • 解决 ： 重启宿主机 。这是最彻底的方法。重启后，内核模块会重新加载，与用户态库版本匹配。如果生产环境不允许重启，可以尝试卸载再重新安装相同版本的NVIDIA驱动，但这也有风险。

问题2：Docker容器启动失败，日志提示 could not select device driver with capabilities: [[gpu]]

  • 原因 ：Docker daemon没有配置NVIDIA运行时，或者NVIDIA Container Toolkit没有正确安装/启动。
  • 解决 ：
    1. 检查 nvidia-container-toolkit 是否已安装： apt list --installed | grep nvidia-container-toolkit 。
    2. 检查Docker daemon配置 /etc/docker/daemon.json 中的 runtimes 配置是否正确。
    3. 重启Docker服务： sudo systemctl restart docker 。
    4. 运行 docker info | grep -i runtime 查看Docker是否识别到了 nvidia 运行时。

问题3：容器内PyTorch报错 CUDA error: out of memory

  • 原因 ：显存不足。可能是模型太大，也可能是显存泄漏（如前一次推理的Tensor没有释放）。
  • 解决 ：
    1. 应用层 ：检查代码，确保在不使用CUDA Tensor时调用 .cpu() 或 del 释放，对于PyTorch，可以使用 torch.cuda.empty_cache() 清空缓存。
    2. 容器层 ：确保没有其他进程（容器）占用同一块GPU。使用 nvidia-smi 确认。
    3. 限制显存 ：尝试在启动容器时，通过PyTorch的环境变量 PYTORCH_CUDA_ALLOC_CONF 设置 max_split_size_mb ，或使用 CUDA_VISIBLE_DEVICES 限制容器只使用一块GPU中的部分显存（这需要应用支持，且是高级用法）。
    4. 换用更小模型 ：如果显存实在不够，考虑使用精度更低（如FP16）或参数量更少的模型。

问题4：模型下载慢或镜像构建时pip安装超时

  • 原因 ：网络连接问题。
  • 解决 ：
    1. Dockerfile内 ：为 pip 设置国内镜像源，如前面示例所示。
    2. 模型文件 ：不要放在Dockerfile里用 RUN 下载。而是通过启动脚本，或者使用 volumes 挂载宿主机上预先下载好的模型目录。甚至可以搭建一个内部的文件服务器或使用OSS。
    3. Docker镜像拉取 ：为Docker daemon配置国内镜像加速器（在 /etc/docker/daemon.json 中配置 registry-mirrors ）。

7. 进阶：向Kubernetes集群迁移

当你的 carefree-creator 服务需要更高的可用性、弹性伸缩和更复杂的资源调度时，就该考虑Kubernetes了。

7.1 在K8s中声明GPU资源

在Kubernetes中，GPU是一种扩展资源（Extended Resource）。你需要先在集群节点上安装NVIDIA Device Plugin（一个DaemonSet），它负责向Kubelet报告节点上的GPU数量。

然后，在Pod的资源配置中，就可以像请求CPU和内存一样请求GPU： 

apiVersion: v1
kind: Pod
metadata:
  name: carefree-creator-pod
spec:
  containers:
  - name: creator
    image: your-registry/carefree-creator:latest
    resources:
      limits:
        nvidia.com/gpu: 2 # 申请2块GPU
      requests:
        nvidia.com/gpu: 1 # 至少需要1块GPU才能调度

Kubernetes调度器会确保将这个Pod调度到拥有至少2块空闲GPU的节点上。

7.2 使用K8s管理多节点GPU资源

在K8s集群中，你可以：

  • 设置资源配额（ResourceQuota） ：限制不同命名空间（对应不同团队或项目）所能使用的GPU总量。
  • 实现弹性伸缩（HPA） ：基于GPU利用率等自定义指标，自动增加或减少 carefree-creator 的Pod副本数。但这需要部署像Prometheus和GPU Exporter这样的监控系统来提供指标。
  • 使用节点亲和性/反亲和性 ：将需要GPU的Pod调度到带有特定标签的GPU节点上，或者避免将多个GPU负载高的Pod放在同一个节点上（防止物理资源争抢）。

向K8s迁移是一个系统工程，涉及镜像仓库、服务发现、配置管理、日志收集等方方面面。但对于大规模部署和管理多个AI服务来说，这是必经之路。从Docker Compose到K8s，你的 carefree-creator 就真正具备了云原生的能力。

# GPU
Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区