Q: 为什么 GLiNER2 实体抽取会漏掉长文档中前 512 个词之后的实体？

修复前的版本在 GLiNER2 模型（`fastino/gliner2-base-v1`、`fastino/gliner2-large-v1`）上执行实体、关系和结构化抽取时，会在 `max_seq_length`（默认为 512 个词）处静默截断每个条目的文本，因此超出该窗口的内容永远无法到达模型。修复方法：升级到包含 PR #552（提交 `689e4d808cbd66008500da8f58d8fa6e71510b8f`）的构建版本。修复后，过长的条目会失败并返回明确的逐条目 `INPUT_TOO_LONG` 错误，而不再是静默的部分读取；被拒绝的条目会被排除在模型调用之外，并报告零输入 token 用量，而同一批次中其他有效的条目则保留其结果和原始位置。通过重叠窗口进行全文档抽取仍是一项尚未合并的增强功能（#649）——在该功能落地之前，请在调用 `POST /v1/extract/{model}` 之前，将长文档拆分为适合词/子词窗口大小的块。

Q: 升级到 gliner2 2.0.0 后，如何修复重复的 NER 实体和 'structured extraction property must be a string' 错误？

gliner2 2.0.0 以两种方式改变了 fastino/gliner2-base-v1 和 fastino/gliner2-large-v1 的输出：（1）NER 去重键从 text.lower() 改为 (text.lower(), start, end)，因此重复实体的每次提及都会被返回，而不再只返回第一个（实体数量可能会骤增，例如在长文本上从 21 → 100）；（2）结构化抽取会重新评分，某些字段现在返回 null，SIE 的 GLiNER2Adapter 会拒绝该结果并报错 GLiNER2 structured extraction property 'person' must be a string，导致整个请求失败。解决方法：将 gliner2 固定在 1.x 版本线（gliner2>=1.3.1,<2，即 1.3.2）——默认捆绑包和根锁文件就是这样处理的。注意：可选启用的实体 LoRA 适配器要求严格使用 gliner2 1.3.2，因此在 2.x 下会失效。如果必须运行 2.0.0，请自行按小写表层形式对实体去重以恢复 1.x 的行为，并处理 null 结构化字段（省略该属性或逐项报错），而不是让整个请求失败。将这些模型迁移到 2.x 仍在等待关于提及策略、null 处理和重新建立基线的决策。

Q: 如何修复在 macOS arm64 (Apple Silicon) 上通过 mmap 加载 safetensors 权重时 torch.nn.functional.linear 输出 NaN/Inf 的问题?

原因：在受影响的 macOS arm64 环境（例如 torch 2.9.1、Python 3.12）上，内存映射的 safetensors 张量可能起始于未对齐的地址（data_ptr % 64 != 0，因为该张量的文件偏移量未按 4/64 字节对齐）。将这样的映射权重传入 torch.nn.functional.linear 会产生非有限值（NaN/Inf）输出，即使权重、输入和偏置全部是有限的。解决方法：在使用前强制对权重做一次对齐的内存内复制 —— weight = weight.clone() —— 或者改用 safetensors.torch.load_file("model.safetensors") 加载检查点，而不是通过 safe_open 或惰性张量框架使用 mmap 视图。克隆之后，字节完全相同的权重会产生 0 个非有限值，并且与 float64 NumPy 参考结果一致（最大绝对误差约 5.2e-6）。要检查自己是否受影响，请查看 tensor.data_ptr() % 64：如果映射张量上该值非零，则表明存在风险。

Q: 为什么 GLiFormer 在短文本上的推理速度很慢，即使 GPU 大部分时间处于空闲状态？我该如何解决这个问题？

在短输入（40-140 tokens）下，GLiFormer 47 ms 的前向传播受限于 CPU 端的 kernel 启动开销：它会触发约 1,270 个小型 CUDA kernel，并伴随约 71 次流同步（其中 31 次来自任务头中的 `.item()` 调用），而 GPU 实际忙碌时间仅约 8 ms。修复方案是 CUDA graph 重放，在 PR #796 中实现，遵循了 #367 中 GLiClass 的做法：前向传播的静态部分（具有固定填充形状的 DeBERTa 主干网络）只录制一次，并作为 CUDA graph 重放，而具有数据依赖控制流的任务头则保持 eager 模式，读取 graph 的静态输出缓冲区。CUDA graphs 为可选功能，默认关闭——启用 'exact shapes' 模式即可，该模式通过了预训练一致性检查，输出与 eager 执行逐位相同。分桶（填充长度）模式被拒绝/不可用，因为它未能满足固定的数值容差限制。内存使用受每个模型的预算上限约束，同一时间只运行一次录制，在内存压力下会跳过录制，并在模型卸载时释放 graph 内存。

Question 1

为什么 Docker 镜像构建时安装的软件包版本比 uv.lock 锁定的版本更新，以及如何让 pip 安装可复现？

Accepted Answer

