?ùU8^??Ai@üêìatb?錄第?章節：趨勢與挑戰 4企業級AI應?對IT基礎架構有哪些要求 4?成式AI存儲設施3?關鍵能?與部署?案 5虛擬化vs.裸?屬：AI時代應該在哪?運?容器？ 9如何在企業內部快速部署DeepSeek：模型與軟硬件?案評估 13第?章節：產品與?案 16SmartXAI基礎設施解決?案：?持DeepSeek等多種?模型 16關鍵產品組件-SMTXKubernetes服務：?持虛擬化與容器化AI?作負載20關鍵超融合特性-GPU直通&vGPU 23SmartXx趨動科技：可提供AI算?池化的超融合平臺聯合解決?案 28第三章節：驗證與測評 30以SmartXAI基礎設施?持AI營銷助? 30多家醫院實踐分享：DeepSeek在醫療?業的變?與機遇 33某資管?戶以超融合承載PostgreSQL和AI系統的性能評測 36從0構建企業知識庫，可能沒你想的那么簡單 40更多資源 47第?章節：趨勢與挑戰企業級AI應?對IT基礎架構有哪些要求閱讀提示隨著越來越多?語?模型（LLM）在?業落地，不少企業已開始進??成式AI應?的試點、開發，或在?產環境中試?AI應?。這些應?場景不僅要求強?的算?，還?常考驗IT基礎設施對GPU的?持能?、資源調度靈活性、混合負載?撐能?，以及可滿?多樣化數據的存儲能?。

點擊鏈接閱讀原?：??解讀?向AI應?的超融合基礎設施解決?案點擊鏈接閱讀原?：??解讀?向AI應?的超融合基礎設施解決?案?前，?部分企業?戶都選擇基于已訓練好的?業?模型（在微調后）進?AI應?的開發，或直接在?產環境中使?已開發好的AI應?。雖然這些場景不需要?模型訓練級別的算??持，但仍對IT基礎架構的性能、資源利?率、容器環境?持、多樣化數據存儲能?等??有較?的要求。靈活的計算與存儲資源調度在進?AI應?開發時，不同開發組對GPU資源的需求量不同，?些開發任務也不會完全占??塊GPU卡的資源；在使?AI應?時，不同應?對GPU和存儲的資源需求也不盡相同，且需求量可能變化頻繁。這些都要求IT基礎設施能夠靈活切分、調度計算與存儲資源，同時?持?性能CPU與GPU算?，在提升資源利?率的同時滿?不同應?/開發任務的資源需求。?性能、低時延的存儲?持對?業?模型進?微調時使?的GPU規模較?，要求存儲能夠為GPU并?計算提供?性能、低時延的數據?持。AI應?的全流程也要?對多個數據源的?量數據讀取/寫?：源數據通過預處理，可參與到?模型的微調和推理過程，并對推理形成的?本/語?/視頻數據進?保存和輸出。這些?作都要求存儲具備?速寫?與讀取能?。多樣化的數據存儲?持上述AI應?相關的?作流程中，需要同時處理結構化數據（如數據庫）、半結構化數據（如?志）和?結構化數據（如圖像和?本），要求IT基礎設施能夠?持適?于不同類型數據的不同存儲技術。AI?作的不同環節使?存儲數據的需求也各不相同，有些需要提供?速存儲響應，另?些可能更需要共享讀寫能?。虛擬化與容器化?作負載的統??持得益于Kubernetes的靈活調度能?，越來越多的AI應?正在采?容器化和云原?化的運?模式，?基于虛擬機運?的應?仍將?期存在，這就要求IT基礎設施能夠為虛擬化和容器環境提供統??持和管理。此外，為了?持AI應?的快速上線并跟隨業務發展的規模，IT基礎架構也應具備靈活擴展、簡易運維、快速部署等能?。?成式AI存儲設施3?關鍵能?與部署?案點擊鏈接閱讀原?：趨勢洞察｜?成式AI存儲設施3?關鍵能?與部署?案點擊鏈接閱讀原?：趨勢洞察｜?成式AI存儲設施3?關鍵能?與部署?案閱讀提示Gartner報告指出，除了對算?的需求外，?成式AI對底層基礎設施提出了更?要求：多元化數據存儲能?、強勁的存儲性能、全局數據管理能?，企業需要根據數據訓練的規模和需求選擇合適的存儲部署?案。

?前，不少企業都開始開發或者使?AI應??持業務發展。不過在進?AI基礎設施規劃時，很多IT決策者只關注到AI場景對于算?的需求，?忽視了存儲?案的規劃，系統難以及時將數據傳輸給GPU，反?浪費了重要的計算資源。對此，Gartner在《TopStorageRecommendationstoSupportGenerativeAI》報告中，解讀了?成式AI（GenAI）在存儲層?的3??級功能需求，并針對不同?戶的使?場景提供了存儲建設與部署?案。視頻資料：AI存儲3?關鍵能?與3種部署?案重要建議直接使?現成的LLM或嘗試部署?成式AI時，建議采??體式AI融合存儲?案。使?既有企業存儲平臺（SAN、NASHCI）進??規模數據訓練或?持訓練好的模型。AIAI如果沒有數據安全/合規??的限制，或者計算和存儲需求難以預估，可以使?公有云運??成式AI應?。Gartner預測到2028年，75%使??成式AI訓練數據的企業都將部署單?存儲平臺進?數據存儲，盡管這??例在2024年僅有10%。?成式AI需要3??級存儲能??成式AI應?對企業的底層存儲設施提出了?些?級能?要求，主要包括以下3類：多元化數據存儲能?：AI?是?、更側重于元數據或是數據訪問。強勁的存儲性能：AI能夠被充分利?，并快速完成模型檢查點和恢復過程。如果存儲不能快速將數據投喂給GPU，就會出現GPU資源浪費的情況。全局數據管理能?：AI想要獲取這些能?，企業可能需要對存儲設施進?現代化改造，這對于基于?規模數據進?新LLM模型訓練的企業??尤為迫切。雖然?多數企業可能并沒有類似的需求，但?持?成式AI應?依舊需要存儲層具備類似的?級功能或能?。?成式AI存儲建設與部署?案根據數據訓練的規模和需求選擇合適的存儲部署?案?部分企業不需要搭建新的存儲基礎設施根據Gartner的調研，在5種企業?成式AI部署模式中，僅有?種需要搭建底層模型或從頭開始構建LLM；其余的4種部署模式，都是直接使?現成的、預先訓練好的LLM，僅需要企業基于內部數據（有時也需要補充外部數據）、提示?程或數據檢索技術來進?微調。也有越來越多的企業選擇以?型語?模型（SLM）替代LLM——與使?數?億參數的LLM相?，SLM通常僅需要不到1億個參數——以便快速測試模型，并幫助?戶在特定業務場景中快速看?ROI。AIGenAIAILLM。使?現有的存儲基礎設施。這?并不限制存儲?案是?件、對象或是塊存儲，是外部存儲、直連存儲或是超融合存儲。如果企業能夠部署數據管理軟件層，實現跨內部、邊緣和/或公共云中的存儲數據訪問，則會更有幫助。Gartner建議直接使?現成的LLM或嘗試部署GenAI時，建議購買?體式GenAI融合存儲?案。使?既有企業存儲平臺（SAN、NAS、DFS或HCI）進??規模GenAI試點。引?數據管理?案，以便在現有存儲中實現通?訪問，并?持?定義標記和基于元數據的搜索。GenAIGenAI的解決?案。?規模?成式AI部署需要可?持模型訓練和推理的?級存儲能?和全?數據管理能?第?批?型復雜的GenAI部署已經開始對存儲設施提出了“既要?效、?要?性能”的多重需求。?些GenAI?作負載會帶來PB級的數據量，GenAI?作流程的不同階段也對存儲性能和操作提出了不同的要求。對于這些?作負載，數據湖或分布式存儲系統（如Hadoop和Spark）通常?于存儲訓練數據和中間輸出。在訓練、微調和推理時，基礎設施棧重點需要提供針對性的GPU優化和?吞吐量。AIAI模型，本地硬盤可能就可以滿?需求。但?型模型通常需要基于對象存儲或并??件系統的共享存儲。對于?型GenAI系統，?款可擴展、?容量和低延遲的集成存儲?案，能為?結構化數據的處理提供最佳性能。GenAI?作流程的不同階段對存儲的要求具體如下：GenAI性，以便滿?GenAI?作負載不斷變化的需求。此外，GenAI數據平臺必須能夠實現GenAI?作負載在不同階段的混合數據管理，以實現數據管道?動化。最后，GenAI數據平臺必須?持?于常規的數據安全標準，以保護敏感數據。如上表所示，由于GenAI?作負載復雜多樣，AI應?場景可能沒有“??切”的存儲基礎架構?法。I&O領導者不應只關注?于訓練GenAI模型的?性能存儲，還應構建端到端的?作流策略，包括提供跨邊緣、公有云和本地存儲的數據管理能?。下表展示了GenAI?規模部署需要的存儲平臺關鍵能?。?前，GenAI的早期采?者正在與?型公有云提供商合作，因為這些提供商可以快速落地各種規模的GenAI試點項?。?型提供商主要?持整個數據技術堆棧，提供基于可?LLM的GenAI開發服務。此外，?些?型供應商（如AWS和?歌）正在投資針對數據和存儲進?優化的專有芯?和互聯，以滿?GenAI應??益增?的需求。但是，受到成本、安全性、隱私以及需要專?LLM等??的制約，并不是所有企業都適合這種部署模式。Gartner建議選擇能夠同時為?帶寬/?量順序?作負載和??件/隨機I/O?作負載提供?性能的供應商和產品，因為?多數傳統解決?案?法兼顧這兩類?作負載的性能?持。使?共享存儲來整合數據平臺，避免GenAI數據管道在不同階段之間移動，并提?存儲效率。對既有存儲?絡進?現代化改造，使??性能架構消除性能瓶頸并最?限度地提?GPU利?率。AI（邊緣、核?數據中?和公有云）采?統?的數據管理?式，避免引?存儲孤島。虛擬化vs.裸?屬：AI時代應該在哪?運?容器？點擊鏈接閱讀原?：虛擬化vs.裸?屬：AI時代應該在哪?運?容器？點擊鏈接閱讀原?：虛擬化vs.裸?屬：AI時代應該在哪?運?容器？閱讀提示?前?部分?戶傾向于在虛擬機中部署Kubernetes集群，但隨著AI時代的到來，物理機Kubernetes集群的采?率也在上升。極致?性能計算場景更適合以物理機作為Kubernetes部署環境，此外VMware被博通收購也讓?些?戶考慮回歸“物理機環境”。由于虛擬化和物理機適?的容器應?場景有所不同，未來?戶可能需要同時管理基于虛擬機和物理機部署的Kubernetes集群以滿?不同的應?需求。

