在实际 AI 模型部署和推理领域，一个常见的挑战是：如何在本地有限的硬件资源上，运行一个参数规模庞大、能力接近顶级闭源模型（如 Claude Opus）的开源模型。Qwen3.8-27B 作为一个近期备受关注的多模态大语言模型，其 270 亿参数的规模和对标 Claude Opus 4.6 Max 级别能力的潜力，使其成为许多开发者和研究者希望本地部署的目标。然而，“本地运行”这四个字背后，涉及的是从模型下载、量化、推理框架选择、显存优化到最终性能验证的一整套复杂工程实践。本文将带你完整走通这一流程，重点不是复现论文，而是解决在个人工作站或单张消费级显卡上，让 Qwen3.8-27B 模型以可接受的性能稳定运行起来所遇到的具体问题。

这个过程的核心矛盾在于模型规模与硬件资源的限制。270 亿参数的 FP16 精度模型需要超过 50GB 的显存，这远超了大多数消费级显卡（如 RTX 4090 的 24GB）的能力。因此，我们必须借助模型量化技术，在尽可能保持模型能力的前提下，大幅降低其存储和计算开销。同时，选择合适的推理框架和优化策略，是提升吞吐量和降低延迟的关键。本文将围绕“准备-量化-部署-验证-优化”这条主线，提供一份可操作的技术指南。

1. 理解 Qwen3.8-27B 与量化部署的核心概念

在动手之前，需要先厘清几个关键概念，这决定了后续所有技术选型和操作步骤。

1.1 Qwen3.8-27B 模型定位与技术特点

Qwen3.8-27B 是阿里通义千问团队开源的多模态大语言模型系列中的一员。“27B”代表其参数量约为 270 亿。根据官方介绍和社区评测，其在多项基准测试中的表现接近甚至在某些任务上超越了 Anthropic 的 Claude 3.5 Sonnet 和 OpenAI 的 GPT-4o 等模型，因此被社区认为具备挑战 Claude Opus 4.6 Max 级别能力的潜力。它是一个“多模态”模型，意味着除了文本，还能理解和生成图像内容。

对于本地部署而言，我们需要关注其两个核心架构细节：

  1. 注意力机制 ：通常采用分组查询注意力（GQA）或滑动窗口注意力（SWA），这会影响推理时的 KV Cache 显存占用。
  2. 激活数据类型 ：模型推理时中间激活值（Activation）的精度和大小，这直接关系到显存峰值。

原始模型通常以 FP16（半精度浮点数）或 BF16（Brain Float 16）格式发布，每个参数占用 2 字节。一个 270 亿参数的 FP16 模型，仅参数本身就需要约 54 GB 存储空间。

1.2 模型量化：在精度与效率间权衡

量化是将高精度数据（如 FP32/FP16）映射到低精度数据（如 INT8, INT4）的过程，是本地运行大模型的必备技术。

  • 权重量化 ：仅对模型权重进行量化，推理时反量化回高精度进行计算。能显著降低模型磁盘占用和加载到内存的占用，但对推理速度提升有限。
  • 激活量化 ：对推理过程中的激活值也进行量化，能进一步减少显存占用并可能加速计算，但对精度影响更大，实现更复杂。
  • 量化粒度 ：
    • 每张量（Per-tensor） ：整个权重张量共享一个缩放因子（scale）和零点（zero point）。简单，但精度损失可能较大。
    • 每通道（Per-channel） ：对权重张量的每一个输出通道分别计算缩放因子和零点。精度保留更好，是当前的主流做法。

对于 Qwen3.8-27B 的本地部署，我们主要采用 权重量化 ，并优先选择 INT4 精度，以实现最大的显存节省。常见的 INT4 格式有 q4_0 , q4_1 , q4_K_M , q4_K_S 等（GGUF 格式），或者 AWQ 、 GPTQ 等量化方法。

1.3 推理框架选型

选择合适的推理框架是成功的关键。不同框架在易用性、性能、量化支持和硬件兼容性上差异很大。

