项目定位与核心能力

Marker 是一个面向 PDF / 图像 / DOCX / PPTX / XLSX / HTML / EPUB 等多格式文档的转换工具链，目标是把各类文档高质量地解析为 Markdown、JSON、HTML 或结构化的 chunk（适合接入 LLM 的 RAG 流水线）。它由若干基于深度学习的「构建器（Builder）」组合而成：OcrBuilder、LayoutBuilder、DetectionBuilder、TableBuilder、EquationBuilder，再加上可选的 LLM 增强（如 GeminiProcessor、ClaudeProcessor、OllamaProcessor），共同完成布局识别、文本识别、表格抽取、公式识别和阅读顺序排序等任务 资料来源：README.md:1-40。

核心入口是 PdfConverter 类，位于 marker/converters/pdf.py。它把上述 Builder 串成一个 ConvertPipeline，并对外暴露 __call__(fname: str | Path) -> DocumentTuple 接口，返回 Markdown / Meta / Images / Document 等对象 资料来源：marker/converters/pdf.py:1-80。

安装方式

仓库使用 Poetry 管理依赖，PyPI 包名为 marker-pdf。标准安装命令如下：

pip install marker-pdf

如需 GPU 加速，可改用 pip install marker-pdf[cu] 或对应的 cu12/cu118 变体；模型权重会在首次运行 marker 命令时按需下载 资料来源：README.md:41-70、pyproject.toml:1-60]()。

社区中常见的 安装失败 场景来自缺失的系统级依赖（如 psutil），该问题已在历史 Issue #818 中暴露，并已被合入主分支修复；当前 PyPI 发布版已默认携带该依赖 资料来源：README.md:60-80。

三种典型使用方式

下表汇总了三种主流入口及其适用场景：

1. CLI 方式

最常用命令：

marker_single /path/to/file.pdf --output_dir ./output

marker_single 实际由 convert_single_cli 实现，参数解析依赖 marker.config.parser，支持 --output_format、--use_llm、--langs、--disable_image_extraction 等丰富的开关 资料来源：marker/scripts/convert_single.py:1-60。

2. Python API 方式

from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict

converter = PdfConverter(artifact_dict=create_model_dict())
markdown, meta, images = converter("input.pdf")

create_model_dict() 会懒加载所有默认 Builder，避免在只需要部分能力时加载全部模型；返回的 Markdown 对象可直接 markdown.markdown 拿到最终字符串 资料来源：marker/models.py:1-80、marker/output.py:1-60。

3. Streamlit GUI 方式

运行 marker_gui 后浏览器访问 localhost:8501，可上传文件并实时切换 LLM 后端、OCR 语言等参数 资料来源：marker/scripts/streamlit_app.py:1-40。

端到端流水线

flowchart LR
    A[输入 PDF / 图像] --> B[PdfConverter.__call__]
    B --> C[ConvertPipeline]
    C --> D[LayoutBuilder<br/>surya-layout]
    C --> E[DetectionBuilder<br/>surya-det]
    C --> F[OcrBuilder<br/>surya-ocr]
    C --> G[TableBuilder<br/>surya-table]
    C --> H[OrderBuilder<br/>阅读顺序]
    H --> I[Markdown / JSON / HTML]
    I --> J[写出到 output_dir]

PdfConverter 内部按顺序驱动 Builder；阅读顺序排序后由 MarkdownOutput、HtmlOutput、JsonOutput、ChunkOutput 各自生成对应格式 资料来源：marker/output.py:1-120。

输出格式与配置

通过 output_format 参数选择目标格式（markdown / json / html / chunks）；Markdown 渲染可叠加 --html_tables_in_markdown（v1.10.0 引入）把表格转成 HTML 标签以提升阅读器兼容性 资料来源：README.md:80-110。

配置层通过 marker.config.loader.load_config() 读取 marker_config.json 或环境变量，可在不修改代码的前提下覆盖 Builder 行为、模型路径、LLM provider 等 资料来源：marker/config/loader.py:1-60。

已知限制与社区高频问题