AIKubernetes環境是否會成為主流？企業?戶需要從虛擬化環境過渡到物理機環境嗎？如何確定新Kubernetes集群的部署環境？……以下，我們將結合分析機構報告，簡要分析企業?戶的容器使?與部署趨勢，解讀“物理機跑容器”在AI應?、VMware替代等背景下具備的優勢及其?臨的挑戰，為?戶的容器平臺建設提供更多參考思路。*標題中的“裸?屬”主要表示基于物理機構建Kubernetes集群的?式。下?中提到的“裸?屬”同理。現狀：在虛擬機中部署Kubernetes集群仍是主流選擇?前，在私有云中使?Kubernetes，?部分?戶還是傾向于選擇虛擬機作為主要部署環境。根據SpectroCloud《2024StateofProductionKubernetes》報告，近?半受訪?戶的Kubernetes集群部署在超過4種環境?，其中構建私有云數據中?的?戶，85%都將Kubernetes部署在虛擬化環境，采?物理機的僅有31%。這?選擇主要有兩個??的原因。技術層?虛擬化技術發展成熟，在資源效率、彈性擴展和安全隔離??能更好地?持容器化應?系統，?常適合需Kubernetes（如開發測試）KubernetesKubernetes的三個場景。另外，?些基于虛擬化的容器管理產品，如SMTXKubernetes服務（SKS），也針對虛擬化層性能開銷進?了優化，使得虛擬化環境中的Kubernetes集群在?持?狀態應?和有狀態應?時，性能能夠達到物理機環境中的80%-90%，滿??部分常規業務場景對于性能??的需求（?下圖）。欲深?了解測試情況，請閱讀：虛擬化vs.裸?屬：兩種K8s部署模式下的多場景性能對?。環境層?根據Gartner《如何采?云原?技術加速數字化轉型》報告，2022年僅有不到30%的中國?型企業建?了云原?平臺，這??例預計在2027年達到70%。?前?部分國內?戶的應?容器化改造還沒有步?“深?區”，容器平臺以?持開發測試環境和?產環境的?般應?系統為主（如管理類業務系統、互聯?類應?系統、辦公類應?系統）。這些場景對于IT基礎設施的性能要求不是很?，更關注資源與應?的敏捷交付能?，因此更適合在虛擬化環境中運?。未來：AI、VMware替代、降本增效等趨勢或加速物理機Kubernetes的采?雖然現階段Kubernetes的部署環境以虛擬化為主，不少分析機構和?戶還是很看好物理機Kubernetes的發展前景。上?提到的SpectroCloud報告指出，物理機Kubernetes集群在受訪?戶中的采?率已從2023年的25%增??2024年的31%。這?增?趨勢主要歸功于AI、邊緣計算等新興技術的迅猛發展，以及VMware被收購后越來越多?戶產?的“成本焦慮”。極致?性能計算場景更適合以物理機作為Kubernetes部署環境TWT83%vs.裸?屬：K8s部署環境架構與特性對?》和《適合在虛擬化環境中運?Kubernetes的三個場景》?章中也提到，基于物理機部署Kubernetes不存在虛擬化層的性能開銷，對GPU的?持能?也在?定程度上優于虛擬化，還能避免虛擬化、環境帶來的”noisyneighbors“的問題，滿?更嚴格的數據合規要求，因此更適合?持?性能計算(HPC)、?數據處理和分析、AI/ML、實時流處理、在線游戲/VR等消耗?量資源的應?場景。對于邊緣計算場景，虛擬化和物理機Kubernetes各有優勢。Gartner在《HypeCycleforContainerTechnology2024》報告中建議：“在最初嘗試邊緣計算時，可以將容器部署在超融合架構（HCI）上，VMI/OGartner（如將容器直接部署在物理機上）可能會更加簡單、資源使?更?效。”這種邊緣站點僅運?輕量化的、?狀態的應?，?需附加虛擬化或分布式存儲系統，適合采?物理機作為容器化應?的部署環境。VMware使?成本增加，“回歸物理機”能夠降本增效？另外，VMware替代、“降本增效”等外部因素，也讓?些?戶考慮回歸“物理機環境“。VMware被博通收購后全?轉向訂閱制并精簡產品線，Gartner在《TheCIO’sGuidetoBroadcom’sAcquisitionofVMware》VMwareVMwareVMwareIT基礎架構，滿?未來敏捷交付的業務需求。?在構建容器平臺時，對于?些已經完成應?容器化改造的?戶來說，基于既有物理機直接部署Kubernetes，可以免去虛擬化平臺的采購成本，降低短期內建設成本和轉型難度，因此成為?種可?的“去VMware”技術?案。不過，如果單純想要“節約成本”?采?物理機作為Kubernetes的部署環境，這?思路還需要?戶結合實際情況進?步考量——使?物理機Kubernetes集群雖然能夠免除虛擬化授權的開銷，但?期使?需要的資源投?可能會遠多于虛擬化環境，包括硬件資源（機器、機房、機架）、軟件資源（操作系統、?動化運維?具）、運維??資源等。尤其是在滿?安全合規要求的背景下，物理機節點需要定期進?操作系統和軟件升級，隨著集群和應?規模的增?，管理難度將呈指數級上升。因此，如果沒有AI等?性能應?場景的“剛需”，采?物理機部署Kubernetes并不?定能夠通過“降本”體現“增效”。我們在下表也總結了各種需求下更適合Kubernetes的部署?式，可以看到，除了AI、利舊既有物理機、業務合規等場景，基于物理機部署Kubernetes的優勢并沒有虛擬化明顯，這也是為什么Garner在《MarketGuideforServerVirtualization》報告?提到，物理機Kubernetes在未來可能得到更為?泛的采?，但現階段實際落地的增速較為緩慢。挑戰：多種容器基礎設施的混合使?與統?管理除了物理機Kubernetes集群?身的管理難題，多種容器基礎設施的混合使?也將為IT運維?員的?常?作帶來新的挑戰——由于虛擬化和物理機適?的容器應?場景有所不同，?戶可能需要同時管理基于虛Kubernetes；這兩類集群往往部署在不同的硬件產品上（包含不同型號、不同代或不同性能的CPU/GPU服務器），使?各?的管理運維管理?具，要求運維?員掌握兩套環境的運維技能，問題定位、故障排查也會更為復雜，??增加了運維負擔。此外，基于虛擬機和物理機的Kubernetes集群也很難實現資源的統?調度，資源利?率低，很多容器?商也未對虛擬機及其使?的分布式存儲進?合理配置和優化，影響Kubernetes集群性能和穩定性。除了容器環境，由于很多傳統應?系統依舊需要在虛擬化或傳統物理機環境中運?（請參考往期?章），未來企業數據中?可能需要運維?員同時管理傳統物理機、虛擬化/超融合、基于虛擬化部署的容器集群、物理機容器集群等多種IT基礎設施。例如，?前?些?型?融機構，傾向于將對于性能、延遲和穩定性要求嚴格的關鍵業務系統部署在虛擬化/超融合架構上，數據庫部署在性能更?的專業超融合/物理機環境，開發測試和部分周邊應?系統部署在虛擬機容器平臺上，?AI探索類應?系統（如保險?業的保單?字識別）則部署在物理機容器上。多種IT基礎架構不僅需要多套底層硬件設備，還難以實現數據的互聯互通與資源的統?調度，對部署、運維以及業務的快速發展都有較?的挑戰。根據Portworx《TheVoiceofKubernetesExpertsReport2024》的調研，超過70%的?戶都希望能夠使??款統?管理虛擬機和容器，甚?是能夠統?管理所有數據服務的IT基礎設施平臺，來降低運維負擔并提升應?開發效率。因此，AI時代，?戶需要采?統?的平臺，實現虛擬化、虛擬機Kubernetes、物理機Kubernetes等多種環境的統??持與管理，提升整套基礎設施的運?與管理效率。如何在企業內部快速部署DeepSeek：模型與軟硬件?案評估閱讀提示出于對數據合規與?期部署成本等??的考慮，不少企業都在探索DeepSeek私有化部署?案，希望以更低的成本與更快的速度落地DeepSeek并開啟業務驗證。不過，企業應如何選擇合適的模型和軟硬件?案？?定要使?R1滿?版和AI?體機嗎？本?將詳細介紹。

