Skip to main content
Back to Prompt Library
implementation

Build the application

Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.

Linked challenge: Build a Multi-LoRA Adapter Memory and Batch Sizing Calculator

Format
Code-aware
Lines
68
Sections
11
Linked challenge
Build a Multi-LoRA Adapter Memory and Batch Sizing Calculator

Prompt source

Original prompt text with formatting preserved for inspection.

68 lines
11 sections
No variables
1 code block
## Build
Profile VRAM usage for serving concurrent LoRA adapters on open-weight base models using vLLM. Synthesize maximum concurrency limits and memory overheads using hosted Claude to generate deployment configuration.

## User
ML Deployment Specialist

## Workflow
1. Parse evaluation logs measuring VRAM footprint scaling per active LoRA adapter on local hardware.
2. Calculate maximum adapter concurrency before triggering out-of-memory errors or significant KV-cache eviction.
3. Prompt hosted Claude API to synthesize a deployment density report justifying adapter count limits.
4. Export a deployment configuration specifying max_loras and max_lora_rank for the vLLM engine.

## Interface
Web dashboard showing projected VRAM usage per adapter and configuration export options.

## Data
JSON arrays containing simplified synthetic VRAM profile measurements for LoRA adapters across various ranks.
Starter examples below are synthetic. They are not downloaded records.

## Source
[vLLM open-model serving](https://raw.githubusercontent.com/vllm-project/vllm/main/README.md)
References vLLM multi-LoRA serving features and configuration flags.

## Tools
anthropic-claude, fastapi, pydantic.
Synthesizes multi-LoRA deployment strategies based on memory profiles.
Hosted Claude API for technical synthesis; benchmarks focus on open-weight models.

## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.

## Acceptance
- Correctly computes VRAM usage per adapter rank and base model overhead.
- Identifies hard limits on concurrent requests when serving heterogeneous LoRAs.
- Generates ready-to-run vLLM multi-LoRA launch arguments.
- Confines profiling strictly to specified open-weight model architectures.

## Starter Examples
```json
[
  {
    "input": {
      "base_model": "open-qwen-7b",
      "base_vram_gb": 14.5,
      "adapter_rank": 64,
      "vram_per_adapter_gb": 0.45,
      "total_vram_gb": 24,
      "target_adapters": 10
    },
    "expected_output": {
      "total_projected_vram_gb": 19,
      "viable_deployment": true,
      "vllm_launch_flag": "--enable-lora --max-loras 10 --max-lora-rank 64",
      "claude_rationale": "Base model and 10 adapters fit well within 24GB VRAM, leaving 5GB for KV cache and context generation."
    }
  },
  {
    "input": {
      "base_model": "open-qwen-7b",
      "base_vram_gb": 14.5,
      "adapter_rank": 128,
      "vram_per_adapter_gb": 0.9,
      "total_vram_gb": 24,
      "target_adapters": 20
    },
    "expected_output": {
      "total_projected_vram_gb": 32.5,
      "viable_deployment": false,
      "vllm_launch_flag": null,
      "claude_rationale": "Projected VRAM (32.5GB) exceeds hardware limits. Reduce target adapters."
    }
  }
]
```

## Safety
Evaluation applies exclusively to open-weight models. No access or extrapolation to proprietary Claude models.
Use mock external writes. Require human review before any real deployment.

Adaptation plan

Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.

Keep stable

Hold the task contract and output shape stable so generated implementations remain comparable.

Tune next

Update libraries, interfaces, and environment assumptions to match the stack you actually run.

Verify after

Test failure handling, edge cases, and any code paths that depend on hidden context or secrets.