MyGit

PassByYou888/Z-AI1.4

Fork: 8 Star: 12 (更新于 2024-11-04 03:59:26)

license: MIT

Language: Pascal .

Z-AI V1.4 发行版本

官方网址 GitHub网址

Z-AI V1.4 发行版本

简单介绍

  • 被ZNet,ZDB2,Code模型,AI-Tech2022,众多新技术体系加持
  • 相比1.3系,这是接近于重构的升级
  • 生产建模端工具链逼近400个
  • 接近150个AI相关Demo
  • 没有AI建模限制
  • 更多请阅读 详情

开源项目定位

开源版本可以自由获取,自由建模,自己解决识别问题,而项目框架设计,底座和平台化,落地等环节并不开源,也不提供文档

1.4 AI算法体系

算法体系由算法api+算法支持组成,算法支持是指运行算法条件,例如建模系统,算法应用思路,比如dnn-thread系统就是一种算法支持,样本数据库也是一种算法支持,基于样本数据库搭建的建模工具也是一种支持.

算法api这一部分就是大家在git接触各种CV+识别性质的开源项目.ZAI会有些自主创新,而算法思路和方向,与这些开源项目基本算一致,甚至一些开源项目比ZAI的算法更加先进,识别率也会更高.看开源项目是看更新强度,持续的强更新才能真正推进到社会生产和应用,否则会被时间洗掉.

在ZAI的早期版本(1.2/1.3),一直很注重算法体系的建设,基本每次更新,都会增加一大堆新算法.后来做完发行版本以后,这些算法加在一起,已经可以等同于数十个开源项目了,同时这些算法大部分都没有被应用.这就很尴尬!因为应用最多的只有,目标检测,目标分类,场景分类,其余算法基本不会应用,即使再增加几十种算法,也不会改变什么,例如把yolov7加进来也会一样.在计算引擎集成多个同性质算法无意义,这并不会改变应用模式,也不会改变建模成果和项目成败.

算法与实际项目的匹配性其实非常小,而我们通过百度,虹软,商汤,这类公司使用的AI方案都是挖空心思做出来的,这并不是算法层面的.这些公司,他们有自己的技术体系,以及,应用层思路,算法是一种资源,算法的命运是被技术体系筛选和重构.算法的方案性占比非常小.算法周边的体系,这才是AI类公司赖以生存的核心.换个角度来说,AI公司靠时代红利生存,算法是AI公司吃下去的食物,框架和算法支持体系是AI公司的消化系统,最后,产出各种应用方案.

明确了算法的本质定位以后,回到ZAI的算法体系中,算法的核心是算法支持体系,在此之后,才是建立应用层框架落地.

ZAI的算法支持体系部分,经历了3年洗礼,现在,ZAI正在走出自己的路线.

1.4 AI数据库体系

AI数据库体系只能适用建模体系,例如场景分类器的样本最少也会上万张720p/1080p,稍微堆大一点,这些样本回答道百万级规模.这时候,大数据管理,高效存取必须使用服务器硬件设备,例如大内存,>20核的cpu.这对于数据库技术有一定要求.

AI数据库体系并不是传统数据库,而是程序级的数据结构,这些数据结构一律支持多线程加速,以及Large-Scale(TB级大数据支持体系).传统mis/erp开发用的pc无法适应AI数据库:样本规模一旦大了,内存就不够了,必须精简or使用Large-Scale方式来管理数据库,这会导致浪费大把时间去干一些和硬件较劲的无意义工作.

AI数据库结构=适应所有的模型的数据要求的+样本链结构+样本链矩阵结构

AI数据库体系=Z.AI.Common(AI数据库)+Z.AI.Editor(AI工具链副本数据库)+*.dproj(整个建模工具链体系,大约20-30个建模支持工具),这些数据库在存储底层大量使用DFE,ZDB1,ZDB2工具形式支持库.

AI数据库体系不区分目标模型,但凡模型凡需要的数据都会在AI数据库体系对应支持,这些支持包括API支持,规范化支持,工具链支持.

1.4 AI工具链体系

由于项目的开发,AI工具链一直作为内部版本在更新.

撰写本文时,工具链已经构建了接近150个版本,历经大量修复+更新.

版本计数历史自1.4 Eval1..Eval9(这里走了90%版本数量)

之后, Beta1..Beta3(这时候,已经逼近2023-6月出发行版本时间计划)

1.4 AI平台和底座类体系

提示:开源版本不包含平台支持技术

简单来说:只能使用AI建模和识别,应用落地靠自己解决

1.4 引入ZDB2体系

首先,明确ZDB2的未来使用路线:大数据底层地基

其次,明确大数据问题solve:数据库引擎必须遵守计算机机理,数据库应用场景永远不确定,数据库不会是一套体系解决一切数据问题,ZDB2认为:解决数据库问题就要自己设计数据库引擎,在所有的项目中都要使用独特自主设计的数据库引擎.

ZDB2体系的技术路线推进回顾

  1. 给出ZDB2底层空间表支持系统:解决数据块的增删存改问题
  2. 在空间表支持系统基础上,尝试过小规模应用,例如C4系统中的UserDB,FileDB,效果平平
  3. 开始自我反思,之后,给出了线程化存储引擎体系,从底层机制来看待,ZDB2此时已经具备大规模存储支持能力.
  4. 支持了线程化存储引擎后,在落地项目应用,将数据库构建与数据中心服务器群集.
  5. 在数据中心运营过程,ZDB2被地狱级难度洗礼,同时也具备了新属性,包括可扩展性,数据安全性,增强自定义数据库设计.在6代监控系统,ZDB2完成了单日PB级数据量驱动,在无人维护环境中持续3个月不重启,不关机.
  6. 走出地狱,面向阳光,坚持走数据库=自定义数据引擎的底层逻辑.

ZDB2的后续动作:未来会持续更新

暂时没有放到前台推广计划,但会开源ZDB2,也会提供一些相关Demo.底层逻辑是因为我是程序员,我与世界的关系就是世界需要我的贡献,同时世界也在随时计算和剽窃我,但世界不能阻挡我的贡献行为,长久以来我和世界都是一种相互踩平衡木的关系,这也是只开源技术,而不开源项目的初衷:拥抱技术,建立开源过滤机制.

因为ZDB2具备了大数据支持能力,未来高几率会在某些条件成立时,在底层会给出非常棒的数据地基.只有自定义数据引擎才能胜任一切需求.

1.4 引入并大幅优化ZNet体系

ZNet代表整个后台服务器体系,以ZNet为基础的上层架构.

从宏观来看,C4体系+ZDB2体系+BigList体系+Core体系

这套组合拳只能在1.4或未来的版本使用.

ZDB2后台系统的数据引擎是独特的,ZNet后台服务器几乎全部工作于线程模型(凡处理延迟大于100ms的请求都用线程拉),BigList体系为数据链带来大容量提升,C4为服务器后台提供了高级架构.

pas圈子有许多以设计模式为工作路线的程序员,他们为广大入门者带来了傻瓜化的后台框架,他们有非常深厚的计算机理论基础.这造成了一个局面:使用者和设计者是依赖关系,不是完全性互相依赖,当设计者不能自我提升时,使用者就会被动.反应在真实生活和工作中就是当世界出现新事物的征兆,有许多人发现了它,但设计者无法驾驭,导致位于设计者下游的使用者无从下手.

以delphi厂商的某些程序员+设计者为例,他们的工作是维护和开发delphi.我在2016年时看见他们还在折腾opengl入门,显然错过了open1.x(固管) -> open2.0(可编程管线)的历史性升级时代,delphi通过商业路线收购dxscene,fmx被提上前台,这是被动行为,这并不是开创型做法.如果设计者在半路上出现自我局限,项目无法达标,使用者就会非常非常被动.

总结:ZNet代表未来整个后台服务器体系,保持开放,保持升级更新.

1.4 引入并优化计算机图形学体系

DrawEngine简称DE,定位是轻量+标准化,它需要渲染输出接口.位于前端用户层.

图形API标准源自Khronos,软硬厂商也会有自己的规范,这些规范,大都反应在像素排列,像素优化,api优化这些机制上.

同时图形api也有许多标准,metal,opengl,gles,vulkan,d3d,这就造成了一种局面:渲染器要兼容各种平台和api,需要大量接口,并且这些接口升级更新非常快,这让渲染引擎的开发和维护变得不容易了.DE在设计定位直接避开了前面的标准接口和平台化,做中间件:渲染api差异大没事,渲染器能在目标平台把至少一种api体系支持到位那就没问题.

FMX的底层是一种渲染器,对于多平台api支持程度,其实做的是可以的,用来设计游戏,VR都是没问题的.DE是把FMX当成输出接口来用,但不会局限于FMX.DE不是渲染器定位.

DrawEngine的应用并不是直接让程序写完流程,因为渲染需要数据来源,例如,视频,图片,各种可视线框,大多时候,这要工具链,后台,内容生产这类体系来支撑.纯代码路线无法驾驭.

另一方面,DE有一定计算机图形学的全局视野.它走了自己路线.

在1.4更新中,DrawEngine的渲染调度能力被大幅优化.

计算机图形学solve组成部分

光栅系统

  • Agg分支:以Agg命名开头的体系库,给出了线条平滑性solve
  • 投影分支:由光栅字体分支,尺度化,api支持分支共同组成
  • CV分支:形态学分支,像素分割分支,共同组成

渲染系统

  • 文本渲染:彩字,倾斜字,自定义字,脚本化文本
  • 图片渲染:没输出接口走光栅流程,有输出接口走渲染器流程
  • 线框绘制和填充:以原子操作,点,线,园,扩展一堆高级api
  • 命令队列:就是把渲染api调用,和物理输出api绘制分离开,用至少两个线程提速
  • 粒子:粒子是个重要分支,做特效,视觉方向使用
  • 运动引擎:运动是渲染引擎必须支持子系统,作用是统一规范,减少实现运动化渲染代码工作,运动引擎是在1.4新引入的分支
  • 场景支持:如果复杂项目,例如,2d游戏,AI建模系统,场景是渲染引擎的必须支持的标准规范,在DE中场景化渲染以DrawInScene这类api来使用

部署与编译

  1. 首先部署建模工具链, 开源版工具链体系确定可完成自主建模 建模与生产工具链部署
  2. 准备好计算引擎 计算引擎部署
  3. 编译说明 编译说明

部署AI-Demo运行数据

  • AI-Demo所需运行数据,将数据解压到"Z-AI1.4\AI-demo\Binary"目录 下载 云和解压密码均为8888
  • 先解压运行数据,再用计算引擎覆盖,颠倒顺序可能导致结果无法预料

建模入门与指引

请阅读: 1.34老版本文档

gpu支持性

请阅读: 详情

delphi编译结果(编译测试版本XE10.4.2与XE11.3)

架构 AI-Demo tools Net-tools Net-Advance-Demo Net-C4-Demo Net-demo
x86 Passed Passed Passed Passed Passed Passed
x64 Passed Passed Passed Passed Passed Passed
MKL64 Passed Passed Passed Passed Passed Passed
CUDA10 Passed Passed Passed Passed Passed Passed
CUDA11 Passed Passed Passed Passed Passed Passed
CUDA12 Passed Passed Passed Passed Passed Passed

fpc编译结果

fpc编译器测试通过source目录中的全部库,source目录子目录为平台关联性,fpc不支持

有问题可到zAI机器学习群提出

  • qq群号811381795
  • 也可以直接加作者qq600585

2023-7-26

最近版本更新:(数据更新于 1970-01-01 00:00:00)

主题(topics):

a100, ai, cv, delphi, gpu, h100, idc, opencv, pascal, server, z-ai

PassByYou888/Z-AI1.4同语言 Pascal最近更新仓库

2024-10-05 14:14:40 JAM-Software/Virtual-TreeView

2020-07-29 03:07:05 quoe/SteamHelper

1970-01-01 00:00:00 CKdiy/simple_broadcaster_observer

1970-01-01 00:00:00 zhugecaomao/HexEditor

1970-01-01 00:00:00 synopse/SynPDF

1970-01-01 00:00:00 marcopin/NewDicomPACS