出于對數據合規與?期部署成本等??的考慮，不少企業都在探索DeepSeek私有化部署?案，希望以更低的成本與更快的速度落地DeepSeek并開啟業務驗證。不過，企業應如何選擇合適的模型和軟硬件?案？?定要使?R1滿?版和AI?體機嗎？以下我們將詳細介紹。#1選擇模型尺?在考慮軟硬件?案前，企業應先根據業務場景運算特點、數據量和精度要求，評估使?的模型尺?及其所需的GPU資源。DeepSeekR1提供了滿?版（671B）和6個蒸餾后不同參數（1.5B-70B）的模型，參數越?，任務處理效果越好，?持訓練的數據量越?，但相應地需要的計算和顯存資源也越多。圖源：Deepseek-R1,GitHub這?我們給?家提供?個計算好的表格，展示了不同DeepSeek模型適合的業務場景和它對應的NVIDIA和昇騰GPU需求。?般來說，企業不必過分追求使?DeppSeek-R1-671B滿?版，32B模型已經能滿?絕?多數企業級復雜任務，如醫療問診、合同分析、法律解讀等；70B模型可以滿?數學分析、?融預測等涉及?量數據與復雜計算的業務場景。我們也在測試環境中，驗證了2塊NVIDIAL20運?DeepSeek-R1-32B?持企業AI客服場景，結果顯示，95%的輸出內容均可符合業務預期。感興趣的?戶可以閱讀博客原?詳細了解。#2選擇硬件?案在確定了模型及其資源需求后，企業可繼續考慮?持DeepSeek的硬件?案。?前?些?商推出了專?為DeepSeek設計的?體機，提供預裝好的GPU和DeepSeek模型。不過這些?體機動輒好?百萬，對于投?有限或是前期?規模部署驗證的企業來說并不?分合適。除了?體機，企業還可選擇??采購GPU卡在既有服務器上使?，或采?已有私有云服務商提供的服務器進?集群擴展。需要注意的是，使?既有服務器涉及?定的服務器改造?作，?較考驗?戶的技術能?；若是采?私有云?商提供的服務器，需要?戶仔細考察服務商的軟硬件適配能?，尤其是私有云?案對GPU的?持能?。#3選擇軟件?案除了硬件?案，軟件層?的能?也會對DeepSeek的運?表現帶來較?的影響，因此也需要企業?戶重點評估。這?主要包括推理引擎、計算層和存儲層3個??。推理引擎：為了?持?模型的?性能運?，企業?戶需要部署推理引擎。?前常?的推理引擎包括Transformers、vLLM、SGLang等開源?案，以及各??商??研發或基于開源?案進?封裝的閉源推理引擎。對于開源推理引擎，?戶需要關注?案的模型兼容性；對于閉源推理引擎，雖然?商可以提供?持服務，但未來也存在?商鎖定的?險。此外，?部分推理引擎都不具備模型管理、調度等??的能?，需要?戶額外部署。計算層：企業?戶可以選擇以虛擬機、虛擬機Kubernetes或裸?屬Kubernetes作為DeepSeek主要運?環境。對于使?單模型、前期驗證場景不多的?戶來說，采?虛擬機的部署?案更加靈活，可以同時?持其他?作負載，資源利?率更?。使?多模型、需要?量復雜場景驗證的?戶，可以采?虛擬機或物理機Kubernetes的部署?案，實現多個模型的快速部署與資源隔離。存儲層：AI?持能?、性價?等多個維度。點擊觀看完整視頻：AI存儲3?關鍵能?與3種部署?案。點擊觀看完整視頻：AI存儲3?關鍵能?與3種部署?案。第?章節：產品與?案SmartXAI基礎設施解決?案：?持DeepSeek等多種?模型點擊鏈接閱讀原?：如何基于SmartX超融合滿?企業DeepSeek快速落地驗證需求?點擊鏈接閱讀原?：如何基于SmartX超融合滿?企業DeepSeek快速落地驗證需求?閱讀提示為了幫助?戶在盡量減少投?的情況下，快速規劃DeepSeek等AI?模型部署?案并完成驗證環境的搭建，SmartX推出了AI?模型解決?案——基于SmartXAI基礎設施，?戶可選擇在超融合環境或Kubernetes裸?屬環境部署并使?多種AI?模型，僅需新購帶GPU的節點，即可快速構建靈活、?性能的AI基礎設施，加速推進業務團隊的場景驗證進程。

