标签： compression

发布于

Flutter 纹理压缩（Texture Compression）：ETC1/ASTC 格式在 GPU 上传中的应用

Flutter 纹理压缩：ETC1/ASTC 格式在 GPU 上传中的应用 大家好，今天我们来深入探讨 Flutter 中纹理压缩技术的应用，重点关注 ETC1 和 ASTC 格式，以及它们在 GPU 上传过程中的作用。在移动应用开发中，纹理是不可或缺的资源，但未经压缩的纹理会占用大量的存储空间和带宽，严重影响应用的性能和用户体验。纹理压缩技术能够有效地减小纹理文件的大小，从而提升应用的加载速度、降低内存占用和减少 GPU 渲染压力。 纹理压缩的必要性 移动设备上的纹理资源，特别是高清纹理，往往体积庞大。未经压缩的纹理直接上传到 GPU 会带来以下问题： 存储空间占用高： 大尺寸纹理会显著增加应用安装包的大小，占用用户的存储空间。 内存占用高： GPU 需要将纹理数据加载到显存中，占用宝贵的内存资源。 带宽消耗大： 在纹理上传过程中，需要传输大量数据，消耗网络带宽和电池电量。 渲染性能下降： GPU 处理未经压缩的纹理需要更多的时间和资源，导致渲染帧率下降，影响用户体验。 因此，纹理压缩是优化移动应用性能的关键步骤。通过使用合适的纹理压缩格式，可以显著减小纹理文件的大小，从而解决上述问 …

继续阅读“Flutter 纹理压缩（Texture Compression）：ETC1/ASTC 格式在 GPU 上传中的应用”

发布于

Context Compression（上下文压缩）：利用LLMLingua通过困惑度筛选关键Token

Context Compression：利用LLMLingua通过困惑度筛选关键Token 各位朋友，大家好。今天我们来深入探讨一个在大型语言模型（LLM）应用中至关重要的问题：上下文压缩。随着LLM处理能力的不断提升，我们能够输入的上下文长度也随之增加。然而，并非所有上下文信息都同等重要。冗余或无关的信息不仅会增加计算成本，还可能降低模型的性能，这就是所谓的“Lost in the Middle”现象。因此，如何有效地压缩上下文，保留关键信息，就变得至关重要。 今天，我们将重点介绍一种基于困惑度的上下文压缩方法，并使用LLMLingua框架来实现它。我们将从背景知识入手，逐步深入到代码实现和实验分析，希望能够帮助大家更好地理解和应用这一技术。 1. 上下文压缩的必要性与挑战 在深入技术细节之前，我们首先要理解上下文压缩为什么如此重要。想象一下，你正在使用一个LLM来回答关于某个文档的问题。这个文档可能长达数百页，包含了大量的信息。如果我们将整个文档都作为上下文输入到LLM中，可能会遇到以下问题： 计算成本高昂：LLM的处理时间和内存消耗与输入长度成正比。处理长文本会显著增加计算成本， …

继续阅读“Context Compression（上下文压缩）：利用LLMLingua通过困惑度筛选关键Token”

发布于

Tokenizer Compression Ratio：分词效率对推理延迟与上下文窗口利用率的定量关系

Tokenizer Compression Ratio：分词效率对推理延迟与上下文窗口利用率的定量关系 大家好，今天我们要深入探讨一个在大型语言模型（LLM）领域至关重要但经常被忽视的方面：Tokenizer的压缩率，以及它如何定量地影响推理延迟和上下文窗口利用率。我们将会看到，Tokenizer的选择不仅仅是一个简单的工具选择，而是一个直接影响模型性能、成本和效率的关键决策。 1. 引言：Tokenizer的重要性 在LLM的世界里，一切皆是数字。文本数据首先需要被转换成模型可以理解的数字形式，这个过程就是Tokenization。Tokenizer的任务是将原始文本分解成一个个独立的单元，即Token。这些Token可以是单词、子词（Subword）或字符。然后，每个Token会被映射到一个唯一的ID，形成模型的输入。 Tokenizer的设计直接影响以下几个关键方面： 词汇表大小（Vocabulary Size）： 词汇表越大，模型需要学习的参数越多，训练和推理的计算成本也越高。 Token序列长度： 相同的文本，不同的Tokenizer会产生不同长度的Token序列。序列越长， …

继续阅读“Tokenizer Compression Ratio：分词效率对推理延迟与上下文窗口利用率的定量关系”

发布于

上下文压缩（Context Compression）：利用AutoCompressor等模型学习压缩Token表征

上下文压缩：利用AutoCompressor等模型学习压缩Token表征 大家好，今天我们来深入探讨一个在大型语言模型（LLM）领域越来越重要的课题：上下文压缩，特别是利用AutoCompressor等模型学习压缩Token表征。随着LLM处理的上下文窗口不断增大，如何高效地利用有限的计算资源，同时保证模型性能，成为了一个关键挑战。上下文压缩正是在解决这个问题。 1. 上下文压缩的必要性 在深入技术细节之前，我们首先要理解为什么需要上下文压缩。现代LLM，比如GPT-4、Claude等，都拥有非常大的上下文窗口，可以处理成千上万个Token。这为模型带来了强大的能力，例如可以理解更长的文档、进行多轮对话、处理复杂的推理任务等。 然而，更大的上下文窗口也意味着更高的计算成本和内存需求。处理更长的序列需要更多的计算资源，而且并非所有的Token都同等重要。很多Token可能包含冗余信息，或者与当前任务无关。 因此，上下文压缩的目标就是在不显著降低模型性能的前提下，减少需要处理的Token数量，从而降低计算成本、提高推理速度。 2. 上下文压缩的几种主要方法 上下文压缩的方法多种多样，可以大 …

继续阅读“上下文压缩（Context Compression）：利用AutoCompressor等模型学习压缩Token表征”

发布于

`InnoDB` `Page` 的`压缩`与`解压`：`innodb_compression_level` 的`性能`权衡。

InnoDB Page 压缩与解压：innodb_compression_level 的性能权衡 大家好，今天我们深入探讨 InnoDB 存储引擎中 Page 压缩与解压，以及 innodb_compression_level 参数对性能的影响。Page 压缩是 InnoDB 优化存储空间利用率的关键技术之一，但同时也引入了额外的 CPU 开销。理解其工作原理，并根据实际场景选择合适的压缩级别，对于提升数据库整体性能至关重要。 1. InnoDB Page 压缩的背景与意义 在传统的数据库存储方式中，数据以固定大小的块（Page）为单位进行存储和管理。 InnoDB 默认的 Page 大小为 16KB。然而，并非所有的 Page 都能完全填满数据。特别是对于包含大量 VARCHAR 或 TEXT 类型字段的表，或者存在频繁的删除操作时，更容易产生碎片，导致存储空间浪费。 Page 压缩技术应运而生，其主要目的就是通过压缩 Page 中的数据，减少实际存储所需的空间，从而提高磁盘利用率，并有可能减少 I/O 操作，提升性能。 压缩带来的好处： 减少磁盘空间占用: 压缩后的 Page 占用 …

继续阅读“`InnoDB` `Page` 的`压缩`与`解压`：`innodb_compression_level` 的`性能`权衡。”

发布于

InnoDB 的数据页压缩（Page Compression）技术与实践

InnoDB 数据页压缩：让你的数据库瘦成一道闪电 ⚡️ 各位观众老爷们，大家好！我是你们的老朋友，人称“代码界的包拯”——专门负责给数据库瘦身的 Dr. Code！今天，咱们就来聊聊一个能让你的 InnoDB 数据库“减肥”成功的秘密武器：数据页压缩 (Page Compression)。 想象一下，你的数据库就像一个堆满了各种珍贵数据的仓库。随着时间的推移，仓库越来越拥挤，效率也越来越低。这时候，你就需要一个像我这样的“仓库整理师”，帮你把没用的东西扔掉，把有用的东西压缩起来，让仓库焕然一新！而 InnoDB 的数据页压缩，就是这个“压缩”环节的关键技术。 一、 什么是 InnoDB 数据页？ 🧱 要理解数据页压缩，首先要了解数据页的概念。在 InnoDB 存储引擎中，数据是以页为单位进行管理的。你可以把数据页想象成一个个砖块 (Page)，每个砖块的大小通常是 16KB。 这些砖块里存储着我们宝贵的数据记录（行），以及一些元数据（关于数据的数据）。InnoDB 通过 B+ 树索引组织这些数据页，形成一个高效的数据存储结构。 二、 为什么需要数据页压缩？ 😫 随着数据量的增长，数据 …

继续阅读“InnoDB 的数据页压缩（Page Compression）技术与实践”