LightOnOCR3模型别名：核对自动profile和最长边，防止1B被自定义名误判

素材身份：作者原创输入/可编辑参考。目标工具未在本轮执行。
先打开 index.html；input.csv 是原始字段，reference.csv 是验收基准，negative.csv 是故意构造的坏样例。
actual-results.csv 保留未测状态，实际执行后再填写。

前置条件：
LightOnOCR-3采用本地或自有授权服务；4B/0.8B为Qwen3.5架构，1B架构不同，显存还受图片与上下文影响，不承诺某张卡必定够用。
使用官方仓库锁定的兼容依赖；当前仓库说明vLLM0.30.0与Transformers5.16.1，模型卡的旧最低版本不能替代锁文件。
模型Apache2.0；仅空prompt或grounding是文档支持输入，原生PDF与检查无需付费，模型识别未执行。

操作步骤：
1. 列出后端模型身份
记录实际加载权重repo与对外served model name。
别名不能代替真实模型版本，台账同时保留二者。

2. 阅读官方profile规则
当前仓库为3-1B采用1540px，3-0.8B和4B采用2048px。
旧代模型也不支持grounding，不能只凭名称中含OCR就开放模式。

3. 检查别名默认
官方说明自定义served-model-name会按3代2048px假设处理。
若实际加载1B，必须显式校对最长边而非相信自动识别。

4. 设置明确最长边
按实际权重使用--longest-edge覆盖页面尺寸。
保留渲染前后宽高，不能只改配置文本不看发送图。

5. 核对兼容依赖
使用仓库锁定版本，特别检查1B在Transformers5.17与vLLM0.30组合的已知问题。
不要盲目升级所有包后把循环输出误归为文档难度。

6. 执行小页验证
先用三行清单看模式、尺寸和输出是否正常。
出现循环或拒绝模式先回查模型身份与依赖。

7. 交付profile记录
保存真实repo、别名、最长边、依赖锁和实际发送图尺寸。
未部署后端时只交配置差异，不声称兼容性已测。

验收：
真实权重repo和别名均有记录。
1B最长边明确1540px。
依赖问题与内容识别问题分开诊断。

官方资料：
https://github.com/lightonai/LightOnOCR

图片身份：assets/ 为内置image_gen生成的原创练习输入缩略版，原始文件保留在网站图片来源地址。可编辑SVG为作者原生排版。