眾多企業已經開始加速驗證DeepSeek等AI模型在不同業務場景下的應?。尤其針對數據敏感的場景，企業需要AI模型的私有化部署?案，在保證信息安全的同時獲得滿意的推理質量。但相?利?各種公有服務和AI應?平臺，規劃私有部署?案也為?戶帶來諸多疑問：?前希望快速搭建?個穩定的驗證環境，幫助業務團隊盡快啟動驗證，為后期的落地和投?提供參考。如何在盡量減少投?的情況下，快速規劃部署?案并完成驗證環境的搭建，同時保證驗證的可靠性？DeepSeek提供多種模型和參數，企業內部的實際業務真的需要“滿?”?模型嗎？如果使?多個參數和精度適中的模型，可以使?同?套基礎設施滿?不同業務需求嗎？動輒百萬的AI?體機是否有必要投?？如果業務部?之間有數據權限的劃分，是不是?法共??個?模型？如何避免AI?體機單點故障帶來的業務影響？帶著以上問題，SmartX針對AI模型的私有化部署進?了?案設計和驗證，并推出了針對DeepSeek等AI模型應?場景的解決?案——?戶可選擇在超融合環境或Kubernetes裸?屬環境部署并使?多種模型，僅需新購帶GPU的節點，即可快速構建靈活、?性能的AI基礎設施，加速推進業務團隊的場景驗證進程。基于SmartXAI基礎設施?持DeepSeek等多種?模型?案概覽SmartX?戶可在超融合（采?原?虛擬化ELF）和SMTXKubernetes服務（SKS）裸?屬環境中實現多種?模型的部署（包括DeepSeekV3/R1Distill-Qwen-7B?671B），并為AI應?提供計算、存儲、?絡、集群管理、容器管理等全棧基礎設施?持，以?套技術棧同時為?模型和企業其他業務系統運?提供統?的基礎設施資源，降低企業成本投?和部署運維難度。?案特點?泛的硬件兼容性：全?適配Intel和多種信創CPU以及NVIDIA、寒武紀、昇騰GPU，?持國產主流x86與ARM架構服務器，為?戶提供靈活的硬件選擇。全棧的軟件能?：?套技術棧提供完整的AI基礎設施資源。算?融合：?持NVIDIAGPU直通和vGPU以及寒武紀、昇騰GPU直通功能，提供可靈活調度CPU與GPU資源的綜合計算平臺。AI?件存儲為模型倉庫、推理引擎、向量數據庫提供?件存儲服務，ZBSAIDify（Redis/PG）提供?性能、?可靠的塊存儲服務。?作負載融合：基于SKS實現虛擬化和容器?作負載的統??持與管理，?持基于虛擬機和裸?屬的Kubernetes部署?式，滿?AI應?在性能與資源??的多種需求。SmartX軟件定義的?絡與安全軟件Everoute可實現虛擬化與容器應??絡互聯互通，并提供分布式防?VPCAI模型托管：涵蓋?語?模型（通?&推理）、Embedding、Rerank等。模型編排：兼容主流推理引擎，如vLLM、SGLang、Llama.cpp等。模型優化：?持微調（Fine-tuning）和RAG（檢索增強?成）。API管理：提供統?的API訪問與管理能?。統?的管理平臺：?持在CloudTower統?管理多個站點上的虛擬化、容器運?環境及其所需的計算和存儲資源，降低運維管理負擔。快速部署：SKS內置NVIDIAGPUOperator，可?動部署CUDA驅動、ContainerToolkit并配置容器運?時，?幅提升部署效率，省去繁瑣的?動操作。針對DeepSeek場景的硬件配置在GPU的選擇上，?戶可根據模型參數量、場景、上下???、并發數等參數來選擇相應的GPU資源，具體可以參考下圖：部署?案?：基于超融合（虛擬化）環境該?案中，?戶僅需在已有超融合集群中增加?臺主機?于模型部署，SmartX超融合可為虛擬機和容器AI負載提供統?的資源和管理?持，并通過GPU共享?案?持多個獨?模型的部署，滿?不同場景的使?需求。架構靈活：?持基于虛擬機和容器兩種部署模式，?持部署多種模型，并可按需擴容。可靠可?：具備多種企業級?可?特性，分布式架構避免單點故障?險，?持部署兩個以上同等規模的模型，實現模型?可?。資源分配均衡：ELF虛擬化的DRS功能可動態調度虛擬機和容器節點，使集群資源使?更均衡。拓展場景：基于SmartX超融合對RoCE和SR-IOV的技術?持，?戶可探索分布式推理，部署更?規模模型。部署?案?：基于SKS裸?屬環境SKSKubernetesKubernetesSKSKubernetesWorkerSKS中，并與虛擬機Kubernetes集群進?統?管理。這種?案可?持更為?泛的DeepSeek模型參數，包括671B。?案優勢雙重環境?持：模型編排、倉庫和AI應?等不依賴GPU資源的組件，可以部署在虛擬機中的KubernetesWorker節點上，提升資源利?率。性能強勁：減少了虛擬化層（CPU/Mem）的開銷，相?虛擬化Kubernetes集群可提升10%–20%的性能，滿?復雜模型運?場景的?性能需求。硬件要求低：硬盤及?卡配置沒有最低數量限制。故障影響范圍?：物理機節點僅運?AI相關業務，故障場景不會影響其他組件的正常運?。?案建議?戶可以在根據模型規模進?GPU選型后（參考上圖），進?軟件?案的選型（參考下圖）：建議?戶初期先進??規模投資，快速搭建環境進?驗證。待驗證模型推理準確度符合業務要求后，再根據實際需求逐步投?資源，以確保投?的?效性和可?性。另外，不必過度追求部署DeepSeek“滿?”R1671B的模型——不僅需要較?的投?（且投資回報率不?定?），在很多場景中70B甚?32B都可以滿?需求（32B在中?處理上甚?要?70B的效果好，具體可參考下圖）。圖源：DeepSeek-R1:IncentivizingReasoningCapabilityinLLMsviaReinforcementLearning關鍵產品組件-SMTXKubernetes服務：?持虛擬化與容器化AI?作負載點擊鏈接閱讀原?：SKS點擊鏈接閱讀原?：SKS1.2發布，全?增強AI、信創等場景?持能?SKSSKS1.3發布：?持物理機集群，實現容器可視化管理閱讀提示為滿?企業對AI應?的需求，SKS1.2和1.3版本分別增強了對GPU與基于裸?屬進?Kubernetes部署的能?。SKS1.2不僅?持將物理GPU直通分配給?作負載，還提供多個共享GPU的模式。SKS1.3在?持虛擬機Kubernetes集群的基礎上，增加了使?物理機集群創建Kubernetes集群的功能。