• 复用 PdfConverter 时显存 / RSS 持续增长：Issue #1040 指出在循环中复用同一实例处理多份 PDF 时 CUDA RSS 可达 60 GB。建议每份文档结束后 del converter; torch.cuda.empty_cache() 或重建实例 资料来源：README.md:110-140`。
• Mac (Apple Silicon) 性能回退：v1.9.0+ 较 v1.8.0 慢 20 倍以上（Issue #960），可临时回退到 pip install marker-pdf==1.8.0。
• 大型 PDF OOM：当 layout_blocks 超过约 1.4 万时，joblib 派生子进程可能触发 OSError: Cannot allocate memory（Issue #1032），可通过减小 --workers 或提升系统内存缓解。
• Docker 部署：根目录提供 Dockerfile，社区已贡献 docker-compose.yml 范例（Issue #157），构建时通过 BASE_IMAGE 参数切换 CUDA 版本 资料来源：Dockerfile:1-40。

快速上手清单

1. pip install marker-pdf，确保 psutil、torch、surya-ocr、pdftext 均已就绪。
2. 小批量使用 CLI：marker_single input.pdf --output_dir out/。
3. 服务端批处理使用 Python API，每个文档生命周期内 实例化一次 PdfConverter 并在结束后释放。
4. 需要可视化或人工核对时切换到 marker_gui。
5. 调整精度/速度权衡：在 marker_config.json 中裁剪 Builder 列表，或启用 --use_llm 调用 Gemini / Claude / Ollama 增强排版。

完成以上步骤后即可让 Marker 进入生产流水线；进一步调优可参考输出格式与 Builder 配置相关页面。

1. 整体架构概览

Marker 是一个面向 PDF 文档的高质量转换框架，其核心设计采用管道化 + 模块化的分层架构。整个系统由四大组件协同构成：Provider（数据源）、Processor（处理单元）、Builder（构建器）和Renderer（渲染器）。其中 PdfConverter 作为顶层编排者，按照既定顺序串联这些组件完成从 PDF 到结构化输出的全流程转换。

PDF → [Provider] → [Processors] → [Builder] → [Renderer] → Markdown/HTML/JSON

这种分层架构的优势在于：每个阶段职责单一、便于独立替换与扩展（例如替换 OCR 引擎或输出格式），同时通过统一的 Block Schema 在阶段间传递数据，保证契约稳定。

资料来源：marker/converters/pdf.py:1-80

2. 核心组件职责

各组件之间通过基于 Pydantic 的 Schema 对象传递中间结果，Schema 既保证了类型安全，也让序列化与调试变得更直观。

资料来源：marker/schema/__init__.py:1-50

资料来源：marker/providers/__init__.py:1-40

3. 处理流水线阶段

PdfConverter 的处理流水线大致划分为以下阶段，每一阶段均可配置、可跳过：

1. PDF 加载（Provider）：将 PDF 拆解为页面级数据，包含渲染图像、文本块坐标和元信息。
2. 布局检测：调用基于 Surya 的检测模型识别文本、表格、图片、标题等元素的边界框。
3. OCR 与文本识别：对图像或低置信文本块执行 Surya OCR，融合 pdftext 抽取的原生文本。
4. 后处理：执行合并段落、修正阅读顺序、过滤误识别块等清理操作。
5. 结构构建（Builder）：将扁平块重组为层级文档，处理表格、列表、代码块等结构化元素。
6. 渲染输出（Renderer）：根据用户指定的 output_format 输出 Markdown、HTML 或 JSON。

flowchart LR
    A[PDF 输入] --> B[Provider<br/>pdftext]
    B --> C[Processor<br/>布局检测]
    C --> D[Processor<br/>OCR 识别]
    D --> E[Processor<br/>后处理]
    E --> F[Builder<br/>结构构建]
    F --> G[Renderer<br/>序列化输出]

资料来源：marker/processors/__init__.py:1-60

资料来源：marker/builders/__init__.py:1-50

4. 扩展点与常见关注点

管线化的设计提供了多处扩展点，便于接入不同的 OCR/LLM 后端或自定义格式化策略：

• 自定义 Processor：通过继承基类并实现 __call__ 即可插入到流程的任意位置。
• LLM 增强：当启用 use_llm=True 时，会调用 Builder 中的 LLM 流程对布局与文本进行二次精炼（这也是社区中讨论 GPU/VRAM 冲突 #1038 与 Gemini 限速 #490 的关键点）。
• 输出格式：Renderer 抽象层支持 Markdown、HTML、JSON；v1.10.0 引入的 --html_tables_in_markdown 即在该层实现。

