Code suitability for Leonardo
Yes. The stack (PyTorch, vLLM, HF) and models (InternVL3, Qwen3.5 BF16) are compatible with A100 GPUs.
Technical evaluation
1 saved evaluation · Revision 138f97334094
Direct answers from the automatic evaluation
Yes. The stack (PyTorch, vLLM, HF) and models (InternVL3, Qwen3.5 BF16) are compatible with A100 GPUs.
Partially. Base libraries are available via cineca-ai; vLLM and PEFT require user installation via venv or container.
Yes. 3,500 node-hours and 3 months are sufficient for the proposed workplan.
High quality. The applicant provided detailed memory and parallelization specifications that align with the hardware.
The project is technically sound, resource requests are within the Benchmark call caps, and the software stack is compatible with the Leonardo BOOSTER architecture.
The complete saved technical evaluation
Final Decision: ACCEPTED
1. Are the codes to be used suitable for Leonardo's architecture? Yes. The software stack (PyTorch 2.x, Hugging Face Transformers, PEFT, and vLLM) is the industry standard for LLM and VLM workloads and is fully compatible with the NVIDIA A100 (Ampere) architecture of the Leonardo BOOSTER partition. The InternVL3 models are explicitly documented as compatible with A100 GPUs. While some specialized quantized versions of Qwen3.5 (e.g., NVFP4) are Blackwell-native, the standard BF16 implementation is compatible with the A100, provided the applicant uses the proposed Tensor Parallelism (TP=4) to distribute the 122B parameters across the 4 GPUs of a single node.
2. Is the code installed on Leonardo?
Partially.
The core libraries (PyTorch, Transformers) are available via the cineca-ai module. However, specific versions of vLLM and PEFT, as well as the model weights, are not pre-installed. The applicant can easily deploy these using a virtual environment or a Singularity container, which is the recommended approach for this stack.
3. Are the proposed targets feasible within the allocation time? Yes. The requested 3,500 node-hours are within the Benchmark call limits. The workplan is realistic, with annotation estimated at 1-2 days per run and fine-tuning runs for InternVL3-2B and 38B fitting comfortably within the allocation. The 3-month duration is sufficient for the proposed experimental program.
4. Technical data quality and conclusions The technical data provided is of high quality. The applicant provides specific memory estimates (e.g., 244 GB for Qwen3.5 weights), clear parallelization strategies (TP=4 for inference, ZeRO-3 for 38B fine-tuning), and grounded resource estimates based on a previous EuroHPC allocation. The I/O strategy is appropriate for GPU-bound workloads.
5. Reasons for final classification The project is technically sound and all resource requests (node-hours, storage, and data transfer) are within the limits of the Benchmark call. The software stack and target models are compatible with the Leonardo BOOSTER architecture.
| Questions | Direct answer | Evidence/comment |
|---|---|---|
| Are the codes suitable for Leonardo's architecture? | Yes | vLLM/PyTorch/HF compatible with A100 (sm80). |
| Is the code installed on Leonardo? | Partially | Base libraries available; vLLM/PEFT require venv/container. |
| Are the proposed targets feasible within the allocation time? | Yes | 3,500 node-hours $\le$ cap; realistic workplan. |
| What are the technical-data quality conclusions? | High Quality | Detailed memory/parallelism specs provided. |
| What are the reasons for final classification? | ACCEPTED | All technical and resource criteria met. |
The project aims to improve the robustness of Vision-Language Models (VLMs) for autonomous driving under camera degradations (blur, illumination changes). The technical workflow involves three stages: (1) generating ground-truth annotations for a new dataset using a teacher model (Qwen3.5-122B), (2) evaluating existing VLMs, and (3) fine-tuning InternVL3-2B and InternVL3-38B using LoRA and DeepSpeed ZeRO-3.
The proposal is technically robust. The applicant demonstrates a deep understanding of the memory constraints associated with large-scale models, specifically planning for Tensor Parallelism to fit the 122B model on a single BOOSTER node and using ZeRO-3 to shard the 38B model across multiple nodes. All resource requests are compliant with the Benchmark call policies.
Verdict: ACCEPTED Summary: The software stack is fully compatible with the A100 architecture. The use of vLLM and PyTorch 2.x is appropriate for the target hardware. Evidence: InternVL3 is explicitly compatible with sm80. Qwen3.5 BF16 is compatible, though the applicant must avoid Blackwell-specific (NVFP4) versions.
| Component | Applicant version or assumption | Partition | Result | Key condition | Source URL |
|---|---|---|---|---|---|
| vLLM | Latest stable | BOOSTER | COMPATIBLE | Use TP=4 for 122B | https://github.com/vllm-project/vllm |
| PyTorch | 2.x | BOOSTER | COMPATIBLE | Standard | https://pytorch.org |
| InternVL3 | 2B / 38B | BOOSTER | COMPATIBLE | A100 80GB target | Model Documentation |
| Qwen3.5 | 122B | BOOSTER | COMPATIBLE | BF16 only; no NVFP4 | Model Documentation |
Verdict: ACCEPTED Summary: Resource requests are well within the limits for the Benchmark call. Evidence: 3,500 node-hours $\le$ 3,500 cap; 3 TB storage $\le$ 10 TB limit; 3 TB transfer is reasonable.
Verdict: ACCEPTED Summary: High-quality technical data with realistic estimates and a clear parallelization strategy. Evidence: Explicit mention of TP=4, ZeRO-3, and memory footprints (244 GB for Qwen3.5).
The evaluation was conducted by analyzing the software stack, model compatibility, and resource requests. The section_reviewer confirmed that the resource requests are compliant and the technical plan is sound. The researcher verified that the InternVL3 models are compatible with A100 GPUs and flagged that only the BF16 version of Qwen3.5 (not the Blackwell-native NVFP4 version) should be used. Since the applicant's plan relies on standard BF16/mixed-precision and Tensor Parallelism, the project is technically feasible. Following the fail-safe logic, as all critical assessments are ACCEPTED (or CONDITIONALLY_ACCEPTED with a clear path to resolution), the final decision is ACCEPTED.
lrd_all_serial before execution.High. The resource requests are explicit and the model compatibility is well-documented.