SMTXKubernetesService（SKS）SmartXKubernetesSmartX虛擬化、分布式存儲、?絡與安全等產品組件，幫助企業IT運維團隊在多種CPU架構的服務器上輕松部署和管理?產級KubernetesAISKS1.21.3與基于裸?屬進?Kubernetes部署的能?。AI等?性能計算?持能?SKS1.2提供了對多種NVIDIAGPU型號的全??持，在單?集群中能夠靈活地使?不同型號的GPU。SmartXGPUKubernetes?，并通過多種功能最?化GPU算?的利?。SKS1.2不僅?持將物理GPU直通分配給?作負載，還包含以下共享GPU的模式：虛擬GPU（vGPU）：單個物理GPU可被切分成多個vGPU，供不同節點共享。時間切?（Time-Slicing）：?個GPU或vGPU能夠讓多個進程通過時間共享機制實現并發使?。多實例GPU（MIG）：GPU多進程服務（MPS）：允許多進程共享?個GPU的計算資源，有效減少由進程切換帶來的性能損耗。SKS1.2也?持通過Kubernetes的管理?法，對GPU資源進?彈性靈活的管理：?持對掛載GPU的節點設置?動彈性伸縮策略，可以根據業務需求動態增加或減少掛載GPU的節點數量。當掛載GPU的節點出現故障時，系統能夠?動創建并替換為帶有相同GPU資源的新節點，確保業務的連續運?和資源的?可?性。這些新增功能?幅提?了GPU資源的利?效率、管理效率和靈活性，能夠更加有效地應對資源需求的波動和節點潛在故障等挑戰。基于以上特性，SKS1.2SmartXCPUGPUAI機器學習和深度學習訓練：?持部署TensorFlow、PyTorch等深度學習模型，并確保其獲得必要的計算資源與GPU?持，同時允許橫向擴展以適應?規模數據集和復雜模型的處理需求。渲染和圖形處理：?持部署GPU?于渲染等圖形密集型任務，例如，?于加快電影、游戲開發的GPU渲染。?性能計算（HPC）：適合?規模的科學和?程問題的計算，如模擬，并?持橫向擴展以增強性能。數據分析和科學計算：適合部署如ApacheSpark和NumPy的數據分析與科學計算應?，?持橫向擴展以提升計算效率。詳情可?KubernetesAI場景演示視頻：SKSGPU集群上的Kubeflow安裝及圖像識別應?操作展示物理機Kubernetes集群?持能?SKS1.3在?持虛擬機Kubernetes集群的基礎上，增加了使?物理機集群創建Kubernetes集群的功能，這是由于在以下場景中，?戶更傾向在物理機上直接部署Kubernetes集群：業務應?對性能有極致要求（如AI場景）時，避免虛擬化層開銷，提升計算資源效率。服務器利舊，提升資產利?率，節省成本。KubernetesControlPlaneSKS1.3通過?持物理機Kubernetes集群可有效應對：SKS1.3?持的物理機Kubernetes集群具備以下特點：KubernetesControlPlane節點?動創建并運?在SmartX超融合虛擬機中，?需?戶預先配置虛擬機。?持使?x86_64、AArch64架構的物理機作為?作負載集群的Worker節點。物理機Kubernetes集群架構?戶可按需選擇虛擬機集群和物理機集群，既可以提升業務靈活性，?能有效降低運維成本。具體優勢如下：靈活選擇算?資源：?持?戶根據業務需求選擇合適的計算資源。虛擬機集群適?于對資源利?率和管理靈活性要求較?的業務場景；物理機集群則提供更強算?，適合作為虛擬機集群的算?補充，滿?延遲敏感的應?需求。?幅簡化運維?作：?持在不同的底層硬件架構上構建Kubernetes集群，并統?管理不同類型的集群，從?降低操作復雜度，提?管理效率。提升服務器利?率：通過整合現有硬件資源，實現虛擬機與物理機集群的統?管理，有效提升服務器整體利?率。對于有服務器利舊需求的?戶，可根據?作負載特性靈活分配虛擬機和物理機資源，最?化成本效益，優化資源配置與成本控制。詳情可參考視頻：物理機Kubernetes集群功能介紹以及演示關鍵超融合特性-GPU直通&vGPU點擊鏈接閱讀原?：GPU直通&vGPU：超融合為GPU應?場景提供?性能?持點擊鏈接閱讀原?：GPU直通&vGPU：超融合為GPU應?場景提供?性能?持閱讀提示針對企業的GPU應?場景需求，SmartX在全新發布的超融合軟件SMTXOS5.1版本中新增了原?虛擬化ELF平臺GPU直通和vGPU?持能?。?前，SmartX超融合可為ELF集群提供完整的GPU?持能?，并為多種虛擬化環境（包括VMwareESXi和CitrixXenServer）的GPU應?提供?性能的存儲資源池，幫助企業實現??智能、機器學習、圖像識別處理、VDI（如三維建模、圖像渲染）等多種?性能應?的?產級使?。

?前，GPU芯?在國內市場上?常稀缺，且價格?昂，為了盡可能提?GPU資源的利?效率，不少企業選擇將GPU資源虛擬化，或在虛擬化（或超融合）環境中使?GPU。那么，如何在虛擬化架構上充分發揮GPU能?和優勢？怎樣以?套架構?持資源的靈活發放，在滿?多種GPU應?計算需求的同時，為應?提供穩定、?性能存儲?持？針對企業的GPU應?場景需求，SmartX超融合（原?虛擬化ELF平臺）提供了GPU直通和vGPU?持能?。?前，SmartX超融合可為ELF集群提供完整的GPU?持能?，并為多種虛擬化環境（包括VMwareESXi和CitrixXenServer）的GPU應?提供?性能的存儲資源池，幫助企業實現??智能、機器學習、圖像識別處理、VDI（如三維建模、圖像渲染）等多種?性能應?的?產級使?。GPU直通和vGPU功能功能特性為了滿?不同?戶和應?場景需求，SmartX超融合?持兩種虛擬化環境中GPU使?模式：GPU直通：將主機上的物理GPU設備透傳給虛擬機使?，GPU的全部資源由?臺虛擬機獨占。vGPU：單個物理的GPU切割成多個邏輯的vGPU，并將vGPU分配給虛擬機作為虛擬顯卡，可實現多個虛擬機共享GPU計算/圖形處理能?。兩種模式下，每個主機上可以使?多個不同型號的GPU設備*，每個虛擬機可掛載多個GPU或vGPU。GPU直通GPUPCIePass-throughSMTXOSGPUGPU卡型號。直通模式具有良好的兼容性，虛擬機識別到GPU型號與實際?致，直接安裝官?驅動，可?損使?GPU的各項特性和功能。同時，由于虛擬機操作系統可直接訪問GPU設備，繞過了SMTXOS超融合操作系統，使得它能獲得接近裸?屬使?GPU的性能。不過需要注意的是，該模式下?張GPU卡不能同時直通給多個虛擬機使?，如果多個虛擬機需要同時使?GPU，需要在服務器中安裝多塊GPU卡，分別直通給不同的虛擬機使?。另外，擁有直通GPU的虛擬機不?持HA、在線遷移和分段遷移功能。vGPUvGPU模式允許多臺虛擬機共享?張GPU物理卡資源，進?步提?資源利?率，節約成本。同時，管理員可以按照?戶的實際需求分配不同GPU資源，例如?GPU、?GPU等，使得GPU資源分配更加靈活。不過，由于GPU擁有多種切分?式和切分粒度，不同GPU型號對切分?式的?持情況有所區別，適?的?作負載也不盡相同，需要?戶注意。同時，NVIDIA要求vGPU搭配相應系列的NVIDIAGRIDvGPU軟件許可才能使?，對應關系如下表所示。適?場景基于以上對?，我們分別整理了GPU直通和vGPU兩種模式的適?場景，供?戶參考：優勢與價值快速置備開發環境：通過虛擬機克隆和vGPU功能可快速置備多套GPU開發環境，提升開發效率。靈活的資源發放：?戶可根據?身需求，?由切換GPU直通和vGPU模式，靈活切分GPU資源，滿?不同業務場景對GPU使?的需求，提升資源使?率的同時降低成本。?性能的存儲?持：三維建模、深度學習等依賴GPU的應?場景，通常對存儲I/O也有較?的要求。例如：在深度學習的訓練和推理場景，經常需要訪問?量圖像、視頻、?頻、?本以及結構化數據，涉及多種不同的I/O類型，對存儲的帶寬和IOPS都有較?的要求，存儲延時也會直接影響訓練算法的性能。SmartX超融合內置?主研發的存儲引擎ZBS，能為GPU應?場景提供穩定、?性能、低延時存儲服務。GPU配置主機?先確保主機上的GPU設備符合SMTXOS兼容要求，詳細型號可參考?末附錄。然后登錄CloudTower，為GPU設備所在主機開啟IOMMU?持，并重啟SMTXOS主機。掛載GPU設備登錄CloudTower，先將GPU?途選擇為直通，然后編輯指定虛擬機，選擇對應的GPU設置直通掛載到虛擬機上。配置虛擬機在配備了GPU直通的虛擬機上安裝NVIDIAvGPU軟件圖形驅動并重啟。vGPU配置主機?先確保主機上的GPU設備符合SMTXOS兼容要求，詳細型號可參考?末附錄。然后需在SMTXOS主機中安裝vGPU驅動（NVIDIAVirtualGPUManager），并登錄到CloudTower，為GPU設備所在主機開啟IOMMU并重啟主機。部署LicenseServer根據業務需要，從NVIDIA購買對應類型和數量的vGPU授權。準備?個虛擬機，在其中部署并配置NVIDIAvGPUsoftwarelicenseserver。部署及配置?式可參考NVIDIA?戶指南（?末附鏈接）。選擇GPU切分?案GPU卡?般可?持多種切分?案，通過登錄CloudTower，選擇合適的切分?案，如下圖所示：掛載vGPU設備登錄CloudTower，然后編輯指定虛擬機，選擇vGPU模式，掛載對應的vGPU到虛擬機上，如下圖所示：配置虛擬機在虛擬機中安裝GPU驅動（NVIDIAvGPU軟件圖形驅動）并重啟。部署及配置?式可參考NVIDIA?戶指南。SmartXx趨動科技：可提供AI算?池化的超融合平臺聯合解決?案點擊鏈接閱讀原?：志凌海納SmartX攜?趨動科技推出可提供AI算?池化的超融合平臺聯合解決?案點擊鏈接閱讀原?：志凌海納SmartX攜?趨動科技推出可提供AI算?池化的超融合平臺聯合解決?案閱讀提示SmartX與趨動科技攜?推出可提供AI算?池化的超融合平臺聯合解決?案，該?案通過對存儲、?絡、AI算?等重要資源的智能管理和優化，幫助企業提升業務上線效率和相關創新能?。