需要注意的是，社区反馈的若干问题与流水线行为密切相关：

• 内存泄漏 #1040、#583：在循环中复用 PdfConverter 时，模型缓存与中间张量未被及时释放，建议每次新文档创建独立 Converter。
• Mac 性能下降 #960：v1.9.0+ 后某些处理路径在 macOS 上的 fork 行为带来显著开销。
• Torch 越界异常 #1036：通常发生在 OCR/文本识别阶段，可通过调整 TORCH_DEVICE 与批大小缓解。

理解这些阶段之间的依赖关系，有助于在出现异常时快速定位瓶颈（例如通过禁用某些 Processor 进行隔离测试）。

资料来源：marker/renderers/__init__.py:1-80

资料来源：marker/converters/pdf.py:80-200

概述

Marker 是一个将 PDF 文档转换为多种结构化输出格式的流水线工具。其核心价值在于两层：渲染层负责把识别出的语义块（Block）序列化为最终格式；LLM 增强层则利用大语言模型对布局识别、文本合并、表格抽取等中间结果进行二次精炼。两个层级通过统一的 Document 数据结构解耦，使同一份中间结果可被任意渲染器消费。

资料来源：marker/renderers/markdown.py:1-30、marker/converters/extraction.py:1-25

渲染器架构

Marker 的渲染器位于 marker/renderers/ 目录下，继承自基类 BaseRenderer，每个子类实现 __call__(document, **kwargs) 接口将 Document 序列化为目标字符串。

四种渲染器共用同一份中间表示，因此切换 output_format 不会触发重新识别。资料来源：marker/renderers/markdown.py:30-80、marker/renderers/json.py:1-60、marker/renderers/html.py:1-50、marker/renderers/chunk.py:1-45

JSONRenderer 的输出包含每个块的 block_type、text、page、bbox 等字段，是实现“导出到 SQLite / CSV”等扩展功能（参见 issue #1035）的基础数据源。资料来源：marker/renderers/json.py:60-120

LLM 增强服务与处理流水线

LLM 增强通过 marker/services/ 中实现的统一服务接口接入，屏蔽不同供应商的 API 差异。当前仓库内置以下后端：

• GeminiService：默认云端服务，对长上下文与表格友好。
• OpenAIService：兼容 OpenAI Chat Completions 接口，可指向任何兼容端点。
• ClaudeService：调用 Anthropic Messages API。
• OllamaService：对接本地 Ollama，便于在单 GPU 上与其他模型共存（参见 issue #1038）。

服务层抽象出 prompt、max_tokens、image_limit 等统一字段。GeminiService.__init__ 会读取 GOOGLE_API_KEY 并初始化生成客户端。资料来源：marker/services/gemini.py:1-60、marker/services/openai.py:1-50、marker/services/claude.py:1-45、marker/services/ollama.py:1-40

LLM 增强主要在三类处理器中起作用：

1. 布局合并（llm_merging.py）：对跨页或相邻的同类型块进行语义合并，减少碎片化。
2. LLM 布局构建器（llm_layout.py）：当传统版面模型置信度不足时，将候选区域交给 LLM 重排。
3. 抽取转换器（extraction.py）：基于用户自定义提示词，直接由 LLM 从图像中提取结构化字段。

资料来源：marker/processors/llm/llm_merging.py:1-70、marker/builders/llm_layout.py:1-55、marker/converters/extraction.py:25-90

flowchart LR
    PDF[PDF 输入] --> Layout[版面识别]
    Layout --> OCR[OCR / 文本识别]
    OCR --> Merge{LLM 增强?}
    Merge -- 是 --> LLM[LLM 服务层]
    LLM --> Refine[合并 / 抽取 / 重排]
    Merge -- 否 --> Skip[直接进入渲染]
    Refine --> Doc[Document 中间表示]
    Skip --> Doc
    Doc --> MD[Markdown]
    Doc --> JSON[JSON]
    Doc --> HTML[HTML]
    Doc --> Chunk[Chunk]

配置与使用

通过 PdfConverter 的配置对象切换渲染器与 LLM 后端。常用参数包括：

• output_format：选择 markdown / json / html / chunks。
• use_llm：布尔值，启用后处理器链中的 LLM 步骤。
• llm_service：指定服务实现类。
• google_api_key / openai_api_key / anthropic_api_key：通过环境变量或参数注入。

