Photo by cottonbro from Pexels
本次演讲讨论基于现实中数据中心所有到一般性问题，尤其是数据处理的困境。而联捷计算科技(CTAccel)针对基于FPGA的异构计算的特点，与赛灵思配合提出发挥FPGA特长的多媒体解决方案，并以应用接口的方式提供给用户。
文 / 俞海乐
整理 / LiveVideoStack
1. 简介
大家好，我是CTAccel Limited创始人兼CEO俞海乐，首先是非常感谢受赛灵思邀请来参加LiveVideoStackCon音视频技术大会，我们的公司叫做联捷计算科技，目前在深圳主要是做图片和视频的加速计算，尤其是针对云端的加速计算。
联捷计算科技公司成立于2016年，但是我们做这个事情源起于2013年，那个时候中国还没有多少人用FPGA加速。当时中国最早做FPGA加速的是百度，后来腾讯也开始做FPGA加速。那个时候我们就跟他们做了一个POC，把图片加速里面的一个function加速了40倍，然后去做黑盒测试/ABtest，发现比较明显的性能提升。我们就沿着这个项目做下来，后来就有了今天的这个公司。我们团队的成长伴随着中国FPGA异构产业的发展，到目前为止共有35人，且都在深圳，成员主要来自于港科大、香港中文大学、复旦、中科院，目前专注于做图片和视频的加速解决方案。
1.1 做FPGA加速的原因
数据的爆炸和算例的停滞增长带来的供需不平衡，是这个大环境下我们要做加速的原因。
2. 加速解决方案
联捷计算科技做TCO Reduction、Enhanced Throughput和Latency Reduction。前两个大家可以认为是一回事，TCO的降低来自于单节点计算密度提升，当我们提到单节点密度提升，通常对应的是TCO。另外一个商业化的途径就是Latency Reduction。举个例子，比如说我做前面的加速，以前运矿车是5吨重，一小时可以往返一次。现在我发明了500吨重的载重卡车，也是一小时可以载500吨，这样吞吐就提升了。但是人家还有一部分Latency的要求，运1千克的货，要求1分钟就跑回来，这个就是坐法拉利，两种不同的变现模式，做过加速计算的人都懂。上述应用的场景主要是互联网，针对云存储、社交、电商、短视频等。
大家听到这些，其实主要由UGC产生的。当我们2013年做加速的POC的时候，尤其是图像的编解码和缩放，我自己都觉得没什么意思，因为我平时自己也拍一些照片，玩摄影。我也在我自己电脑上存了几千上万张照片，经常做转码和缩放，但是没有任何被加速的需求。但是后来才知道，原来是一个workload，哪怕是几百毫秒，几十毫秒，也架不住请求多。举个例子，一个单机500个QPS，如果不经过FPGA加速已经不算低了，但是一百万个QPS的时候就需要2000台服务器，这已经是非常大的体量了。刚才阿里的同学说他们才用几千块FPGA就已经是中国最大的workload了。所以说关键是架不住并发度，而并发度的出现，其实就是受移动互联网的红利。
拍照片拍视频比以往任何时候都便捷，因为有4G的网络，分享也更加快捷。所以我们会看到供需的GAP进一步加大，这些都来自于三点。第一点是5G时代新的杀手应用还没有产生；第二点是新的交互，尤其视觉交互分辨率是越来越大，因为今天局限在1080p和2k这个层面是受手机屏幕的限制——只有5到6度的视场，但是在沉浸式的设备里呢，通常有至少60度以上，这对分辨率的需求也将越来越大；还有就是编解码的计算复杂度，视频和图片每一代都比上一代有更大的计算复杂度，计算复杂度的增长远远大过单节点算例的增长。
2.1 System Stack
System Stack比较偏技术一些。我们的客户也是解耦在应用的加速接口这一层，应用软件包括常见的图片和视频的处理框架软件。下面是Service & Driver ，再下面是加速引擎——AFU(AcceleratorFunction Unit)，这里通常是我们实现在FPGA里的东西。无论是图片还是视频，基本上transcoding都避不开三个step，Decode 、像素级的处理，以及一些Encode。
3. 图像加速解决方案
联捷计算科技目前的产品矩阵包含了最主流的两种：JPEG和WebP。我们目前也支持苹果刚发布的HEIF。听说安卓手机在明年也会支持默认的HEIF存储格式。现在拍一张4兆的照片，默认就是2兆，但是会给互联网网站带来压力。因为以前只Decode JPEG，现在要Decode HELF，那么HELF由于单文件size更小，在固定带宽的情况下，上传到单个server数量更多。server计算密度的要求比之前JPEG解码大很多。最后是一个Lepton比较邪门的格式，是Dropbox发明的，主要用于JPEG的无损压缩。目前来说主要是Dropbox在用，其他的云存储厂家对这个方案也有一些兴趣，都处在评估阶段。
3.1 JPEG缩略图客户基于CPU的现有解决方案
这是非常古老的workload，有互联网那天起就有这种workload。最开始主要用ImageMagick，但是因为计算视觉的workload越来越多。客户慢慢转向OpenCV。这其中有个小故事，互联网的早期——Facebook网站上线几年之内，都没有允许用户上传图片，这在今天很难想象，Facebook一开始不允许上传图片，后来只能上传头像，结果Facebook一开feature(图片上传)，服务器就挂，因为做不了转码。
今天像Facebook这种主流一线厂家，已经成为异构计算新的定义者。大家关注新闻的话，现在Facebook定义了3款加速芯片，分别针对视频、AI推理和AI训练。所以我们可以看到Facebook是互联网移动社交的霸主，掌握全世界超过一半的workload，那么它走向异构，就说明确实CPO做不过来。
3.2 挑战：缩短图像加载时间
在GitHub社区，牵扯到Thumbnailgeneration，不时的看到用户抱怨loading的速度太慢，这也是我们做加速的原因之一。
3.3 JPEG 缩略图性能基准
整体而言，我们给客户实现的是上图所示的workload，大概是5倍的吞吐、12%的延时、CPU利用率从100%降低到29%。不同的厂家关于这种阐述有不一样的理解，主要是看怎么去理解整个系统。当落地方案的时候，我们发现有一个问题就是一个新技术进入传统业务场景的时候，一个单点性能的急速提升，比如说提升十倍甚至几十倍，带来的是很快在其他节点产生新的系统痛点和系统瓶颈。真正讲商业落地，你会发现客户需求的单节点计算密度和TCO节省并没有账面数字上写得那么高。比如现在花100块钱办的事，用了你的产品花10块钱就解决了，一般来说有一个相对比较合理的降比已经足够了。他想要的是什么呢？2B(To-Business)的方案，尤其是数据中心这种加速计算，这其中有一个公式是客户的净收益减去迁移成本才是最终的净收益。比如说，这个热水器特别好，但是我得把你家拆了，把你厨房卫生间打得稀烂，你还得重新装修，计算下来省的东西还不如我多花的部分，你可能就不这么选择了。但是如果我能一尘不染的就能把更好的引擎集成进去，对客户来说才是真正有落地价值的东西。
3.4 在图像搜索时将webp作为缩略图
WebP是反复提到由谷歌推出的一种格式，主要应用在安卓和Chrome浏览器生态。
3.5 jpeg2 webp性能基准
Benchmark我们一般控制在3倍左右，因为同行内有个说法，单做吞吐不是一个很好的生意。想想看，你给他100台机器减成10台，且不说网络和存储允不允许你做到这么高，即便真正能做到的话，怎么收费？互联网大厂也不是不知道卡的价格，你一下收巨额的方案费，基本上是不太可行的。所以真实落地的时候能有3倍就非常好了，你也得一点收益，客户这个集群还不能缩太少，互联网布服务器肯定是按着冗余布的。
我举个例子，如果真的10台机器减成1台了，还有没有冗余，灾备会有很大问题的。举个非常具体的例子：如果他有50台机器掉了1台，性能损失1/50，根据运维标准，也许今晚还能睡个觉，不用连夜去处理故障。可是减到5台机器掉1台，性能降低20%，这就是另一个级别的运维失误了，今晚就得连夜工作。虽然加速计算有一些就技术论技术的Benchmark，但是真正进到商业里会有一些非技术的制约，这都会造成一些落地上的特别考虑。
3.6 Appleannounced to use HEIF
HELF是IOS12之后苹果才推出来的，苹果是很主流的一个移动平台，这个格式一出来，数据中心各个大的app马上就涌现出很多HELF流量进来，所以才会发现它的处理比JPEG消耗更多的计算这个痛点，我们也发现很多app一开始就没有兼容性。比如钉钉也是阿里旗下的，我们同事用苹果手机上传照片在安卓端看不了，只显示个HEIF，那就说明app没有做到转码。我相信如果我们和阿里合作很快他们就有这个方案了。
3.7 JPEG到HEIF转码性能基准
JPEG到HEIF转码性能基准有48倍的吞吐提升，大概延时能降低到软件处理的6%。客户已经在反映说吞吐太大，太大就埋不了几片，有时候要控制，其实卡能放几个是方案上定的。现在内部宁可做高延时也不要做大吞吐。因为反正干掉CPU是很容易的一件事情，哪一个加速方案上，不比CPU秒杀几倍几十倍，这已经不是新闻了，关键是延时需要再做。延时是什么呢？我有一个workload。比如说手机卡顿不想用了，而且一旦用过不卡的就回不去了。所以在2B端也有类似的现象，客户对延时的要求有点类似于，你用过卡的电脑和手机，之后你真的不想用它，那都不是省钱不省钱的问题，是能用不能用的问题。我觉得未来几年，尤其是5G本身就强调低延时。延时是CPU怎么都解决不了的问题，吞吐撑死就是有钱、堆服务器，堆一万台服务器，每一个workload该是多少毫秒还是多少毫秒。这是计算代差的问题，与电器和蒸汽时代的差别一样，不是说靠吞吐堆的。在2013年到2016年间，客户都讲TCU，因为那个时候每个workload，CPU的延时都在可用范围以内，就算性价比，性价比比不过就不用了。今天不一样了，现在有相当一个比例的workload是CPU的延时，这是不可被接受的，因此也没办法说价钱问题。什么是算力的游戏？2个算力的Latency是一样的基础上再比较吞吐和计算密度，如果Latency都不一样，就不能比较密度，因为没有可比性。
3.8 无损压缩
Lepton就是无损压缩，把存储无损下压。这个是比较重要的问题，因为云存储不能篡改用户的数据，就是你什么样子传给我，取回的时候比特是一致的，无损也是我们的产品之一。
3.9 JPEGto Lepton 转码性能基准
JPEG至Lepton都加之后，JPEG转成压缩格式和压缩格式返回有3倍的性能，有时候讲几倍也看卡的数量。就像重型火箭，当时设计有两个方案，第一个是单个的大推力引擎，研发成本非常高；第二个是用捆绑式的，几个小引擎给它捆绑起来，所以在做工程型的东西的时候，很少有极致的偏执狂和强迫症的技术追求，通常是因为成本所导致。当我们选择加速器芯片的时候，是根据workload选取应该使用什么最合适的加速器芯片，XLILNX显然是最合适的。
4. 视频加速解决方案
视频有一部分也是用MPSoC。我觉得7EV芯片代表未来，因为以前异构是主处理器和协处理器作为PC连接的，MPSoC是多核处理器 Soc，可以从XILINX的ACAP上看出趋势，更多的host和加速器连接更紧密而去，而且芯片里有一个VCU，是一个硬核编解码器，它的编码效率非常高，还有可编程逻辑资源，相当于中小规模的FPGA，还有ARM的core，里面有实时操作系统的core，相对比较全面的。打个比方，如果这个东西再加个TPU就是ACAP了。当然这个说法也不严谨，因为ACAP采用了很多新的互联技术。
我们也有264Encoder的基于U200软核方案，因为云平台目前没有一个上MPSoC计算实力，基本上都是基于纯FPGA的，U200又比较多是渠道导向的研发。很多客户确实需要Video的Workload，但是几个云平台都是U200为主，我们开发了基于U200的编码方案，我们设想的客户他很有可能将来异构计算也分成稳态异构和动态异构。什么叫稳态异构和动态异构，互联网公司都有波峰波谷，相对有一个业务存量，保底的用量是多少，这块是用MPSoC，甚至是ASCII，问题不大。FPGA最适合是弹出来那部分，我可能一天就用几个小时，就高峰时间段用，用完了就退资源。云平台除了AI，很少上ASCII计算加速器就是因为不灵活，我们很多用户一配，华北阿里好几个可用期，万一可用期里没有呢？就是售罄或者是资源调配不过来，ASCII很难几个小时内调配，我们认为存量资源有可能用ASCII，但是弹出来的资源还得用可编程资源，FPGA就像CPU一样是最符合资源池概念和完全可编程资源池概念的计算资源，这就是FPGA能经久不息的原因， 那为什么CPU还有这么大市场？CPU的极致性能是最弱的，但是可承用性、可编程性是最好的。所以可以给下一代异构计算一个启发，我认为将来CPU会成为功能产生平台。
今天大家编程不可能摆脱CPU，好的想法和好的算法肯定是在CPU上先做原型，也可能是早期原型部署平台，早期小批量，之后再大一点，可能FPGA或者ASCII接棒，继续往下走，最后才可能会实现动态平衡。
当一个算法诞生到渐渐火起来，觉得CPU不够，到最后真正形成它的硬核架构这样一个动荡。新的好的应用好的算法层出不穷，就一浪一浪的出来，FPGA卡这个阶段是相当合适的。我们公司对FPGA是重仓的，根据经济学原理，到达某一个用量，才能到达盈亏平衡。从之前的加密货币可以看出，只有少数几个币种可以走到商业化可行路径。
Transcoding第一部分是7EV的，差不多是7.8倍。
这个是一转三的，推流1080p入，720、540、360出，比较典型的直播场景，是一个4.4倍的性能密度。
这个是软核的，大概有5.1倍。这是一种设计倾向，对于砍腰部还是铲尾，还是砍头部的问题，这个设计倾向相对有点腰部偏长尾，不是完全对标medium，但是我们做出高度稳定高度接口可调用的方案，总会卡到自己的目标群体去。
这个是一些案例了。比较知名的手机互联网公司的云相册，TCU的节省、High performance、High throughput、Latency讲到底是叫用户体验提升。其实加速计算就是两件事：降成本提体验。降成本就是单节点密度，提体验就是降低Latency。不光是降低Latency，还有就是确定性延时波动非常小，10ms总在9.5和10.5之间波动，总在不会出现非常大的波动，这个是QPS的实质。但是load Latency不是非常的完全的load Latency。在图片上还好，有一张load不出来就不看了。Deterministic timing在金融上是非常非常重要的，因为很多金融方案策略是时延和timing有非常紧密联系的。我的策略就是发现100秒之后下一个单，timing错了，导致整个策略就错了，当然这个也是客户发现的。Deterministictiming在FPGA加速计算的另外一个领域有更大的应用，金融方向。
WebP这是个视频网站，但是用在社交平台，也是处理UGC内容，也同样可以观测到这些benefit。
LiveVideoStackCon 2020
上海/北京/旧金山 讲师招募
2020年LiveVideoStackCon将持续迭代，LiveVideoStackCon将分别在上海（6月13-14日），北京（9月11-12日）和旧金山（11月）举行。欢迎将你的技术实践、踩坑与填坑经历、技术与商业创业的思考分享出来，独乐不如众乐。请将个人资料和话题信息邮件到 speaker@livevideostack.com 或点击【阅读原文】了解成为LiveVideoStackCon讲师的权益与义务，我们会在48小时内回复。
