fix(layout): fall back to the uncompiled model when torch.compile fails (#3956) - #3964
Open
Anai-Guo wants to merge 1 commit into
Open
fix(layout): fall back to the uncompiled model when torch.compile fails (#3956)#3964Anai-Guo wants to merge 1 commit into
Anai-Guo wants to merge 1 commit into
Conversation
torch.compile() is lazy: the backend only builds a kernel on the first forward pass, so on a machine without a working C++ compiler the failure surfaces in predict_batch() rather than in initialize(). Nothing catches it there, so it propagates as a ConversionError and the whole conversion fails. Since docling-project#3914 made LayoutObjectDetectionOptions the default and compile_torch_models defaults to True, this is on the default PDF path, so a plain convert() raises on any environment without a compiler -- Windows without MSVC, but also slim Linux images without g++. Compilation is an optimization, so keep a handle on the uncompiled model and degrade to it with a warning instead of failing the conversion. The swap is permanent, so later batches do not retry compilation. A missing handle, and errors that are not TorchDynamoException, still propagate unchanged. Signed-off-by: Tai An <antai12232931@outlook.com>
Contributor
|
✅ DCO Check Passed Thanks @Anai-Guo, all your commits are properly signed off. 🎉 |
Contributor
Merge Protections🟢 Merge protection satisfied — ready to merge. Show 1 satisfied protection🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related to #3956 (and complementary to #3962, which changes the default rather than the failure mode).
The problem
torch.compile()is lazy. It returns anOptimizedModuleimmediately and the backend only builds a kernel on the first forward pass. InTransformersObjectDetectionEnginethe compile call sits insideinitialize()'stry/except, but the first forward happens inpredict_batch():Nothing catches it there, so on a machine without a working C++ compiler the conversion dies with
torch._dynamo.exc.BackendCompilerFailedwrappingInvalidCxxCompiler, surfaced to the user as aConversionError.Since #3914 made
LayoutObjectDetectionOptionsthe default andcompile_torch_modelsdefaults toTrue, this sits on the default PDF path — a plainDocumentConverter().convert(...)raises. It is not Windows-specific: it reproduces the same way on a slim Linux image with nog++(reported againstpython:3.12-slimin neuml/txtai#1176, where it also broke that project's Windows CI).The change
Compilation is an optimization, not a correctness requirement, so keep a handle on the uncompiled module and degrade to it with a warning instead of failing the conversion:
initialize()recordsself._uncompiled_modelbefore handing the model totorch.compile()._forward()helper wraps the call. Ontorch._dynamo.exc.TorchDynamoExceptionit logs a warning naming the env var, swaps_modelback to the uncompiled module, and retries once.Deliberately narrow: if no uncompiled handle was recorded (
compile_model=False, so nothing was compiled), the error propagates unchanged; anything that is not aTorchDynamoExceptionpropagates unchanged, so a genuine model error is never masked as a compile problem.Verification
torch.compile()really does defer the failure to the first forward — confirmed on torch 2.5.1, Python 3.12, Windows with nocl/g++onPATH:Against a genuinely failing compile on that machine:
BackendCompilerFailed→ConversionErrortests/test_object_detection_compile_fallback.pycovers those three rows and needs no model download. It fails 3/3 against the code before this change and passes 3/3 after.ruff==0.15.12checkandformat --checkclean with the repo config.Notes
image_classificationandvlmtransformers engines share the same shape. I left them alone to keep this focused on the default layout path that refactor(layout): run all layout inference through the object-detection factory path #3914 turned on; happy to extend if you'd prefer one pass.🤖 Generated with Claude Code