框架 核心特点 适合场景 对 Qwen3.8-27B 的支持
Ollama 开箱即用，命令行和 API 简单，内置量化与拉取模型。 快速体验、原型验证、个人使用。 官方可能尚未直接提供 qwen3.8:27b 标签，但可通过 Modelfile 自定义。
LM Studio 图形化界面，无需命令行，内置模型市场与聊天界面。 非开发者、UI 爱好者、快速测试。 依赖其模型市场更新，支持 GGUF 格式。
vLLM 高性能推理与服务框架，支持 PagedAttention 显存优化。 生产环境 API 服务、高吞吐量场景。 支持 Transformers 格式模型，需自行量化或寻找量化版。
llama.cpp C++实现，极致性能与内存效率，GGUF 格式发明者。 资源受限边缘设备、追求极限性能、研究量化。 推荐 。社区支持好，有丰富的量化工具和运行选项。
Text Generation Inference (TGI) Hugging Face 官方推理容器，功能丰富。 云原生部署、需要高级功能（如 LoRA）。 支持，但部署相对复杂。

对于本地运行且资源紧张的场景， llama.cpp 因其卓越的内存效率和广泛的社区工具链，成为最稳妥和灵活的选择。本文将主要基于 llama.cpp 及其生态工具展开。

2. 环境准备与依赖配置

本地运行大模型需要一个稳定的基础环境，包括硬件、操作系统、驱动和必要的软件库。

2.1 硬件与系统要求

  • GPU（强烈推荐） ：至少 12GB 显存。运行 INT4 量化的 Qwen3.8-27B，建议拥有 16GB 或以上显存（如 RTX 4080 16G, RTX 4090 24G）。纯 CPU 推理需要极大的系统内存（>64GB）且速度很慢。
  • CPU ：现代多核 CPU（如 Intel i7/i9 或 AMD Ryzen 7/9）。
  • 内存 ：32GB 及以上。用于存放模型权重（量化后）和系统缓存。
  • 磁盘空间 ：至少 30GB 可用空间，用于存放原始模型、量化后模型和临时文件。
  • 操作系统 ：Linux (Ubuntu 20.04/22.04 LTS)、Windows (WSL2) 或 macOS (Apple Silicon)。本文以 Ubuntu 22.04 为例，命令在 WSL2 中同样适用。

2.2 基础软件安装

首先更新系统并安装编译和 Python 环境。

# 更新系统包列表
sudo apt update && sudo apt upgrade -y

# 安装基础编译工具
sudo apt install -y build-essential cmake git wget

# 安装 Python 3.10 及 pip
sudo apt install -y python3.10 python3.10-venv python3.10-dev python3-pip

接下来，配置 CUDA 环境（如果你使用 NVIDIA GPU）。确保已安装对应显卡驱动，然后安装 CUDA Toolkit。以 CUDA 12.1 为例：

# 从 NVIDIA 官方仓库安装 CUDA Toolkit 12.1
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-ubuntu2204.pin
sudo mv cuda-ubuntu2204.pin /etc/apt/preferences.d/cuda-repository-pin-600
sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/3bf863cc.pub
sudo add-apt-repository "deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/ /"
sudo apt update
sudo apt install -y cuda-toolkit-12-1

# 将 CUDA 路径加入环境变量（写入 ~/.bashrc）
echo 'export PATH=/usr/local/cuda-12.1/bin${PATH:+:${PATH}}' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.1/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}' >> ~/.bashrc
source ~/.bashrc

# 验证安装
nvcc --version

2.3 获取模型权重

我们需要从 Hugging Face 下载原始的 Qwen3.8-27B 模型。使用 git-lfs 来下载大文件。

# 安装 git-lfs
sudo apt install -y git-lfs
git lfs install

# 克隆模型仓库（确保你有足够的磁盘空间）
git clone https://huggingface.co/Qwen/Qwen3.8-27B-Instruct
cd Qwen3.8-27B-Instruct

这个过程会下载约 50GB 的数据（FP16 格式）。如果网络不稳定，可以考虑使用镜像源或 huggingface-cli 工具。

3. 模型量化与格式转换

