这次我们来看 Skild S1。它不是普通的视觉分类模型也不是对话大模型而是面向机器人操作任务的具身智能基础模型。它最核心的设计点用一句话就能说清视频即提示词。传统机器人控制模型要写文本指令、要标状态、要画 rewardSkild S1 换了一条路径——直接把一段视频作为输入让模型从中理解任务目标、操作约束和执行顺序最后输出机器人可执行的动作序列。从公开资料看Skild S1 的重点在“通用性”和“泛化能力”。它试图让一个模型应对多种机械臂、多个操作场景而不是每个任务单独训一个模型。这意味着开发者可以把一段真实演示视频丢给模型模型自己提取“该做什么、怎么做”这比手写 prompt、手拆任务状态要直观得多。对于机器人算法工程师、具身智能研究方向的学生以及正在评估 VLA 模型落地的团队来说S1 是一个值得关注和测试的模型。这篇文章会围绕“视频即提示词”这条主线展开。第一部分先给出 S1 的核心能力速览说明这个模型适合谁、不适合谁。然后梳理使用边界和合规要求再给出环境准备、部署方式、功能测试、接口调用、批量任务、性能观察和排错清单。整体目标是帮你在不踩大量坑的前提下完成 S1 模型的接入评估和验证。1. 核心能力速览能力项说明项目类型机器人基础模型 / 具身智能 VLA 模型核心输入视频/多帧图像序列即“视频作为提示词”核心输出机器人动作指令、轨迹序列或动作分布典型模型构思从演示视频中提取任务语义映射到机器人动作空间突出特点泛化到多种机器人形态、多种任务强调通用性硬件门槛需要 GPU 服务器或云端算力具体规格以官方要求为准显存占用未公开统一数值需按实际模型版本和推理长度测试支持平台以 Linux 服务端为主具体支持范围以官方文档为准启动方式官方托管 API / 本地推理脚本取决于开放程度是否支持 API需要看官方开放策略接入评估时优先询问 API 形态是否支持批量任务可以设计批量视频输入流程但需考虑推理耗时和限流适合场景机器人操作算法评估、同类 VLA 模型对比、仿真任务验证从这张表能看出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然后调用接口。典型的调用流程是准备一段演示视频将视频发送到官方接口附带任务描述参数如机器人类型、动作空间接口返回动作序列或策略代码将动作序列在仿真环境或真机中执行。假设官方接口路径是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, headersheaders, paramsparams, datavideo_data, timeout120 ) 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.jsonlDocker 的好处是依赖隔离干净不会污染宿主机 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.mp45.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 失败定位功能测试失败时按下面的顺序排查视频是否包含足够的任务信息视频编码是否是模型支持的格式机器人型号和动作空间参数是否填写正确推理长度是否被最大步数限制截断是否缺少后处理步骤比如动作平滑、碰撞检测。这一节是整个评估中最花时间的地方。不要怕失败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, headersheaders, paramsparams, filesfiles, timeout300) 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_okTrue) 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, headersHEADERS, paramsparams, filesfiles, timeout300 ) 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, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(fprocessed: {video_path}) time.sleep(0.5) except Exception as exc: failed.append({video: str(video_path), error: str(exc)}) print(ffailed: {video_path} - {exc}) with open(OUTPUT_DIR / failed.json, w, encodingutf-8) as f: json.dump(failed, f, ensure_asciiFalse, indent2)批量任务必须考虑失败重试。原因是视频上传、网络波动、接口限流都会导致偶发失败。比较稳的设计是设置最大重试次数比如 3 次并对接口返回 429 限流时做指数退避。批量脚本里最好记录总耗时、平均单视频耗时、失败率这几个指标方便和后续模型版本做对比。Batch 命令可以从命令行传入输入目录和输出目录把逻辑做干净python batch_inference.py \ --input_dir data \ --output_dir outputs \ --api_url http://127.0.0.1:8000/predict \ --max_retries 37. 资源占用与性能观察机器人基础模型是计算密集型任务资源占用与性能观察不能只看模型参数量还要看视频预处理、动作解码、后处理三个环节。下面给出一个可操作的观察方法不依赖官方宣传数据。7.1 观察工具在推理过程中用nvidia-smi每 1 秒采样一次 GPU 状态nvidia-smi --query-gpuutilization.gpu,utilization.memory,memory.used,memory.total --formatcsv -l 1如果是在服务器后台运行建议把日志写进文件nvidia-smi --query-gputimestamp,utilization.gpu,memory.used --formatcsv -l 2 gpu_stats.log 21这个日志能帮你看到显存占用峰值出现在哪个阶段是在视频编码阶段还是在模型前向推理阶段。两次采样之间如果出现明显波动说明任务的前处理或后处理阶段也在占用大量资源。7.2 关键性能指标建议记录四个指标单视频端到端延迟从提交视频到拿到完整动作序列的时间平均显存占用推理过程中显存使用的中位数峰值显存占用推理过程中显存使用的最大值吞吐率单位时间内能处理多少条视频。对这些指标不要只看一次结果要用多组视频长度做对比。比如固定机器人型号和动作步数分别测 5 秒、10 秒、20 秒视频的延迟和显存变化。通常视频越长显存占用和延迟都会上升具体趋势要实测后才能得到。7.3 资源占用优化思路如果显存不足优先降低输入视频分辨率其次减少输入帧率从 30fps 降到 10fps对很多任务语义影响不大但显存占用会明显下降再次缩短推理最大步数把max_steps调小最后才考虑换更小版本的模型或使用 batch size 为 1。如果计算资源非常有限建议直接更换策略用官方 API 做效果验证本地只做动作后处理和仿真回放。这样可以把本地 GPU 需求降到最低。这里要再强调一次具体显存数字取决于模型版本、输入视频长度、动作空间维度、精度设置本文没有杜撰一个“实测 7G 显存”之类的结论。一定要以你自己环境跑出来的nvidia-smi数据为准。8. 常见问题与排查方法接入 VLA 类模型最浪费时间的问题往往不是模型本身有多难理解而是环境、数据格式、网络和路径细节。这里整理一个常见问题排查表遇到问题可以直接对着查。问题现象可能原因排查方式解决方案接口返回 401API Key 错误或已过期检查请求头中的鉴权字段重新申请或确认 Key 正确上传视频后返回 413视频文件超出接口大小限制查看官方文档的请求体限制压缩视频、降低分辨率或抽帧模型返回空动作序列视频无法解析任务意图查看原始视频是否包含操作过程换一段更清晰的演示视频动作序列与机器人型号不匹配机械臂关节数或动作空间设置错误对比输出动作维度和机器人自由度检查接口参数并重新调用推理时显存不足视频过长或模型输入分辨率过高用nvidia-smi -l 1观察显存降低帧率、分辨率或调小 max_steps启动时提示模型文件缺失权重文件没有放到指定路径检查模型目录和配置文件下载完整模型并配置路径Docker 容器无法调用 GPU容器缺少 NVIDIA runtime运行docker run --gpus all测试安装 NVIDIA Container Toolkit批量任务跑到一半卡住单个请求超时或接口限流查看 failed.json 和网络日志增加超时时间写指数退避重试仿真执行时机械臂乱动动作坐标类型理解错误检查返回的是绝对角度还是增量角度转换动作形式后再执行输出轨迹抖动严重输出频率和仿真控制频率不一致查看输出时间戳和步数使用低通滤波或重置控制频率依赖安装失败也是常见问题。比如 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 把视频直接放到了提示词的位置这会让后续更多开发者在“视频数据”上做文章。对于关注具身智能的团队来说尽早把手放到这类模型上建立自己的评测集会是一件越早做越有回报的事。