企业官网建设流程全解析

这次我们来看 Skild S1。它不是普通的视觉分类模型，也不是对话大模型，而是面向机器人操作任务的具身智能基础模型。它最核心的设计点用一句话就能说清：视频即提示词。传统机器人控制模型要写文本指令、要标状态、要画 reward，Skild S1 换了一条路径——直接把一段视频作为输入，让模型从中理解任务目标、操作约束和执行顺序，最后输出机器人可执行的动作序列。

从公开资料看，Skild S1 的重点在“通用性”和“泛化能力”。它试图让一个模型应对多种机械臂、多个操作场景，而不是每个任务单独训一个模型。这意味着，开发者可以把一段真实演示视频丢给模型，模型自己提取“该做什么、怎么做”，这比手写 prompt、手拆任务状态要直观得多。对于机器人算法工程师、具身智能研究方向的学生，以及正在评估 VLA 模型落地的团队来说，S1 是一个值得关注和测试的模型。

这篇文章会围绕“视频即提示词”这条主线展开。第一部分先给出 S1 的核心能力速览，说明这个模型适合谁、不适合谁。然后梳理使用边界和合规要求，再给出环境准备、部署方式、功能测试、接口调用、批量任务、性能观察和排错清单。整体目标是帮你在不踩大量坑的前提下，完成 S1 模型的接入评估和验证。

1. 核心能力速览

从这张表能看出，S1 不是给普通消费级显卡用户玩的“开箱即用 Demo”，而是面向机器人开发者的基础模型。它更适合做策略生成、任务泛化研究和机械臂操作预训练。如果你手里只有一台 8G 显存的家用显卡，建议先走 API 或云 GPU 方案，不要一开始就尝试本地加载大模型权重。

关于显存占用，这里要特别说明：根据目前公开信息，Skild S1 没有统一公布“4G 可用”或“12G 可用”这类消费级显卡指标。机器人基础模型通常参数量不小，推理时还要同时处理视频帧和动作序列，显存消耗和视频长度、动作维度强相关。更稳妥的判断是：先按官方部署文档准备足够大的 GPU 显存，或者直接使用官方 API 服务，算力需求这一块放到后面实测部分再量化。

2. 适用场景与使用边界

Skild S1 适合的典型的场景是“从视频到动作”的机器人学习流程。比如你有一台机械臂，希望它学会抓取桌面上的杯子，传统方式是采集专家轨迹、标注状态、训练控制策略。用 S1 的方式，你可以录制一段人操作机械臂或人手抓取杯子的视频，把视频交给模型，模型输出对应的动作序列，再通过仿真或真机执行。这个流程对算法验证、快速原型、跨任务泛化测试非常友好。

它也适合做 VLA 模型的对比评估。如果你之前接触过 RT-2、OpenVLA、Octo 这类模型，可以把 S1 加入评测集，用同一组视频任务去测不同模型的动作预测质量和泛化能力。由于 S1 主打“视频即提示词”，评测时不需要为每个任务写冗长的文本指令，这能减少人为 prompt 带来的偏差，让评估更接近任务本身的难度。

但 S1 并不适合所有机器人问题。它不解决硬件层的电机控制、力控和动力学建模问题；也不是一个可以直接上生产线的闭环控制器。它更像一个“策略生成器”或“高层决策器”，输出动作序列后，下游还需要运动规划、安全校验和底层执行模块。此外，如果你的任务没有视频数据、只有文本描述或传感器数据，S1 的核心优势就发挥不出来。

使用边界方面必须强调几点：第一，涉及真人视频、手势、面部信息时，要确保已经获得对应人员的授权；第二，涉及公司内部产线、实验室设备操作时，要确认视频数据是否可以外传，避免隐私和商业机密泄露；第三，机器人动作输出可能造成实体碰撞或伤害，任何真实机械臂实验都必须加装安全急停、限位保护和独立监控；第四，如果模型从视频中学到了不该执行的危险动作，开发者必须做行为筛除和安全策略后置。合法授权、隐私保护、安全边界这三件事，比模型效果本身更重要，务必放在测试流程的最前面。

3. 环境准备与前置条件