原始的 FP16 模型无法在消费级显卡上运行，我们必须将其量化为 GGUF 格式。我们将使用 llama.cpp 项目中的 convert.py 和 quantize 工具。

3.1 编译 llama.cpp

首先获取并编译 llama.cpp ，启用 CUDA 支持以获得 GPU 加速。

# 返回到工作目录
cd ~
# 克隆 llama.cpp 仓库
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

# 编译启用 CUDA 的版本
make LLAMA_CUBLAS=1 -j$(nproc)

# 编译完成后，生成的可执行文件在 `./bin` 目录下，将其加入 PATH 或直接使用
export PATH=$(pwd)/bin:$PATH

3.2 将 Hugging Face 格式转换为 GGUF 格式

llama.cpp 不能直接读取 Hugging Face 的 safetensors 格式，需要先转换为中间格式（FP16 GGUF）。

# 假设你的原始模型路径是 ~/Qwen3.8-27B-Instruct
# 进入 llama.cpp 目录执行转换脚本
cd ~/llama.cpp
python3 convert.py ~/Qwen3.8-27B-Instruct \
  --outtype f16 \
  --outfile ~/qwen3.8-27b-f16.gguf

这个命令会读取原始模型的所有文件，并将其合并、转换为一个单独的 qwen3.8-27b-f16.gguf 文件。这个过程需要一些时间，并且会生成一个约 50GB 的 FP16 GGUF 文件。

3.3 量化 FP16 GGUF 文件为 INT4 精度

现在，我们将这个巨大的 FP16 文件量化为更小的 INT4 文件。 llama.cpp 提供了多种量化类型，我们选择在精度和大小之间平衡较好的 q4_K_M 。

cd ~/llama.cpp
./bin/quantize ~/qwen3.8-27b-f16.gguf \
  ~/qwen3.8-27b-q4_K_M.gguf \
  q4_K_M

关键参数解释 ：

  • q4_K_M : 一种中等粒度的 4 位量化方式。它比 q4_0 精度更高，比 q5_0 文件更小。对于 27B 模型，这是一个非常流行的选择。
  • 量化过程同样需要时间，最终生成的 qwen3.8-27b-q4_K_M.gguf 文件大小约为 17-19 GB ，这使其能够在 24GB 显存的显卡上运行（还需预留空间给 KV Cache 和激活值）。

注意 ：量化完成后，原始的 FP16 GGUF 文件（ ~/qwen3.8-27b-f16.gguf ）可以删除以节省空间，除非你计划尝试其他量化类型。

4. 使用 llama.cpp 进行本地推理

拥有量化模型后，就可以使用 llama.cpp 的 main 工具进行推理了。

4.1 基础命令行交互

最简单的交互方式是使用 -i 参数进入交互模式。

cd ~/llama.cpp
./bin/main -m ~/qwen3.8-27b-q4_K_M.gguf \
  -n 512 \ # 生成的最大令牌数
  -t 8 \   # 使用的 CPU 线程数（如果使用 GPU，这个数字影响不大）
  -ngl 99 \ # 将多少层模型加载到 GPU 显存中（99 表示尽可能多）
  -c 8192 \ # 上下文长度（Qwen3.8 支持 128K，但设置太高会占用大量显存）
  --color \ # 彩色输出
  -i        # 交互模式

启动后，你会看到一个 >>> 提示符，可以直接输入问题。例如，输入“用 Python 写一个快速排序函数”，模型会开始生成代码。

4.2 关键运行参数详解

llama.cpp 的 main 工具参数众多，以下是与性能和资源最相关的几个：