资料来源：marker/services/gemini.py:30-60、marker/converters/extraction.py:90-140

社区中常见的两类问题与本页主题相关：issue #490 反映了 Gemini API 速率限制下缺少退避机制；issue #1040 则提示在循环复用 PdfConverter 时需关注内存释放。这些都直接影响 LLM 增强层的稳定性，建议结合 gc.collect() 与进程级隔离使用。

选型建议

• 追求速度与离线运行：关闭 use_llm，使用 Markdown 输出。
• 需要结构化下游处理：选择 json 输出，并保留 JSONRenderer 的原始字段。
• 文档以复杂表格为主：启用 LLM 增强，配合 OllamaService 在本地 GPU 上运行以避免 VRAM 冲突（参见 issue #1038）。
• RAG 接入：使用 chunks 输出，并在后处理阶段做向量化。

资料来源：marker/renderers/chunk.py:45-90、marker/services/ollama.py:40-80

性能调优

硬件与运行模式选择

marker/utils/gpu.py 提供了对 CUDA / MPS / CPU 设备的探测与回退逻辑，CLI 与服务脚本都通过它选择运行设备 资料来源：marker/utils/gpu.py:1-80。在 GPU 显存充足时应优先启用 CUDA；在 Apple Silicon 上，MPS 路径在 v1.9.0 之后存在显著性能回退，社区中已确认回退到 marker==1.8.0 可恢复速度 资料来源：issue #960。

批处理与并发

marker/scripts/convert.py 的 convert_cli 是单进程入口，循环调用时 PdfConverter 实例常被复用，导致模型对象和 CUDA 上下文不断累积 资料来源：marker/scripts/convert.py:1-120。推荐做法是：每个文档独立创建并销毁 PdfConverter，或在长任务中使用 chunk_convert.py 做分片提交。marker/scripts/chunk_convert.py 把大文件按页切片并发处理，可显著降低单次峰值内存 资料来源：marker/scripts/chunk_convert.py:1-200。

模型选择与配置覆盖

marker/settings.py 集中定义可调参数，例如 TORCH_DEVICE、PDFTEXT_WORKERS、RECOGNITION_BATCH_SIZE 等；通过环境变量或 Settings(... ) 覆盖即可降低显存峰值 资料来源：marker/settings.py:1-150。当 LLM 与 marker 共享单卡时，应关闭 use_llm、降低批大小并预留 6-8GB 显存 资料来源：issue #1038。

内存管理

PdfConverter 复用导致的内存膨胀

社区中最常见的内存问题是：在循环中复用同一个 PdfConverter 处理多份 PDF 时，RSS 持续增长，10 份 200-400 页文档即可使 CUDA RSS 达到 60GB 资料来源：issue #1040。PdfConverter.__call__ 内部会向 BuilderRunner 注入中间状态 资料来源：marker/converters/pdf.py:1-220，如果复用实例而未显式清理，PyTorch 的 CUDA 缓存与 python 引用会同时滞留。建议模式：

from marker.converters.pdf import PdfConverter
for path in paths:
    converter = PdfConverter()  # 每份文档新建
    converter(path)
    del converter

大文件与 joblib fork

marker/builders/ 下的子构建器（如 OCR、layout、merge）会通过 joblib 并行派发任务；fork 子进程时若父进程已占用大量 RSS，会触发 OSError: [Errno 12] Cannot allocate memory 资料来源：issue #1032。chunk_convert.py 正是通过分片避免单进程膨胀 资料来源：marker/scripts/chunk_convert.py:1-200。

显式释放策略

在脚本与服务器中应显式调用 torch.cuda.empty_cache() 与 gc.collect()，并在转换完成后断开对中间 Document 对象的引用。examples/marker_modal_deployment.py 给出了基于 Modal 的容器级隔离示例，把每次转换放到独立容器中回收，从根本上规避进程内泄漏 资料来源：examples/marker_modal_deployment.py:1-180。

常见故障排除

服务化部署

marker/scripts/server.py 暴露 FastAPI 接口，常驻进程中 PdfConverter 长期持有 GPU 上下文；marker/scripts/streamlit_app.py 同样会跨请求复用模型 资料来源：marker/scripts/server.py:1-160 资料来源：marker/scripts/streamlit_app.py:1-200。生产环境建议：

