RedHive 文档与技术资料库

一句话理解

RedHive 把用户的渲染任务、节点设备、文件传输、安全工作区和费用结算连接在一起。任务提交者上传工程并查看结果，节点用户贡献空闲 GPU，平台负责调度、传输、状态追踪和异常处理。

它不是单纯的网盘，也不是传统远程桌面。RedHive 更接近一个面向渲染场景的高吞吐任务网络：每个任务被描述、拆分、分配、执行、回传，并留下可追踪的状态记录。

• 任务提交者：提交工程、确认渲染设置、查看进度和下载结果。
• 算力节点：安装客户端、完成环境检测、空闲时接收渲染任务。
• 平台：做任务画像、节点匹配、文件分发、安全隔离、费用结算和问题追踪。

适合谁看

如果你只是想提交任务，先看“提交一个渲染任务”和“任务状态怎么理解”。如果你想贡献机器，先看“成为算力节点”。如果你是合作方、技术负责人或希望评估平台能力，可以继续看架构树、调度数据、传输系统、安全工作区和参考文献。

提交前检查

渲染任务失败最常见的原因不是算力不够，而是工程缺贴图、插件版本不一致、帧范围写错，或者输出路径设置不清楚。提交前做一次简单检查，可以减少返工。

• 确认工程能在本机正常打开，并至少试渲一帧。
• 把贴图、缓存、代理文件和外部素材放进工程目录或统一打包。
• 写清楚 Cinema 4D、Redshift、Octane、插件和渲染器版本。
• 确认帧范围、分辨率、输出格式、多通道设置和结果命名规则。
• 如果项目涉密，先选择更高安全等级，必要时联系官方支持。

提交后会发生什么

任务提交后，RedHive 会读取工程信息，评估任务需要的 GPU、显存、软件环境、传输体积和安全要求，然后匹配在线、稳定、环境合适的节点。

适合接入的机器

节点不一定是机房服务器。工作室里的桌面工作站、闲置 GPU 主机、夜间空闲的渲染机，都可以在符合要求时作为 RedHive 节点。

• GPU 和显存满足常见渲染任务，驱动稳定。
• 安装了常用渲染软件和插件。
• 网络稳定，上传和下载速度不能过低。
• 磁盘空间足够保存临时工程包、缓存和结果。
• 机器能在较长时间内保持在线，不频繁休眠或断网。

节点为什么有时接不到任务

节点接单不是手动抢单，而是平台根据任务要求自动匹配。即使机器在线，如果软件版本、插件、显存、网络或安全等级不匹配，也可能暂时没有任务。

• 任务需要特定软件或插件，而节点环境不匹配。
• 当前节点网络质量不适合大体积任务。
• 节点历史失败率较高，需要先稳定运行。
• 任务安全等级较高，只分配给符合隔离要求的节点。

从用户到结果的主链路

RedHive 可以拆成五层：入口层负责让用户提交任务和管理节点，控制层负责账号、任务和调度，传输层负责工程包和结果流转，执行层负责节点渲染，安全层负责文件暴露面和工作区生命周期。

为什么要这样分层

渲染任务不是一次普通上传下载。它同时包含大文件传输、长时间执行、异构硬件、失败重试、费用计算和文件安全。分层后，每一层都能单独定位问题：是工程文件问题、节点环境问题、调度问题、传输问题，还是安全准入问题。

问题定义

CG 渲染任务具有计算密集、文件体积大、软件环境复杂、失败成本高和商业素材敏感等特征。传统单机渲染受限于本地 GPU 数量，传统云渲染又常常让小团队面对较高接入成本、环境适配成本和排队不确定性。

RedHive 的技术目标是把大量分散工作站变成可调度的渲染网络，同时通过任务画像、节点画像、传输稳定性和安全工作区降低分布式执行的不确定性。

核心假设

平台不假设所有节点都可靠，也不假设所有网络都能直连。系统默认面对异构设备、不稳定在线、复杂 NAT、插件版本差异和商业文件保护需求。因此 RedHive 的设计优先级是完成率、可追踪性和安全边界，其次才是极限性能。

• 任务必须有画像，否则无法判断节点是否能渲染。
• 节点必须有画像，否则无法区分可用、慢、不稳定和不匹配。
• 传输必须可修复，否则大工程包会放大单次网络失败。
• 安全必须 fail closed，否则异常路径会扩大文件暴露面。
• 费用和收益必须可追踪，否则平台无法长期运营。

可验证指标

任务画像包含什么