这种情况发生在镜像构建过程中运行带有范围版本约束的 `pip install -r`（例如 `gliner>=0.2.26,<1`）时：pip 会在构建时解析最新的匹配版本，从而覆盖 `uv.lock` 中锁定的确切版本，因此同一 commit 的两次构建可能会发布不同的、未经测试的版本。在 sie_server 中，此问题已通过 PR #653 和 #802 修复：bundle 镜像不再在构建期间解析版本范围，而是从 15 个已检入仓库的目标 lock 文件安装保存的依赖闭包，这些 lock 文件覆盖了全部 11 个已发布的 Linux amd64 镜像以及 4 个受支持的 CPU arm64 组合。除非存在明确记录在案的 bundle 例外情况，否则各包保持其根 `uv.lock` 中锁定的版本；CI 会拒绝过期或不一致的 lock 文件，镜像构建会验证并保留已安装的 `/app/bundle-libs` 清单（`pip freeze`），以便任何已部署的版本都可以被审计。要在你自己的项目中修复此问题：（1）使用 `uv export --frozen --no-hashes` 导出锁定的版本，并将其作为 constraints 文件传递给 pip（`pip install -c constraints.txt -r requirements.txt`），使锁定的包保持其固定版本；（2）或者为每个 bundle 维护单独的 lock 文件，将确切版本检入仓库；（3）在镜像内记录已安装目标目录解析后的 `pip freeze` 结果。

Question 2

为什么 GLiNER2 实体抽取会漏掉长文档中前 512 个词之后的实体？

Accepted Answer

修复前的版本在 GLiNER2 模型（`fastino/gliner2-base-v1`、`fastino/gliner2-large-v1`）上执行实体、关系和结构化抽取时，会在 `max_seq_length`（默认为 512 个词）处静默截断每个条目的文本，因此超出该窗口的内容永远无法到达模型。修复方法：升级到包含 PR #552（提交 `689e4d808cbd66008500da8f58d8fa6e71510b8f`）的构建版本。修复后，过长的条目会失败并返回明确的逐条目 `INPUT_TOO_LONG` 错误，而不再是静默的部分读取；被拒绝的条目会被排除在模型调用之外，并报告零输入 token 用量，而同一批次中其他有效的条目则保留其结果和原始位置。通过重叠窗口进行全文档抽取仍是一项尚未合并的增强功能（#649）——在该功能落地之前，请在调用 `POST /v1/extract/{model}` 之前，将长文档拆分为适合词/子词窗口大小的块。

Question 3

升级到 gliner2 2.0.0 后，如何修复重复的 NER 实体和 'structured extraction property must be a string' 错误？

Accepted Answer

gliner2 2.0.0 以两种方式改变了 fastino/gliner2-base-v1 和 fastino/gliner2-large-v1 的输出：（1）NER 去重键从 text.lower() 改为 (text.lower(), start, end)，因此重复实体的每次提及都会被返回，而不再只返回第一个（实体数量可能会骤增，例如在长文本上从 21 → 100）；（2）结构化抽取会重新评分，某些字段现在返回 null，SIE 的 GLiNER2Adapter 会拒绝该结果并报错 GLiNER2 structured extraction property 'person' must be a string，导致整个请求失败。解决方法：将 gliner2 固定在 1.x 版本线（gliner2>=1.3.1,<2，即 1.3.2）——默认捆绑包和根锁文件就是这样处理的。注意：可选启用的实体 LoRA 适配器要求严格使用 gliner2 1.3.2，因此在 2.x 下会失效。如果必须运行 2.0.0，请自行按小写表层形式对实体去重以恢复 1.x 的行为，并处理 null 结构化字段（省略该属性或逐项报错），而不是让整个请求失败。将这些模型迁移到 2.x 仍在等待关于提及策略、null 处理和重新建立基线的决策。

Question 4

如何修复在 macOS arm64 (Apple Silicon) 上通过 mmap 加载 safetensors 权重时 torch.nn.functional.linear 输出 NaN/Inf 的问题?

Accepted Answer

原因：在受影响的 macOS arm64 环境（例如 torch 2.9.1、Python 3.12）上，内存映射的 safetensors 张量可能起始于未对齐的地址（data_ptr % 64 != 0，因为该张量的文件偏移量未按 4/64 字节对齐）。将这样的映射权重传入 torch.nn.functional.linear 会产生非有限值（NaN/Inf）输出，即使权重、输入和偏置全部是有限的。解决方法：在使用前强制对权重做一次对齐的内存内复制 —— weight = weight.clone() —— 或者改用 safetensors.torch.load_file("model.safetensors") 加载检查点，而不是通过 safe_open 或惰性张量框架使用 mmap 视图。克隆之后，字节完全相同的权重会产生 0 个非有限值，并且与 float64 NumPy 参考结果一致（最大绝对误差约 5.2e-6）。要检查自己是否受影响，请查看 tensor.data_ptr() % 64：如果映射张量上该值非零，则表明存在风险。

Question 5

为什么 GLiFormer 在短文本上的推理速度很慢，即使 GPU 大部分时间处于空闲状态？我该如何解决这个问题？

Accepted Answer

在短输入（40-140 tokens）下，GLiFormer 47 ms 的前向传播受限于 CPU 端的 kernel 启动开销：它会触发约 1,270 个小型 CUDA kernel，并伴随约 71 次流同步（其中 31 次来自任务头中的 `.item()` 调用），而 GPU 实际忙碌时间仅约 8 ms。修复方案是 CUDA graph 重放，在 PR #796 中实现，遵循了 #367 中 GLiClass 的做法：前向传播的静态部分（具有固定填充形状的 DeBERTa 主干网络）只录制一次，并作为 CUDA graph 重放，而具有数据依赖控制流的任务头则保持 eager 模式，读取 graph 的静态输出缓冲区。CUDA graphs 为可选功能，默认关闭——启用 'exact shapes' 模式即可，该模式通过了预训练一致性检查，输出与 eager 执行逐位相同。分桶（填充长度）模式被拒绝/不可用，因为它未能满足固定的数值容差限制。内存使用受每个模型的预算上限约束，同一时间只运行一次录制，在内存压力下会跳过录制，并在模型卸载时释放 graph 内存。

sie

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