project_6

dylanyunlong/project_6

Fork 0

Commit Graph

Author	SHA1	Message	Date
muh-pipeline	da553227e9	[BASE] qwen3_6_scripts/verify_functional.py: add CCCL-derived boundary tests Random CCCL pick: cub/test/catch2_test_thread_scan_exclusive_partial.cu (310 lines, full read) CCCL tests valid_items at 5 boundary points: 1, [2..num_items-1], num_items, num_items+1, max_int Applied same principle to vllm functional tests: TC-11: max_tokens boundary values - max_tokens=1 (CCCL valid_items=1 — minimum output, partial tile) - max_tokens=2 (CCCL valid_items=2 — near-minimum) These trigger partial partition handling in paged_attention_v2. TC-12: json_object structured output - response_format={'type':'json_object'} forces JSON - Maps to competition functional test requirement Also read: vllm/core/evictor_v2.py, vllm/attention/ops/paged_attn.py Base files modified: qwen3_6_scripts/verify_functional.py	2026-08-06 02:30:48 +00:00
dylanyunlon	8cdac642de	[CCCL-PORT] Functional verification from three_way_partition test pattern + sampler deploy Source: cccl_upstream/cub/test/catch2_test_device_three_way_partition.cu (random pick) CCCL test design pattern applied: 1. Empty input handling (TC-10: empty messages → 4xx) 2. Stability verification (TC-11: chat_dataset_v0.json all turns pass) 3. Edge cases (TC-07 tool calling, TC-08 stop sequence, TC-06 reasoning) 4. Large problem coverage (TC-11: multi-turn conversations) CCCL three-way partition test insight: always verify both CUB and Thrust paths produce identical results. Our equivalent: verify every modification we make to base doesn't break any of the 11 functional test cases. Also deploys sampler.py with CCCL-ported top-k fast path (from partition/flagged.cu benchmark's radix select insight).	2026-08-05 08:31:52 +00:00

Author

SHA1

Message

Date

muh-pipeline

da553227e9

[BASE] qwen3_6_scripts/verify_functional.py: add CCCL-derived boundary tests

Random CCCL pick: cub/test/catch2_test_thread_scan_exclusive_partial.cu
(310 lines, full read)

CCCL tests valid_items at 5 boundary points:
  1, [2..num_items-1], num_items, num_items+1, max_int
Applied same principle to vllm functional tests:

TC-11: max_tokens boundary values
  - max_tokens=1 (CCCL valid_items=1 — minimum output, partial tile)
  - max_tokens=2 (CCCL valid_items=2 — near-minimum)
  These trigger partial partition handling in paged_attention_v2.

TC-12: json_object structured output
  - response_format={'type':'json_object'} forces JSON
  - Maps to competition functional test requirement

Also read: vllm/core/evictor_v2.py, vllm/attention/ops/paged_attn.py
Base files modified: qwen3_6_scripts/verify_functional.py

2026-08-06 02:30:48 +00:00

dylanyunlon

8cdac642de

[CCCL-PORT] Functional verification from three_way_partition test pattern + sampler deploy

Source: cccl_upstream/cub/test/catch2_test_device_three_way_partition.cu (random pick)

CCCL test design pattern applied:
  1. Empty input handling (TC-10: empty messages → 4xx)
  2. Stability verification (TC-11: chat_dataset_v0.json all turns pass)
  3. Edge cases (TC-07 tool calling, TC-08 stop sequence, TC-06 reasoning)
  4. Large problem coverage (TC-11: multi-turn conversations)

CCCL three-way partition test insight: always verify both CUB and Thrust
paths produce identical results. Our equivalent: verify every modification
we make to base doesn't break any of the 11 functional test cases.

Also deploys sampler.py with CCCL-ported top-k fast path (from
partition/flagged.cu benchmark's radix select insight).

2026-08-05 08:31:52 +00:00

2 Commits