Z AI1.4
1.0.0
บทนำสั้น ๆ
เวอร์ชันโอเพ่นซอร์สสามารถรับได้อย่างอิสระสร้างแบบจำลองได้อย่างอิสระและแก้ไขปัญหาและระบุด้วยตนเอง การออกแบบกรอบโครงการฐานและแพลตฟอร์มและการใช้งานไม่ใช่โอเพ่นซอร์สและไม่ได้จัดทำเอกสาร
ระบบอัลกอริทึมประกอบด้วยอัลกอริทึม API + การสนับสนุนอัลกอริทึม การสนับสนุนอัลกอริทึมหมายถึงการเรียกใช้เงื่อนไขอัลกอริทึมเช่นระบบการสร้างแบบจำลองแนวคิดแอปพลิเคชันอัลกอริทึมเช่นระบบ DNN-thread ซึ่งเป็นระบบสนับสนุนอัลกอริทึมฐานข้อมูลตัวอย่างยังเป็นอัลกอริทึมสนับสนุนและเครื่องมือสร้างแบบจำลองที่สร้างขึ้นตามฐานข้อมูลตัวอย่าง
อัลกอริทึม API เป็นส่วนหนึ่งของโครงการโอเพ่นซอร์สที่มีคุณสมบัติการจดจำ CV+ ต่างๆใน Git Zai จะมีนวัตกรรมอิสระบางอย่างและแนวคิดและทิศทางอัลกอริทึมนั้นสอดคล้องกับโครงการโอเพนซอร์สเหล่านี้ โครงการโอเพ่นซอร์สบางโครงการมีความก้าวหน้ามากกว่าอัลกอริทึมของ Zai และมีอัตราการรับรู้ที่สูงขึ้น เมื่อดูที่โครงการโอเพนซอร์สเราดูความเข้มของการอัปเดต มีเพียงการอัปเดตที่แข็งแกร่งอย่างต่อเนื่องเท่านั้นที่สามารถก้าวไปสู่การผลิตและแอปพลิเคชันทางสังคมอย่างแท้จริงไม่เช่นนั้นจะถูกล้างออกไปตามกาลเวลา
ในรุ่นแรก ๆ ของ Zai (1.2/1.3) ฉันให้ความสนใจอย่างมากกับการสร้างระบบอัลกอริทึม โดยทั่วไปทุกครั้งที่ฉันอัปเดตจะมีการเพิ่มอัลกอริทึมใหม่จำนวนมาก ต่อมาหลังจากรุ่นที่วางจำหน่ายเสร็จสิ้นอัลกอริทึมเหล่านี้สามารถเทียบเท่ากับโครงการโอเพนซอร์สหลายสิบโครงการและอัลกอริทึมเหล่านี้ส่วนใหญ่ยังไม่ได้ใช้ นี่มันน่าอาย! เนื่องจากแอปพลิเคชันส่วนใหญ่เป็นเพียงการตรวจจับเป้าหมายการจำแนกเป้าหมายการจำแนกฉากและอัลกอริทึมอื่น ๆ จะไม่ถูกนำไปใช้ แม้ว่าจะมีการเพิ่มอัลกอริทึมหลายสิบครั้ง แต่ก็จะไม่เปลี่ยนแปลงอะไรเลย ตัวอย่างเช่นมันจะเหมือนกันเมื่อเพิ่ม YOLOV7 มันไม่มีความหมายที่จะรวมอัลกอริธึม-ธรรมชาติหลายตัวเดียวกันในเอ็นจิ้นคอมพิวเตอร์ สิ่งนี้จะไม่เปลี่ยนรูปแบบแอปพลิเคชันและจะไม่เปลี่ยนผลลัพธ์การสร้างแบบจำลองและความสำเร็จของโครงการหรือความล้มเหลว
การจับคู่ระหว่างอัลกอริทึมและโครงการจริงนั้นมีขนาดเล็กมากและโซลูชั่น AI ที่เราใช้ผ่าน Baidu, Hongruan, Sensetime ฯลฯ ล้วนทำด้วยความพยายามอย่างมากซึ่งไม่ได้อยู่ในระดับอัลกอริทึม บริษัท เหล่านี้มีระบบทางเทคนิคของตนเองและแนวคิดระดับแอปพลิเคชัน อัลกอริทึมเป็นทรัพยากรและชะตากรรมของอัลกอริทึมได้รับการคัดกรองและสร้างใหม่โดยระบบเทคนิค สัดส่วนของอัลกอริทึมมีขนาดเล็กมาก ระบบรอบอัลกอริทึมเป็นแกนหลักของการอยู่รอดของ บริษัท AI เพื่อให้เป็นอีกวิธีหนึ่ง บริษัท AI พึ่งพาเงินปันผลของเวลาอัลกอริทึมเป็นอาหารที่ บริษัท AI กินและระบบสนับสนุนกรอบและอัลกอริทึมเป็นระบบย่อยอาหารของ บริษัท AI และในที่สุดก็ผลิตโซลูชั่นแอปพลิเคชันต่างๆ
หลังจากชี้แจงการวางตำแหน่งที่สำคัญของอัลกอริทึมแล้วกลับไปที่ระบบอัลกอริทึม ZAI ซึ่งเป็นแกนหลักของอัลกอริทึมคือระบบสนับสนุนอัลกอริทึม หลังจากนั้นก็สามารถกำหนดกรอบการทำงานของเลเยอร์แอปพลิเคชันได้
ระบบสนับสนุนอัลกอริทึมส่วนหนึ่งของ Zai ได้รับบัพติสมาเป็นเวลาสามปี ตอนนี้ Zai กำลังใช้เส้นทางของตัวเอง
ระบบฐานข้อมูล AI สามารถใช้สำหรับระบบการสร้างแบบจำลองเท่านั้น ตัวอย่างเช่นตัวอย่างตัวจําแนกของฉากจะมีอย่างน้อยนับหมื่น 720p/1080p ใหญ่ขึ้นเล็กน้อยตัวอย่างเหล่านี้จะตอบระดับล้านระดับ ในเวลานี้สำหรับการจัดการข้อมูลขนาดใหญ่และการเข้าถึงที่มีประสิทธิภาพจะต้องใช้อุปกรณ์ฮาร์ดแวร์เซิร์ฟเวอร์เช่นหน่วยความจำขนาดใหญ่> 20 COR CPU สิ่งนี้มีข้อกำหนดบางประการสำหรับเทคโนโลยีฐานข้อมูล
ระบบฐานข้อมูล AI ไม่ใช่ฐานข้อมูลดั้งเดิม แต่เป็นโครงสร้างข้อมูลระดับโปรแกรม โครงสร้างข้อมูลเหล่านี้สนับสนุนการเร่งความเร็วแบบมัลติเธรดและขนาดใหญ่ (ระบบสนับสนุนข้อมูลขนาดใหญ่ระดับ TB) พีซีที่ใช้ในการพัฒนา MIS/ERP แบบดั้งเดิมไม่สามารถปรับให้เข้ากับฐานข้อมูล AI ได้: เมื่อขนาดตัวอย่างมีขนาดใหญ่หน่วยความจำก็ไม่เพียงพอและจะต้องมีความคล่องตัวหรือใช้วิธีการขนาดใหญ่ในการจัดการฐานข้อมูลซึ่งจะเสียเวลาไปกับการทำงานที่ไร้ความหมาย
โครงสร้างฐานข้อมูล AI = + โครงสร้างห่วงโซ่ตัวอย่าง + โครงสร้างเมทริกซ์โซ่ตัวอย่างที่ปรับให้เข้ากับข้อกำหนดข้อมูลของทุกรุ่น
ระบบฐานข้อมูล AI = z.ai.Common (ฐานข้อมูล AI) + z.ai.editor (ฐานข้อมูลการคัดลอก AI Toolchain) +*. DPROJ (ระบบการสร้างแบบจำลองทั้งหมดประมาณ 20-30 เครื่องมือสนับสนุนการสร้างแบบจำลอง) ฐานข้อมูลเหล่านี้ใช้ DFE, ZDB1 และ ZDB2 Libraries ที่ด้านล่างของชั้นจัดเก็บ
ระบบฐานข้อมูล AI ไม่ได้แยกความแตกต่างระหว่างโมเดลเป้าหมาย ข้อมูลใด ๆ ที่ต้องการโดยรุ่นจะได้รับการสนับสนุนตามระบบฐานข้อมูล AI การสนับสนุนเหล่านี้รวมถึงการสนับสนุน API การสนับสนุนที่เป็นมาตรฐานและการสนับสนุน Toolchain
เนื่องจากการพัฒนาโครงการ AI Toolchain ได้รับการปรับปรุงเป็นเวอร์ชันภายใน
ในช่วงเวลาของการเขียน Toolchain ได้สร้างเกือบ 150 เวอร์ชันซึ่งได้รับการซ่อมแซมและอัปเดตมากมาย
ประวัติความเป็นมาของเวอร์ชันคือ 1.4 eval1..EVAL9 (90% ของจำนวนเวอร์ชันหายไปที่นี่)
หลังจากนั้น Beta1..Beta3 (ในเวลานี้แผนเวลาวางจำหน่ายสำหรับ 2023-มิถุนายน)
เคล็ดลับ: เวอร์ชันโอเพ่นซอร์สไม่รวมเทคโนโลยีการสนับสนุนแพลตฟอร์ม
เพียงแค่ใส่: เฉพาะการสร้างแบบจำลอง AI และการรับรู้เท่านั้นและการใช้งานแอปพลิเคชันขึ้นอยู่กับของคุณเอง
ก่อนอื่นให้ชี้แจงเส้นทางการใช้งานในอนาคตของ ZDB2: รากฐานของข้อมูลขนาดใหญ่
ประการที่สองชี้แจงการแก้ปัญหาข้อมูลขนาดใหญ่: เอ็นจินฐานข้อมูลต้องปฏิบัติตามกลไกคอมพิวเตอร์สถานการณ์แอปพลิเคชันฐานข้อมูลไม่แน่นอนและฐานข้อมูลจะไม่เป็นระบบในการแก้ปัญหาข้อมูลทั้งหมด ZDB2 เชื่อว่าในการแก้ปัญหาฐานข้อมูลคุณต้องออกแบบเอ็นจิ้นฐานข้อมูลด้วยตัวเองและใช้เอ็นจินฐานข้อมูลการออกแบบที่เป็นเอกลักษณ์และเป็นอิสระในทุกโครงการ
ตรวจสอบการส่งเสริมเส้นทางทางเทคนิคของระบบ ZDB2
มันไม่ได้ถูกนำไปใช้ในแผนการส่งเสริมการขายเบื้องหน้าในขณะนี้ แต่มันจะโอเพนซอร์ส ZDB2 และจะให้การสาธิตที่เกี่ยวข้อง ตรรกะพื้นฐานเป็นเพราะฉันเป็นโปรแกรมเมอร์และความสัมพันธ์ของฉันกับโลกคือโลกต้องการการสนับสนุนของฉัน ในขณะเดียวกันโลกก็คำนวณและลอกเลียนแบบฉันได้ตลอดเวลา แต่โลกไม่สามารถหยุดพฤติกรรมการมีส่วนร่วมของฉันได้ เป็นเวลานานที่ฉันและโลกมีความสัมพันธ์ของการก้าวเข้าสู่คานสมดุล นี่เป็นความตั้งใจดั้งเดิมของเทคโนโลยีโอเพ่นซอร์สเท่านั้น แต่ไม่ใช่โครงการโอเพนซอร์ส: โอบกอดเทคโนโลยีและสร้างกลไกการกรองโอเพ่นซอร์ส
เนื่องจาก ZDB2 มีความสามารถในการสนับสนุนข้อมูลขนาดใหญ่ความน่าจะเป็นสูงในอนาคตจะให้รากฐานข้อมูลที่ดีมากที่ด้านล่างเมื่อมีเงื่อนไขบางประการ มีเพียงเครื่องมือข้อมูลที่กำหนดเองเท่านั้นที่สามารถตอบสนองความต้องการทั้งหมดได้
ZNET แสดงถึงระบบเซิร์ฟเวอร์แบ็กเอนด์ทั้งหมดซึ่งเป็นสถาปัตยกรรมระดับบนตาม ZNET
จากมุมมองของแมโครระบบ C4 + ระบบ ZDB2 + ระบบ BigList + ระบบหลัก
ชุดของการผสมผสานชุดนี้สามารถใช้ใน 1.4 หรือรุ่นอนาคตเท่านั้น
กลไกข้อมูลของระบบแบ็กเอนด์ ZDB2 นั้นไม่ซ้ำกัน เซิร์ฟเวอร์แบ็กเอนด์ ZNET เกือบทั้งหมดทำงานในรุ่นเธรด (ทุกคำขอที่มีความล่าช้ามากกว่า 100ms จะถูกดึงโดยเธรด) ระบบ BigList นำการปรับปรุงความจุขนาดใหญ่มาสู่การเชื่อมโยงข้อมูลและ C4 ให้สถาปัตยกรรมขั้นสูงสำหรับแบ็กเอนด์เซิร์ฟเวอร์
มีโปรแกรมเมอร์จำนวนมากในวงกลม PAS ที่ใช้รูปแบบการออกแบบเป็นเส้นทางการทำงานของพวกเขา พวกเขานำกรอบการทำงานแบ็คเอนด์ที่เหมือนคนโง่มาสู่ผู้เริ่มต้นส่วนใหญ่และพวกเขามีรากฐานทฤษฎีคอมพิวเตอร์ที่ลึกมาก สิ่งนี้ได้สร้างสถานการณ์: ผู้ใช้และนักออกแบบขึ้นอยู่กับการพึ่งพาซึ่งกันและกันอย่างสมบูรณ์และเมื่อนักออกแบบไม่สามารถปรับปรุงตัวเองได้ผู้ใช้จะอยู่เฉยๆ การไตร่ตรองในชีวิตจริงและการทำงานเป็นสัญญาณว่าสิ่งใหม่ ๆ ปรากฏในโลก หลายคนค้นพบมัน แต่นักออกแบบไม่สามารถควบคุมได้ซึ่งทำให้ผู้ใช้ตั้งอยู่ปลายน้ำของนักออกแบบไม่สามารถเริ่มต้นได้
นำโปรแกรมเมอร์และนักออกแบบของผู้ผลิต Delphi เป็นตัวอย่างงานของพวกเขาคือการรักษาและพัฒนา Delphi ในปี 2559 ฉันเห็นพวกเขายังคงพยายามเริ่มต้นกับ OpenGL และเห็นได้ชัดว่าพลาดยุคการอัพเกรดประวัติศาสตร์ของ Open1.x (Solid Tube) -> Open2.0 (Programmable Pipeline) Delphi ได้รับ DXScene ผ่านเส้นทางการค้าและ FMX ถูกนำไปที่ด้านหน้า นี่เป็นพฤติกรรมที่ไม่โต้ตอบซึ่งไม่ใช่การฝึกฝน หากนักออกแบบมีการ จำกัด ตัวเองระหว่างทางและโครงการไม่สามารถปฏิบัติตามมาตรฐานได้ผู้ใช้จะอยู่เฉยๆมาก
สรุป: ZNET แสดงถึงระบบเซิร์ฟเวอร์แบ็กเอนด์ทั้งหมดในอนาคตทำให้เปิดและอัปเดต
DrawEngine เป็นตัวย่อเป็น DE และการวางตำแหน่งของมันมีน้ำหนักเบา + มาตรฐานและต้องใช้อินเทอร์เฟซการแสดงผลและเอาต์พุต มันอยู่ในชั้นผู้ใช้ส่วนหน้า
มาตรฐานกราฟิก API มาจาก Khronos และผู้ผลิตซอฟต์แวร์และฮาร์ดแวร์จะมีข้อกำหนดของตนเอง ข้อมูลจำเพาะเหล่านี้ส่วนใหญ่สะท้อนให้เห็นในกลไกของการจัดเรียงพิกเซลการเพิ่มประสิทธิภาพพิกเซลและการเพิ่มประสิทธิภาพ API
ในเวลาเดียวกันกราฟิก API ยังมีมาตรฐานหลายอย่างคือโลหะ, OpenGL, GLES, Vulkan, D3D ซึ่งสร้างสถานการณ์: Renderer จำเป็นต้องเข้ากันได้กับแพลตฟอร์มและ APIs ต่างๆและต้องใช้อินเทอร์เฟซจำนวนมาก DE หลีกเลี่ยงอินเทอร์เฟซมาตรฐานก่อนหน้านี้และแพลตฟอร์มในการวางตำแหน่งการออกแบบและทำให้มิดเดิลแวร์: ไม่เป็นไรที่จะทำให้ตัวแสดงความแตกต่างและไม่มีปัญหาที่ผู้แสดงผลสามารถรองรับระบบ API อย่างน้อยหนึ่งระบบบนแพลตฟอร์มเป้าหมาย
ชั้นพื้นฐานของ FMX เป็นตัวแสดงผล สำหรับการสนับสนุน API แบบหลายแพลตฟอร์มมันเป็นไปได้ที่จะทำ มันถูกใช้ในการออกแบบเกมและ VR ก็ใช้ได้ DE ใช้ FMX เป็นอินเทอร์เฟซเอาต์พุต แต่จะไม่ จำกัด เฉพาะ FMX DE ไม่ใช่ตำแหน่งเรนเดอร์
แอปพลิเคชันของ DrawEngine ไม่อนุญาตให้โปรแกรมดำเนินการให้เสร็จสมบูรณ์โดยตรงเนื่องจากการเรนเดอร์ต้องใช้แหล่งข้อมูลเช่นวิดีโอรูปภาพและเฟรมภาพต่างๆ ส่วนใหญ่เวลานี้ต้องใช้ระบบเช่นห่วงโซ่เครื่องมือแบ็กเอนด์และการผลิตเนื้อหา ไม่สามารถควบคุมเส้นทางรหัสบริสุทธิ์ได้
ในทางกลับกัน DE มีมุมมองระดับโลกของกราฟิกคอมพิวเตอร์ ต้องใช้เส้นทางของตัวเอง
ในการอัปเดต 1.4 ความสามารถในการจัดตารางการแสดงผลของ DrawEngine ได้รับการปรับให้เหมาะสมอย่างมาก
ส่วนประกอบของการแก้ปัญหากราฟิกคอมพิวเตอร์
โปรดอ่าน: 1.34 เอกสารเวอร์ชันเก่า
กรุณาอ่าน: รายละเอียด
| สถาปัตยกรรม | ai-demo | เครื่องมือ | เครื่องมือสุทธิ | สุทธิ | Net-C4-Demo | สุทธิ-เดโม |
|---|---|---|---|---|---|---|
| x86 | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน |
| x64 | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน |
| MKL64 | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน |
| cuda10 | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน |
| cuda11 | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน |
| CUDA12 | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน | ผ่าน |
คอมไพเลอร์ FPC ทดสอบไลบรารีทั้งหมดในไดเรกทอรีต้นฉบับ ไดเรกทอรีย่อยไดเรกทอรีแหล่งที่มาคือความสัมพันธ์ของแพลตฟอร์ม FPC ไม่รองรับ
เกิน
2023-7-26