在接入 Skild S1 之前，先确认你的环境满足两个方向的要求：一个方向是纯 API 调用，只需要能发送 HTTP 请求的机器和网络环境；另一个方向是本地推理，需要准备深度学习环境和 GPU 资源。从实用角度来看，我建议第一轮评估优先走 API 方向，先把模型行为跑明白，再决定是否需要本地部署。

如果走 API 方向，环境准备非常简单：

• 一台能联网的 Linux 服务器、Windows 或 macOS 开发机；
• Python 3.9 以上环境；
• requests或httpx库；
• 视频处理工具，比如ffmpeg，用于裁剪、转码和抽帧；
• 官方 API Key 或访问令牌，具体申请方式以官方渠道为准。

如果是本地推理方向，建议准备：

• Linux 服务器，Ubuntu 22.04 是比较稳的选择；
• NVIDIA GPU，显存大小要按官方部署说明来，先预留充足余量；
• CUDA 驱动和对应版本的 PyTorch；
• 可能需要的 Python 依赖：torch、transformers、decord、opencv-python、numpy；
• 如果还要在仿真中回放动作，需要安装 MuJoCo、Isaac Lab 或 ROS 2 环境；
• 模型权重文件和推理脚本，以官方渠道发布为准。

磁盘空间也是一个需要提前确认的点。机器人基础模型的权重文件通常不会太小，加上视频数据集、动作日志和仿真缓存，建议预留 100GB 以上空闲磁盘。如果你打算在本地做批量视频推理，磁盘空间的需求会更高。

登录到服务器后，可以用下面的命令做一个基础检查：

# 检查 GPU 和驱动 nvidia-smi # 检查 Python 版本 python3 --version # 检查 pip 版本 pip3 --version # 检查 ffmpeg 是否可用 ffmpeg -version

如果nvidia-smi能正常输出显卡信息，说明驱动可用；如果确认已经安装了深度学习的 CUDA 环境，可以用 PyTorch 自带命令验证：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

这个检查能帮你在部署前把环境问题区分开：是 GPU 驱动问题、PyTorch 版本问题，还是模型依赖问题。

4. 安装部署与启动方式

Skild S1 的部署方式取决于官方到底推出的是云端 API 服务、开源模型权重，还是仅面向合作伙伴开放。这里按两种常见形态分别说明。

4.1 云端 API 服务

如果官方提供 API，部署成本最低。你不需要下载模型权重，也不需要关心显存，只需要注册账号、拿到 API Key，然后调用接口。典型的调用流程是：

1. 准备一段演示视频；
2. 将视频发送到官方接口，附带任务描述参数（如机器人类型、动作空间）；
3. 接口返回动作序列或策略代码；
4. 将动作序列在仿真环境或真机中执行。

假设官方接口路径是https://api.example.com/v1/policy/video（这里仅为示意，不是真实地址），一个通用的调用请求会用 POST 方式上传视频文件。这里给出一个 Python 调用模板，实际路径和参数必须按官方文档调整：

