2 使用Python训练和部署低精度模型 张校捷使用Python训练和部署低精度模型 (TensorFlow版) 张校捷 2019/9/21 目录 CONTENTS 低精度的概念和意义 TensorFlow的FP16模型 TensorRT的FP16/Int8模型 总结 1 低精度的概念和意义 实数的16-bit半精度浮点数和8-bit定点数表示 使用低精度的意义 深度学习模型中实数的表示 FP32: E8M23 FP16: FP16: E5M10 Int8 (TPU, tf.bfloat16) (tf.float32) (GPU, tf.float16) 低精度浮点数的优点 1.节约内存/显存的使用(FP16为原来的1/2,int8为原来的1/4) 2.特殊的硬件专门用于低精度浮点数的计算加速(TensorCore) Model Speedup BERT Q&A 3.3X speedup GNMT 1.7X FP16浮点数(E5M10)的表示范围 FP16模型的训练方法 Int8模型的推断过程 2 TensorFlow的FP16模型 实数的16-bit半精度浮点数和8-bit定点数表示 使用低精度的意义 TensorCores适用条件 1. 卷积:K(输入通道),C(输出通道) 2. 通用矩阵乘法(GEMM):MxK,KxN,(M,N,K) FP16: 大小为8x Int8: 大小为16x0 码力 | 24 页 | 981.45 KB | 1 年前3
OpenShift Container Platform 4.10 可伸缩性和性能禁用透明巨页 第 第 14 章 章 低延 低延迟节 迟节点的 点的 PERFORMANCE ADDON OPERATOR 14.1. 了解低延迟 14.2. 安装 PERFORMANCE ADDON OPERATOR 14.3. 升级 PERFORMANCE ADDON OPERATOR 14.4. 置备实时和低延迟工作负载 14.5. 使用性能配置集调整节点以实现低延迟 14.6. 使用 PERFORMANCE NIC 队列 14.7. 调试低延迟 CNF 调整状态 14.8. 为红帽支持收集调试数据延迟 第 第 15 章 章 为 为平台 平台验证执 验证执行延 行延迟测试 迟测试 15.1. 运行延迟测试的先决条件 15.2. 关于延迟测试的发现模式 15.3. 测量延迟 15.4. 运行延迟测试 15.5. 生成延迟测试失败报告 15.6. 生成 JUNIT 延迟测试报告 15.7. 在单节点 在单节点 OPENSHIFT 集群上运行延迟测试 15.8. 在断开连接的集群中运行延迟测试 15.9. 对 CNF-TESTS 容器的错误进行故障排除 78 78 78 80 80 82 83 84 87 87 87 90 90 92 92 94 94 94 95 96 96 96 100 100 100 101 103 104 106 106 1060 码力 | 315 页 | 3.19 MB | 1 年前3
万亿级数据洪峰下的消息引擎Apache RocketMQ未来展望 m w a l i b a b a - i n c . c o m ©2016 Alibaba Middleware Group n 历年双11消息数量变化 n 消息中间件核心链路 n 低延迟存储 n 容量保障 n 熔断机制 n 多副本高可用 10亿 百亿 千亿 5千亿+ 万亿+ 历年双11消息数量变化 2012双11 2013双11 2014双11 2015双11 2016双11 消息中间件分布式慢请求解法 01 02 低延迟分布式存储系统 在线熔断机制,秒级隔离 03 容量保障,限流 1.4万亿 低延迟分布式存储系统 – RocketMQ存储 Java Heap Lock Page Cache Disk Request Request Request Request Request Request 万级请求/秒/单机 1.4万亿 低延迟分布式存储系统 – 并发锁的开销 lReentrantLock/synchronized ØFair ØUnfair lLockSupport.unpark/park 1.4万亿 低延迟分布式存储系统 – PageCache真的那么快吗? 1.4万亿 低延迟分布式存储系统 – PageCache的毛刺现象分析 1.4万亿 低延迟分布式存储系统 – PageCache的毛刺现象分析 lMemory access latency issues: ØDirect0 码力 | 35 页 | 993.29 KB | 1 年前3
万亿级数据洪峰下的消息引擎 Apache RocketMQ未来展望 m w a l i b a b a - i n c . c o m ©2016 Alibaba Middleware Group n 历年双11消息数量变化 n 消息中间件核心链路 n 低延迟存储 n 容量保障 n 熔断机制 n 多副本高可用 10亿 百亿 千亿 5千亿+ 万亿+ 历年双11消息数量变化 2012双11 2013双11 2014双11 2015双11 2016双11 消息中间件分布式慢请求解法 01 02 低延迟分布式存储系统 在线熔断机制,秒级隔离 03 容量保障,限流 1.4万亿 低延迟分布式存储系统 – RocketMQ存储 Java Heap Lock Page Cache Disk Request Request Request Request Request Request 万级请求/秒/单机 1.4万亿 低延迟分布式存储系统 – 并发锁的开销 lReentrantLock/synchronized ØFair ØUnfair lLockSupport.unpark/park 1.4万亿 低延迟分布式存储系统 – PageCache真的那么快吗? 1.4万亿 低延迟分布式存储系统 – PageCache的毛刺现象分析 1.4万亿 低延迟分布式存储系统 – PageCache的毛刺现象分析 lMemory access latency issues: ØDirect0 码力 | 35 页 | 5.82 MB | 1 年前3
RISC-V 开放架构设计之道 1.0.0架构作为模型机的差别都不大,但是 RISC-V 基本指令集的小型浓缩化、功能指令集 的模块化、代码长度的可缩性、访存指令的简洁与灵活性、过程调用的简洁性、特权 模式的可组合性、异常/中断处理的简洁和灵活性,以及无分支延迟槽等诸多特性,都 使得采用 RISC-V 架构进行相关教学更能阐述清楚上层软件与指令集架构之间、指令 集架构与底层微架构之间的密切关系。 在过去数十年,我们一直跟踪国外一流大学计算机组成与系统结构相关课程的教 式中的立即数字段,可节省处理器设计的门电路数量;而 RISC-V 把全 0 指令作为非 法指令,则能让处理器更早捕捉到程序跳转到被清零内存区域的错误,从而降低此类 错误的调试难度;RISC-V 并未像 MIPS 那样采用延迟分支技术,是因为该技术违反 架构和实现分离的原则。同时,本书还介绍 x86、ARM 和 MIPS 的设计,并通过插 入排序和 DAXPY(双精度乘加)程序量化对比它们,突出 RISC-V 的优势,深入阐 第 8 章所介 绍,增长的主要原因是 x86 ISA 通过 SIMD 指令实现数据级并行。 AL 寄存器是默认的源寄存器和目的寄存器。 If AL 寄存器的低 4 位大于 9, 或辅助进位标志 AF 为 1, Then AL 的低 4 位加 6 且忽略溢出 AL 的高位字节加 1 进位标志 CF = 1 辅助进位标志 AF = 1 Else CF = AF = 0 AL 的高0 码力 | 223 页 | 15.31 MB | 1 年前3
RISC-V 手册 v2(一本开源指令集的指南)大部分成本来自于处理过 的晶圆本身。不太直观的是,晶粒越小,产率(生产出的可用晶粒所占的比例)越高。原因 在于目前的硅生产工艺会在晶圆上留下一些散布的小瑕疵。因此晶粒越小,有缺陷部分所占 比重会越低。 图1.4:由SiFive设计的直径为8英寸的RISC-V晶圆。 它有两种类型的RISC-V芯片,使用较旧的较大加工 线。 FE310芯片为2.65mm×2.72mm,SiFive测试芯片为2 不一定能保证性能。对于架构师来说, 为了在性能和成本上对某一特定时间的某种实现进行优化,而在 ISA 中包含某些指令,有时 候是一件有诱惑性的事情。但这样做会给其他实现或者今后的实现带来负担。 延迟分支是 MIPS-32 ISA 的一个令人遗憾的例子。条件分支导致流水线执行出现问题, 因为处理器希望下一条要执行的指令总是已经在流水线上,但它不能确定它要的到底是顺序 执行的下一条(如果分支未执 能导致流水线一个时钟周期的阻塞。 MIPS-32 通过把分支操作重新定义在分支指令的下一条指令执行完之后发生,因此分支指令 的下一条指令永远会被执行。程序员或编译器编写者要做的是把一些有用的指令放入延迟槽。 唉,这个“解决方案”对接下来有着更多流水级(于是在计算出分支结果之前取了更多 的指令)的 MIPS-32 处理器并无益处,反而让 MIPS-32 程序员,编译器编写者,以及处理 器设计者(因为增量0 码力 | 164 页 | 8.85 MB | 1 年前3
API7 ⽹关技术⽩⽪书ONWebToken、IP⿊⽩名单、OAuth等; 性能极⾼ 5. API7使⽤Radixtree算法实现⾼性能、灵活路由,在AWS8核⼼服务器中,QPS约为140K,延迟约 为0.2ms; 全动态能⼒ 6. 修改⽹关配置、增加或修改插件等,⽆需重启⽹关服务即可实时⽣效;⽀持动态加载SSL证书; 扩展能⼒强 7. 借助灵活的插件机制,可针对内部业 分析监控:API7内置了请求审计、监控告警、统计报表等分析监控功能,API⽹关将记录所有节点 每个请求的信息,并进⾏成功请求、异常请求统计,可在控制台查看请求成功数、请求失败数、错 误码、请求延迟等指标。此外,借助Grafana的能⼒,可满⾜更多维度地分析监控需求; • 全⽣命周期管理:API7⽀持API版本管理、API分组、API上下线、在线调试等功能,并兼容 OpenAPI3 ✖ ✖ ✖ ✅ ⽣成SDK和⽂档 ✔ ✖ ✖ ✖ ✅ 插件管理 动态新增、修改和删除插件 ✔ ✖ ✔ ✖ ❌ 插件编排(低代码) ✔ ✖ ✖ ✖ ❌ ⽀持Lua、Java和Go编写⾃定义插件 ✔ ✔ ✖ ✖ ❌ 安全 ⽤⼾相关 RBAC ✔ ✖ ✖0 码力 | 19 页 | 1.12 MB | 1 年前3
2022年美团技术年货 合辑测试时,每次只对一层进行量化,获取该层的激活数据后计算敏感度数值,代表了 该层的量化敏感度。作为对比,我们可以直接计算网络在 COCO val 数据集上的 mAP,使用检测精度作为该层的量化敏感度,即检测精度越高,该层敏感度越低(下 文称为 mAP 方法)。 算法 < 23 表 2 常用的量化敏感度计算方法及含义 测试结果如下图 5 所示,我们对测试结果进行归一化后,从不同敏感度分析结果中选 择敏感性最高的 6 层跳过,计算部分量化精度。 Prediction。它们都是时间序列 问题,前者是预测未来两天的污染物浓度以及变化,后者是预测未来几个小时高速 交通情况和变化。它们的共同点一是传统行业问题,实际意义强;二是存在各种突变 性、稳定性低;三是都涉及到多地域、多空间问题,需结合时空进行建模。它们的异 同点是污染物浓度突变需要一个短期时间才能发生,数据在突变时存在一定规律性, 但交通突变具有强偶发性,交通道路容易受到偶发性车祸、偶发性地质灾害等影响, 频次等方面存 在着较大差异;且高低频用户的点击行为分布差异明显,呈现出高频用户行为丰富聚 集、低频用户行为稀疏的特点。 对于高频用户,可能会导致兴趣圈封闭导致模型建模无法跳脱既有的兴趣圈;对于低 频用户,由于信息的缺乏导致其兴趣刻画不完整。因此,我们需要具备拓展用户兴趣 边界的信息扩展能力、对单点信息的扩充能力;即寻找一种新的数据结构,打破二维 线性限制,实现三维立体扩展,基于此种想法,我们从图的角度来重新思考用户行0 码力 | 1356 页 | 45.90 MB | 1 年前3
ffmpeg翻译文档一个粗略的估计值,最后还以一个空的字幕帧结束。 这个选项可能失败,或者出现夸张的持续时间或者合成失败,这是因为数据中有非单调递增的时 间戳。 注意此选项将导致所有数据延迟输出到字幕解码器,它会增加内存消耗,并引起大量延迟。 音频选项 高级音频选项 字幕选项 高级字幕选项 5 选项 - 25 - 本文档使用 书栈(BookStack.CN) 构建 -canvas_size size -dts_delta_threshold :时间不连续增量阀值。 -muxdelay seconds (input) :设置最大 解复用-解码 延迟。参数是秒数值。 -maxpreload seconds (input) :设置初始的 解复用-解码延迟,参数是秒数值。 -streamid output-stream-index:new-value (output) :强制把输出文件中序号为 出来的偏移。这一般用于具有不是从0开始时间戳的文件,例如一些传输流(直播下)。 -thread_queue_size size (input) :这个选项设置可以从文件或者设备读取的最大排队数据包数 量。对于低延迟高速率的直播流,如果不能及时读取,则出现丢包,所以提高这个值可以避免出 现大量丢包现象。 -override_ffserver (global) :对 ffserver 的输入进行指定。使用这个选项0 码力 | 502 页 | 3.06 MB | 1 年前3
APISEVEN 和Kong EE 的性能评测3-GigaOmAPI负载测试设置9 API压⼒测试9 测试环境10 单节点10 环境清单10 软件版本信息11 4-测试结果12 图2.空转时的压⼒测试API的基线延迟12 图3.API7与KongEE在20,000rps时的对⽐13 图4.API7与KongEE在10,000rps时的JWT对⽐。13 图5.API7与KongEE在10 署和 应⽤程序开发,且能降低计算成本的开销。 更重要的是,许多组织也依赖API和微服务来实现⾼性能和可⽤性。在本⽂中,我们将“⾼性能”定义 为每秒负载超过1000个交易且在整个API环境中最⼤延迟⼩于30毫秒。对公司⽽⾔,对性能的需求和 对管理的需求⼀样,因为公司依靠API交易速率来跟上业务发展速度。 API管理解决⽅案不能成为性能瓶颈。许多公司都在寻找跨多个API端点的负载均衡和⾼交易量吞吐的 000个请求的情况下, 99.99%的情况API7的延迟⽐KongEE低14倍。API7和KongEE⼆者百分⽐越⾼延迟差异越明显。在 我们所有的测试中,最⼤延迟差异体现得最明显的是达到99.9%和99.99%的请求时。 云上测试软硬件是⾮常具有挑战性的。在可⽤性、虚拟机处理器、内存、最佳输⼊/输出的存储、⽹络 延迟、软件和操作系统版本以及负载这些⽅⾯的配置可能会有利于其中⼀⽅。更具挑战性的是测试完0 码力 | 14 页 | 1.11 MB | 1 年前3
共 784 条
- 1
- 2
- 3
- 4
- 5
- 6
- 79













