JiaHe - 家和的学习分享

相遇即是缘

发表于 分类于 本文字数： 868 阅读时长 ≈ 3 分钟

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

阅读全文 »

发表于 分类于 本文字数： 674 阅读时长 ≈ 2 分钟

在选择 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. 你的决策表

显存（VRAM）建议选择评价
> 32GBQ8_0 或 BF16壕无人性，直接满血
24GBQ6_K完美平衡，无损体验
16GB - 20GBQ4_K_M 或 Q5_K_S最推荐，性价比最高
12GB - 16GBQ3_K_M 或 IQ4_XS稍有损耗，但依然可用
< 12GBIQ2_M仅做演示，不建议生产

发表于 分类于 本文字数： 487 阅读时长 ≈ 2 分钟

如果你使用标准的 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 文件，如何挑选最完美的那张？

优先级特征说明
P0targetsize-256高清分辨率首选。
P1unplated核心要求：必须无底板。
P2scale-400 / scale-200如果没有 256px，则寻找高缩放倍率的 Logo。
P3AppList / Logo语义关键词，通常代表应用主图标。

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 提供的合成图，不如直接潜入应用的资源目录，利用文件系统层面的规律挑选出最纯净的原始资源。

发表于 分类于 本文字数： 431 阅读时长 ≈ 2 分钟

快捷方式（.lnk）是 Windows 桌面的基石。提取它的图标和元数据（如备注）需要深入 Win32 COM 接口。

1. 解析 LNK 元数据

要获取快捷方式指向的路径或用户定义的描述，需要使用 IShellLinkW 接口。

核心步骤

  1. 创建实例：CoCreateInstance(&ShellLink, ...)。
  2. 加载文件：通过 IPersistFile 接口调用 Load 方法加载 .lnk 路径。
  3. 读取描述：调用 GetDescription 获取用户在属性窗口中填写的“备注”。

2. 提取图标：从 ShellItem 到 Base64

直接读取 .ico 文件可能不准确，因为很多应用使用内部资源索引。最稳健的方法是利用 Shell 的缩略图缓存接口。

技术实现：IShellItemImageFactory

  1. 转换为 IShellItem：将路径转换为 Shell 项目。
  2. 请求图像：转型为 IShellItemImageFactory，调用 GetImage。
    • 标志位：使用 SIIGBF_BIGGERSIZEOK | SIIGBF_ICONONLY 获取原始质量的图标。
  3. 处理 HBITMAP：
    • 将 HBITMAP 像素数据读入缓冲区。
    • 特别注意：许多 Windows 图标只有 RGB 通道，Alpha 通道全为零。如果检测到所有 Alpha 均为 0，需要强制设置为 255（不透明），否则图标会“消失”。
  4. 编码：将图像编码为 PNG 的 Base64 字符串，方便前端 <img> 标签直接展示。

3. 常见陷阱

  • COM 线程模型：操作 Shell 接口前必须初始化 CoInitializeEx（建议使用 COINIT_APARTMENTTHREADED）。
  • 内存泄漏：HBITMAP 和 CoTaskMem 分配的内存必须手动释放。
  • 图标尺寸：请求 64x64 或 128x128 通常能获得兼顾性能与清晰度的结果。

4. 结语

通过 Shell API 提取图标不仅能获得最准确的图像（包含叠加层），还能利用 Windows 的图像缓存，是构建高效启动器的不二之选。