1. 在 worker 进程内为每次请求重建 PdfConverter，或使用 --max-requests 触发回收。
2. 在容器/Modal 部署中让请求以独立进程/容器执行，依赖生命周期结束自动释放显存 资料来源：examples/marker_modal_deployment.py:1-180。
3. 通过 nvidia-smi 与 torch.cuda.memory_summary() 周期采样，定位泄漏阶段。

Docker 与依赖

仓库提供 Dockerfile，社区维护的 docker compose 示例（基于 pytorch/pytorch:2.1.2-cuda12.1）可在多容器场景中隔离 marker 与 LLM 资料来源：issue #157。无论使用哪种方式，都应显式固定 marker-pdf、surya-ocr、pdftext、torch 的版本组合，以避免上游行为变化引发回归。

Pitfall Log / 踩坑日志

项目：datalab-to/marker

摘要：发现 21 个潜在踩坑项，其中 6 个为 high/blocking；最高优先级：安装坑 - 来源证据：Docker compose ?。

1. 安装坑 · 来源证据：Docker compose ?

• 严重度：high
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个安装相关的待验证问题：Docker compose ?
• 对用户的影响：可能增加新用户试用和生产接入成本。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/157 | 来源讨论提到 python 相关条件，需在安装/试用前复核。

2. 安装坑 · 来源证据：Memory seems to grow unbounded when reusing PdfConverter across multiple PDFs

• 严重度：high
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个安装相关的待验证问题：Memory seems to grow unbounded when reusing PdfConverter across multiple PDFs
• 对用户的影响：可能增加新用户试用和生产接入成本。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/1040 | 来源讨论提到 python 相关条件，需在安装/试用前复核。

3. 安装坑 · 来源证据：[BUG: Breaking]

• 严重度：high
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个安装相关的待验证问题：[BUG: Breaking]
• 对用户的影响：可能阻塞安装或首次运行。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/1032 | 来源讨论提到 python 相关条件，需在安装/试用前复核。

4. 安装坑 · 来源证据：[BUG: Breaking] Marker is 20x+ slower since v1.9.0+ in Mac

• 严重度：high
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个安装相关的待验证问题：[BUG: Breaking] Marker is 20x+ slower since v1.9.0+ in Mac
• 对用户的影响：可能影响升级、迁移或版本选择。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/960 | 来源讨论提到 python 相关条件，需在安装/试用前复核。

5. 安装坑 · 来源证据：[BUG: Breaking] missing dependency: psutil

• 严重度：high
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个安装相关的待验证问题：[BUG: Breaking] missing dependency: psutil
• 对用户的影响：可能影响升级、迁移或版本选择。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/818 | 来源讨论提到 python 相关条件，需在安装/试用前复核。

6. 运行坑 · 来源证据：[BUG: Output] ListItem html logic strips all internal dashes/hyphens from the first formatted line.

• 严重度：high
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个运行相关的待验证问题：[BUG: Output] ListItem html logic strips all internal dashes/hyphens from the first formatted line.
• 对用户的影响：可能增加新用户试用和生产接入成本。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/1024 | 来源讨论提到 python 相关条件，需在安装/试用前复核。

7. 安装坑 · 来源证据：Converting speed is farely slow with marker_single

• 严重度：medium
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个安装相关的待验证问题：Converting speed is farely slow with marker_single
• 对用户的影响：可能增加新用户试用和生产接入成本。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/1007 | 来源类型 github_issue 暴露的待验证使用条件。

8. 安装坑 · 来源证据：[Performance] RTX 3090 extremely slow (0.014 pages/sec) despite 19GB free VRAM

• 严重度：medium
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个安装相关的待验证问题：[Performance] RTX 3090 extremely slow (0.014 pages/sec) despite 19GB free VRAM
• 对用户的影响：可能增加新用户试用和生产接入成本。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/919 | 来源讨论提到 python 相关条件，需在安装/试用前复核。

9. 配置坑 · 来源证据：OCR_ENGINE=None Doesn't work

• 严重度：medium
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个配置相关的待验证问题：OCR_ENGINE=None Doesn't work
• 对用户的影响：可能增加新用户试用和生产接入成本。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/256 | 来源类型 github_issue 暴露的待验证使用条件。