任务画像是系统理解工程的方式。它尽量从工程文件、插件和客户端自动读取，减少用户手填。用户只需要补充业务语义，例如期望完成时间、隐私等级和特殊说明。

节点画像包含什么

节点画像用于判断一台机器能不能接某个任务，以及接了之后是否可能稳定完成。它不是一次性静态表，而是会随着在线状态、成功率、网络质量和真实渲染结果持续更新。

调度的简单公式

真实系统会比公式复杂，但可以用下面的表达理解：先过滤不能接任务的节点，再在可用节点里比较预计完成时间、失败风险、传输成本、收益合理性和安全等级。

可接任务节点 = 节点硬件达标 + 软件环境匹配 + 在线稳定 + 安全等级满足
综合评分 = 完成概率 × 速度收益 - 传输风险 - 失败惩罚 - 成本偏差
最终分配 = 在满足硬门槛的节点中，选择综合评分更高的一组节点

为什么不能只追求直连

很多用户设备位于家庭宽带、公司内网或复杂 NAT 后面。直接连接成功时速度可能很好，但不能把任务完成建立在直连一定成功的假设上。RedHive 的策略是先保证稳定链路可用，再逐步利用直连优化速度和成本。

• 工程包分发失败会直接导致任务无法开始。
• 结果回传失败会让已完成渲染变成不可交付。
• 同一任务可能跨多个节点，任何一个节点异常都需要可追踪和可修复。
• 直连优化必须服从完成率，不能因为追求直连比例牺牲交付。

传输链路树

和行业标准的关系

RedHive 的产品目标不是做通用音视频通信，但 NAT、STUN、TURN、ICE 这些标准解释了为什么公网设备之间的连接需要探测、候选地址和中继。RedHive 会吸收这些思想，但在渲染任务里会把完成率和文件完整性放在第一位。

安全边界怎么理解

分布式渲染必须在节点机器上执行工程文件，因此安全设计的重点是减少暴露面、限制权限、缩短明文生命周期、记录异常，并在关键条件缺失时拒绝启动。

• 工程包传输和落盘尽量使用加密包形式。
• 明文只在受控临时工作区短暂存在。
• 客户端界面只展示状态，不直接接触任务密钥。
• 缺少密钥、工作账号、软件环境或权限时，任务不应启动。
• 任务结束后清理 workspace、缓存、输出和临时授权。

安全工作区流程

不应该承诺什么

安全文档要诚实。没有内核级隔离的方案，不应承诺可以防御已经控制本机管理员权限、调试器、内存转储或内核级攻击的对手。RedHive 更合理的承诺是：通过加密、权限隔离、生命周期控制和异常追踪降低风险。

费用为什么需要数据化

渲染任务的费用和帧数、渲染时长、节点性能、传输体积、会员策略、安全等级和失败重试有关。为了让用户信任平台，费用和收益都应该有可追踪的数据。

公开讨论和隐私边界

费用问题可以在论坛讨论规则、体验和异常现象，但不要公开完整支付账号、身份证号、银行卡号、合同内容或客户素材。涉及资金明细时，优先通过官方支持处理。

分布式算力与高吞吐调度

RedHive 的任务模型和传统科学计算不完全一样，但“利用分散机器”“让空闲设备工作”“在异构环境中追求吞吐”这些问题是相通的。

网络连接与中继标准

RedHive 不把音视频实时通信当作目标，但大量节点位于 NAT 之后。理解 STUN、TURN、ICE 有助于解释为什么需要候选地址、连通性检查和中继兜底。

先收集这些信息

问题越具体，越容易定位。建议在论坛或联系支持时一次性提供关键上下文，减少来回确认。

• 任务编号或帖子链接。
• 使用的软件版本、渲染器和插件。
• 错误提示截图或日志片段。
• 任务停在哪个状态：排队、调度、渲染、回传，还是完成后结果异常。
• 网络环境是否变化，上传或下载速度是否明显波动。

常见原因

什么时候去论坛

论坛适合公开讨论节点接入、渲染任务、传输稳定性、计费结算和功能建议。公开讨论能让其他用户也看到解决方案。

• 节点接任务失败。
• 提交任务前不确定需要准备什么。
• 传输速度波动或结果回传失败。
• 希望反馈产品功能或页面体验。

什么时候联系官方

涉及账号、资金、隐私、商务合作或保密项目时，不建议公开发帖。可以通过官网联系方式联系 RedHive。

• 邮箱：support@redhive.com.cn。
• 公司：青岛米萨莫影视科技有限公司。
• 服务地址：山东省青岛市城阳区仙山西路666号。