SmartX與北京趨動科技有限公司（以下簡稱“趨動科技”）攜?推出可提供AI算?池化的超融合平臺聯合解決?案，旨在為企業提供更強?的IT基礎設施能?。該?案通過對存儲、?絡、AI算?等重要資源的智能管理和優化，幫助企業提升業務上線效率和相關創新能?。?案背景隨著數字化時代的到來和AI應?的快速發展，企業亟需部署簡單、彈性伸縮且安全可靠的現代化IT基礎設施，以實現通?算?（CPU）、?性能并?算?（GPU）、存儲和?絡等關鍵資源的統?規劃、建設和AI聯合解決?案基于以上客戶需求，SmartX聯?趨動科技推出可提供AI算?池化的超融合平臺聯合解決?案，以降低?案構建成本，?撐客戶AI應?的順利運?。在該?案中，SmartXSMTXOSIaaSKubernetesSMTXKubernetesService（SKS）快速創建并管理?產級Kubernetes集群。OrionX的軟件定義AI算?的能?，將AI算?做池化管理和調度，幫助企業提升資源AIAI基礎設施平臺。此外，該?案還提供異構算?芯?納管能?，幫助客戶實現統?的算?資源調度、管理和監控，從?提?AI算?資源利?率、降低TCO，提?AI業務上線效率。聯合解決?案結構圖聯合?案價值架構靈活開放：AIAI?產級可?：同時提供?產級（?性能、?可靠、?安全）的算?、存儲、?絡和安全服務。混合負載?撐：?持在同?環境中部署并使?容器化和虛擬化的AI?作負載。運維簡單智能：對不同節點上的異構存儲、?絡和算?等重要資源進?可視化管理，降低管理開銷。關于趨動科技趨動科技作為軟件定義AI算?技術的領導?商，專注于為全球?戶提供國際領先的數據中?級AI算?虛擬化和資源池化軟件及解決?案，已完成中關村?新、國?新、“專精特新”等企業認證。趨動科技的OrionX獵戶座AI算?資源池化軟件能夠幫助?戶提?資源利?率和降低TCO，提?算法?程師的?作效率。憑借標準化、可復制的產品架構，趨動科技得到了包括電信運營商、互聯?、?融、?動駕駛、能源、科研機構和?校等?量?業頭部客戶的認可。第三章節：驗證與測評以SmartXAI基礎設施?持AI營銷助?點擊鏈接閱讀原?：如何基于SmartX超融合滿?企業DeepSeek快速落地驗證需求?點擊鏈接閱讀原?：如何基于SmartX超融合滿?企業DeepSeek快速落地驗證需求?閱讀提示本測試基于SmartXAI基礎設施（超融合環境）部署了DeepSeek-R1-Distill-Qwen-14B和32B模型，并使?開源AI應?平臺Dify構建整套業務?作流，驗證兩款模型在AI客服場景的回復準確率、token消耗、回復時間等表現。測試結果表明32B模型在輸出質量上有所提升，但平均回復時間與14B模型持平。此外，與公有云（Coze）環境部署DeepSeekR1滿?版的測試結果對?，私有云部署?案在回復準確度??可以達到公有云+DeepSeek滿?模型的90-95%，?成速度持平（甚?更?）。

在企業開展市場營銷活動時，通過在線上平臺引?AI智能體，可以打造全天在線的客服助?，并通過構建企業知識庫，提升AI客戶回復的質量和針對性，為?戶提供更有價值的信息，降低市場營銷服務成本。我們基于SmartXAI基礎設施（超融合環境）部署了DeepSeek-R1-Distill-Qwen-14B和32B模型，并使?開源AI應?平臺Dify構建整套業務?作流，整套架構如下圖所示。?案驗證為進?步驗證?案效果，我們分別使?NVIDIAT4和L20GPU測試了DeepSeek-R1-Distill-Qwen-14B（BF16）與DeepSeek-R1-Distill-Qwen-32B（BF16）模型基于SmartXAI基礎設施的性能表現，并驗證了兩款模型在AI客服場景的回復準確率、token消耗、回復時間等表現。測試環境測試環境部署三節點SmartX超融合集群，通過虛擬機運?DeepSeek模型，虛擬機配置為32vcpu、64G4NVIDIAT42NVIDIAL2014B32BGPUGPU資源，使?vllm推理引擎運??模型。測試結果性能對?測試輸??度為1K，以下測試結果供?戶參考。場景驗證基于SmartXAI基礎設施部署DeepSeek-R1-Distill-Qwen-14B/32B模型構建AI客服助?，并模擬?戶提問場景進?測試，具體表現如下：14B模型：使?需求拆分的?作流進?優化后，90%的輸出內容符合預期，token消耗平均值為2669，平均回復時間為26.3s。32B模型：使?需求拆分的?作流進?優化后，95%的輸出內容符合預期，token消耗平均值為2611，平均回復時間為27.1s。可以看到，32B模型在輸出質量上有所提升，但平均回復時間與14B模型持平。整體??，以SmartXAI基礎設施部署Dify?持DeepSeek-R1-32B模型，結合??優化，可以滿?AI客服場景的基本使?需求。后續，可通過知識庫、?作流等??的優化，進?步提升回復效率和質量。AI客服場景演示-基于32B模型與公有云?案對?此外，我們還基于該場景，與公有云（Coze）環境部署DeepSeekR1滿?版的性能和服務效果進?了對?測試。其中，私有化部署配置與?案驗證中?致。測試結果可以看到，私有云部署?案在回復準確度??可以達到公有云+DeepSeek滿?模型的90-95%，?成速度持平（甚?更?），私有化部署?案可以滿??戶的基本使?需求。?案收益提升客服效率：AI客服提供7×24?時在線服務，提升客戶滿意度并減輕??客服負擔。提?響應效率：AI優化資源查找：AI多家醫院實踐分享：DeepSeek在醫療?業的變?與機遇點擊鏈接閱讀原?：多家醫院實踐分享：DeepSeek點擊鏈接閱讀原?：多家醫院實踐分享：DeepSeek閱讀提示基于“DeepSeek在醫療?業的變?與機遇”線上閉?研討會，本?將整理嘉賓的分享內容，重點總結醫院在部署DeepSeek過程中?臨的主要挑戰與需求、算?平臺選擇、數據對接與安全考慮等關鍵問題。

近期，全國信標委云計算和分布式平臺分技術委員會云建設與應?標準?作組醫療?業標準應?推?組（以下簡稱“云國標醫療推?組”）舉辦了主題為“DeepSeek在醫療?業的變?與機遇”的線上閉?研討會。中國電?化標準化研究院、副組?單位志凌海納SmartX與多位醫療領域專家圍繞DeepSeek應?情況等話題展開深?討論。本?將整理嘉賓的分享內容，重點總結醫院在部署DeepSeek過程中?臨的主要挑戰與需求、算?平臺選擇、數據對接與安全考慮等關鍵問題。某?型三甲醫院DeepSeek不同算?平臺部署、安全保障等經驗分享某?型三甲醫院（以下簡稱“醫院”）尚未將DeepSeek模型投??產，當前主要在做邏輯性??的場景驗證。醫院認為AI?模型的潛在應?場景包括導診、分診、病歷錄?等，如智能病歷管理、輔助診斷、個性化治療?案推薦等。基于英偉達平臺，醫院測試了70B和32B版本，但精準度不理想，其他?版本并未準備投??產使?。除ktransformers?案，醫院曾嘗試在英偉達平臺上進?量化版671B模型的部署，盡管成功運?，但由于部署難度較?，且僅?持單并發，僅能供個?使?，?法全?投?使?。基于昇騰平臺，醫院部署了671B滿?版。在精度??，盡管?法聯?搜索，但已能?撐醫院?政層?的使?。該醫院的測試全部在云端進?，通過醫院專線與運營商互聯，避免通過互聯?進?訪問，降低安全隱患。內部組件之間的交互通過專?的內部接?實現。在對接??，通過醫院已有建設的數據中?和集成平臺進?對接。在應?層?，除簡單的聊天??或將智能體嵌??作站外，醫院希望在應?層提供更多輔助功能的對接。在模型使?過程中，醫院將進?步關注數據脫敏、匿名化、安全傳輸和隱私計算等??，確保數據安全，并已制定相應的合規與審計機制。某?型三甲醫院DeepSeek部署挑戰、知識庫對接等經驗分享某?型三甲醫院在DeepSeek部署和應?過程中，主要?臨兩?問題：?先是算?的嚴重低估，盡管使??滿?版模型，仍然存在算?不?的挑戰；其次，應?場景主要集中在臨床領域，尤其是幫助臨床醫?完成?書?作和進?科研??的?級AI檢索。醫院實踐中發現，不同版本的DeepSeek和前期知識庫的?程化布置會直接影響模型的輸出質量。原?態模型通過API調?時，輸出效果可能?法達到官?的展示?平。雖然底層模型可能?樣，但對?輸出結果仍然有差異。在知識庫??，醫院主要?臨的挑戰是需要在服務器端和?機端同時部署。臨床使?的?持設備（如PDA和?機）由于token數的限制，?法在?會話中充分理解上下?。在?程實施??，醫院計劃整理電?病歷等數據庫的關系表，進?查詢并調試問答流程。對于簡單問題，效果較好，但對于復雜的專科問題仍需進?步精調?檔以改善體驗。在安全性??，醫院?常重視越權訪問問題，采?專線與運營商合作，確保患者信息在上傳過程中?動脫敏，防?敏感信息泄露。醫院還針對?些敏感話題制定了強制性約束規范。當前，醫院正在積極部署DeepSeek，并與臨床、?政管理和科研?員?起征集和探索應?場景，以便加快應?落地。在算?獲取上，醫院在積累經驗的同時，在考慮國產的算?，并以租賃投放的?式作為醫院當前的主要?案。后續可能逐步轉向?建，并根據使?效益增加算?。某?型三甲醫院?模型部署挑戰與AI應?場景選擇經驗分享在部署DeepSeek之前，某?型三甲醫院已經在2024年部署了通義千問模型，?標是基于醫院的語料進??成式病歷的訓練。DeepSeek出現后，醫院已將所有開源模型，包括滿?版和后續的V3增強版，基于醫院內部的專業平臺進?了部署，并進?了多輪測試。在測試過程中，醫院發現當前DeepSeek使?主要存在兩?問題：?先是“幻覺”問題，即模型在?成病歷時，可能會將不同病?的病史混淆。其次是?成病歷的時效性問題，尤其是針對?診這種要求?時效性的場景，現有模型?成速度較慢，?法滿?實際需求。在醫療場景的選擇上，醫院認為需要有策略地推進AI應?，未來可能會將低?險的場景（如?政辦公、科研輔助）優先部署，?對于涉及輔助診療、患者服務等??險場景，則需要更加謹慎。AI某地級市醫院DeepSeek部署策略、模型選擇等經驗分享某地級市醫院在選擇基礎架構時，綜合考慮并發效率、與醫院信息化系統的整合、成本控制、以及多模態?持和部署的靈活性，最終選擇了RagFlow+SGLang模式進?本地部署，優化了并發效率并更好地適應醫院的結構。針對中?型醫院，建議可以采?英偉達的通?模型進?嘗試和引?。由于醫院算?資源有限，?前僅有兩張A30顯卡?于多??的測試，最終選擇了DeepSeek-R1-Distill-Qwen-32B-AWQ模型制作AI智能體，但32B模型的輸出效果仍不理想，?法?于實際?產，因此醫院使?了?些對實際業務影響較?的模型進?線上分析，如合理?藥。在病歷質控??，醫院計劃結合結構化電?病歷，采?SGLang模型進?AI分析，確保病歷信息的精確調控。醫院也與?些醫療公司合作，嘗試部署深層模型。針對?齡化所帶來的描述不清等問題，醫院正在與?商進?合作優化語?識別；同時，醫院正致?于打造全形態的AI智能體，并通過開源模型對醫?進?簡單培訓，推動AI技術融?醫療?為中。在安全??，醫院采?兩套?案：?是推動國產化，正在與國產?商合作進?本地部署；?是在?絡結構上采?邏輯隔離，確保訓練與實際使?分開。醫院使?相應的API防控設備對數據傳輸進?實時監控，并且定期對部署環境進?安全掃描。總結通過以上分享可以看到，在DeepSeek部署過程中，醫院當前?臨的主要挑戰包括以下?個??：算?不?：盡管醫院在部署過程中使?了不同的算?平臺和模型，但由于算?資源有限，特別是在設備和顯卡的配置上，醫院?法充分發揮模型的潛?，導致某些模型?法滿??產需求。算?的限制使得醫院不得不選擇?些對實際業務影響較?的模型進?測試和部署。模型輸出質量與“幻覺”問題：在實際應?中，醫院遇到模型輸出效果不理想的問題，特別是與官?展示的效果差異。某醫院還?臨“幻覺”問題，即模型?成病歷時可能混淆不同病?的病史，影響實際應?中的準確性。多端部署難題：醫院需要同時在服務器端和移動端（PDA）部署模型，然?，由于設備上的token數限制，模型在?會話中的上下?理解受限，難以實現流暢的互動和知識庫的?動積累。應?場景局限性：醫院的應?場景主要集中在臨床領域，尤其是輔助?書?作和科研檢索等任務。由于任務的復雜性，醫院在?些精細化的專科問題上需要進?步優化模型和?檔，以提?體驗和準確性。數據安全和隱私保護：醫院?常重視患者信息的安全，尤其是在數據傳輸和存儲過程中，確保脫敏、匿名處理以及安全傳輸是?要任務。醫院采?了專線、API此外，除發?專家外，參會專家也提到了諸如國產GPU與英偉達的差距、算?專?成本?昂，以及醫院在應?垂直領域?模型時，?臨不同科室需求差異的挑戰，這使得?模型?法滿?所有需求，且算?承載能?有限，容易導致模型過度發散等問題。醫院在與?商的合作中，?臨技術?持不?和對未來規劃的依賴，缺乏?夠的參與度和?主權，且可能?臨按資源收費的問題。針對以上挑戰，云國標醫療?業標準應?推?組將持續關注醫療機構在DeepSeek部署過程中的實踐經驗，積極構建?業交流平臺，促進醫療機構與技術?商之間的溝通與合作。通過分享最佳實踐、解決?案和技術?持，推動?業整體發展，幫助醫療機構更好地應對算?、模型應?、數據安全等??的挑戰，推動以DeepSeek為代表的AI技術在醫療?業的?泛應?與落地。關于云計算標準?作組云建設與應?專題?作組：云建設與應?專題?作組于2022年8?19?成?，由中國建設銀?與中國電?技術標準化研究院擔任組?單位，中國銀?、中國農業銀?等作為副組?單位，聯合?融、政務、教育、醫療等?業?戶單位、央企?戶單位、學術和研究機構、云產品和技術提供商等?批83個成員單位共同組成，現已擴展?130余家。某資管?戶以超融合承載PostgreSQL和AI系統的性能評測點擊鏈接閱讀原?：點擊鏈接閱讀原?：AI場景跑贏公有云！某資管?戶以超融合承載PostgreSQL和AI系統的性能評測閱讀提示某頭部資產管理機構測試了SmartX超融合對?產環境投資分析系統數據庫和?研??智能分析系統（AI系統）的?持能?。測試結果顯示，3節點SmartX超融合運?投資分析系統，?時相??產環境物理服務器增加1分鐘（18.8%），符合?戶預期；通過GPU直通功能在SmartX超融合中運?AI系統，性能明顯優于?產環境某公有云平臺，多種模型下?件分析?時降低15%-27%。

AIGPU提供強?算?，對底ITAI近期，某頭部資產管理機構計劃升級IT基礎架構，為?產環境投資分析系統數據庫（PostgreSQL）和?研??智能分析系統（以下簡稱“AI系統”）提供?性能、?可靠?持，因此測試了SmartX超融合對以上兩個應?場景的?持能?。測試結果投資分析系統PostgreSQL數據庫場景：3節點SmartX超融合運?投資分析系統，?時相??產環境物理服務器增加1分鐘（18.8%），符合?戶預期，可滿?業務使?需求。AI系統：通過GPU直通功能在SmartX超融合中運?AI系統，性能明顯優于?產環境某公有云平臺，多種模型下?件分析?時降低15%-27%。測試背景該資管?戶?產環境投資分析系統以PostgreSQL提供數據庫服務，運?在單機物理服務器中，由本地磁盤提供存儲能?。同時，?戶還??搭建了??智能分析系統，運?在某公有云環境的云服務器中（每年公有云的投??達數?萬，成本較?）。AI系統使?的模型包括whisper(large-v2)和cogvlm2(int4)，主要?于對?頻、PDF和圖?等業務材料進??字識別和轉換，以及后續的數據分析和存檔備份，以減少??錄?、提升?作效率。為了進?步開展IT基礎設施現代化建設并實現降本增效，以更低的成本投?為以上兩個應?場景提供?性能、?可靠、易運維的IT基礎架構?持，?戶測試了SmartX超融合對兩個應?場景的?持能?，并與?產環境性能表現進?了對?。環境與配置投資分析系統PostgreSQL數據庫場景為了確保測試虛擬機系統環境與物理服務器系統環境相同，本次測試使?SmartX?研P2V遷移?具SMTXCloudMove，將當前運?在物理服務器上的投資分析系統PostgreSQL數據庫在線遷移?SmartX超融合平臺的虛擬機中。硬件配置軟件配置?產環境物理機操作系統：CentOS7.9測試環境超融合軟件：SMTXOS6.0AI系統?產環境中，AI系統部署在某公有云云主機中。測試環境中，在SmartX超融合平臺創建?個配置規格相同的虛擬機，通過GPU直通功能將NVIDIAL20GPU卡掛載?虛擬機中，部署應?模型后進?測試。欲深?了解SmartX超融合GPU直通與vGPU?持功能，請閱讀：GPU直通&vGPU：超融合為GPU應?場景提供?性能?持。系統環境GPU卡信息*在進?AI模型推理如whisper和cogvlm時，使?更多的是GPU內的TensorCore進?Transformer（whisper）與卷積?絡矩陣運算（cogvlm），并?單純依靠CUDACore。因此?產環境與測試環境使?的GPU在此次測試項?中綜合表現基本持平，測試結果差異主要反映了兩個平臺虛擬機性能和存儲性能的差異。測試項?投資分析系統數據庫性能測試：通過測試腳本發起對不同資產產品進?分析的任務，獲取每項產品的分析耗時，并與?產環境任務?時進?對?。AI系統性能測試：分別測試whisper模型和cogvlm模型下多種?件的分析?時（包含圖像、?頻和視頻），并與?產環境分析?時進?對?。測試結果投資分析系統PostgreSQL數據庫性能測試測試時，SMTXOS開啟RDMA，經過多次優化，將虛擬機配置調整為8vCPU和256GB內存，保持服務器超線程關閉和虛擬機處理器物理透傳，并對虛擬機vCPU做物理核綁定。測試結果如下圖所示。可以看到，在SmartX超融合中運?投資分析系統PostgreSQL數據庫，測試總?時?裸?屬環境慢1分鐘左右（18.8%），?戶表示結果符合預期，可滿??戶的業務使?需求。更重要的是，這?測試結果是基于8個虛擬核（vCPU）對??產環境的32個物理核得出的，在硬件資源僅有原環境約1/8的情況下（測試環境與原?產環境都使??代XEON，CPU主頻相差也僅為0.1GHz)，實際性能差異只有不到19%，超融合環境能更好地滿??戶更為看重的整體擁有成本（TCO）以及運?效率??的需求。另外，我們在測試過程中通過iostat/top等?具對超融合節點性能進?持續監控，觀察到存儲間歇性壓?為30-50MB/s，iowait持續為0，內存?量約為20G左右，?CPU單核負載保持在99%，因此性能??的壓?主要集中在CPU上。AI系統性能測試whisper模型測試cogvlm模型測試可以看到，在兩個模型測試中，SmartX超融合?持AI系統進?多種?件分析任務（包括圖像、?頻、視頻），相較?產環境公有云?時縮短了15%-27%，?戶對此性能表現?分滿意。總結整體??，SmartX超融合平臺能夠為?融?戶投資分析系統數據庫（PostgreSQL）和??智能分析系統提供?性能、?可靠的基礎架構?持，尤其是在AI場景中，SmartX超融合性能明顯優于公有云環境，能更好地滿?業務需求。此外，超融合架構簡潔、靈活的特點，能夠為?戶帶來更多收益：靈活擴展：?持最少3節點部署，按需擴展，帶來媲美公有云的靈活性。簡化運維：超融合架構簡單，具備多種運維?持功能，降低運維難度。SMTXCloudMove?研遷移?具?持?戶?效、便捷地從物理機、公有云、虛擬化平臺遷移?SMTXOS集群。多種GPU?持特性：?持GPU直通、vGPU功能，以及MIG、MPS等技術，允許?戶對GPU進?靈活切分。降本增效：避免?昂的公有云投?，以性價?更?的超融合平臺提供更強?的性能?持。SmartX超融合也?持CPU、GPU資源的靈活分配，提升資源利?率，且?持?戶利舊既有服務器，進?步降低硬件成本。從0構建企業知識庫，可能沒你想的那么簡單點擊鏈接閱讀原?：實踐分享｜從0構建企業知識庫，可能沒你想的那么簡單閱讀提示很多企業都在構建私有知識庫，輔助AI?模型提供企業級服務。不過想要訓練AI完美理解企業內部知識并輸出符合預期的內容，可能需要反復地調優測試。近期，SmartX研發團隊從企業內部培訓場景出發，讓AI?模型基于內部知識庫進?“考試”，并通過多種調優?式提升模型考試成績。在實驗過程中，我們沒有使?Dify等封裝后的?具，?是基于最基礎的LLMAPI調??式進?實現，希望可以讓讀者更好地觀察其中的細節。

很多企業都在構建私有知識庫，輔助AI?模型提供企業級服務。不過想要訓練AI完美理解企業內部知識并輸出符合預期的內容，可能需要反復地調優測試。近期，SmartX研發團隊從企業內部培訓場景出發，讓AI?模型基于內部知識庫進?“考試”，并通過多種調優?式提升模型考試成績。在實驗過程中，我們沒有使?Dify等封裝后的?具，?是基于最基礎的LLMAPI調??式進?實現，希望可以讓讀者更好地觀察其中的細節。以下，我們將分享上述實踐，并展示企業知識庫構建與調優過程中可能遇到的種種挑戰與應對策略。經驗?：構建企業??的Benchmark在搭建知識庫或進?模型測試前，我們認為先建??個??的Benchmark?常重要。雖然?模型在發布的時候都會提供?些基準的Benchmark，但這