10. 配置坑 · 来源证据：Support surya-ocr 0.20 (transformers 5.x / Pillow 12 / huggingface-hub 1.x)

• 严重度：medium
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个配置相关的待验证问题：Support surya-ocr 0.20 (transformers 5.x / Pillow 12 / huggingface-hub 1.x)
• 对用户的影响：可能影响升级、迁移或版本选择。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/1048 | 来源类型 github_issue 暴露的待验证使用条件。

11. 配置坑 · 来源证据：marker_single always emits json which is not documented as a feature

• 严重度：medium
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个配置相关的待验证问题：marker_single always emits json which is not documented as a feature
• 对用户的影响：可能增加新用户试用和生产接入成本。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/1054 | 来源类型 github_issue 暴露的待验证使用条件。

12. 能力坑 · 能力判断依赖假设

• 严重度：medium
• 证据强度：source_linked
• 发现：README/documentation is current enough for a first validation pass.
• 对用户的影响：假设不成立时，用户拿不到承诺的能力。
• 证据：capability.assumptions | https://github.com/datalab-to/marker | README/documentation is current enough for a first validation pass.

13. 维护坑 · 来源证据：Flawed CUDA / NVidia GPU detection logic

• 严重度：medium
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个维护/版本相关的待验证问题：Flawed CUDA / NVidia GPU detection logic
• 对用户的影响：可能增加新用户试用和生产接入成本。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/1050 | 来源讨论提到 python 相关条件，需在安装/试用前复核。

14. 维护坑 · 来源证据：marker_single defaults output_dir to site packages

• 严重度：medium
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个维护/版本相关的待验证问题：marker_single defaults output_dir to site packages
• 对用户的影响：可能增加新用户试用和生产接入成本。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/1055 | 来源类型 github_issue 暴露的待验证使用条件。

15. 维护坑 · 维护活跃度未知

• 严重度：medium
• 证据强度：source_linked
• 发现：未记录 last_activity_observed。
• 对用户的影响：新项目、停更项目和活跃项目会被混在一起，推荐信任度下降。
• 证据：evidence.maintainer_signals | https://github.com/datalab-to/marker | last_activity_observed missing

• 严重度：medium
• 证据强度：source_linked
• 发现：no_demo
• 证据：downstream_validation.risk_items | https://github.com/datalab-to/marker | no_demo; severity=medium

17. 安全/权限坑 · 存在评分风险

• 严重度：medium
• 证据强度：source_linked
• 发现：no_demo
• 对用户的影响：风险会影响是否适合普通用户安装。
• 证据：risks.scoring_risks | https://github.com/datalab-to/marker | no_demo; severity=medium

18. 安全/权限坑 · 来源证据：Model weights are not loaded when marker-single is first run after installing marker-pdf

• 严重度：medium
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个安全/权限相关的待验证问题：Model weights are not loaded when marker-single is first run after installing marker-pdf
• 对用户的影响：可能影响授权、密钥配置或安全边界。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/1049 | 来源类型 github_issue 暴露的待验证使用条件。

19. 安全/权限坑 · 来源证据：Unauthenticated arbitrary local file read via `filepath` in POST /marker

• 严重度：medium
• 证据强度：source_linked
• 发现：GitHub 社区证据显示该项目存在一个安全/权限相关的待验证问题：Unauthenticated arbitrary local file read via filepath in POST /marker
• 对用户的影响：可能影响授权、密钥配置或安全边界。
• 证据：community_evidence:github | https://github.com/datalab-to/marker/issues/1058 | 来源讨论提到 python 相关条件，需在安装/试用前复核。

20. 维护坑 · issue/PR 响应质量未知

• 严重度：low
• 证据强度：source_linked
• 发现：issue_or_pr_quality=unknown。
• 对用户的影响：用户无法判断遇到问题后是否有人维护。
• 证据：evidence.maintainer_signals | https://github.com/datalab-to/marker | issue_or_pr_quality=unknown

21. 维护坑 · 发布节奏不明确

• 严重度：low
• 证据强度：source_linked
• 发现：release_recency=unknown。
• 对用户的影响：安装命令和文档可能落后于代码，用户踩坑概率升高。
• 证据：evidence.maintainer_signals | https://github.com/datalab-to/marker | release_recency=unknown