-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add tests for ONNX models #6
Comments
Progress on #6. A sample test report HTML file is available here: https://scotttodd.github.io/iree-test-suites/onnx_models/report_2024_09_17.html These new tests * Download models from https://github.com/onnx/models * Extract metadata from the models to determine which functions to call with random data * Run the models through [ONNX Runtime](https://onnxruntime.ai/) as a reference implementation * Import the models using `iree-import-onnx` (until we have a better API: iree-org/iree#18289) * Compile the models using `iree-compile` (currently just for `llvm-cpu` but this could be parameterized later) * Run the models using `iree-run-module`, checking outputs using `--expected_output` and the reference data Tests are written in Python using a set of pytest helper functions. As the tests run, they can log details about what commands they are running. When run locally, the `artifacts/` directory will contain all the relevant files. More can be done in follow-up PRs to improve the ergonomics there (like generating flagfiles). Each test case can use XFAIL like `@pytest.mark.xfail(raises=IreeRunException)`. As we test across multiple backends or want to configure the test suite from another repo (e.g. [iree-org/iree](https://github.com/iree-org/iree)), we can explore more expressive marks. Note that unlike the ONNX _operator_ tests, these tests use `onnxruntime` and `iree-import-onnx` at test time. The operator tests handle that as an infrequently ran offline step. We could do something similar here, but the test inputs and outputs can be rather large for real models and that gets into Git LFS or cloud storage territory. If this test authoring model works well enough, we can do something similar for other ML frameworks like TFLite (#5).
Progress on iree-org/iree-test-suites#6. Current tests included and their statuses: ``` PASSED onnx_models/tests/vision/classification_models_test.py::test_alexnet PASSED onnx_models/tests/vision/classification_models_test.py::test_caffenet PASSED onnx_models/tests/vision/classification_models_test.py::test_densenet_121 PASSED onnx_models/tests/vision/classification_models_test.py::test_googlenet PASSED onnx_models/tests/vision/classification_models_test.py::test_inception_v2 PASSED onnx_models/tests/vision/classification_models_test.py::test_mnist PASSED onnx_models/tests/vision/classification_models_test.py::test_resnet50_v1 PASSED onnx_models/tests/vision/classification_models_test.py::test_resnet50_v2 PASSED onnx_models/tests/vision/classification_models_test.py::test_shufflenet PASSED onnx_models/tests/vision/classification_models_test.py::test_shufflenet_v2 PASSED onnx_models/tests/vision/classification_models_test.py::test_squeezenet PASSED onnx_models/tests/vision/classification_models_test.py::test_vgg19 XFAIL onnx_models/tests/vision/classification_models_test.py::test_efficientnet_lite4 XFAIL onnx_models/tests/vision/classification_models_test.py::test_inception_v1 XFAIL onnx_models/tests/vision/classification_models_test.py::test_mobilenet XFAIL onnx_models/tests/vision/classification_models_test.py::test_rcnn_ilsvrc13 XFAIL onnx_models/tests/vision/classification_models_test.py::test_zfnet_512 ``` * CPU only for now. We haven't yet parameterized those tests to allow for other backends or flags. * Starting with `--override-ini=xfail_strict=false` so newly _passing_ tests won't fail the job. Newly _failing_ tests will fail the job. We can add an external config file to customize which tests are expected to fail like the onnx op tests if we want to track which are passing/failing in this repository instead of in the test suite repo. Sample logs: https://github.com/iree-org/iree/actions/runs/11371239238/job/31633406729?pr=18795 ci-exactly: build_packages, test_onnx
An initial set of ONNX model tests has landed in https://github.com/iree-org/iree-test-suites/tree/main/onnx_models and is now running on every IREE PR / commit. Sample logs from a test run in IREE: https://github.com/iree-org/iree/actions/runs/11390747229/job/31693710855#step:8:19. Test summary:
Open tasks now:
|
…8819) Progress on iree-org/iree-test-suites#2 and iree-org/iree-test-suites#6 . Signed-off-by: Elias Joseph <[email protected]>
I'll try to import more tests and parameterize across backends today. |
Progress on #6. See how this is used downstream in iree-org/iree#19524. ## Overview This replaces hardcoded flags like ```python iree_compile_flags = [ "--iree-hal-target-backends=llvm-cpu", "--iree-llvmcpu-target-cpu=host", ] iree_run_module_flags = [ "--device=local-task", ] ``` and inlined marks like ```python @pytest.mark.xfail(raises=IreeCompileException) def test_foo(): ``` with a JSON config file passed to the test runner via the `--test-config-file` option or the `IREE_TEST_CONFIG_FILE` environment variable. During test case collection, each test case name is looked up in the config file to determine what the expected outcome is, from `["skip" (special option), "pass", "fail-import", "fail-compile", "fail-run"]`. By default, all tests are skipped. This design allows for out of tree testing to be performed using explicit test lists (encoded in a file, unlike the [`-k` option](https://docs.pytest.org/en/latest/example/markers.html#using-k-expr-to-select-tests-based-on-their-name)), custom flags, and custom test expectations. ## Design details Compare this implementation with these others: * https://github.com/iree-org/iree-test-suites/tree/main/onnx_ops also uses config files, but with separate lists for `skip_compile_tests`, `skip_run_tests`, `expected_compile_failures`, and `expected_run_failures`. All tests are run by default. * https://github.com/nod-ai/SHARK-TestSuite/blob/main/alt_e2eshark/run.py uses `--device=`, `--backend=`, `--target-chip=`, and `--test-filter=` arguments. Arbitrary flags are not supported, and test expectations are also not supported, so there is no way to directly signal if tests are unexpectedly passing or failing. A utility script can be used to diff the results of two test reports: https://github.com/nod-ai/SHARK-TestSuite/blob/main/alt_e2eshark/utils/check_regressions.py. * https://github.com/iree-org/iree-test-suites/blob/main/sharktank_models/llama3.1/test_llama.py parameterizes test cases using `@pytest.fixture([params=[...]])` with `pytest.mark.target_hip` and other custom marks. This is more standard pytest and supports fluent ways to express other test configurations, but it makes annotating large numbers of tests pretty verbose and doesn't allow for out of tree configuration. I'm imagining a few usage styles: * Nightly testing in this repository, running all test cases and tracking the current test results in a checked in config file. * We could also go with an approach like https://github.com/nod-ai/SHARK-TestSuite/blob/main/alt_e2eshark/utils/check_regressions.py to diff test results but this encodes the test results in the config files rather than in external reports. I see pros and cons to both approaches. * Presubmit testing in https://github.com/iree-org/iree, running a subset of test cases that pass, ensuring that they do not start failing. We could also run with XFAIL to get early signal for tests that start to pass. * If we don't run with XFAIL then we don't need the generalized `tests_and_expected_outcomes`, we could just limit testing to only models that are passing. * Developer testing with arbitrary flags. ## Follow-up tasks - [ ] Add job matrix to workflow (needs runners in this repo with GPUs) - [ ] Add an easy way to update the list of XFAILs (maybe switch to https://github.com/gsnedders/pytest-expect and use its `--update-xfail`?) - [ ] Triage some of the failures (e.g. can adjust tolerances on Vulkan) - [ ] Adjust file downloading / caching behavior to avoid redownloading and using significant bandwidth when used together with persistent self-hosted runners or github actions caches
cc @vinayakdsci @pdhirajkumarprasad @zjgarvey Tests are now parameterized across compiler flags (e.g. target backend choice) and runtime flags (e.g. HAL driver/device choice). Inputs/outputsLooking over nod-ai/SHARK-TestSuite#393 and more properties of the https://github.com/onnx/models repository, I now see that the validated model tests include reference inputs and outputs (hidden behind iree-test-suites/onnx_models/conftest.py Lines 170 to 182 in 82640d6
Input file cachingI've been thinking about caching a bit too. Right now the download code is quite naive: iree-test-suites/onnx_models/conftest.py Lines 278 to 284 in 82640d6
I want something similar to huggingface's cache (which is backed by git lfs), and for these files we could actually use git (lfs) directly too. Something like this:
Then some extensions:
|
More code to reference for caching:
(But I'm liking the git repo with LFS ideas, rather than reinvent the wheel...) |
I haven't used git lfs directly much. Is there a way to pull files with |
Sorta: https://stackoverflow.com/questions/74272833/how-to-git-clone-a-lfs-repo-through-python . We can try https://github.com/liberapay/git-lfs-fetch.py, but otherwise I was going to use Right now I have each test download the files it needs as the test runs. That lets you run a subset of tests and only download the files that those tests need. In the old SHARK-TestSuite/iree_tests code I had that There are currently less than 100 tests, using less than 50GB of files. That's easy enough to manage with downloads within each test case. I would like to support all the models, like in https://github.com/nod-ai/SHARK-TestSuite/blob/main/alt_e2eshark/onnx_tests/models/external_lists/onnx_model_zoo_computer_vision_1.txt and related files, and that would pretty quickly hit some of the harder scaling challenges. |
See nod-ai/SHARK-TestSuite#275
Some work has gone into importing models already at https://github.com/nod-ai/SHARK-TestSuite/tree/main/e2eshark/onnx/models
The text was updated successfully, but these errors were encountered: