申明：
利益相关，是阿里云“云渲染”的实际开发者（至2013年底）。

正文：
其实，Pixar公司有一个可以比照的对象，他们基于亚马逊的云平台技术，提出了renderman on demand在线服务（可google到），即将PRrenderman这样的渲染器搬到了云端。

我稀里糊涂的参与了整个渲染云的开发过程，算是这个项目的"始作俑者"。楼上的有些内容讲的中肯，部分猜测也是正确的，确实与我们的体会经验相一致。对于我来说，渲染云是十多年前读研究生时的一个梦想，当时希望用最强力的集群来完成超大规模的图形计算。从目前来看，是初步实现了我当时的设想，当然还是有很远的路要走。不过开发过程中的艰辛也有我们自己知道，各种的试错和弯路。

值得骄傲的是，我们向人们展示了不光是我们有专业的图形学知识，来自实验室的顶尖研究技能，而且能将这样一个实际商业系统的实现和运维扛下来，不管有多丑陋。我的理解，工程就是在特定条件下，特定的资源约束下去完成达到目标。然后需要反复迭代改良。渲染云的主要意义在于这是第一次，我们将图形集群计算、海量存储服务以及计量计费集于一身，构建基于云的完整统一的SaaS互联网应用。在这里要感谢各类大小用户的支持，对我们的包容，给我们提出了各种建议，与我们的系统一起成长。

在阿里云的渲染系统，与一般纯粹的集群渲染不一样。首先，它采用的是真正的云计算技术，即基于map－reduce进行任务调度（当然这里我们已做了很多优化和调整），基于与之一体的云存储系统来存储海量的场景和渲染数据，基于互联网的形式提供自助服务，可分布式地将计算任务部署到全国各大计算节点。第二，它不是单纯的渲染计算，我们的计算任务能与其他大型计算任务分享集群资源，例如部分渲染计算节点实际上也在跑阿里金融的业务，所以可以有更低的运营成本。第三，我们实际在系统中预设了很多数据和内容管理的选项，便于用户数据的隔离与保护，远要好于一般渲染农场。所以楼上谈到用户数据的问题完全可以不用担心，毕竟服务提供方与用户是有内容保护协议的，私自泄露内容可通过法律手段解决。而且服务提供方也不会去干这种“杀鸡去卵”的事。

另外，我要反驳下楼上的观点。从我们已有的各种大规模云计算实践来看，集群规模的扩展性远比单个节点的效率更重要。这不是几台至几十台机器时候，注重效能度量的概念，小规模的计算是会更加关注单机或者核的效能，这会走入误区。到一定规模后，主要考虑的问题是对资源的全局管理和控制，有时“节约”就是另一种形式的浪费。

后记：
阿里云已经与各方合作，推出了新一代云渲染服务，目前国内诸多厂家已经能顺利调用我们当初设计的后台协议投入实际生产，国内新一代的动画电影很多已经开始使用这个服务，具体的名单在合适的时间公布给大家。而且该技术已经进一步演化为通用的阿里云批量计算服务，欢迎大家关注。

我们自身的技术已经演化为一个单独的平台 http://www.50bus.com ， 也欢迎关注。

这件事，只能说是个人或者一小撮人的一个执念，希望它的未来能够路越走越宽。

小花絮：

其实在做阿里云的云渲染系统之前，我们已经在小规模的平台上做过大量的实验，最近注意到1篇我们2009年写的关于云渲染的架构论文，目前被很多人关注，颇为意外。有兴趣的可以看这里： 《A Distributed Render Farm System for Animation Production》 https://www.researchgate.net/publication/262404570_A_Distributed_Render_Farm_System_for_Animation_Production?_sg=o3Lb9aWBqBtOEpscy9pIDgFnOHR_xhGPXgM9XokxIflmdNDvohtmUfTlNVF2dRru4VCTXetdckAAS539AWL0O1j2qgsn32Gf-eIe49OJ.TJGsW9mj3XWsjPGX7yNy7RjHPDWOX_fkv-LgvKyKmk4SoG51F72xxxojDgdJDVoXJZEqwitGBS51rdnrv5JaPw