参数 全称 作用与建议值
-m, --model MODEL_PATH 模型文件路径。 必须指定 。
-n, --n-predict N_PREDICT 生成文本的最大长度（token 数）。默认 128，可设为 512 或 1024。
-t, --threads N_THREADS CPU 线程数。当部分层在 CPU 上运行时使用。通常设为物理核心数。
-ngl, --n-gpu-layers N_GPU_LAYERS 最重要参数之一 。指定将多少层模型转移到 GPU。值越大，GPU 利用率越高，速度越快，但显存占用也越大。对于 27B 模型，在 24GB 卡上可尝试 40-60 层，在 16GB 卡上尝试 20-30 层。设为 -1 或 99 表示全部加载（如果显存足够）。
-c, --ctx-size CTX_SIZE 上下文窗口大小（token 数）。Qwen3.8 支持 128K，但设置越大，KV Cache 显存占用越大。初次测试可设为 4096 或 8192。
-b, --batch-size BATCH_SIZE 批处理大小。影响推理吞吐量。增大可以更充分利用 GPU，但也会增加显存占用。对于交互式单次生成，保持默认（512）即可。
--mlock 将模型锁定在内存中，防止被交换到磁盘。如果系统内存充足，可以启用以提升性能。
--no-mmap 不使用内存映射加载模型。如果 --mlock 失败，可以尝试此选项。

一个更优化的运行示例，假设你有一张 24GB 显存的显卡：

./bin/main -m ~/qwen3.8-27b-q4_K_M.gguf \
  -n 1024 \
  -t 10 \
  -ngl 55 \ # 尝试将约55层放在GPU上
  -c 8192 \
  -b 512 \
  --mlock \
  -p “” # 使用 -p 指定提示词，而非交互模式
# 例如：-p “### Instruction: 解释量子计算。### Response:”

4.3 通过 API 服务提供调用

llama.cpp 还提供了一个与 OpenAI API 兼容的服务器 server ，这允许你通过 HTTP 请求来调用模型，方便集成到其他应用中。

cd ~/llama.cpp
./bin/server -m ~/qwen3.8-27b-q4_K_M.gguf \
  -c 4096 \
  -ngl 55 \
  --host 0.0.0.0 \ # 监听所有网络接口
  --port 8080

服务器启动后，你可以使用 curl 或任何 HTTP 客户端（如 Python 的 requests 库）进行调用。

# 使用 curl 调用聊天补全接口
curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3.8-27b",
    "messages": [
      {"role": "system", "content": "你是一个乐于助人的助手。"},
      {"role": "user", "content": "你好，请介绍一下你自己。"}
    ],
    "max_tokens": 200,
    "temperature": 0.7
  }'

5. 性能验证与能力评估

部署完成后，如何验证模型是否真的在“工作”，并且其能力是否符合预期？

5.1 基础功能测试

运行一些简单的指令，观察模型的响应速度、连贯性和基础能力。

  1. 指令遵循 ：给出明确的指令，如“写一封感谢信，感谢同事在项目中的帮助”。
  2. 代码生成 ：要求用特定语言实现一个算法，如“用 JavaScript 实现二叉树的深度优先遍历”。
  3. 逻辑推理 ：提出一个简单的逻辑谜题，如“如果所有 A 都是 B，有些 B 是 C，那么有些 A 是 C 吗？为什么？”
  4. 知识问答 ：询问事实性知识，注意检查其时效性，因为模型知识可能不是最新的。

5.2 性能指标监控

在模型生成文本时，关注 llama.cpp 输出的性能指标：

llama_print_timings:        load time =   XXXX ms
llama_print_timings:      sample time =    YYY ms /    ZZ runs   (   AA ms per token,   BB.00 runs per second)
llama_print_timings: prompt eval time =   PPPP ms /    QQ tokens (  RRR.ms per token,  SSS.tt tokens per second)
llama_print_timings:        eval time =  TTTTT ms /    UU runs   ( VVVV ms per token,  WWW.XX tokens per second)
llama_print_timings:       total time =  YYYYY ms
  • prompt eval time / tokens per second : 处理输入提示词的速度。这反映了模型的“理解”速度。
  • eval time / tokens per second : 生成 token 的速度 。这是衡量推理性能的核心指标。在 GPU 上， q4_K_M 量化的 27B 模型，速度通常在 20-50 tokens/秒 之间，具体取决于你的 GPU 型号和 -ngl 参数设置。
  • load time : 模型加载时间。使用 --mlock 后，首次加载会变慢，但后续运行会更快。

5.3 与“Opus 级能力”的对照

