Skip to content

[2.0] Add new Frontier-CS 2.0 problem vllm_llm_serving_optimization#145

Open
momoway wants to merge 2 commits into
FrontierCS:mainfrom
momoway:main
Open

[2.0] Add new Frontier-CS 2.0 problem vllm_llm_serving_optimization#145
momoway wants to merge 2 commits into
FrontierCS:mainfrom
momoway:main

Conversation

@momoway

@momoway momoway commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Summary

Please read CONTRIBUTING.md before submitting.

Type of Change

  • New Frontier-CS 2.0 problem

Testing

Checklist

  • Code follows the project structure and conventions
  • Self-review completed
  • Documentation updated (if applicable)

CI Validation (for new problems)

When adding new problems, CI will automatically validate that your reference solution achieves score > 0.

  • Algorithmic problems: Include reference.cpp in your problem directory
  • Research problems: Include reference.py (or reference.cpp if language: cpp in config.yaml)
  • 2.0 problems: Include reference.py unless the problem config declares another language

@joyemang33 joyemang33 changed the title feat: Add new Frontier-CS 2.0 problem vllm_llm_serving_optimization [2.0] Add new Frontier-CS 2.0 problem vllm_llm_serving_optimization Jun 11, 2026
wenhaochai added a commit that referenced this pull request Jun 13, 2026
The CI validator (scripts/validate_problems.py -> get_language_config) only
supports {python, cpp, rust}; `language: patch` raised
`ValueError: Unsupported language: patch` and crashed the whole validate
step with a traceback before any per-problem logic ran.

Mirror vllm_llm_serving_optimization (#145), the canonical Modal-GPU 2.0
task: declare `language: python`, keep the real solution in reference.patch,
and make reference.py a docstring-only placeholder. Also align the tag to
`systems` (matches #145 and the sibling systems-optimization tasks
duckdb_e2e_query_optimization / vector_db_ann).

Submission contract is unchanged: agents still submit /app/solution.patch;
the static patch policy + Modal-GPU scoring in {speedup,stability}_eval are
untouched. The judge stays CPU-only (no runtime.docker.gpu), exactly like
#145. Verified locally: language resolves to python, reference.py is found,
both evaluators return 1.0 on the no-GPU smoke path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant