JiaHe - 家和的学习分享

新建 /etc/yum.repos.d/mysql-community.repo

[mysql-connectors-community]
name=MySQL Connectors Community
baseurl=https://mirrors.tuna.tsinghua.edu.cn/mysql/yum/mysql-connectors-community-el9-$basearch/
enabled=1
gpgcheck=1
gpgkey=https://repo.mysql.com/RPM-GPG-KEY-mysql
       https://repo.mysql.com/RPM-GPG-KEY-mysql-2022
       https://repo.mysql.com/RPM-GPG-KEY-mysql-2023

[mysql-tools-community]
name=MySQL Tools Community
baseurl=https://mirrors.tuna.tsinghua.edu.cn/mysql/yum/mysql-tools-community-el9-$basearch/
enabled=1
gpgcheck=1
gpgkey=https://repo.mysql.com/RPM-GPG-KEY-mysql
       https://repo.mysql.com/RPM-GPG-KEY-mysql-2022
       https://repo.mysql.com/RPM-GPG-KEY-mysql-2023

[mysql-8.4-community]
name=MySQL 8.4 Community Server
baseurl=https://mirrors.tuna.tsinghua.edu.cn/mysql/yum/mysql-8.4-community-el9-$basearch/
enabled=1
gpgcheck=1
gpgkey=https://repo.mysql.com/RPM-GPG-KEY-mysql
       https://repo.mysql.com/RPM-GPG-KEY-mysql-2022
       https://repo.mysql.com/RPM-GPG-KEY-mysql-2023

dnf cache all
dnf makecache
dnf install -y mysql-community-server

在微调过程中，max_seq_length 是一个至关重要的参数，它决定了模型单次处理文本的“视野”范围。以下是它的具体作用及对显存、性能和效果的影响：

¶1. 核心作用：定义窗口大小

max_seq_length 规定了输入模型（包括 System Prompt + User Prompt + Assistant Output）的总 Token 数量上限。

• 截断机制：如果你的输入文本超过这个长度，超出部分会被直接丢弃（Truncation）。
• 填充逻辑：对于短于此长度的文本，训练器会进行填充（Padding），使数据对齐以方便 GPU 进行批处理。

¶2. 对显存 (VRAM) 的决定性影响

显存消耗与序列长度并非线性关系，而是呈平方级增加（因为注意力机制计算量为 $O(n^2)$）。

• 显存占用：max_seq_length 从 2048 增加到 4096，显存开销会大幅跳升。
• Unsloth 优化：Unsloth 通过 Flash Attention 等技术降低了显存增长的斜率，使得在 T4 这种 16GB 显存的显卡上能够跑更长的上下文。

¶3. 性能与速度的权衡

• 训练速度：长度越短，单步训练（Step）的速度越快。如果你只需要提取简短的合同摘要，将 4096 改为 1024 能节省大量时间。
• 吞吐量：较小的长度允许设置更大的 per_device_train_batch_size，从而提升 GPU 利用率。

¶4. 对 IDP（要素提取）任务的影响点

在你的文档处理场景中，设置不当会导致以下问题：

• 提取不全：如果你处理的是长达 10 页的法律文书（约 6000 Token），但设置 max_seq_length = 2048，模型将永远看不见文档后半部分的信息，导致提取出的 JSON 字段为 null 或出错。
• 格式损毁：如果 assistant 的 JSON 输出刚好在末尾被截断，会导致导出的 JSONL 文件损坏，影响微调质量。

¶💡 针对你的 Qwen3-4B 设置建议

1. 通常推荐 2048：这能覆盖绝大多数简历、发票和短篇法律合同。
2. 显存压力：如果在 Colab T4 上出现 Out of Memory，优先降低 max_seq_length（例如降到 1024）或开启 use_gradient_checkpointing。
3. 动态匹配：检查你生成的 data.jsonl 中最长的一行有多少 Token。建议设置略大于该长度的值，以保证信息完整。

简单来说，长度要够用，但不能浪费——够用保证准确，不浪费保证训练效率。

在 LLM（大语言模型）和微调的语境下，max_seq_length 既不是字节（Byte），也不是字符（Character），而是 Token（标记/词元）。

¶1. 什么是 Token？

Token 是大模型处理文本的最小单位。

• 对于英文：通常一个 Token 约等于 0.75 个单词（Word），或者约 4 个英文字符。
• 对于中文：由于中文的特殊性，Qwen3 采用的是基于字节对编码（BPE）的词表。通常情况下，1 个汉字 ≈ 1 到 1.5 个 Token。

¶2. 长度单位对比

为了方便你在 IDP 任务中估算，可以参考下表：

¶3. 为什么是 Token 而不是字符？

• 压缩效率：模型通过 Token 将常用词组（如“中华人民共和国”）压缩成一个或少数几个数字，从而提高处理效率。
• 计算限制：模型的注意力机制（Attention）矩阵是基于 Token 数量进行计算的，显存占用直接与 Token 数量的平方相关。

¶4. 你的 IDP 任务如何换算？

如果你要处理一份 3000 字的法律合同：

1. 汉字与标点：约 3000 字符。
2. 转换为 Token：大约需要 4000 - 4500 个 Token。
3. 结论：如果你设置 max_seq_length = 2048，这份合同在训练或推理时会被截断掉一半以上的内容。

建议做法：

如果你不确定自己的数据长度，可以在 Colab 中运行以下代码来查看你最长的一条数据有多少个 Token：

token_counts = [len(tokenizer.encode(text)) for text in dataset["text"]]
print(f"最长数据 Token 数: {max(token_counts)}")

根据这个输出结果来设置你的 max_seq_length，既能保证数据不被截断，又能最大化节省显存。

llama-bench 是 llama.cpp 自带的基准测试工具，用于评估大语言模型（LLM）在特定硬件环境下的推理性能。通过它，我们可以量化硬件的算力边界、显存带宽瓶颈以及并发处理能力。

在选择 LLM（大语言模型）的量化版本时，本质是在 “智力（精度）”、“速度” 和 “显存容量” 之间做权衡。

对于你列出的这些 Qwen3-4B 模型版本，选择逻辑可以参考以下“金字塔”法则：

¶1. 核心选择准则

• 4-bit 是黄金平衡点： 它是目前社区公认的性价比最高的量化等级。
• 6-bit 以上边际效应递减： 超过 6-bit 后，智力提升极小，但显存占用大幅增加。
• 3-bit 以下智力崩塌： 除非你的显存实在太小，否则不建议使用 2-bit，因为它会导致模型逻辑混乱、胡言乱语。

¶2. 不同场景下的最佳推荐

¶场景 A：追求极致性能与智力（生产环境/逻辑推导）

如果你正在处理复杂的 Java 架构设计或 Rust 代码审查，且显存充足：

• 首选：Q6_K 或 Q5_K_M
  • 理由： 它们与原始 BF16 模型的智力差距几乎可以忽略不计（困惑度增量极小），但体积减少了一半以上。
• 备选：Q8_0
  • 理由： 如果显存富余到没处花，可以用 8-bit，但其实体验上和 6-bit 区别不大。

¶场景 B：日常开发与平衡（最推荐）

如果你希望响应速度快，同时逻辑在线：

• 首选：Q4_K_M 或 IQ4_XS
  • 理由： Q4_K_M 是量化界的“标准答案”。它保留了模型约 99% 的智力，且推理速度非常快。
  • 注意： IQ4_NL (Importance Quant) 这种带 “I” 开头的版本，在低比特下比传统的 Q 精度更高。

¶场景 C：显存吃紧或尝试超大规模模型

如果你想在较小的硬件上运行更高参数（如把 7B 模型塞进 8GB 显存）：

• 首选：Q3_K_M
  • 理由： 3-bit 是能维持“正常交流”的底线。
• 避坑：2-bit (IQ2_XXS 等)
  • 理由： 除非你是为了科研或纯粹测试，否则 2-bit 无法胜任任何实际的开发任务。

¶3. 名词简要科普

• Q (Quantization)： 传统的量化方式。
• IQ (Importance Quantization)： 这种方式会根据权重的重要性进行非均匀量化，同样的体积下，IQ 比 Q 聪明。
• K (K-Quants)： 采用块级量化的技术，通常 _M（Medium）代表中等大小，_S（Small）代表略小。
• UD (Un-Distilled/Unified)： 通常指未经蒸馏或采用统一权重分布的版本。

¶4. 你的决策表

如果你使用标准的 Shell API 获取 UWP 应用图标，往往会得到一个带有系统主题色（通常是蓝色）背景的正方形图标。这在现代、极简的 UI 设计中显得非常突兀。

本文分享如何通过“暴力”搜索物理资源，还原 UWP 应用的透明高清图标。

¶1. 为什么会有蓝色背板？

Windows 为了让 UWP 图标在磁贴（Tiles）上看起来统一，会自动将应用提供的透明 Logo 合成到一个背景板上。我们要做的就是跳过这个合成过程。

¶2. 核心思路：从安装目录提取

每个 UWP 应用都有一个受保护的安装目录（通常在 C:\Program Files\WindowsApps）。

¶策略：递归资源搜索

1. 定位路径：通过 PKEY_AppUserModel_PackageInstallPath 拿到应用的物理根目录。
2. 目标目录：递归扫描根目录下的 Assets 和 images 文件夹。
3. 文件名匹配：UWP 图标有一套标准的命名规范：
   • targetsize-256：高清图标。
   • unplated：不带背板。
   • altform-unplated：另一种透明底变体。

¶3. 排序与权重算法

我们会搜到几十甚至上百个 PNG 文件，如何挑选最完美的那张？

¶4. 实战代码逻辑（Rust 为例）

// 伪代码：简化后的搜索逻辑
let mut candidates = search_pngs(vec!["Assets", "images"]);
candidates.sort_by(|a, b| {
    // 1. 优先 targetsize-256
    // 2. 优先 unplated
    // 3. 优先 scale-*
});
return read_and_convert_to_base64(candidates.first());

¶5. 总结

解决 UWP 图标问题的关键在于 “主动出击”。与其被动接受 Shell 提供的合成图，不如直接潜入应用的资源目录，利用文件系统层面的规律挑选出最纯净的原始资源。