要评估是否达到“Opus 4.6 Max 级能力”，需要进行更系统的评测。作为本地实践，可以运行一些公认的基准测试套件，但需要注意量化会带来轻微的性能损失。

  • 使用 lm-evaluation-harness ：这是一个流行的评估框架。你可以编写或使用现有的任务配置来测试 Qwen3.8-27B 在 MMLU（大规模多任务语言理解）、HellaSwag、GSM8K（数学）等数据集上的表现。将结果与官方公布的 FP16 精度下的 Qwen3.8-27B 分数，以及 Claude Opus 公开的基准分数进行对比。
  • 主观体验对比 ：在创意写作、复杂指令遵循、代码调试等需要深度推理的任务上，与你能接触到的 Claude Opus（例如通过 API）进行并排比较。注意，量化模型在需要极高数值精度的任务（如复杂数学运算）上可能会有更明显的退化。

6. 常见问题排查与优化

在本地运行过程中，你几乎一定会遇到各种问题。以下是典型的问题及其解决方案。

6.1 显存不足（Out of Memory, OOM）

这是最常见的问题。

现象 ：运行命令后立即崩溃，或在生成过程中崩溃，提示 CUDA out of memory 。

原因与解决方案 ：

  1. -ngl 参数过高 ：这是最主要的原因。减少 -ngl 的值，让更多层留在 CPU 内存中。每次减少 5-10 层进行尝试。 
    # 尝试更少的 GPU 层数
./bin/main -m ~/qwen3.8-27b-q4_K_M.gguf -ngl 30 ...
  2. 上下文长度 -c 过大 ：上下文长度直接影响 KV Cache 的显存占用。将 -c 从 8192 降低到 4096 或 2048。
  3. 批处理大小 -b 过大 ：在交互式场景下，将其设为 1 或 128。
  4. 使用更激进的量化 ：如果 q4_K_M 仍然太大，尝试 q4_0 或 q3_K_M ，但要做好精度显著下降的准备。
  5. 关闭其他占用显存的程序 ：确保没有其他应用（如浏览器、IDE）占用大量显存。

6.2 推理速度过慢

现象 ：生成 token 的速度远低于预期（例如 < 5 tokens/秒）。

排查与优化 ：

  1. 检查 -ngl 参数 ：使用 nvidia-smi 命令查看 GPU 利用率。如果利用率很低（例如 < 20%），说明大部分计算在 CPU 上进行。尝试增加 -ngl 值，直到 GPU 利用率达到 80% 以上，或者显存即将用满。
  2. 检查 CPU 线程数 -t ：如果很多层在 CPU 上运行，确保 -t 设置合理（通常等于物理核心数）。可以使用 htop 查看 CPU 占用。
  3. 使用 --no-mmap 和 --mlock ：在某些系统上，内存映射可能导致性能问题。尝试添加 --no-mmap 参数。如果系统内存充足，同时添加 --mlock 可以避免页面交换。
  4. 升级驱动和 CUDA ：确保使用最新的 NVIDIA 驱动和与 llama.cpp 兼容的 CUDA 版本。
  5. 尝试不同的量化类型 ： q4_K_M 是平衡之选。 q5_K_M 精度更高但更慢更大； q4_0 更快更小但精度更低。在速度和精度间权衡。

6.3 模型输出乱码或无意义

现象 ：模型生成的内容是乱码、重复字符或完全不符合逻辑的文本。

排查步骤 ：

  1. 检查模型文件完整性 ：重新下载或转换模型文件。计算 GGUF 文件的 MD5 或 SHA256 哈希值，与社区提供的哈希值对比。
  2. 检查提示词格式 ：Qwen 系列模型通常有特定的聊天模板。确保你的输入符合其训练时的格式。对于 Qwen3.8-Instruct，正确的格式通常类似于： 
    <|im_start|>system
You are a helpful assistant.<|im_end|>
<|im_start|>user
Hello!<|im_end|>
<|im_start|>assistant
    在使用 llama.cpp 的 main 工具时，你可能需要使用 -f 参数指定一个包含此格式的提示文件，或者使用 server （它通常能自动处理格式）。 格式错误是导致输出乱码的最常见原因 。
  3. 降低温度 --temp ：如果温度参数过高（如 >1.0），模型输出会变得随机。尝试将其设为 0.1 到 0.8 之间，以获得更确定性的输出。
  4. 检查量化是否失败 ：尝试用同一个量化工具和参数，量化一个更小的、已知能正常工作的模型（如 Qwen2.5-7B），看是否出现问题。如果小模型正常，则问题可能出在原始的大模型文件上。

6.4 服务器（ server ）启动失败或无法连接

现象 ： ./bin/server 启动后立即退出，或 curl 请求返回连接拒绝。

解决方案 ：

  1. 端口占用 ：默认端口 8080 可能被占用。使用 --port 8081 更改端口。
  2. 权限问题 ：在 Linux 上，绑定 1024 以下端口需要 root 权限。要么使用高于 1024 的端口，要么用 sudo 运行（不推荐）。
  3. 防火墙 ：如果从其他机器访问，确保服务器机器的防火墙放行了对应端口。
  4. 服务器日志 ：查看 server 启动时的输出日志，通常会有错误信息。

7. 生产环境考量与最佳实践

如果计划将本地运行的 Qwen3.8-27B 用于开发测试或轻量级生产，以下最佳实践至关重要。

7.1 资源隔离与监控

  • 使用容器 ：考虑使用 Docker 容器来隔离模型运行环境，避免与宿主机其他服务冲突。可以基于 nvcr.io/nvidia/cuda 等官方镜像构建。
  • 资源限制 ：在 Docker 中使用 --gpus all --memory , --memory-swap , --cpus 等参数限制容器资源使用，防止单个服务耗尽所有资源。
  • 基础监控 ：监控 GPU 显存使用率、GPU 利用率、系统内存和 CPU 使用率。可以使用 nvidia-smi , htop , 或集成到 Prometheus/Grafana。

7.2 性能与稳定性优化

  • 持久化服务 ：使用 systemd 或 supervisor 管理 llama.cpp 的 server 进程，确保其崩溃后能自动重启。
  • 预热 ：在服务启动后，先发送几个简单的请求进行“预热”，让模型完全加载并初始化 CUDA 上下文，避免第一个真实请求延迟过高。
  • 负载测试 ：使用工具（如 locust 或 wrk ）模拟多用户并发请求，了解服务的最大吞吐量和瓶颈所在。根据测试结果调整 -b （批处理大小）和 --parallel （ server 的并行请求数）参数。
  • 实现简单的请求队列 ：如果并发请求超过服务处理能力，应在应用层实现队列，避免压垮推理进程。

7.3 安全与权限

  • API 密钥 ：如果对外提供服务，务必不要将 API 端口直接暴露在公网。使用反向代理（如 Nginx）并配置 API 密钥认证。
  • 输入过滤 ：对用户输入进行基本的过滤和长度限制，防止提示词注入攻击或过长的输入耗尽上下文窗口。
  • 日志记录 ：记录所有请求和响应的元数据（如时间戳、用户 ID、token 使用量），但不记录敏感的对话内容，以便审计和计费。

7.4 模型更新与回滚

  • 版本化模型文件 ：将量化后的 GGUF 文件进行版本管理（如 qwen3.8-27b-q4_K_M-v1.gguf ）。
  • 蓝绿部署 ：准备两个相同的服务环境，通过切换负载均衡指向来更新模型，实现零停机部署和快速回滚。

在本地成功运行一个 270 亿参数的多模态模型，并使其发挥出接近顶级闭源模型的潜力，是一项充满挑战但极具成就感的工作。整个过程的核心在于对量化、推理框架和硬件资源的精细把控。从选择 llama.cpp 和 q4_K_M 量化，到反复调整 -ngl 参数平衡显存与速度，再到处理模型特定的提示词格式，每一步都需要结合具体环境进行调试。记住，没有一劳永逸的配置，最好的参数来自于对你自身硬件和工作负载的持续观察与调优。未来，可以进一步探索 vLLM 的 PagedAttention 以服务更高并发，或者尝试 AWQ/GPTQ 等更先进的量化方法，在精度和效率之间寻找更优的平衡点。

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 亚马逊云科技技术品牌专区