import requests api_url = "https://api.example.com/v1/policy/video" headers = { "Authorization": "Bearer YOUR_API_KEY", "Content-Type": "application/octet-stream" } video_path = "demo.mp4" with open(video_path, "rb") as f: video_data = f.read() params = { "robot": "ur5e", # 机器人型号，以官方支持列表为准 "action_space": "joint", # joint 或 cartesian，以模型定义为准 "max_steps": 200 } response = requests.post( api_url, headers=headers, params=params, data=video_data, timeout=120 ) print(response.status_code) print(response.json())

这里要提醒一句：不要直接把这段代码拷进生产环境。它只是一个通用调用模板，用来理解 HTTP 调用形态。实际接口的鉴权头、请求格式、参数名、返回结构都需要以官方文档为准。如果官方没有开放 API，这种调用方式就不存在。

4.2 本地推理部署

如果官方开放权重，本地部署一般需要下载模型文件、安装依赖，然后运行推理脚本。你可以把它看作一个标准的深度学习模型部署流程：

# 创建虚拟环境，示例命令 python3 -m venv skild_s1_env source skild_s1_env/bin/activate # 安装基础依赖，这里用的是占位版本，实际以 requirements.txt 为准 pip install torch torchvision torchaudio pip install transformers decord opencv-python numpy # 下载模型权重后，假设官方提供了推理脚本 python inference.py --video inputs/demo.mp4 --output outputs/actions.jsonl

如果你的环境是 Windows，则需要把source skild_s1_env/bin/activate换成：

skild_s1_env\Scripts\activate

启动前重点检查两件事：模型路径是否写对，视频路径是否存在。模型权重下载完成后，不要放在中文路径下，也不要带空格，否则很多深度学习框架都会踩到路径解析问题。

如果官方提供了 Docker 镜像，部署会省很多事：

# 拉取镜像，示例命令 docker pull your_registry/skild-s1:latest # 启动 GPU 容器，示例命令 docker run --gpus all --rm \ -v $PWD/data:/app/data \ -v $PWD/outputs:/app/outputs \ your_registry/skild-s1:latest \ python inference.py --video /app/data/demo.mp4 --output /app/outputs/actions.jsonl

Docker 的好处是依赖隔离干净，不会污染宿主机 Python 环境；坏处是需要提前处理模型文件挂载、CUDA 运行时一致性等问题。首次启动如果遇到容器内无法调用 GPU，先检查nvidia-smi是否能在容器里运行。

4.3 服务启动后的访问确认

服务启动后，不要急着喂数据。先确认服务是否存活、端口是否正常监听。如果是本地 WebUI 或 API 服务，先看启动日志里打印的访问地址：

# 查看端口监听情况 netstat -tuln | grep 7860 # 或者 curl -v http://127.0.0.1:7860/health

如果返回 200 或者有正常的 JSON 状态，说明服务已经起来了。如果端口被占用，可以使用lsof -i:端口号找到占用进程，或者换一个端口重新启动。启动阶段最常见的坑是服务进程没有真正跑起来，日志却显示 success，这时优先检查模型加载日志和 GPU 占用日志。

5. 功能测试与效果验证

验证 Skild S1 有没有用，关键不是“接口能通”，而是“视频转动作到底靠不靠谱”。这里建议搭建一套可重复的评估流程，分别从基础抓取、多步骤任务、视频长度、跨机器人泛化几个维度去测。

5.1 测试数据准备

准备测试视频时注意三点：分辨率不要过于夸张，1080p 或以下即可；视频内容要清晰展示任务目标和操作过程；视频长度按任务复杂度控制在几秒到几十秒之间。更关键的是，视频不能只包含目标状态的静态画面，要包含完整的操作过程，比如从机械臂移动、张开夹爪、抓取物体、移动并释放。

建议把测试视频按任务类型放目录：

data/ ├── pick_place/ # 抓取放置任务 │ ├── demo_01.mp4 │ └── demo_02.mp4 ├── tool_use/ # 工具使用任务 │ ├── demo_01.mp4 │ └── demo_02.mp4 └── multi_step/ # 多步骤任务 ├── demo_01.mp4 └── demo_02.mp4

5.2 测试维度

建议至少测五个维度：

• 基础抓取能力：输入一段“抓取杯子放到底座上”的视频，观察输出的动作是否包含抓取、移动、释放三个完整阶段。
• 多步骤任务：输入一段“打开抽屉，拿出螺丝刀，放在桌面上”的视频，观察模型是否能拆分步骤并保持动作顺序。
• 新任务泛化：输入一段模型没见过的物体组合或场景布局，观察成功率衰减是否剧烈。
• 视频长度影响：分别用 3 秒、10 秒、20 秒的视频测同一类任务，观察输出质量和推理延迟的变化。
• 机器人形态迁移：如果模型宣称支持多种机器人，分别用不同机械臂的演示视频测试。

每个测试至少要跑 10 个演示视频，不能只测单个视频就下结论。动作空间不同，模型输出的轨迹格式也不同，建议把每次输出保存成 JSONL 文件，方便后续统计成功率。

{ "video_id": "demo_01", "task": "pick_place", "robot": "ur5e", "action_start": 0, "trajectory": [ {"step": 0, "joint_position": [1.2, -0.5, 0.3, 0.0, 0.0, 0.0]}, {"step": 1, "joint_position": [1.3, -0.4, 0.4, 0.0, 0.0, 0.0]} ], "success": true }

5.3 判断成功标准

判断“视频即提示词”是否有效，不能只看能不能输出动作序列。要看输出动作能不能在仿真环境中完成任务。建议这样定义成功：

• 执行过程中没有出现明显碰撞或越过关节限位；
• 目标物体被正确操作；
• 任务完成标记达到；
• 多次运行成功率不低于 50%。

如果模型输出拿不到任务完成标记，说明模型对视频任务意图的理解可能不够。这时先排除视频质量问题，再检查动作空间设置是否匹配机器人型号。

5.4 失败定位

功能测试失败时，按下面的顺序排查：

1. 视频是否包含足够的任务信息；
2. 视频编码是否是模型支持的格式；
3. 机器人型号和动作空间参数是否填写正确；
4. 推理长度是否被最大步数限制截断；
5. 是否缺少后处理步骤，比如动作平滑、碰撞检测。

这一节是整个评估中最花时间的地方。不要怕失败，S1 这类模型对视频质量、相机视角、执行频率都比较敏感，多记录失败样本，反而能帮你判断模型真正适合哪些任务。

6. 接口 API 与批量任务

机器人基础模型的落地形态往往是 API 服务。视频即提示词这种交互方式非常依赖“上传视频 → 输出动作”的接口闭环。如果你要评估 Skild S1，接口和批量任务的设计会直接影响测试效率。

6.1 接口调用流程

先启动服务，再确认接口鉴权方式。如果官方提供了 OpenAPI 文档，直接根据文档调用。如果没有文档，可以用下面这个通用流程：

import requests api_url = "YOUR_SKILD_S1_API_ENDPOINT" video_path = "demo.mp4" params = { "robot": "your_robot_model", "action_type": "joint_positions", "max_steps": 100, } headers = { "Authorization": "Bearer YOUR_ACCESS_TOKEN" } with open(video_path, "rb") as f: files = {"video": (video_path, f, "video/mp4")} response = requests.post(api_url, headers=headers, params=params, files=files, timeout=300) print(response.json())

这里使用的YOUR_SKILD_S1_API_ENDPOINT、YOUR_ACCESS_TOKEN都是占位符，需要替换成官方提供的真实值。如果在真实调用中遇到 401，优先检查 API Key 是否失效；遇到 413，说明视频文件太大，先压缩或抽帧。

6.2 返回结果解析

接口返回结果通常会包含一个动作序列。以下是一个假设的响应结构，便于理解解析方式：

{ "task_id": "task_001", "success": true, "action_type": "joint_positions", "actions": [ [1.2, -0.5, 0.3, 0.0, 0.0, 0.0], [1.3, -0.4, 0.4, 0.0, 0.0, 0.0] ], "duration_ms": 850 }

解析时要注意两个风险点：第一，动作数组是相对量还是绝对量，这关系到下游执行逻辑；第二，输出的频率是多少，比如 1 秒输出 10 个关节位置还是 50 个，要和执行端控制频率匹配。建议把原始返回结果原样保存，不做预采样，方便后续排查。

6.3 批量任务脚本

批量测试时，不可能一条一条手动调接口。建议写一个目录扫描脚本，自动遍历所有视频，依次调用 API，保存每个视频的输出结果，并记录错误信息。下面给出一个通用 Python 批量任务脚本：

import os import json import time import requests from pathlib import Path API_URL = "YOUR_SKILD_S1_API_ENDPOINT" HEADERS = {"Authorization": "Bearer YOUR_ACCESS_TOKEN"} INPUT_DIR = Path("data") OUTPUT_DIR = Path("outputs") OUTPUT_DIR.mkdir(exist_ok=True) video_extensions = [".mp4", ".avi", ".mov"] def process_video(video_path: Path): with open(video_path, "rb") as f: files = {"video": (video_path.name, f, "video/mp4")} params = {"robot": "your_robot_model", "max_steps": 100} response = requests.post( API_URL, headers=HEADERS, params=params, files=files, timeout=300 ) return response.json() failed = [] for video_path in INPUT_DIR.rglob("*"): if video_path.suffix.lower() not in video_extensions: continue try: data = process_video(video_path) out_file = OUTPUT_DIR / f"{video_path.stem}.json" with open(out_file, "w", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2) print(f"processed: {video_path}") time.sleep(0.5) except Exception as exc: failed.append({"video": str(video_path), "error": str(exc)}) print(f"failed: {video_path} -> {exc}") with open(OUTPUT_DIR / "failed.json", "w", encoding="utf-8") as f: json.dump(failed, f, ensure_ascii=False, indent=2)

批量任务必须考虑失败重试。原因是视频上传、网络波动、接口限流都会导致偶发失败。比较稳的设计是设置最大重试次数，比如 3 次，并对接口返回 429 限流时做指数退避。批量脚本里最好记录总耗时、平均单视频耗时、失败率这几个指标，方便和后续模型版本做对比。

Batch 命令可以从命令行传入输入目录和输出目录，把逻辑做干净：

python batch_inference.py \ --input_dir data \ --output_dir outputs \ --api_url http://127.0.0.1:8000/predict \ --max_retries 3

7. 资源占用与性能观察

机器人基础模型是计算密集型任务，资源占用与性能观察不能只看模型参数量，还要看视频预处理、动作解码、后处理三个环节。下面给出一个可操作的观察方法，不依赖官方宣传数据。

7.1 观察工具

在推理过程中，用nvidia-smi每 1 秒采样一次 GPU 状态：

nvidia-smi --query-gpu=utilization.gpu,utilization.memory,memory.used,memory.total --format=csv -l 1

如果是在服务器后台运行，建议把日志写进文件：

nvidia-smi --query-gpu=timestamp,utilization.gpu,memory.used --format=csv -l 2 >> gpu_stats.log 2>&1

这个日志能帮你看到显存占用峰值出现在哪个阶段：是在视频编码阶段，还是在模型前向推理阶段。两次采样之间如果出现明显波动，说明任务的前处理或后处理阶段也在占用大量资源。

7.2 关键性能指标

建议记录四个指标：

• 单视频端到端延迟：从提交视频到拿到完整动作序列的时间；
• 平均显存占用：推理过程中显存使用的中位数；
• 峰值显存占用：推理过程中显存使用的最大值；
• 吞吐率：单位时间内能处理多少条视频。

对这些指标，不要只看一次结果，要用多组视频长度做对比。比如固定机器人型号和动作步数，分别测 5 秒、10 秒、20 秒视频的延迟和显存变化。通常视频越长，显存占用和延迟都会上升，具体趋势要实测后才能得到。

7.3 资源占用优化思路

如果显存不足，优先降低输入视频分辨率；其次减少输入帧率，从 30fps 降到 10fps，对很多任务语义影响不大，但显存占用会明显下降；再次缩短推理最大步数，把max_steps调小；最后才考虑换更小版本的模型或使用 batch size 为 1。

如果计算资源非常有限，建议直接更换策略：用官方 API 做效果验证，本地只做动作后处理和仿真回放。这样可以把本地 GPU 需求降到最低。

这里要再强调一次：具体显存数字取决于模型版本、输入视频长度、动作空间维度、精度设置，本文没有杜撰一个“实测 7G 显存”之类的结论。一定要以你自己环境跑出来的nvidia-smi数据为准。

8. 常见问题与排查方法

接入 VLA 类模型，最浪费时间的问题往往不是模型本身有多难理解，而是环境、数据格式、网络和路径细节。这里整理一个常见问题排查表，遇到问题可以直接对着查。

依赖安装失败也是常见问题。比如 PyTorch 版本和 CUDA 驱动不匹配，import torch时报错，说明安装时没有选对 CUDA 版本。这种情况先跑一下nvidia-smi看驱动支持的 CUDA 版本，再根据官网给出的安装命令重装 PyTorch。

接口调用失败时，不要只看 status code，要把响应体完整打印出来。很多错误提示比状态码更有用。另外，所有网络请求都要设置超时，避免在一个坏请求上卡死整个批量任务。

批量任务卡住时，优先检查是网络问题还是视频文件问题。建议每次调用前先打印视频文件大小，如果文件为 0KB，说明数据拷贝有问题。处理海量视频时，优先用 SSD，机械硬盘的随机读取会成为瓶颈。

如果发现输出质量不稳定，说明需要增加测试视频数量。模型在某个场景下表现好，不代表换一个背景、换一个物体颜色后还能保持稳定。机器人基础模型的泛化评估，本质上是一个统计问题，至少要准备 20 条以上评测视频，并记录每次的 success 标记。

9. 最佳实践与使用建议

在完成基础功能验证之后，下面这些工程化建议能帮你把 Skild S1 接入到更接近生产的状态。

第一，第一轮测试永远用小参数。不要上来就测 20 秒的高清视频，也不要开很大的 batch。先用一条短视频、一个简单抓取任务跑通全流程，确认输入输出格式没问题，再逐步加大负载。

第二，保留一套最小可运行配置。把模型版本、依赖清单、启动命令、参数文件都写进一个 README，冻结在代码仓库里。这样即使换机器、换同事，也可以快速复现。

第三，模型文件、输入视频、中间输出、最终结果分别分目录管理。建议目录结构如下：

skild_s1_eval/ ├── models/ # 模型权重和配置文件 ├── data/ # 原始评测视频 ├── outputs/ # 模型输出动作序列 ├── logs/ # 运行日志和 gpu 统计 └── scripts/ # 调用脚本和批量任务脚本

第四，批量任务一定要加日志和失败重试。每条视频的处理状态、开始时间、结束时间、错误信息都要记录下来。不要只记录 success，失败样本是最重要的调参依据。

第五，接口服务要限制访问范围。如果模型部署在公网服务器，必须设置鉴权、IP 白名单和调用频控，防止被刷。本地测试时绑定127.0.0.1而不是0.0.0.0，避免暴露到外部网络。

第六，涉及真实机器人实验时，必须先在仿真环境里跑完整流程。仿真能覆盖大部分逻辑问题，但不能完全替代真机验证。真机实验要安排双人互检：一个人负责发指令，一个人负责按住急停，机器人动作路径上不要站人。

第七，视频数据授权问题要在采集阶段就解决。无论是人的操作视频、机械臂录屏还是第三方视频，都要确认授权和版权状态。涉及人脸信息时，按隐私保护要求做匿名化处理。

第八，发布或商用之前要做效果复核。S1 或任何 VLA 模型输出的轨迹，都不能直接拿来当最终控制结果。要加一层安全校验，比如关节限位检查、碰撞检测、任务完成度判断，不符合条件就拒绝执行。

机器人基础模型还在快速发展期，不要迷信单个模型的单次成功表现。建议以可重复的评测集为准，用“平均成功率”和“失败模式分布”来评价模型，而不是只看几条炫酷的演示视频。

10. 总结与下一步

Skild S1 最值得尝试的一点，是“视频即提示词”这条技术路线带来的评估方式变化。你不必手写 prompt，不必标注复杂的状态，只需要一段演示视频，就能把任务意图传给模型。这种交互对机器人开发者非常友好，也让跨任务泛化测试变得更直观。

拿到模型后，建议最先验证的不是复杂操作，而是一个最简单的抓取任务。跑通这一步，再逐步加任务复杂度。最容易踩的坑集中在三块：视频格式和编码不符合要求、机器人型号和动作空间配置错误、训练时统一把视频帧率设置太高导致显存不足。这三类问题占掉八成以上调试时间。

后续可以继续扩展的方向包括：把 S1 接入仿真环境做大规模数据飞轮；用 S1 输出的动作序列做数据增强，训练更小的端侧策略；对比 S1 与其他 VLA 模型在同一任务集上的表现；如果你有机械臂硬件平台，还可以评估模型输出轨迹在真实控制器上的可执行性。

如果进一步复现模型效果，建议从官方文档入手，确认 API 形态、机器人支持列表和输入视频规范，再决定要不要本地部署。前期先用云 API 验证任务成功率，比一上来就搭环境高效得多。

机器人基础模型下一步就是最大化利用视频本身的信息。而 Skild S1 把视频直接放到了提示词的位置，这会让后续更多开发者在“视频数据”上做文章。对于关注具身智能的团队来说，尽早把手放到这类模型上，建立自己的评测集，会是一件越早做越有回报的事。