大家下午好感謝大家十隔四年我們又重新在CoupleCon聚在了一起然後今天我們分享的話題是叫從0到無限我們來看一個基於AI技術的量化投資科技公司如何聰明地去構建自己的CoupleNatives的上的AI平台我們的內容大概分成三部分首先第一部分我們會介紹一下業務背景以及這個業務背景會產生一些什麼樣的技術問題然後在這個技術問題下我們如何用一些KBS原生的技術來解決這些技術的挑戰在這個技術上我們在做一個最佳時間的分享和相應的Demo最終還有一個QA環節的安排首先簡單介紹一下Speaker我叫車樣我來自阿里雲容器服務團隊我同時也是開源社區FluedCNCF的Sandbox項目的發起人和主要的Mountainer另外一個演講者是李志義他來自於前向投資他也是在多家IT科技企業從業的很資深的經驗我和志義一個共同的特點就是我們都致力於在探索如何在Kubernetes平台上去構建一個AI Platform的最佳實踐首先我們請志義先介紹一下前向的業務背景好謝謝車老師的精彩開場現在就由我來為大家介紹一下我們的業務背景我們的故事起源於一個概念叫走量化投資如果現在在場的各位是為了得到一些投資小技巧來到我們這個Talk不好意思 要讓你失望了今天我們的演講內容不會涉及到任何投資建議唯一的建議就是投資需謹慎我好像說到一點Sense of humorPeopleOK好 我繼續在非常謹慎的賽道Metabit Trading也就是前向投資我們花了僅僅五年的時間做到了公開目擊資金達到100億的量級就在業內是非常令人矚目的在高速發展的背後離不開公司對於工程技術的投入和儲備像是在Metabit我們的研究策略是高度依賴於人工智能模型的我們的交易過程也是實現了全面的自動化創新與革新是我們公司不斷追求卓越的推動力也許在座各位對於AI模型是怎麼運用在量化交易這件事情上不是特別熟悉我們這裡有一張簡單的試圖大家可以看到其實我們的流程和普通的互聯網公司上可能沒有特別大的流程上來講從非常非常宏觀的角度來看不會有特別大的區別我們也會做特徵提取模型訓練優化算法推理下單等等但是因為交易的特性我們有一些東西處理是不一樣的比如說我們的數據非常稀疏我們模型邊界定義是非常難的然後我們對模型有更高的獨棒性要求以及我們有非常重要的商業機密那因為這些原因使得在量化交易這個scenario下我們的研究平台需要更多的疊帶我研究本身需要更多的疊帶然後我們的平台需要更豐富的研究工具和更強的平台能力在這個背景下Metabit選擇了以雲淵身為主的以系列技術購家並且我們逐步打造了以Cubanets為標準的各種基礎設施舉個簡單的例子上市這個我們在彈性AI平台為例在購價層大家可以看到我們其實是採用了非常多的雲淵身組件為我們的平台來提供功能和性能的支持可以看到像是在scheduling的層面我們會使用Vocano來為我們提供batching的能力然後在緩存層of course我們使用了Food然後讓它為我們來提供緩存層相應的管理和抽象然後像是在App Delivery上我們選用了Cubanets來統一我們的應用交付標準那得益於KBIOS的能力和生態當然還有我們非常牛逼的Infra團隊的同事然後我們可以構建一個穩定高度彈性的並且功能豐富的平台然後這個購價它只是不是一處而就的整個具體的例子來講我們在存儲上一開始的選擇是使用Juice FS提供的CSI作為我們的數據接口那什麼是Juice FS呢我們可以簡單來參考一下它的技術購價簡單來說Juice FS是一個基於Object Store並且有完整的Project協議支持的PB級別的數據存儲系統Juice FS想做的是一個無線存儲的NAS並且希望提供不錯的延遲性這些能力對於非工程師的研究性用戶而言是非常非常有吸引力的但是緊緊不屬一個Juice FS是不能解決我們所有的問題的讓我們一起來回顧一下我們Metabit的業務屬性量化金融的業務形態是有非常強的彈性特徵的也就是說突發任務對於我們的平台而言是非常非常常見的比較直觀一點我們可以看到這是我們一個集群在一段時間的實力運行數我們可以看到在很多個時間段內我們都會有突發就是集群實力會出現巨幅的伸縮我們會出現有1000倍的Burst然後我們也會有集群規模極限縮減到0的時候就是因為在量化機構裡面計算任務其實和研究員的研發進度有非常大的關聯性就是波風和波谷的差距是會非常大的我們就是KBS讓我們簡單的獲得了我們計算能夠有彈性的能力但是它帶來另外一個問題就是我們的純粗特別是它的帶框後流量它也需要有彈性那更進一步來看這個問題我們需要面對的到底是什麼呢我們需要面對的是我們會有大量的熱數據的讀取然後我們的存儲吞吐本身也需要隨著任務的增長做到水平擴容還有就是因為計算資源會跨區所以我們的數據訪問需要跟計算的存儲相靠近這樣能夠降低我們因為跨區而帶來的延遲的影響再者就是因為我們的任務會有多樣的信用我們需要採用不同的存儲方案來滿足我們的任務需求並且在平台層面對於這些不同的存儲我們需要有類似的管理能力以及對數據的保護能力所以面對上述我們剛剛提出的需求我們可以看到這不僅僅是一個簡單的存儲問題我們其實需要面對的是需要以下一些能力包括是我們需要一個存儲然後這個存儲本身是需要有彈性能力的還有就是我們需要有不同的PVC因為有PVC的實現我們才能來對接不同的存儲的訪問模式最後是我們需要對我們的計算的調度它要能夠感受到數據的位置根據上面的這些結論我們可以總結出來以下兩個觀點就是說我們不僅僅是說計算需要彈性我們的存儲訪問的吞吐也是需要彈性的在這個基礎上我們如果在計算測有分布式的緩存的話那會對存儲本身的吞吐能力是一個重要的補充所以我們通過一系列的調研找到了復原的因為它能夠輕鬆的幫我們應對以上兩個需求那我們可以簡單的來做一個對比我們現在存儲的視角如果是用傳統的CSI的話對於一個簡單的應用它需要不同的接口去訪問不同的存儲但是站在復原的角度它可以通過一個簡單的Data Set的抽象就可以訪問不同類型的存儲並且在計算測復原的會為我們運為和管理相應的緩存那接下來我把時間交給車老師由他來為我們介紹復原的具體功能和基礎購價感謝施毅好在這一頁裡面我給大家簡單介紹一下Fluid的概念以及它的核心能力Fluid的概念其實比較簡單是Fluid負責在Kubernetes中對數據以及使用數據的任務進行編排這個編排分為兩個層次一個是空間上的編排另外一個是時間上的編排所謂空間上的編排的意思是當我去調度一個使用數據的任務的時候我會優先把它調度到有緩存的節點或者是臨近緩存的節點這樣我就可以提升計算去訪問數據的性能這是空間上的編排而時間上的編排的意思是說當一個數據科學家同時提交了數據和任務的時候他要求一些數據的運位操作先執行比如說像數據的遷移數據的預熱當執行完之後才要求真正的把任務進行運行起來而Fluid可以支持用戶完全是無人職守的去參與這個工作提升整個的工程的效率這是兩個層面然後Fluid的核心能力是什麼呢其實是五件事情標準化自動化加速到處運行以及數據編排我們可以看到隨著計算存儲分離的架構越來越被廣泛地使用帶來了一個結果是我們可以看到業內其實有越來越多的緩存層的工作被完成比如說像開源的Election Juice還包括像京斗像EFC這些是雲廠商提供的一些緩存的引擎它有一個問題是什麼呢這些緩存引擎實際上都不是為K8S而建立的如何在K8S中使用它運為它其實成了一個新的挑戰需要暴露新的API所以Fluid在做的一件事情是Fluid把這些分布式緩存的引擎轉換成了一個可管理可調度可編排可自恢復的分布式緩存的系統能力放到了K8S中這是Fluid做的第一件事情在此基礎上我們可以看到這些緩存操作中有一些通用的緩存操作以CRD的方式進行暴露而這些通用的緩存方式其實包括比如說數據的處理數據的預熱數據遷移以及緩存的擴縮容當我們把它以K8SAPI暴露出來之後就非常方便的用戶把它建設到自己的自動化的運為體系中這是第二件事Automation第三件事加速有很多人有一個想法是說我是不是在我的計算機群裡面搭建一個緩存機群我就能得到一個很好的效果呢其實並不是這樣的因為不同的數據訪問它實際上都有不同的特性比如說像大模型像自動下使中的一些訓練數據它的小文件它的特徵其實完全不一樣那幅度的提供的是什麼呢是提供了一個場景化的彈性的分布式的緩存能力提供一個自動化的帶寬同時呢我又有一個新合性調度因為我們知道在雲上通常會在一個地域裡面有多個的恐龍區那如果你的你的計算和存儲根本就不在一個恐龍區的話其實即使有緩存的話效果也不會好第三件事是Run anywhere就是到處運行我們看到Cubanitis的發展到今天有越來越多的K8S形態出現了比如說像上游開源的K8S像一些邊緣場景的Cubanitis還有包括像現在比較流行的這種Slowness的Cubanitis和Nodeless的Cubanitis這些Cubanitis的形態其實是完全不同的他們的特點有的是共享內核基於Run C有的是獨佔內核比如說基於Run V和Run D那麼在這種不同的情況下Fluid會根據你的運行時的差異去選擇CSI和Sidecar的模式去做底層的運行而這個和具體的存儲類型是無關的最後我們再結合了一系列的Data自動化操作之後我們還可以編排這些相關的數據操作和任務調度的一個順序實現一個Data Flow的一個Oxytration簡單介紹一下Fluid的架構Fluid對外暴露了兩個概念一個叫Data Side一個叫Run Time我們後面會具體講一下這兩個概念是什麼為了支撐這兩個概念Fluid提供了控制面和數據面層的支持在控制面上面其實Fluid的支持了像管理數據級的自動化運作操作相關的Data Side的Controller以及管理這些管存引擎的Run Time controller還有管理這些使用這些數據的應用和負載的生命週期和調度的Application Manager他們是屬於控制層面然後在數據面上所有的存儲的客戶端都是以容器化的方式來運行的這樣能帶來好處是它可以被觀測可以被調度可以被控制然後其實整個生命週期相對的管理也是非常容易的然後我們又會根據你的KBS具體的環境比如說像我剛才談到的是Runs這種共享Linux內核的場景那我們就會讓你使用CSI Plane如果你是獨佔內核的這種亂地亂危的場景的話我們實際上就會讓你用SideCard的模式這樣但是這些事情對於存儲對於分布式管存的提供者來說他不用管這件事情他只需要把他的這個分布式管存引擎接入到Fluid裡面按Fluid的規約接進來就可以直接具備這個能力了那我們現在看一下Fluid提供的一些一些主要的能力首先第一件事情是數據級Fluid首先提供了一個數據級的CRD不同於傳統的PVC它其實主要的部分有三部分組成第一部分是數據的來源和傳統的CSI這種的PVC的區別是Fluid提供了一個多數據的來源包括的是可能是S3也可能包括你KBS這種本身的PVC甚至包括HOST PASS這樣我就可以能跟你提你即使是用一些非標的一些實現的話通過Fluid也能提供一個統一的加速的能力這是第一層描述數據來源的多樣性第二層是描述這個管存開始的可遷移性管存開始的可遷移性是什麼意思呢就是我們在訓練的時候通常習慣把數據加載到GPU的節點上來進行訓練這樣有更好的計算和數據之間的親和性但是當我們的計算結束之後我們可能會把GPU收掉收掉之後我的管存可能要重新再拉但這種帶來的成本其實是巨大的所以我們這裡提供了一個親和性的調度就是它可以把GPU遷到CPU就是你當你不用管存的時候可以把一些數據overloading到CPU的節點上這是第二件事第三件事是描述你的數據特徵比如說你的數據如果是一個指讀場景並且你的文件是小文件的話Fluid會把這些信息傳給底層的Runtime底層的Runtime會根據你的這個信息進行自動化的配置因而降低使用者的使用成本同時在下面可能是有點黑大家看不太清楚Fluid還提供了一個數據級的可觀測性我可以看到這個數據級總的數據量有多少能提供的數據管存能力有多少命中率有多少其實我們經常會問我用了數據管存好像性能並沒有提升那可能是不是它沒有命中你的管存你的模式是不是有問題完全可以通過可觀測性來看在此基礎上就是Deadside其實是這個概念真正去實現這個數據加速的能力其實是各種各樣的Runtime在標準的CSI中它其實並沒有能力去描述描述自己的管存引擎的一個部署的拓捕形式是什麼樣子而Fluid通過CRD的方式提供了這樣一個統一的配置你可以在這裡面去定義你的Master Walker你的各個組件的一個拓捕樣式還有它的GPU它的CPU內存的使用率以及相關的調度策略在這個基礎上Fluid提供了一個通用的開發框架降低你去接入的一個成本降低你開發的難度同時又結合不同的一些數據場景提供了一些最佳實踐的最優配置就一些默認的配置你就可以直接開箱集用而不需要做複雜的配置然後最後我們可以發現這其實是兩個完全不同的Runtime一個是Juice Runtime一個是Lexus Runtime你可以發現它們之間的遷移成本其實並不高因為它整個的概念模型是類似的包括它的這個緩存的副本數比如說這都是用Replica的描述然後緩存的分層內存 磁盤 SSD然後緩存路徑包括Cauta的配置這些東西都是通用的也有很多的我們的用戶實際上就拿著Fluid可以來測試不同的緩存引擎執行效果誰更好拿一個統一的Bunch Mark來測試Fluid在此之上又做了Automation所謂的Automation是什麼意思呢是說Fluid提供了一個標準的CRD來執行一些數據和緩存相關的一些操作而這操作支持的是單次型的按時的 定時的還有事件驅動的而這常見的操作比如說像數據預熱數據預熱它是幫助把數據從遠程直接拉到本地的分布式緩存中我們可以看到通過數據預熱它的整個性能能達到五到六倍的提升然後數據的緩存的擴縮容這個其實後面致意會介紹到這個其實是非常重要的一個能力它能夠一方面擴大吞吐一方面能幫降低緩存的成本第三個是數據的遷移可以實現數據從冷存儲到熱存儲之間來回的搬遷也是為了降低成本的一個考量最後呢其實是一些用戶可以把自己的一些數據操作接入到Fluid中包括如果你要做一些數據降維數據的拆分你都可以在data process中進行一些自定義的操作第三件事情就是加速Fluid提供了彈性的分布式緩存來幫助加速就是這裡面有三種模式第一種模式是通過Cube control手動的操作以及API的調用在這種場景下用戶可以結合自己的業務特點來調用數據的緩存和縮容這個是就可以做一些比較自動化的和自己的業務相關聯的操作下一件事情是定時的擴縮容這個就符合一些有潮溪特徵的業務它的業務就可以使用這種定時的分配然後來實現在業務高峰的時候有比較好的併發業務低估的時候有比較好的成本然後也支持的是按照一些特定的特定參數和Matrix來進行彈性擴縮容比如說聚合吞吐比如說像它的緩存的緩存的緩存的一個capacity的上限下一件事情是調度Fluid的支持的是本身緩存引擎的調度和使用緩存引擎的數據使用緩存引擎的應用的調度當使用緩存引擎的調度的時候我們可以配置各種KBS特定的一些調度參數然後我們也默認支持各個的緩存worker之間是一個anti-finity默認的配置這個好處是說它能夠讓大家有充分的自己的帶寬獨佔帶寬達到更好的性能然後當調度在使用這個數據的任務或者應用的時候它會有支持一個分層的清合性調度什麼是分層的清合性調度呢是我首先會優先調度到有緩存的節點做一個本地的清合性但是當很多調度條件不滿足的時候我會退而期休息次調度到一個和它相關在同一個可用區裡面的一個節點甚至還可以做一些配置化在同一個數據中心在同一個機架上的一些清合性調度來提升整個的數據訪問性能這個其實在實測中是非常重要的跨可用區的性能其實它帶寬還有延時其實帶來了很大的性能上的降低在此基礎上Fluid提供這是RUN Anniversary的能力對於用戶來說使用Fluid是很簡單的你創建一個data set當你在使用PVC的時候你只要使用同名的一個PVC就可以了然後Fluid會根據你運行在不同的K8s形態下就是像我剛才說的如果是共享內核就是單足戶的場景下你其實可以完全用CSI Play你有沒有問題但是像一種這些獨佔內核其實就是有多足的場景下大家比較在乎自己的整個的安全性所有的容器都是跑在一個單獨的VM的情況下Sidecar其實是一種你不需要做額外太多的成本配置就可以有比較好的性能收益的方式最後我們講一下DateFlow就是我們前面其實是提供了一系列的自動化的數據操作包括數據預熱包括數據遷移包括整個數據的自定義操作然後我們連點呈現用喬布斯的話Connect DOS就是有許多客戶覺得我有一個很重要的場景需求是我希望把我整個的數據操作的流程變成一個比較簡單的自動化但我又不太希望用一些像阿戈一些比較重的操作Fluid就給他提供了一個通用的能力叫DateFlow的能力DateFlow的能力是可以適用於什麼場景呢就比如說有些情況下絕大多數數據其實都是在比如說對象存儲的冷存儲中做了Archive但是他開始要訓練的時候他需要把這個數據從冷存儲拉到熱存儲相當於做解Archive然後解Archive之後在真正去提交這個訓練的任務讓任務去執行執行完之後執行出來的結果又需要把它搬回到冷存儲之中那麼這整個的過程它其實就完全可以用Fluid來把這整個的流程串起來它都是一個數據集為中心來執行這整個的操作的OK我這一部分的介紹就到這裡了現在有請質疑講一下他們的實踐謝謝徐老師剛剛深度的講解那現在又有我來跟大家介紹一下我們在具體場景裡面使用Fluid的具體例子那希望通過這個例子我們可以更直觀的能夠體會到Fluid在構建幻存的這個效率上和它相應的資源的節省通常我們會有兩個場景會使用到Fluid的第一個場景就像我們這邊講的我們會通過坦先申縮來使用雲上的資源進行一些大規模的理線計算任務我們會從雲開始擴容然後並且在這些任務裡面進行一些並發數據讀取然後進行一些計算在這個實驗中我們會依靠幻存的容量和吞吐來創建獨立性的擴容能力然後我們會把這個聚合帶寬打到一個很高的數值例如300GPS這樣那第二種場景我們是會考慮數據的隔離和分享我們會設定不同的Data Set然後限制說在獨立的幻存的話只能在固定Name Space內訪問但是共享的幻存我們希望它能夠做到跨Name Space的訪問現在我們我們接下來要做這個demo主要是針對第一個場景我們可以看一下我們實驗的一個簡單設定我們會通過Fluid和JuiceFS來創建一個很小的幻存集群在訓練之前我們會進行數據預熱並且配置對應的彈性伸縮我們會希望說當數據幻存達到一定的比例的時候我們的幻存節點可以進行相應的擴容來避免因為過早的擴容一些資源的浪費這裡呢這裡還提到一些關鍵數據比如說我們的聚合帶寬然後我們整個的cost saving然後我們會在那個實驗之後來進行對這些數據進行一個一對一的副盤在我們正式進入我們這個demo的video之前我們要簡單介紹一下我們整體實驗的setup我們會使用200個ECI pod來在沒有幻存的情況下對JuiceFS上的同一個文件進行讀取這個文件呢我們希望它是大概10GB大小這個樣子我們會對比這200個pod讀取文件的總花銷和總效率然後在實驗裡面我們使用了阿里雲ECI作為我們的計算資源這簡單是因為那個ECI裡面pod和資源是同周期的這樣我們可以更好的計算我們的計算花銷也耗時那現在就開始我們的demo再來這個demo的一開始呢我們會進行data set的配置然後這裡可能highlight大家看的不是特別清楚我就一步一步的講解然後我們會創建JuiceFS的round timeApply是access key以及我們會設置我們的round time然後可以看到replay class只選的是0就代表說我們這個時候並沒有任何的幻存然後接下來我們會創建fluid的CRD它有點快CRD已經創建好了然後接下來會創建我們的計算任務然後在這裡就highlight的是200個計算任務然後我們同時是在訪問同一個文件大家可以看到我們的計算任務已經創建起來了這裡為了節省時間我們會跳過任務的執行然後從結果上我們大概就可以看到任務執行的平均耗時對pod而言是在22分鐘左右那200個任務的話總合起來這裡應該就是4400分鐘這是我們的第一個實驗然後我們來看我們第二個實驗第二個實驗這個圖可能跟剛剛非常相似的唯一的區別就是在這裡我們加我們使用fluid來構建了一個幻存集群然後除此之外就是我們有幻存集群的構建時間以及相應的數據加載的時間然後其餘的setup的話跟第一個實驗是一模一樣的那接著進行完這個實驗之後我們可以整體來看一下我們資源花銷和讀書效率的一個對比至上剛剛提到我們的setup因為是一模一樣的所以這裡省去了data set的配置但是為了要創建幻存集群的話我們需要進行一次手動的擴容就是這裡已經開始擴容了然後就是這個video可能有點out of date所以我們可以看到就是這寫的是這個幻存集群的創建需要3分鐘但實際上ECR已經對這個場景進行了大幅的優化現在我們在做這件事情的話在十幾秒內就可以完成了然後在我們成功擴容之後我們是可以通過查看我們的cash worker泡的都有開起來然後這個時候我們再來進行我們的數據預加載然後這裡同樣我們也跳過這個過程然後整個數據預加載是27秒左右然後我們可以通過data set的可觀察性能夠看到我們實際上cash下來的數據是這裡9.78GB我們想要的數據大小那接下來就來創建同樣的任務200個ECI pod然後訪問同樣一個文件那跟之前一樣我們進行了一些簡單的加速掩飾我們最後可以來看到結果是在有了這個cash的情況下我們訪問同樣的數據每個泡的平均耗時是大概兩分鐘左右那這就是我們的整個demo那我們來回顧一下我們這兩個比較實驗之後我們基本上可以看到耗時和成本上的差異還是蠻大的首先如果我們通過附位的直接訪問的情況下我們完成整個任務每一個泡的平均耗時是22分鐘那200個泡的總共加起來就是4400分鐘它相當於其實三個小時總化費也就是接近總是1元人民幣但是我們如果通過附位的構建的緩存我們這裡看到包括算上緩存的構建時間和預渣熱時間這200個泡的我們數據訪問這個過程下來是平均耗時是在2分鐘左右實際總耗時是400分鐘也就是6個小時那它的費用是不到9元的大家可以看到幾乎有10倍的差距那我們這裡就是兌現了因為大家黃教主說的那句話買的越多省的越多這是實驗2裡面我們是使用了更多的ECI因為我們需要有緩存但是我們通過節省計算的IO所以我們的總鐵花銷只是實驗1的10分之1然後我們也通過這些ECI portal使用網速構建了更高的聚合貸寬這樣我們能夠提升遠高於訪問OSS直接的那個10GB美秒的貸寬限制我們這裡最後總結一下我們在量化建容中是非常常見的會有計算會需要彈性的計算資源然後我們的波風波鼓會非常明顯因此我們在計算的過程中不僅是計算資源需要彈性然後我們的緩存它的用量吞吐也是需要彈性的Fluid通過data set的抽象能夠幫我們整合不同的存儲戒指讓我們在計算冊統一能夠構建一個計算緩存然後並且能夠統一管理這樣我們能夠達到用計算冊的網絡資源換取存儲冊的貸寬資源然後提升存儲的吞吐和彈性能力加速我們的數據讀取減少我們的資源消耗最後的最後大家想廣告就是通過這個演講我們可能介紹兩個開約項目像Fluid和GCFS然後大家如果對這兩個項目感興趣的話可以通過下面的網址去訪問他們獲得更多的信息然後像是我們前相投資Metallic Trading我們也在活動中然後如果大家感興趣的話可以通過這個鏈接或者掃這個二維碼來獲取更多的信息OK那到最後我們可能還有一點點時間然後如果大家有任何問題的話只是任何問題的話可以現在提給我們你好那個我想問一下你們這個Fluid的組件在我來看是阿里巴巴的是吧還是不是阿里巴巴的他是CNCF旗下的CNCF旗下的是吧對然後他對於譬如說其他的私有雲我舉個例子因為我可能是阿里巴巴的私有雲用戶那如果說我要在阿里的容器上去構建Fluid的這個組件的話你們覺得難度有多大我這是第一個問題第二個我可能想問量化策略那部分的就是說我看你們剛才那個冷熱數據的那個data set的那個拉通但是其實做量化我們經常會和全球的各地的交易所我在供雲策略加很多的交易的虛擬資源或雲端資源我盡量希望我的量化交易策略拉通到我的交易的這個交易所所在時區的這些雲端資源上去做量化的交易投資策略然後盡量縮短我的交易的這個實現那像這種的策略你的Fluid的組件可以在全球的那個雲計算中心裡面去做全球測的那種冷熱數據的那種同步和拉通這個我不知道我想問兩個問題好 謝謝我嘗試回答一下首先Fluid完全是一個開源組件你我記得前向小夥伴最開始的時候也完全是用Fluid的開源板把整個的端道端就可以跑起來了這個沒有太大的問題除了就是後面可能是ECI雲自己的修改和修之外其實在標準的就是像標準的這些硬件上其實把它跑下來是沒有問題的但是可能後面設計到你用什麼樣的Runtime去調優那些可能需要一些就是去做一些調研去做一些了解這個是具體的工作然後第二個您是說當時在這些全球化的場景下如何來用Fluid來做這個數據加速實際上確實現在就有我們有一些用戶就是這樣來用的它的做法是首先建立一個多級群然後在多級群中創建不同的Fluid的Data site他們可能是採用同名然後上層做統一調度然後因為Fluid也支持這種定時的數據預熱各種策略你可以用它來做你的數據同步相關的一些操作目前有人是這樣用的那我想問的就是同步時效會有大概一個什麼樣的數量級呢這個因為我只要有人在這樣用因為他們也並沒有真正跟我們去交流這個實驗我覺得這個實驗其實是取決於網絡和計算 對吧這個實際上並不是一個能夠在這回答因為不同不同存儲其實完全是不一樣的 對吧好 謝謝OK你好 感謝你的分享我這邊有個問題剛剛看到你Fluid提供了一個抽象層抽象來不同的數據圓我想問一下對於不同數據圓你們做的這個抽象它差異化配置是怎麼怎麼去配置的是一個很大的一個模型包含所有數據圓的所有的配置還是說你們只是取了一個交集是這樣的就是首先站在Fluid的世界觀裡面我們認為不同的數據級它的優化策略完全是不一樣就是大模型的文件對吧你和一些特別小文件這種它其實完全就是比如說大模型場景它有一個特點它數據是完全通過預讀讀到內核讀到內存再從內存加到GPU對吧它是完全沒有一個隨機讀的場景它就可以認為這是業務場景可以讀所以我們是有不同的data set來分別針對不同的場景來優化的它並不是一個統一優化OK我理解一下你說的抽象層其實是指我針對每一種data set我都構建了一個模型是吧是的它其實是根據不同的上層計算的特點來去構建不同的data setdata set的核心是以應用為中心的就是說你的應用是怎麼去用數據的那我就為它構建一個什麼樣的data set而不是說把所有的數據都灌到了一個data set的下這個是和傳統傳統PVC是不一樣的好 謝謝沒事我們下面可以繼續再溝通你好 謝謝非常有實際只用那個價值的一個演示我有一個問題是當我們用它來去部署大模型的時候那個大模型小的話也有十多個G能聽到我說話嗎可以對比較大的模型有大概有100多G吧我想問的是就這個for的能不能去緩存大模型的文件Flu的其實現在在緩存大模型實際上已經有些很多的落地的案例了這個其實昨天有一個專門的阿里雲場景就是Flu的專門針對大模型場景我們的一些解析和優化那個其實如果您有機會看那直播的話我完全是可以看的首先第一件事就是緩存下來沒有問題因為其實我們現在看到比較大的模型比如說是760B這種模型其實也有300多G它完全是能夠緩存下來的然後緩存下來並不一定能加速為什麼呢它其實受制於幾件事情比如說客戶端的並發請求量到底有多大它能不能把客戶端的需求測的貸款打滿這個事情Flu的還做了一些相應的優化我們能夠比默認的模型加載速度快7到8倍這個如果你敢信的話我們有些相關的信息都可以來了解一下對還有一個小問題就是它能不能跟我們那個阿里雲需要來自KBS那個ACK結合來使用有的就是首先ACK上面就專門有ACKFlu的這個組件直接開箱就用了好謝謝你好我想問一下質疑我想問一下質疑就是我看PVT裡說到咱們的Workload也就是工作負載我看那個意思好像是工作的時差會比較短就是它從啟動到結束會有一個比較短的時間這件事和我理解的AI相關領域的應用不太一樣因為在我們遇到的很多場景它的Workload都是要長期運算的所以我想問一下你能不能大概介紹一下你們這些你們這些容器裡跑的這個作業到底是在做什麼這個可能設計一些機密我不太能透露好 謝謝但是就剛剛修正一點就是什麼我們的任務不會很短的我們會有短任務我們也會有長期任務對 然後我們只是說併發會很高我們的彈性會很高你好我想問一下那個剛才那個Delo裡面JuiceFS你們是部署在雲下的還是雲上的就是你們做那個對比的時候是跟那個ECS是不在同一個region嗎還是說它就是一個雲下的存儲我來給您解答吧是他們是在同一個可容區的同一個region的就是因為它用的是OSS就是Juice實際上它也可以選多個可容區它其實是雲上部署在同一個可容區的OK所以但是它不是跟那個ECS在同一個機房這種所以它有加速嗎還是說是因為JuiceFS它本身有那個帶寬的瓶頸就是它那個加速效果到底是因為我理解就是Fluid它其實是把數據拉到一個可能是集區內部或者是一個同一個機房的一個USSD搭起來的一個樣的換存所以它的就是是因為它突破了那個帶寬還是說是因為一個本身性能的這樣OK您提了一個非常好的問題是這樣的就是所以剛才我們看到第一個Demo中一些併發的任務去拉取數據時間比較耗時比較長它的平靜其實是在於Juice背後的OSS帶寬如果您了解Juice的話Juice其實是提供了遠人數據的管理它其實並不提供數據的管理而背後的數據管理其實OSS提供的OSS帶寬是10Gb10Gb的帶寬就是默認是10Gb默認是10Gb然後200個同時去拉它的話每個人其實分到的有限帶寬就是10除以200對吧那每個人其實分到的可能就是幾十兆甚至就幾十兆的帶寬而後面我們通過Flu的進行有款存加速其實一方面是說幫你把數據Lay off就Lay off到你的本身的計算機群降低延時另外一件是很重要的是我通過加更多的ECI或者ECS的計算節點我把的帶寬稱大了比如說一台機器它帶寬可能我們提供的那個是40Gb小b的那10台就是400Gb小b它的聚合帶寬和10Gb變成了40倍對吧那它的整個的這個速度其實就在這個上面是差異如果是單節點就是單獨的一個進程去請求的話其實性能是是不會有明顯的差距的所以就是剛才那個第二個demo那邊用那個data load其實是在ECI裡面創建更多的那個ECS的這樣的一個虛擬容器然後作為它的那個幻存層是的它現在就是用10個是吧那個demo是用了10個10個但是一個的帶寬一個的ECI是帶寬是40Gb小bOK了解好 謝謝好 謝謝是不是就到這裡我看時間有點有點脫糖了好 謝謝大家感謝大家的歷靈