MARVELL Monitor v0.0.1
MARVELL Monitor v0.0.1모델 · 결과 · Compaction sweep · 백업 scripts/models/CAN_MODEL.md · 2026-10-22 15:57

현황

1.0.1

TandemSpec(CompressSpec) · HeadInfer · NEO · SparseSpec 에서 실제로 돌려 본 모델과 그 설정. 조건만 정리한 문서는 같은 디렉터리의 README.md.

1.0.2
항목값
1.0.2.1smoke 노드n88 (H200 143 GiB, Xeon Platinum 8562Y+, 할당 core 8개)
1.0.2.2측정 노드Nebius RTX PRO 6000 (81.85.1.77 · 81.85.4.145 × 8)
1.0.2.3축약 전 원문model_matrix/_redesign/before/CAN_MODEL.md (지운 표·로그·예시는 여기)
1.0.3
모델크기TandemSpecHeadInferNEOSparseSpec실험 채택
1.0.3.1Magistral-Small-2509 (text-only)23.57B / 43.90 GiB통과통과통과통과채택
1.0.3.2ibm-granite/granite-4.2-30b30B / 54.53 GiB통과통과통과통과채택
1.0.3.3skt/A.X-3.134.7B / 64.6 GiB통과통과통과통과불가 부적합
1.0.4
  • 기(상황) 네 시스템 통과와 실험 채택은 다르다. A.X-3.1 은 reasoning 모델이 아니다
  • 승(증상) AIME 30문제 생성 길이 중앙값 Magistral 16,107 vs A.X-3.1 1,173 token (13.7배). 둘 다 30개 전부 EOS 종료
  • 전(원인) 길이를 강제하면 8-gram 고유율이 0.883 → 0.451 로 떨어져 speculative accept 이 부풀려진다
  • 결(조치) 긴 출력 비교 실험에서 제외. 기록 results/20260920_magistral_aime/gen_mag_len.jsonl · gen_ax_yarn.jsonl
1.0.5

위 표의 수치는 core 8개 조건이라 성능 비교에 쓰지 않는다. TandemSpec 은 GPU 엔진까지만 확인했고 CPU verify 서버를 붙인 전체 경로는 미확인.

1.1모델별로 실제 필요했던 작업

1.1.1
모델코드 수정그 밖에 필요한 것
1.1.1.1Magistral-Small-2509HeadInfer 1줄 · NEO 1줄 + pacpu macrotext-only 변환, params.json 삭제, eos_token_id, 24b 이름
1.1.1.2ibm-granite/granite-4.2-30bHeadInfer 1줄 · NEO 1줄 + pacpu macro · attention_multiplier 지원없음. 자세한 것은 준비 탭의 모델 준비 · 코드 수정
1.1.1.3skt/A.X-3.1없음 (NEO pacpu macro 만)35b 이름 symlink. 다만 reasoning 모델이 아니라 실험에서는 제외

1.2통과 근거

1.2.1
모델시스템확인한 것
1.2.1.1MagistralvLLM 엔진256 token 생성, AIME 문제를 정상 전개
1.2.1.2MagistralHeadInfer40층 × 8 kv = 320 pseudo-layer, decode 145 ms/token
1.2.1.3MagistralSparseSpec요청 2개 정상 종료, acceptance 93.93%
1.2.1.4MagistralNEO16 token 생성, decode 579 ms/token
1.2.1.5GranitevLLM 엔진registry 에 있고 attention_multiplier 를 읽음
1.2.1.6GraniteHeadInfer64층 × 8 kv = 512 pseudo-layer 로 동작
1.2.1.7GraniteSparseSpecacceptance 52.35% → 86.92% (attention scale override 적용)
1.2.1.8GraniteNEO첫 토큰이 반복·특수문자에서 정상 토큰으로 바뀜
1.2.1.9A.X-3.1vLLM 엔진256 token 생성
1.2.1.10A.X-3.1HeadInfer48층 × 8 kv = 384 pseudo-layer, decode 183 ms/token
1.2.1.11A.X-3.1SparseSpecacceptance 90.77%, model 65.19 GB / KV 53.63 GB
1.2.1.12A.X-3.1NEO16 token 생성, decode 640 ms/token

1.3지금 무엇을 하고 있나

1.3.1
노드내용
1.3.1.1Nebius 81.85.1.77측정 종료. 마지막 판 qw4b_ss_b64r256_20260921_110558 을 214/256 에서 끊었습니다. GPU 3 MiB
1.3.1.2RunPod사용자 지시로 중단. 메인 세션 소관
1.3.2

각 arm 은 요청수 − batch 개 완료 시점에 끊었다. 원본 trace 와 요약 CSV 는 results/sparsespec_batch_sweep_20260921/. 모델별 monitor plot 은 결과 탭에 있다.

1.3.3
위 행: 모델별 batch size 에 따른 throughput, vanilla 대 SparseSpec. 아래 행: 같은 모델의 AIME 30문제 prompt 길이와 generation 길이 histogram(세로축 log). steady window 가 아직 서지 않은 arm 은 점이 없다
1.3.3.c 위 행: 모델별 batch size 에 따른 throughput, vanilla 대 SparseSpec. 아래 행: 같은 모델의 AIME 30문제 prompt 길이와 generation 길이 histogram(세로축 log). steady window 가 아직 서지 않은 arm 은 점이 없다

준비

2.0.1

측정 전에 갖춰야 하는 것. 모델 · 실행 환경 · 주의사항 · AIME pool · 코드 수정 · KV 계산기.

2.1.1

Magistral-Small-2509

2.1.2

VLM(Mistral3ForConditionalGeneration)이라 text-only 로 바꿔야 한다. 준비된 사본: HF private repo PsalMonster/Magistral-Small-2509-text.

2.1.3
python scripts/models/convert_vlm_textonly.py <src> <tokenizer_dir> <dst>
rm -f <dst>/params.json <dst>/tekken.json        # 없애야 vLLM 이 HF 형식으로 읽는다
ln -sfn <dst> models/mistralai/magistral-24b-2509-text
2.1.4
단계내용
2.1.4.1vision 제거vision_tower.*, multi_modal_projector.* tensor 222개
2.1.4.2prefix 변경language_model.model.* → model.*
2.1.4.3configtop-level 로 올리고 MistralForCausalLM · mistral · eos_token_id: 2
2.1.4.4tokenizer공식 repo 에 없어 unsloth/Magistral-Small-2509 에서 가져옴
2.1.5

skt/A.X-3.1

2.1.6

LlamaForCausalLM 이라 변환이 필요 없다. 이름만 맞춰 준다.

2.1.7
huggingface-cli download skt/A.X-3.1 --local-dir models/skt/A.X-3.1
ln -sfn A.X-3.1 models/skt/ax-35b-3.1            # SparseSpec 크기 parsing
# NEO 는 pacpu 에 48/64/8 macro 추가 후 build (실행 환경 → NEO)
2.1.8
항목값
2.1.8.1층/Q/KV · head_dim · ctx48 / 64 / 8 (GQA ratio 8) · 128 · 32,768
2.1.8.2sliding window · bias · rope scaling모두 없음
2.1.8.3weight69.34 GB (BF16), 약 34.7B params
2.1.9

ibm-granite/granite-4.2-30b

2.1.10

변환은 필요 없다(GraniteForCausalLM 이 vLLM registry 에 있고 attention_multiplier 도 읽는다). 긴 컨텍스트를 쓰려면 밑작업이 따로 있다. n88(H200 1장, TP=1)에서 확인.

2.1.11
항목값
2.1.11.1층/Q/KV · head_dim64 / 32 / 8 (GQA ratio 4) · 128
2.1.11.2max_position_embeddings131,072
2.1.11.3rope_scaling · rope_thetanull · 50,000,000
2.1.11.4attention_multiplier0.0078125 (= 1/128, 표준 1/√d 의 11.3배 차이)
2.1.11.5weight · KV / token54.53 GiB · 256 KiB (Qwen3-30B-A3B 의 2.67배)
2.1.12
1) 128K 를 넘기려면
2.1.13
  • 기(상황) checkpoint 는 max_position_embeddings=131072 만 싣고 나온다. vLLM 은 이 값으로 상한을 잡는다(vllm/config/model.py:2022)
  • 승(증상) README 는 512K 를 내걸지만 확장 방법이 없다. 서빙 예시는 전부 --max-model-len 131072
  • 전(원인) Granite 는 yarn 이 아니라 rope_theta 50M 으로 길이를 확보하는 설계다(Llama-3 의 100배)
  • 결(조치) rope 는 두고 max_position_embeddings 만 올린 사본을 만든다. yarn 을 덧씌우면 128K 이하 구간까지 망가진다. 짧은 실험은 원본 config
2.1.14
# weight 는 symlink 라 54.53 GiB 를 복사하지 않는다. config.json 한 줄만 바꾼다.
python make_mpe.py models/ibm-granite/granite-30b-4.2 models/ibm-granite/granite-30b-4.2-mpe288k 294912
2.1.15
2) max_model_len 은 prompt + generation 이다
2.1.16
  • 기(상황) max_model_len=262144 에 262,127 token prompt 를 넣었다
  • 승(증상) 출력이 16 token 에서 finish_reason=length. thinking 모델이라 답을 못 냈다
  • 전(원인) 생성 여유 = max_model_len − prompt_len = 17. max_tokens=8192 는 쓰이지도 못했다
  • 결(조치) mpe 를 prompt + generation 으로 잡는다. 256K + 8K = 270,336 → 294,912 사용. KV pool 실측(util 0.95) 304,176 token
2.1.17
3) H200 한 장의 상한은 256K
2.1.18
GPUTP=1 · util 0.95 KV pool400K 요청
2.1.18.1H200 (140.40 GiB)304,176 token (74.26 GiB)불가 (97.66 GiB 필요)
2.1.18.2RTX PRO 6000 (95.60 GiB)약 130,000 token불가
2.1.19

256K 요청 하나가 64.0 GiB 라 동시 2개는 못 들어간다 → batch 1 순차. 512K 는 TP 2 이상.

2.1.20
4) prompt 는 그 모델 template 으로 새로 감싼다
2.1.21
  • 기(상황) 공용 long-context pool(dump/lb_prompts_qwen/)은 Qwen template 이 박힌 완성 프롬프트이고 길이도 Qwen tokenizer 기준
  • 승(증상) 같은 262144_Q*.txt 가 Granite tokenizer 로는 262,207 ~ 331,057 token 으로 26% 흩어진다. Q1·Q4 는 KV pool 을 넘는다
  • 전(원인) Granite vocab 100,352 < Qwen 151K 라 같은 텍스트가 더 많은 token 이 된다
  • 결(조치) 길이 축을 Granite token 으로 정의하고, Qwen template 을 벗겨 apply_chat_template(enable_thinking=True) 로 다시 감싼다. <text> 안쪽만 자르고 질문·보기·형식 지시는 보존
2.1.22
자르는 규칙 (펼치기)
1. <|im_start|> / <|im_end|> 를 벗기고 user turn 의 내용만 남긴다
2. <text> 안쪽만 잘라 목표 토큰 수를 맞춘다
3. 질문 · 보기 · "Format your response..." 는 절대 자르지 않는다 (꼬리는 80~422 토큰)
4. tokenizer.apply_chat_template(..., enable_thinking=True) 로 다시 감싼다
5. 감싼 뒤 디코딩해 앞뒤를 눈으로 확인한다
ground truth 는 prompt 에 없다. 질문 문자열로 LongBench-v2 를 역조회해 "The correct answer is (X)" 와 대조한다.
2.1.23
5) 실행 설정
2.1.24
항목값비고
2.1.24.1envvllm0140vanilla_L40S 는 CPU 빌드라 H200 에서 못 쓴다
2.1.24.2modelgranite-30b-4.2-mpe288krope 원본, mpe 만 294,912
2.1.24.3gpu_memory_utilization0.950.90 이면 KV pool 이 256K 에 6.7% 여유뿐
2.1.24.4enable_prefix_cachingFalse길이별 대조라 셀이 캐시를 공유하면 안 된다
2.1.24.5samplingtemperature 1.0 / top_p 0.95generation_config.json 값, thinking ON
2.1.25
6) 256K 는 동작한다
2.1.26
  • 기(상황) mpe 상향 사본으로 262,144 Granite token 을 H200 TP=1 에 넣었다 (LongBench-v2 5문항, max_model_len 307,200 · util 0.97 · max_tokens 8,192)
  • 승(증상) 정답 2/4 (Q4 는 원본 데이터셋과 질문 문자열이 달라 정답 대조 실패 → 분모 제외). 벤치마크의 상위 모델도 50% 안팎
  • 전(원인) 생성문이 본문을 정확히 인용한다(LoraConfig(..., use_dora=True), cluster_jaxpr_by_cost, 몽테크리스토 27장). 위치 인코딩 붕괴가 아니다
  • 결(조치) 결과 jh_script/claude_script/results/20260921_214419_granite_lb_lenscan/. 64K·128K·192K needle 판은 전부 stop 정상 종료
2.1.27
문항출력종료답 / 정답판정
2.1.27.1Q15,300stopD / A✗ 본문은 읽었으나 마지막 일반화가 틀림
2.1.27.2Q21,621stopD / C✗
2.1.27.3Q32,291stopB / B✓
2.1.27.4Q48,192lengthD / —thinking 미수렴 (8-gram 고유율 0.219, 텍스트는 온전)
2.1.27.5Q56,245stopD / D✓
2.1.28
  • max_tokens 권고는 16,384. 정상 생성 최대는 6,245 였으나 수렴하지 않는 문항(Q4)이 실제로 나왔다
  • 8-gram 고유율은 0.20~0.94 로 흔들리고 Q5 는 0.20 인데도 정답. thinking 모델에서는 finish_reason 이 더 나은 반복 신호다
  • 생성 예시 원문(Q1·Q4·Q5)은 축약 전 원문 2절 7) 에 있다
2.2.1

시스템별 설정

2.2.2
TandemSpec
2.2.3

vLLM fork + CPU verify. 두 모델 모두 코드 수정 없음.

2.2.4
export ST_MODEL=<model_dir> ST_ROUTER=1          # ROUTER=0 이면 순수 CompressSpec
bash scripts/models/smoke/run_smoke_vllm.sh      # 엔진 단독 확인
bash scripts/saturate/run_sweep.sh <arm>         # AIME harness
2.2.5
항목값
2.2.5.1envvllm0140
2.2.5.2GQAMagistral 4, A.X-3.1 8 → 둘 다 2의 거듭제곱이라 CPU attention 수정 불필요
2.2.5.3주의aime_data.py 는 jsonl 의 id key 를 기대. baseline jsonl 은 problem_idx
2.2.6
HeadInfer
2.2.7

registry 에 architecture 를 등록하면 끝난다. A.X-3.1(llama)은 이미 있다.

2.2.8
# headinfer/mp_modern.py 에 _register("mistral", "MistralForCausalLM", "MistralAttention") 한 줄
HI_SRC=<clone> HI_MODEL=<model> CTX=0 LB_DIR=<docs> python scripts/longcontext/lib/hi_lb.py
2.2.9
항목값
2.2.9.1env · branchheadinfer-qwen3 · third-party/mistral-support (PSAL-POSTECH/headinfer)
2.2.9.2입력CTX=0 자연 길이 모드, doc*.txt 를 읽음
2.2.11

유일하게 매번 손이 가는 곳. model type 허용 + pacpu shape + GPU architecture 별 build.

2.2.12
# pacpu/dtype.h 에 NUM_LAYERS / NUM_Q_HEADS / NUM_KV_HEADS 세 줄을 넣고
bash scripts/models/smoke/neo_pacpu_build_all.sh    # CPU 쪽, shape 별
bash scripts/models/smoke/neo_csrc_build_sm90.sh    # GPU 쪽, architecture 별
2.2.13
항목값
2.2.13.1env · branchneo · third-party/mistral-ax-support (PSAL-POSTECH/NEO), dtype FP16 고정
2.2.13.2clone 위치<ws>/third-party/NEO + <ws>/compressspec symlink
2.2.13.3이미 있는 shape32/32/8, 36/32/8, 40/40/8, 48/32/4, 64/64/8, 80/64/8, 40/32/8, 48/64/8, 64/32/8
2.2.14
SparseSpec
2.2.15

코드 수정 없음. 경로 이름과 config 두 가지만 맞춘다.

2.2.16
ln -sfn <model_dir> models/<name>-24b-...          # 이름에서 parameter 크기를 읽는다
python -c "import json;p='<model>/config.json';c=json.load(open(p));c.setdefault('eos_token_id',2);json.dump(c,open(p,'w'))"
torchrun --standalone --nproc_per_node=1 serve/run_sat.py --model_name <model> --dtype bfloat16 ...
2.2.17
항목값
2.2.17.1env · 본체sparsespec · baseline/SparseSpec
2.2.17.2score tile(spec_stride+1) × (q/kv). Magistral 36, A.X-3.1 72 (64 초과지만 실행 정상)
2.2.17.3전체 인자--kv_cache pillar --admit_policy offloading --chunk_size 2048 --spec_stride 8 --budget_ratio 0.05
2.2.18

측정 계약 (RTX PRO 6000 large batch)

2.2.19

Pod 의 /workspace/aime30b 에 Qwen3-30B-A3B-Thinking-2507(yarn2)로 돌린 batch 스윕이 있다. 같은 계약을 따라야 비교가 된다.

2.2.20
항목값
2.2.20.1armb4r16 ~ b64r256 × {SparseSpec, vanilla}, 요청 수 = batch × 4
2.2.20.2입력 pool · MAXLEN · OUT_CAPAIME 2025 30문제 순환 · 40,960 · 39,936
2.2.20.3samplingtemperature 0.6 · top_p 0.95 · top_k 20 · seed 0 (Nebius 장문 실험도 같음)
2.2.20.4mem_fraction · chunk0.85 · vanilla 16,384 / SparseSpec 2,048 (유일하게 의도한 arm 차이)
2.2.20.5SparseSpec--spec_stride 8 --budget_ratio 0.05 --num_min_budget 128 --clip_length (OUT_CAP + 최장 prompt) + SSPEC_FIXED_OUTPUT
2.2.20.6tracevanilla ITER_TRACE=1 DUMP_INTERVAL=20, SparseSpec SSPEC_ITER_TRACE=1 SSPEC_REQ_TIMING=1 SSPEC_ACCEPT_CHECK=1
2.2.20.7결과 · 안전장치04_results/<arm>_<TS>/ · 실행 전 memory.used ≥ 500 MiB 이면 거부
2.2.21

모델이 권장하는 sampling 값

2.2.22

generation_config.json 에 실제로 들어 있는 값. — 는 미지정. 시스템 간 비교가 목적이면 0.6 / 0.95 / 20 통일, 모델 품질을 보려면 권장값.

2.2.23
모델temperaturetop_ptop_kmax_new_tokens출처
2.2.23.1우리 실험값 (기존 계약)0.60.952039,936 (cap)run_arm_30b.sh
2.2.23.2Qwen/Qwen3-30B-A3B-Thinking-25070.60.9520—generation_config.json ↗
2.2.23.3Qwen/Qwen3-32B0.60.9520—generation_config.json ↗
2.2.23.4mistralai/Magistral-Small-25090.70.95—131,072generation_config.json ↗
2.2.23.5skt/A.X-3.1———28,000generation_config.json ↗
2.2.24

ctx · 출력 cap · eos

2.2.25

cap 39,936 이 그대로 쓰이는지는 최장 입력 + 39,936 > ctx 로 판정.

2.2.26
모델native ctxYaRN최장 입력판정eos (config / generation_config)
2.2.26.1Magistral-Small-2509131,072없음872여유2 (우리가 넣음) / 2
2.2.26.2skt/A.X-3.132,768factor 4 → 131,072751초과0 / 27 — SparseSpec 은 [0, 0, 27, 2] 를 모두 stop 으로 잡음
2.2.26.3Qwen3-30B-A3B-Thinking-2507262,144기존 실험은 yarn2 사본872여유
2.2.26.4Qwen3-32B32,768factor 4 → 131,072872초과
2.2.26.5Qwen3-4B-Thinking-2507262,144없음872여유
2.2.27
  • A.X-3.1·Qwen3-32B 는 cap 을 28,000 이하로 낮추거나 YaRN 사본(-yarn4 처럼 이름으로 구분)을 쓴다. YaRN 은 rope 를 바꾸므로 다른 모델과 같은 조건이 아니다
  • A.X-3.1 YaRN 4배 실측(2026-09-20): 자연 종료 중앙값 1,173 token, 강제 채움 시 8-gram 고유율 0.451. 현황 탭 참고
2.2.28

RTX PRO 6000 준비

2.2.29
대상sm_120 에서 해야 하는 것
2.2.29.1NEO swiftllm_cTORCH_CUDA_ARCH_LIST=12.0 으로 재빌드
2.2.29.2NEO pacpuCPU 전용이라 arch 무관. shape macro 만 있으면 됨
2.2.29.3vLLM fork _C`cuobjdump --list-elf _C.abi3.so \grep sm_120` 로 확인
2.2.29.4FlashInferJIT cache 를 /workspace 로 (/tmp 는 재시작 때 사라짐)
2.2.29.5neo·headinfer env 의 torchcu121 이라 sm_120 이 없다. 교체 필요. pip install vllm-flash-attn 은 neo env 를 망가뜨리므로 install_fa_shim.py
2.2.30
Pod 운영값
2.2.30.1저장소 · GPU300 GB 중 약 120 GiB 여유 (text-only 43.9 GiB 만 받음) · 95.6 GiB 가시
2.2.30.2envsparsespec, vllm_probe 만 있음. neo·headinfer 는 새로 만들어야 함
2.2.30.3결과 보존/tmp·/root 는 정지 시 사라짐. /workspace 에 둔다
2.2.30.4접속proxy 는 동시 연결 1개. 명령을 겹쳐 보내지 않는다
2.3.1

같은 함정이 RTX PRO 6000 에서도 재발한다.

2.3.2

1. 변환본에 Mistral 형식 파일이 남음

2.3.3
  • 기(상황) VLM 을 text-only 로 변환해 vLLM 에 올렸다
  • 승(증상) shard 를 못 열고 FileNotFoundError. trace 가 pixtral.py 를 지난다
  • 전(원인) params.json·tekken.json 이 남아 vLLM 이 Mistral 형식(VLM loader)으로 오인
  • 결(조치) 두 파일을 지운다. 지우면 llama.py 경로로 들어간다
2.3.4

2. config 에 eos_token_id 가 없음

2.3.5
  • 기(상황) 변환본을 SparseSpec 에 넘겼다
  • 승(증상) "Missing required HF config fields" 로 거부
  • 전(원인) text_config 를 top-level 로 올릴 때 eos_token_id 가 빠졌다
  • 결(조치) generation_config.json 값을 config 에 넣는다 (Magistral 은 2)
2.3.6

3. 모델 경로 이름에 크기가 없음

2.3.7
  • 기(상황) 모델 경로를 받은 이름 그대로 지정했다
  • 승(증상) SparseSpec 이 Unsupported <name> 으로 거부
  • 전(원인) 경로 이름에서 parameter 크기를 정규식으로 읽는 구조
  • 결(조치) 이름에 24b·35b 가 든 symlink 를 만든다
2.3.8

4. NEO clone 위치

2.3.9
  • 기(상황) NEO clone 을 임의 위치에 두고 실행했다
  • 승(증상) numa_first_touch.py 를 못 찾는다며 종료
  • 전(원인) checkout 기준 4단계 위에서 compressspec/ 을 찾는다
  • 결(조치) <ws>/third-party/NEO 배치 + <ws>/compressspec symlink
2.3.10

5. GPU architecture 가 다른 build

2.3.11
  • 기(상황) L40S 용 build 를 H200 에서 그대로 썼다
  • 승(증상) no kernel image is available for execution
  • 전(원인) swiftllm_c 가 sm_89 전용. PRO 6000 은 sm_120 이라 더 넓게 발생
  • 결(조치) TORCH_CUDA_ARCH_LIST 를 주고 확장을 다시 build
2.3.12

6. CUDA toolkit 과 torch 불일치

2.3.13
  • 기(상황) pacpu 를 build 하려 했다
  • 승(증상) cmake 가 Failed to find nvToolsExt 로 실패
  • 전(원인) PATH 의 CUDA toolkit 과 torch 의 cu 버전이 다르다
  • 결(조치) torch 에 맞는 toolkit 을 CUDA_HOME 으로 지정
2.3.14

7. 한 GPU 에서 두 판이 겹침

2.3.15
  • 기(상황) 앞 판이 모델을 올리는 중에 다음 판을 띄웠다
  • 승(증상) CUDA out of memory (KV 53.63 GiB 요청, 4.86 GiB 남음)
  • 전(원인) 한 GPU 에서 두 판이 동시에 메모리를 잡았다
  • 결(조치) 앞 판이 끝나고 memory.used 가 0 인 것을 보고 띄운다
2.4.1

모델마다 chat template 이 달라 pool 을 새로 만든다. Qwen3 용 pool 을 재사용하면 안 된다.

2.4.2
python scripts/models/make_aime_pool.py <aime2025.jsonl> <model_dir> <out_dir>
# 결과: p00.txt ~ p29.txt (30문제) + meta.json
2.4.3
모델prompt 길이template
2.4.3.1Magistral144 ~ 872 tokensystem message 가 없으면 [THINK] system prompt 자동 삽입
2.4.3.2A.X-3.133 ~ 751 token`<\im_start\><\user\>`
2.4.3.3Granite43 ~ 804 tokenGranite chat template
2.4.3.4Qwen3-4B38 ~ 778 tokenQwen3 chat template
2.4.4

unsloth tokenizer 는 regex pattern 경고가 난다. 본 측정 전에 fix_mistral_regex=True 로 다시 저장할지 정해야 한다.

2.5.1

승인 대기 목록. 모두 clone 에서만 고쳤고 공유 tree 와 dev 에는 올리지 않았다. - 가 수정 전, + 가 수정 후.

2.5.2

[Magistral · A.X-3.1 · Granite] 모델 등록

2.5.3

새 architecture 는 세 곳의 지원 목록에 더해야 한다. 등록하지 않으면 TypeError·assert·pacpu #error 로 멈춘다.

2.5.4
 # HeadInfer — headinfer/mp_modern.py:47-52
+_register("mistral", "MistralForCausalLM", "MistralAttention")
+_register("granite", "GraniteForCausalLM", "GraniteAttention")
 # NEO — swiftllm/model_config.py:7
-SUPPORTED_MODEL_TYPES = ("llama", "qwen3", "qwen3_moe")
+SUPPORTED_MODEL_TYPES = ("llama", "mistral", "granite", "qwen3", "qwen3_moe")
 # NEO — pacpu/dtype.h (MISTRAL_24B 40/32/8 · AX_35B 48/64/8 · GRANITE_30B 64/32/8)
+#elif defined(GRANITE_30B)
+  #define NUM_LAYERS 64
+  #define NUM_Q_HEADS (32 / TP_DEGREE)
+  #define NUM_KV_HEADS (8 / TP_DEGREE)
2.5.5

shape 마다 bash build.sh <name> 1 로 .so 를 만든다.

2.5.6

[Granite] attention_multiplier 파라미터 추가

2.5.7
  • 기(상황) SparseSpec 과 NEO 는 attention scale 을 1/√head_dim 으로 가정한다. 모델이 다른 값을 쓰면 반영할 통로가 없다
  • 승(증상) Granite 에서 SparseSpec acceptance 52.35% · 30.07 tok/s, NEO 첫 토큰이 반복·특수문자. 둘 다 오류는 없었다
  • 전(원인) Granite 는 attention_multiplier = 0.0078125(1/128)인데 두 엔진이 이 필드를 읽지 않는다. 1/√128 = 0.0884 와 11.3배 차이
  • 결(조치) config 값을 scale 로 흘려 넣는다. 값이 없는 모델은 기존 식. kernel 에 넘기는 상수 하나라 연산량·메모리는 그대로
2.5.8
검증 (H200, 정확성 기준)수정 전수정 후
2.5.8.1SparseSpec acceptance52.35%86.92%
2.5.8.2NEO 첫 토큰[100274, 100274, 65, 65, 28, 198][1687, 1205, 311, 1505, 7698, 23963]
2.5.8.3회귀 (Magistral, override 없음)93.93%91.24% — 순전파가 비재현적이라 ±2%p 는 정상 범위
2.5.9
patch 원문 6곳 (펼치기)

NEO — swiftllm/model_config.py:41 (생성자)

 self.vocab_size = model_config["vocab_size"]
+self.attention_multiplier = model_config.get("attention_multiplier")

NEO — swiftllm/model_config.py:120-122 (softmax_scale property)

     @property
     def softmax_scale(self) -> float:
-        return self.head_dim ** -0.5
+        # Granite ships attention_multiplier (1/d) instead of the usual 1/sqrt(d).
+        return self.attention_multiplier or self.head_dim ** -0.5

SparseSpec — serve/model/config.py:36-37 (ModelArgs)

     rope_type: str = None
+    attention_multiplier: float = None   # Granite: 1/d instead of 1/sqrt(d)

SparseSpec — serve/attention/backend.py:5

 import math
+
+# set once from the model config; None keeps the 1/sqrt(head_dim) default
+ATTENTION_SCALE_OVERRIDE = None

SparseSpec — serve/attention/backend.py:350 과 :388 (두 곳 모두)

         if self._sm_scale is None:
-            self._sm_scale = 1.0 / math.sqrt(head_dim_qk)
+            self._sm_scale = ATTENTION_SCALE_OVERRIDE or 1.0 / math.sqrt(head_dim_qk)

SparseSpec — serve/run_sat.py:194-198

     model_config = ModelArgs.from_name(config_name)
+    if getattr(model_config, "attention_multiplier", None):
+        from serve.attention import backend as _attn_backend
+        _attn_backend.ATTENTION_SCALE_OVERRIDE = float(model_config.attention_multiplier)
+        logging.info(f"[attn] scale override {model_config.attention_multiplier}")
2.5.10

clone 위치

2.5.11

Granite 패치는 2026-09-22 에 서브모듈 baseline_update branch 로 push 했다(origin/dev 에서 분기, dev 는 그대로). dev 반영은 승인 후.

2.5.12
대상정본 (push 됨)실험용 clone
2.5.12.1HeadInferthird-party/headinfer · baseline_update · d85be78tmp/headinfer_mistral
2.5.12.2NEOthird-party/NEO · baseline_update · 66243adtmp/neo_ws/third-party/NEO
2.5.12.3SparseSpec아직 dev 위 미커밋tmp/sparsespec_granite
2.5.13

NEO 는 clone 만으로는 돌지 않는다. git 에 없는 빌드 산출물 두 개가 더 필요하다.

2.5.14
산출물성격없으면
2.5.14.1pacpu/build/libpacpu-granite_30b-tp1.so모델 shape 을 macro 로 굽는다 (GRANITE_30B 64/32/8)neo_lb.py:68 assert 에서 멈춘다
2.5.14.2swiftllm_c.cpython-310-*.soCUDA extension, GPU architecture 별no kernel image is available for execution on the device
2.5.15

2026-09-22 확인은 tmp/neo_ws/pacpu_so/·tmp/neo_ws/ext_sm90/ 을 참조했다. pacpu 재빌드는 CMake 4.4.2 에서 CUDA::nvToolsExt target 이 사라져 실패 → CMake 3.x 로 내리거나 우회.

2.5.16

새 모델 추가 절차

2.5.17
  1. config.json 을 받아 README.md 의 체크리스트 14개를 대조한다.
  2. VLM 이면 text-only 로 변환한다.
  3. NEO pacpu 에 (층/q/kv) shape 가 있는지 보고, 없으면 macro 추가 후 build 한다.
  4. 이름에 <크기>b 가 든 경로와 eos_token_id 를 준비한다.
  5. 그 모델의 chat template 으로 AIME pool 을 만든다.
  6. smoke 를 vLLM → HeadInfer → SparseSpec → NEO 순서로, 한 번에 하나씩 돌린다.
2.6.1
KV per token = 2 (K,V) × layers × kv_heads × head_dim × dtype_bytes     ← num_key_value_heads 를 쓴다
Granite-4.2-30B BF16 = 2 × 64 × 8 × 128 × 2 = 262,144 B = 256 KiB
KV pool   = GPU total × gpu_memory_utilization − weight − overhead
max token = KV pool ÷ (KV per token)                                    ← prompt + generation 합계 상한
2.6.2
모델layersqkvratioKV / tokenweight
2.6.2.1Qwen3-4B-Thinking-2507363284144 KiB7.49 GiB
2.6.2.2Qwen3-30B-A3B (MoE)48324896 KiB56.87 GiB (상주. decode 가 읽는 byte 는 활성 expert 만)
2.6.2.3Magistral-Small-2509403284160 KiB43.91 GiB
2.6.2.4Granite-4.2-30B643284256 KiB54.53 GiB
2.6.2.5Llama-3.1-8B-Instruct323284128 KiB14.96 GiB
2.6.3

GPU 메모리는 H200 143,771 MiB(n88) · L40S 46,068 MiB(n82) · RTX PRO 6000 97,887 MiB(Nebius) 실측, RTX 4090 24,564 MiB 만 스펙값.

2.6.4
—GPU 메모리
—weight
—KV pool
—max token
—
컨텍스트KV동시 요청
2.6.5
overhead 기본값 4.59 GiB 의 근거와 한계 (펼치기)
Granite-4.2-30B · H200 · util 0.95 에서 vLLM 이 찍은 GPU KV cache size: 304,176 tokens 를 역산.
140.40 GiB × 0.95 − 54.53 − 4.59 = 74.26 GiB.
overhead 는 activation buffer 와 CUDA graph 라 GPU·모델·max_num_batched_tokens 에 따라 달라진다.
다른 조합에 4.59 를 그대로 쓰지 말고 한 번은 엔진을 올려 GPU KV cache size 를 보고 맞춘다.
Qwen3-4B · RTX PRO 6000 · fraction 0.85 의 SparseSpec 로그(Model 7.45 GB, KV 73.27 GB)는 overhead 가 거의 0 으로 보이나
vLLM 회계와 같은 기준인지 확인하지 않았다. 동시 요청 수는 KV pool 만 본 상한이고 스케줄러는 더 적게 받는다.

결과

3.1.1

측정 노드 Nebius RTX PRO 6000 (81.85.1.77, 97,887 MiB).

3.1.2
항목값
3.1.2.1batch · 요청batch × 4 (pool 30문제 순환), 요청수 − batch 개 완료 시 중단
3.1.2.2출력 cap32,768 (batch 스윕) · 39,936 (스윕 이전 고정판)
3.1.2.3samplingtemperature 0.6 · top_p 0.95 · top_k 20 · seed 0
3.1.2.4vanillaCompressSpec fork 0.14.1.dev236 의 compression 스위치를 끈 arm, core 0-3
3.1.2.5SparseSpecspec_stride 8 · budget_ratio 0.05 · num_min_budget 128, core 0-23
3.1.3
armbatch요청상태
3.1.3.1mag_van_b8r32_c32k · mag_ss_b8r32_c32k832완료
3.1.3.2mag_van_b16r64_c32k · mag_ss_b16r64_c32k1664완료
3.1.3.3mag_van_b32r128_c32k32128진행 중
3.1.3.4mag_ss_b32r128_c32k32128대기
3.1.3.5b64 van · SS64256대기
3.1.4
Magistral cap 32,768 batch 스윕. 열 = vanilla · SparseSpec · TandemSpec, 행 = batch. 각 칸은 위 output tps(20초 window) · 가운데 GPU-run batch · 아래 GPU KV utilization. 보라색 선 stable tps, 빨간색 선 e2e tps, 회색 구간은 stable 평균에서 제외한 warmup·cooldown
3.1.4.c Magistral cap 32,768 batch 스윕. 열 = vanilla · SparseSpec · TandemSpec, 행 = batch. 각 칸은 위 output tps(20초 window) · 가운데 GPU-run batch · 아래 GPU KV utilization. 보라색 선 stable tps, 빨간색 선 e2e tps, 회색 구간은 stable 평균에서 제외한 warmup·cooldown
3.1.5
batchvanilla stableSparseSpec stable배수vanilla KV util
3.1.5.18180.6151.50.8435.0%
3.1.5.216305.8277.80.9170.6%
3.1.5.332진행 중대기—96.1%
3.1.6

batch 를 올리면 KV utilization 과 배수가 같이 오르지만 아직 1 을 넘지 못했다. stable window 는 앞 batch 개 완료(warmup)를 빼고 시작하며, 요청수 − batch 에서 중단한 run 은 cooldown 이 없어 뒤를 자르지 않는다.

3.1.7
cap 39,936 고정판 (스윕 이전)vanilla b8r32SparseSpec b8r32
3.1.7.1stable tps184.2153.4 (0.83배)
3.1.7.2acceptance rate—78.41% (verify step 80,377, 504,124 / 642,896)
3.1.7.3출력 길이 중앙값14,89616,644
3.1.8

breakdown 뷰어

3.1.9

BD_COARSE=1 phase timeline. 조건과 읽는 법은 3.2 Granite 와 같다.

3.1.10
조건값
3.1.10.1모델 · 노드Magistral-Small-2509 (text-only, 40층 · kv 8) · n88 H200 1장
3.1.10.2컨텍스트32,768 token · decode 16 token · warmup 1 · iters 1
3.1.11
시스템prefill (iter0)decodephase row시간이 쌓이는 곳
3.1.11.1HeadInfer5.93 s733 ms/tok16,978PCIe h2d 9.46 s · d2h 1.97 s (GPU attn 2.39 s)
3.1.11.2NEO3.7 s139 ms/tok3,554CPU pacpu 1.88 s (PF 5.97 s · DC 2.49 s)
3.1.12

pseudo-layer 40 × 8 = 320 이라 Granite(512)보다 PCIe 항목이 적다(PCIe 11,200 vs 17,920). 층수 × kv head 수가 그대로 전송 횟수다.

3.1.13
3.2.1

n88(H200)에서 네 시스템 확인 완료. 수정 내용은 2.5 코드 수정, 판정은 정확성 기준(속도는 H200 값이라 적지 않음).

3.2.2
시스템상태적용한 수정판정 근거
3.2.2.1vLLM 엔진통과없음registry 에 있고 attention_multiplier 를 읽음
3.2.2.2HeadInfer통과registry 한 줄64층 × 8 kv = 512 pseudo-layer 로 동작
3.2.2.3SparseSpec통과attention scale overrideacceptance 52.35% → 86.92%
3.2.2.4NEO통과granite type · scale · pacpu 64/32/8첫 토큰이 반복·특수문자에서 정상 토큰으로 바뀜
3.2.3

서브모듈 baseline_update 재확인 (2026-09-22, n88)

3.2.4
  • 기(상황) 패치를 서브모듈로 옮긴 뒤 같은 노드에서 같은 26-token 프롬프트(chat_template.jinja 적용)로 다시 돌렸다. vanilla transformers 를 대조군으로
  • 승(증상) 세 경로의 token id 가 완전히 일치. vanilla 32 tok = HeadInfer 32 tok, NEO 는 생성한 17 tok 전부 동일
  • 전(원인) 셋 다 greedy 라 일치 = 세 구현이 옳다. 통상 경로로 빠진 것이 아님은 아래 속도·경로로 확인
  • 결(조치) 스크립트 jh_script/claude_script/granite_baseline_check/. neo env 의 transformers 는 chat_template.jinja 를 못 읽으므로 직접 넣는다
3.2.5
forwardKV 위치속도
3.2.5.1vanillaforward (기본)전부 GPU52 ms/tok
3.2.5.2HeadInferheadinfer_attention_forward (layer_idx_base=504)cpu=510 / gpu=2429 ms/tok (8.3배 느림 = CPU 왕복의 증거)
3.2.5.3NEOswiftllm 자체 엔진[POOL] owned=1 k_pinned=True v_pinned=True65 ms/tok, softmax_scale=0.0078125 확인
3.2.6

breakdown 뷰어

3.2.7

BD_COARSE=1 phase timeline. phase 경계마다 cuda.synchronize() + perf_counter() 를 찍어 긴 컨텍스트에서도 돈다. 레인은 GPU · PCIe · CPU.

3.2.8
조건값
3.2.8.1모델 · 노드Granite-4.2-30B · n88 H200 1장
3.2.8.2컨텍스트 · decode32,768 token (lb_docs_synth/doc0.txt) · 16 token, warmup 1 · iters 1
3.2.9
시스템prefill (iter0)decodephase row시간이 쌓이는 곳
3.2.9.1HeadInfer8.71 s1,171 ms/tok27,154PCIe h2d 15.1 s · d2h 3.1 s (GPU attn 3.8 s)
3.2.9.2NEO5.1 s218 ms/tok5,666CPU pacpu 3.0 s (PF 7.95 s · DC 3.85 s)
3.2.10

HeadInfer 는 토큰마다 KV 를 CPU 에서 다시 끌어와 PCIe 18.2 초가 GPU attention 3.8 초를 압도한다.

3.2.11

HeadInfer 의 h2d/d2h 는 BD_PREALLOC_CACHE=1 이 있어야 찍힌다. 빠뜨리면 PCIe·CPU 레인이 비고 전부 attn 으로 남아 계측 누락을 성능 특성으로 오독한다(2026-09-22 실제 발생).

3.2.12
3.2.13

RTX PRO 6000 측정 (cap 32,768)

3.2.14

긴 컨텍스트 준비와 생성 품질은 2.1 Granite. 한 GPU 에 한 판씩 순차. sampling 은 generation_config.json 기본값.

3.2.15
항목값
3.2.15.1batch · 요청8 · 32 (pool 30문제 순환)
3.2.15.2출력 cap · sampling32,768 (MAXLEN 33,792) · temperature 1.0 · top_p 0.95 · seed 0
3.2.15.3armgra_van_b8r32_c32k 28/32 중단 (kv_util 100%, preempted) · gra_ss_b8r32_c32k 24/32 중단
3.2.16
Granite cap 32,768 판. 열 = vanilla · SparseSpec · TandemSpec, 행 = batch. 각 칸은 위 output tps(20초 window) · 가운데 GPU-run batch · 아래 GPU KV utilization
3.2.16.c Granite cap 32,768 판. 열 = vanilla · SparseSpec · TandemSpec, 행 = batch. 각 칸은 위 output tps(20초 window) · 가운데 GPU-run batch · 아래 GPU KV utilization
3.2.17
값vanilla b8r32 (28/32)SparseSpec
3.2.17.1stable tps69.5 tok/s104.3 tok/s (1.50배)
3.2.17.2e2e tps92.9 tok/s108.1 tok/s
3.2.17.3GPU KV utilization 평균78.9%67.4%
3.2.18
  • 기(상황) 8 요청 × 32K × 256 KB = 65 GB 가 필요한데 KV pool 은 23.2 GB
  • 승(증상) vanilla kv_util 이 1.000 에 닿고 preemption 발생, running 8 → 6.67
  • 전(원인) vanilla 가 무너지는 구간에 처음 들어간 판. KV 가 GPU 를 넘치면 SparseSpec 이 이긴다
  • 결(조치) cap 8,192 → 32,768 로 평균 out_tok 6,490 → 11,946 (1.84×, 중앙값은 8,192 → 8,478). vanilla stable 172.7 → 93.1, KV util 26.5% → 82.3%
3.2.19
폐기한 판 cap 8,192내용
3.2.19.1폐기 사유32개 중 20개가 cap 에 걸려 length 종료. KV 가 쌓이기 전에 끝나 f 가 0.11
3.2.19.2남긴 수치vanilla stable 172.7 · SparseSpec 118.8 (0.69배), acceptance 70.42%
3.2.19.3scale override 효과Nebius 트리에 override 가 없던 첫 판 acceptance 15.36% · tps 39.5 → 이식 후 71.09% · 118.8 (_ABORTED_no_scale_override 보존)
3.2.19.4파일cs/run/granite/gra_van_b8r32_20260920_105100, gra_ss_b8r32_20260920_120712
3.3.1

논문 조건을 그대로 두고 GPU 만 Blackwell 로 바꾼 대조군. 논문(L40S)은 b8 1.49배 · b16 2.51배 · b32 2.93배.

3.3.2
항목값
3.3.2.1모델36 layer · 32 q · 8 kv · head_dim 128 · weight 7.6 GB
3.3.2.2batch · 요청 · cap8 · 32 (24개에서 중단, 뒤 8개는 cooldown) · 81,920 (MAXLEN 83,968)
3.3.2.3sampling · pooltemperature 0.6 · top_p 0.95 · top_k 20 · seed 0 · Qwen3 template 30문제
3.3.3
열 = vanilla · SparseSpec · TandemSpec, 행 = batch(위 8, 아래 32). 각 칸은 위 output tps(20초 window) · 가운데 GPU-run batch · 아래 GPU KV utilization
3.3.3.c 열 = vanilla · SparseSpec · TandemSpec, 행 = batch(위 8, 아래 32). 각 칸은 위 output tps(20초 window) · 가운데 GPU-run batch · 아래 GPU KV utilization
3.3.4
값vanilla b8r32SparseSpec b8r32
3.3.4.1stable tps424.4 tok/s400.9 tok/s (0.94배)
3.3.4.2e2e tps468.1394.4
3.3.4.3GPU KV utilization 평균20.0%15.6% (최대 23.0%)
3.3.4.4acceptance rate—72.20%
3.3.4.5출력 길이중앙값 18,910 (6,734 ~ 41,604), 25개 전부 EOS완주 후 집계
3.3.5
  • 기(상황) f 가설(vanilla iteration 중 attention 비율)은 상주 KV 절대량이 같으면 같은 배수를 예측한다
  • 승(증상) 논문 L40S b8 은 상주 KV 약 17.4 GB 에서 1.49, 우리 PRO 6000 b8 은 약 16.9 GB 에서 0.94
  • 전(원인) 미규명. 후보는 Blackwell persistent attention kernel 의 CTA 절반, CUDA graph 미적용 iteration(32~38%, +20 ms), round 당 iteration 10개
  • 결(조치) L40S trace 에 같은 분석을 적용해 draft-only KV 기울기가 Ada 에서도 60% 인지 확인 (GPU 불필요, 800 마운트 복구 필요)
3.3.6

vanilla 초반 tps 는 4B 593 · Magistral 239 · Granite 190. weight 가 작을수록 iteration 당 읽는 byte 가 적다.

3.4.1

SparseSpec batch 1 · Qwen3-30B-A3B-Thinking-2507 base · medium144 · 출력 상한 8,192 · LOG_SS=1 — 105/144 에서 정지 (vanilla 판으로 GPU 를 넘기며 멈춤, 실패 0). 이전 LOG_SS=2 판은 계측 비용으로 TPOT 이 약 1.6배 부풀려져 폐기(Marvell_cloud/011·012, TPOT·E2E 사용 금지).

3.4.2
항목값
3.4.2.1모델Qwen3-30B-A3B-Thinking-2507 (base, 창 262,144, YaRN 미사용), bf16
3.4.2.2문서results/RTXPRO6000/longcontext/medium144_selection.json 144개 중 긴 순서로 105개 완료
3.4.2.3SparseSpeccommit 8246fb6 · batch 1 · chunk 2048 · spec_stride 7 · budget_ratio 0.05 · mem_fraction 0.85 · SSPEC_CPU_CAP_MULT=1 · SSPEC_MAX_SELECTED_KV=16384
3.4.2.4생성 · 실행자연 EOS · 상한 8,192 · temp 0.6 / top_p 0.95 / top_k 20 · seed 0 · Nebius 81.85.4.145 × 8, 문서당 프로세스 1개
3.4.2.5지표TTFT = t_first − t_start · TPOT = (t_done − t_first)/(out − 1) · E2E = t_done − t_start
3.4.2.6결과/mnt/filesystem-p1/cs/run/medium144_ss_b1_cap8192_logss1/20260925_045942/ (summary.csv, 요청별 105행)
3.4.3
갱신 블록 · 요약 (펼치기)

정지 (105/144) · 갱신 2026-09-25 15:24:45 KST · 시작 105 / 144 · 완료 105 · 실패 0

setnΣ e2e sΣ TTFT sΣ decode sΣ out tokΣout/Σe2e tok/sTTFT 평균/중앙 sTPOT 평균/중앙 msout 중앙cap 도달
완료 10510510,223.05,988.04,235.0310,56630.3857.03 / 53.3813.75 / 13.572,14110
3.4.4
완료 105Σ out tokΣout/Σe2eTTFT 평균/중앙TPOT 평균/중앙out 중앙cap 도달
3.4.4.1105310,56630.38 tok/s57.03 / 53.38 s13.75 / 13.57 ms2,14110
3.4.5
완료 요청 기준 context 구간(20K)별 TTFT · TPOT · TPS (막대 median, 선 p25–p75, 점 요청 1개), 구간별 요청 수, 출력 token 수 분포(512 단위)
3.4.5.c 완료 요청 기준 context 구간(20K)별 TTFT · TPOT · TPS (막대 median, 선 p25–p75, 점 요청 1개), 구간별 요청 수, 출력 token 수 분포(512 단위)
3.5.1

SparseSpec 재측정 · temperature 0 (greedy) · chunk 1024 · YaRN 끔 · 출력 상한 8,192 · LOG_SS=1 · 문서 20개 (측정 16 + warm-up 4) · 완료.

3.5.2
항목값
3.5.2.1모델 · 엔진Qwen3-30B-A3B-Thinking-2507 base bf16 · SparseSpec 8246fb6 · kv_cache pillar · admit_policy offloading · async_cpu · cuda_graph · mem_fraction 0.85
3.5.2.2sampling · spectemperature 0 → is_greedy_sampling(argmax) · seed 0 · spec_stride 7 · budget_ratio 0.05 · num_min_budget 128 · chunk 1024
3.5.2.3환경변수LOG_SS=1 · SSPEC_REQ_TIMING=1 · SSPEC_CPU_CAP_MULT=1 · SSPEC_MAX_DRAFT_KV=262144 · SSPEC_MAX_SELECTED_KV=16384 · SSPEC_MAX_VERIFY_KV=524288 · SSPEC_FIXED_OUTPUT=8192
3.5.2.4문서 · 분배측정 16개 146,609~205,995 tok (긴 것과 짧은 것을 짝지어 GPU 당 2개) · warm-up 4개 128,996~143,804 tok (GPU 0~3, 4~7 재사용)
3.5.2.5실행GPU 당 프로세스 1개 · batch 1 · warm-up 1 → 측정 2 순차 · clip_length = 최장 prompt + 8,192 · core 24g~24g+23
3.5.2.6결과/mnt/filesystem-p1/cs/run/ss20_temp0_c1024/20260925_070231/ (shards.json, per_request.csv) · 재현 판 ss20_temp0_c1024_rep2/20260925_072725/ (compare_vs_rep1.csv)
3.5.3
측정 16/16Σ out tokΣout/Σe2eTTFT 평균/중앙TPOT 평균/중앙out 중앙cap 도달
3.5.3.11693,79038.68 tok/s73.41 / 71.28 s13.50 / 13.59 ms8,1929
3.5.4
  • 기(상황) temperature 0 재현성: 같은 문서·GPU 배정·설정으로 한 번 더 돌려 요청별 출력 token id 전체를 비교했다 (재판 8 GPU 모두 EXIT=0)
  • 승(증상) 24개 중 23개 전체 일치 (측정 16개 중 15개). GPU 7 670bf1c4 (167,246 tok) 만 1,498번째 token 에서 갈림 — … So the 뒤가 correct / cause
  • 전(원인) 미규명. LOG_SS=1 이라 logit 은 남지 않았다. 최종 답은 둘 다 (C), 출력 길이 1,956 / 1,855
  • 결(조치) 요청별 비교표는 compare_vs_rep1.csv, 축약 전 원문 3.5
3.5.5

재현성 확인 · 갱신 2026-09-25 16:40:53 KST · 재판 종료 GPU 8 / 8 · token 비교 완료 24 / 24 요청 → 전부 같음 23 (측정 15 / 16)

3.5.6

출력 token 분포 (실시간) — 아래 접힌 요청별 표를 읽어 그린다.

3.5.7
기본 0 ~ 8,192 (전체) · Enter 또는 적용
3.5.8
요청별 표 24행 (펼치기)

완료 · 갱신 2026-09-25 16:19:38 KST · 요청 24 / 24 처리 · 종료 GPU 8 / 8

idxdoc idrole상태temperatureGPU순서prompt tokout tokTTFT sTPOT msE2E sTPS종료
067246413bb02136c067d7374measured완료002/3205,9958,192100.9214.06216.137.91cap
166f3a311821e116aacb2de19measured완료012/3201,8522,35098.5614.34132.317.77eos
2670cf52abb02136c067d2728measured완료022/3193,9628,19289.4113.89203.240.31cap
3670bffa2bb02136c067d23b5measured완료032/3193,6708,19289.3713.90203.240.32cap
46724c83fbb02136c067d7962measured완료042/3190,0252,54986.4214.19122.620.80eos
5670bf6ddbb02136c067d2379measured완료052/3181,7928,19278.7313.45188.943.37cap
666ec2755821e116aacb1b6f2measured완료062/3177,6208,19275.4213.37185.044.29cap
767246903bb02136c067d74f2measured완료072/3176,9791,89375.1914.10101.918.58eos
8670bf1c4bb02136c067d2341measured완료073/3167,2461,95667.3814.1295.020.59eos
967246a00bb02136c067d759fmeasured완료063/3162,7163,99564.2813.23117.134.11eos
106725e351bb02136c067d8758measured완료053/3158,1918,19261.4112.95167.448.92cap
1167286698bb02136c067d9223measured완료043/3157,3941,42361.7213.7381.317.51eos
126725d898bb02136c067d82d6measured완료033/3157,2325,89661.7113.09138.842.46eos
1367039cfabb02136c067cd04emeasured완료023/3151,8618,19256.6612.46158.751.60cap
14672464aebb02136c067d73e6measured완료013/3148,4958,19254.6012.64158.251.79cap
1566f95e11bb02136c067c5370measured완료003/3146,6098,19252.8112.53155.552.70cap
16672494e5bb02136c067d7697warmup완료001/3143,8043,49453.8212.7298.235.57eos
16672494e5bb02136c067d7697warmup완료041/3143,8043,49453.4812.6597.735.77eos
176723a0a7bb02136c067d7040warmup완료011/3141,4168,19252.4612.30153.353.45cap
176723a0a7bb02136c067d7040warmup완료051/3141,4168,19252.1612.32153.153.52cap
18670aac92bb02136c067d218awarmup완료021/3138,8018,19249.8012.26150.254.53cap
18670aac92bb02136c067d218awarmup완료061/3138,8018,19249.7912.28150.454.46cap
196725d977bb02136c067d8373warmup완료031/3128,99635645.0214.1850.17.11eos
196725d977bb02136c067d8373warmup완료071/3128,99635644.9214.1449.97.13eos
3.6.1

vanilla vLLM · Qwen3-30B-A3B-Thinking-2507 · temperature 0 · 출력 상한 8,192 · LongBench-v2 medium 라벨 128K 미만 126개 (42K~130K) · GPU 8장 · 완료. 계획서 Medium 구간(170K~194K)이 아니다.

3.6.2
항목값
3.6.2.1엔진CompressSpec 서브모듈 vLLM 0.14.1.dev236 (RULER_MODE=vanilla, 압축 경로 없음), env draft, FLASHINFER
3.6.2.2모델Qwen3-30B-A3B-Thinking-2507 base (YaRN 없음, max_model_len 262,144), bf16, block 32
3.6.2.3문서 · 분배length=medium · prompt < 131,072 tok · 126개. warm-up = 가장 짧은 16개 GPU 당 2개, 측정 110개 (GPU 간 prompt 합 1.33M~1.40M 균등)
3.6.2.4sampling · 생성temperature=0 (EXP_TEMP=0 확인) · seed 0 · 자연 EOS · 상한 8,192 · prefix caching 끔 · chunked prefill 기본(16,384)
3.6.2.5계측RequestOutput.metrics. TTFT = first_token_ts − scheduled_ts · TPOT = (last − first)/(out − 1) · E2E = 요청 wall
3.6.2.6결과/mnt/filesystem-p1/cs/run/vanilla126_temp0_cap8192/20260925_061459/ (per_request.csv, totals.csv)
3.6.3
setnΣ out tokΣout/Σe2eTTFT 평균/중앙TPOT 평균/중앙out 중앙cap 도달
3.6.3.1measured110388,83357.81 tok/s14.05 / 13.15 s13.18 / 13.08 ms2,63319
3.6.3.2warm-up (제외)1648,51341.40 tok/s5.01 / 4.77 s10.33 / 10.25 ms2,2571
3.6.4
측정 요청 기준 context 구간(20K)별 TTFT · TPOT · TPS (막대 median, 선 p25–p75, 점 요청 1개), 구간별 요청 수, 출력 token 수 분포
3.6.4.c 측정 요청 기준 context 구간(20K)별 TTFT · TPOT · TPS (막대 median, 선 p25–p75, 점 요청 1개), 구간별 요청 수, 출력 token 수 분포
3.6.5

출력 token 분포 (실시간) — 아래 접힌 요청별 표를 읽어 그린다.

3.6.6
기본 0 ~ 8,192 (전체) · Enter 또는 적용
3.6.7
요청별 표 126행 (펼치기)

완료 (2026-09-25 15:36 KST, 8 GPU 모두 EXIT=0) · 갱신 2026-09-25 15:47:19 KST · 완료 126 / 126 (측정 110 / 110, warm-up 16 / 16)

idxdoc idroletemperatureprompt tokGPUout tokTTFT sTPOT msE2E sTPS종료
066f568dc821e116aacb33995measured0130,29301,51621.6015.0044.833.86stop
16725da56bb02136c067d841bmeasured0129,02212,99321.3914.9666.644.93stop
26725d92bbb02136c067d833cmeasured0129,01225,63121.4515.05106.652.83stop
36725d977bb02136c067d8373measured0128,99635,18321.5415.0399.851.92stop
46725dda1bb02136c067d8654measured0128,99448,19221.6915.13146.056.10cap
566fad00bbb02136c067c76cemeasured0128,72552,55921.4114.9360.042.63stop
666f4f87b821e116aacb31d62measured0127,66961,94921.0114.8650.438.66stop
766ec4e43821e116aacb1cb54measured0127,01171,52520.8614.8043.834.80stop
86719dc46bb02136c067d470bmeasured0125,49371,72520.3914.7046.137.39stop
96723a770bb02136c067d7233measured0121,33268,19219.1414.65139.558.71cap
1067192e81bb02136c067d427fmeasured0121,232546719.2014.3826.317.73stop
116719185cbb02136c067d40abmeasured0120,902443419.2514.3725.916.76stop
12671b2e2dbb02136c067d515bmeasured0120,67132,69619.0014.4358.346.24stop
13672468b1bb02136c067d74bdmeasured0120,36128,19218.8814.58138.759.07cap
146719167dbb02136c067d4025measured0120,186173418.7914.3329.724.71stop
156718a43fbb02136c067d3ca8measured0120,13601,17618.7114.3436.032.64stop
16671b99e5bb02136c067d583dmeasured0120,07661,99018.8414.3747.841.60stop
17671b5d49bb02136c067d55fbmeasured0120,03115,28518.8214.4795.755.25stop
18671b2822bb02136c067d5020measured0119,96828,19218.8514.56138.559.15cap
1967189156bb02136c067d3b8dmeasured0119,80732,28118.8014.3651.943.91stop
20671b58e8bb02136c067d5525measured0119,787446418.9514.3026.017.85stop
2167192057bb02136c067d41b4measured0119,563532418.8214.2923.913.59stop
2266ed23ce821e116aacb1ee84measured0119,45301,80818.5514.3344.740.42stop
2366ef8aa3821e116aacb22db5measured0119,15072,82018.5114.3459.347.55stop
246719ef50bb02136c067d4911measured0118,99261,63218.5114.3042.238.64stop
256719d65ebb02136c067d45dcmeasured0118,918137618.3814.2724.115.60stop
2667191791bb02136c067d406cmeasured0118,801281418.4514.2630.526.73stop
276703bed0bb02136c067cd381measured0118,35032,31018.4314.2851.844.61stop
2866ebd3ba5a08c7b9b35e0446measured0117,92252,40318.4114.2453.045.35stop
29671a4444bb02136c067d4a40measured0117,774440118.5014.1824.616.32stop
30671b56cfbb02136c067d54e9measured0117,52103,11617.9314.2562.749.67stop
316719c1febb02136c067d44dbmeasured0117,34171,19618.0314.1735.433.83stop
32671b530dbb02136c067d5454measured0117,14502,21217.8814.2049.744.53stop
3366f3c219821e116aacb2eb4emeasured0116,38755,80517.9714.25101.157.43stop
3466f016e6821e116aacb25497measured0115,49048,19217.9014.27135.160.63cap
3566f3d10b821e116aacb2f14fmeasured0115,08832,89917.5014.0858.749.41stop
3666f26c5f821e116aacb2907cmeasured0114,30262,01617.2014.0045.844.04stop
3766eb873c5a08c7b9b35dd849measured0114,16524,32717.2114.0678.455.22stop
38670646aebb02136c067cf85ameasured0113,60513,38916.9813.9964.752.35stop
3966f17aab821e116aacb2772dmeasured0113,31973,06316.8913.9660.051.05stop
4066ed4274821e116aacb1f8f1measured0111,98512,65316.5113.8653.649.51stop
4166f2b5ec821e116aacb2b1ecmeasured0111,47223,67316.4213.8767.754.29stop
4266ebdfb65a08c7b9b35e140ameasured0107,13772,53615.2513.5750.050.76stop
43670c090bbb02136c067d2404measured0106,33468,19215.0813.69127.664.19cap
4466ed1734821e116aacb1ead5measured0104,30438,19214.6113.56126.164.99cap
4566f3cca6821e116aacb2ef7cmeasured0103,34642,25514.4513.3144.850.31stop
4666ec2df6821e116aacb1bb7bmeasured0102,74652,41714.2113.2746.651.84stop
4766f2b11c821e116aacb2aeb6measured0101,64803,28513.8413.2357.657.07stop
4866ec542b821e116aacb1cc87measured0101,60008,19213.8213.39123.866.14cap
4966fa700bbb02136c067c6c06measured0100,30641,00113.7513.0727.236.86stop
50670fb882bb02136c067d2c1dmeasured099,52654,16313.4613.1268.660.71stop
51670fb8dfbb02136c067d2c48measured099,52638,19213.4813.26122.466.93cap
52670fbb1fbb02136c067d2ca4measured099,52568,19213.4213.26122.466.92cap
53670fbae0bb02136c067d2c79measured099,51474,72613.4013.1475.862.34stop
5466ec31eb821e116aacb1bf28measured098,66511,24913.1212.9729.642.14stop
5566f3cb88821e116aacb2eeb9measured098,16728,19213.0513.17121.267.57cap
566725dcb2bb02136c067d85b7measured098,13652,60313.0612.9847.255.19stop
576725dd39bb02136c067d861bmeasured098,05943,72513.1813.0162.060.10stop
586725dc6abb02136c067d8586measured098,05432,55213.0412.9846.554.92stop
5967286533bb02136c067d919fmeasured097,95804,90612.8713.0577.263.55stop
60672864b4bb02136c067d916cmeasured097,92864,23812.9913.0368.561.85stop
616725dc28bb02136c067d8555measured097,76771,85712.9412.9337.349.80stop
6266f2a7a9821e116aacb2a721measured097,28821,58112.8012.8933.447.32stop
6367286ab8bb02136c067d92e4measured096,85618,19212.6813.08120.268.17cap
6466ec6582821e116aacb1cf7ameasured096,44458,19212.7013.05119.968.32cap
65670fbf5abb02136c067d2d9cmeasured096,36048,19212.7813.05120.068.28cap
66670fbfa4bb02136c067d2dcbmeasured096,35538,19212.6713.05119.968.33cap
67670fbbd0bb02136c067d2d04measured096,35004,55612.5212.9371.763.51stop
68670fbb78bb02136c067d2cd3measured096,33068,19212.5913.05119.868.38cap
6966ed211f821e116aacb1ee0dmeasured093,72571,56211.9812.6932.148.66stop
70670cf163bb02136c067d26b6measured093,02021,09211.8212.6225.942.24stop
71670cf1c0bb02136c067d26e5measured093,01411,96011.7912.6536.953.12stop
7266f55ddb821e116aacb33761measured092,63874,02611.8012.6963.163.79stop
736725dbd1bb02136c067d8522measured091,40152,58011.5112.5444.158.44stop
7467286795bb02136c067d92abmeasured091,38443,29111.5912.5753.261.84stop
756725dabfbb02136c067d8450measured091,38335,08111.5212.6475.966.92stop
766725db8bbb02136c067d84ebmeasured091,37503,39311.3912.5854.462.42stop
776725db46bb02136c067d84b4measured091,37123,50811.4712.5855.862.84stop
786725db01bb02136c067d847fmeasured091,36817,84011.4412.72111.470.35stop
7966f8d4b3bb02136c067c45c2measured090,04063,94011.1412.5160.764.95stop
8066f793f4bb02136c067c306emeasured089,49153,17511.1812.4350.962.34stop
8166f19f04821e116aacb27babmeasured088,66143,65010.9412.4056.564.64stop
8266ec4370821e116aacb1c905measured087,20462,72310.6512.2944.361.47stop
8366efa5ea821e116aacb23268measured086,90031,88810.5712.2433.955.70stop
8466f920d8bb02136c067c4b81measured085,32171,76610.2012.1431.955.34stop
8566ec3aff821e116aacb1c52emeasured083,85401,8209.8012.0532.056.84stop
8666ed364d821e116aacb1f47emeasured083,82321,6409.9412.0429.954.84stop
8766fd4f54bb02136c067c9987measured082,58811,2119.5611.9524.349.87stop
8866fa9ff6bb02136c067c71e0measured082,54911,9179.5711.9732.858.49stop
8966f3fb15821e116aacb303dcmeasured081,80508,1929.3212.12108.975.24cap
9066ebd0ea5a08c7b9b35dff57measured081,53422,7369.4111.9342.364.68stop
9166ec3352821e116aacb1c085measured079,48271,3198.9611.7524.753.40stop
9266f3d738821e116aacb2f446measured079,32831,3908.9811.7425.554.51stop
9366f379e8821e116aacb2d161measured078,63161,6338.8011.7128.158.11stop
9466f3c806821e116aacb2ed77measured076,60643,9068.4511.6454.272.12stop
9566ef1a4d821e116aacb229d5measured075,76452,3488.2511.5435.666.01stop
9666f4cd2c821e116aacb316efmeasured075,72859798.2511.4919.749.64stop
97670fb813bb02136c067d2becmeasured075,36842,4868.2511.5237.166.99stop
98670fbd96bb02136c067d2d49measured075,36672,6138.2111.5238.667.74stop
99670fb6a3bb02136c067d2b94measured075,35168,1928.2111.71104.478.50cap
100670fb637bb02136c067d2b65measured075,34938,1928.2611.70104.478.50cap
10166efaf70821e116aacb234bdmeasured074,95112,4748.0511.4936.767.36stop
10266f8c783bb02136c067c44b8measured074,47422,7957.9811.4740.369.42stop
10366faa8efbb02136c067c7357measured070,99803,8337.3411.2950.875.45stop
10466fc05b6bb02136c067c88e4measured070,98202,0497.3411.2330.667.05stop
10566f950acbb02136c067c5021measured070,87541,4987.4811.2124.561.22stop
10666f590fa821e116aacb33f35measured070,26951,5217.2911.1724.562.18stop
10766ecfe1e821e116aacb1e41cmeasured070,26174,7137.2911.2760.677.72stop
10866ebc3165a08c7b9b35deb38measured069,79821,1687.1611.1420.457.38stop
10966ebd2975a08c7b9b35e01e3measured069,79662,1667.1511.1731.568.73stop
11066f56630821e116aacb3392bwarmup068,23005,3696.8011.1795.256.40stop
11166ec0c4c821e116aacb1994awarmup067,33201,9546.7210.9995.220.53stop
11266f3cfa5821e116aacb2f096warmup065,88212,2376.4310.9361.436.42stop
11366ed875e821e116aacb2023ewarmup062,78212,2785.9310.7061.437.09stop
11466ec1aef821e116aacb1aa1awarmup062,44621,7905.8410.6677.223.19stop
11566f118e1821e116aacb26b79warmup060,94224,3605.6410.6477.256.49stop
11666fe81dcbb02136c067ca2dewarmup055,85431,6664.8710.27112.014.87stop
11766ec332a821e116aacb1c042warmup055,05138,1924.7710.39112.073.11cap
11866f6b623bb02136c067c2646warmup055,04943,0834.7710.2452.658.63stop
11966ece28e821e116aacb1db1fwarmup054,52841,1144.7610.1252.621.19stop
12066f97d7fbb02136c067c56b2warmup053,55053,6454.5310.1765.755.44stop
12166f4ce9e821e116aacb31731warmup053,00351,9324.5310.0565.729.39stop
12266fba2bcbb02136c067c8112warmup050,70863,7464.2110.0278.247.88stop
123670397b5bb02136c067ccec6warmup049,09963,2843.929.8678.241.98stop
12466f3e473821e116aacb2fa73warmup045,69272,1523.479.6843.549.43stop
125670493d4bb02136c067cdcd9warmup042,04871,7113.049.3543.539.30stop

Sweep

4.0.1

CompressSpec compaction 정책 스윕(Sweep Monitor)을 요약해 옮긴 것. 원본 페이지 전체(17 MB, 7탭·JS 그림)는 원본 보기 ↗ 에 그대로 있고, 사본은 dashboard_n01/sweep_monitor_src/job_9f4386c4_tmp/. 갱신은 2026-09-23 12:57 이후 없다(정적).

4.1.1

CompressSpec(GPU draft + CPU verify) · Qwen3-4B-Thinking-2507-yarn2.0 · LongBench-v2 · 128K·256K·420K · arm 9개 · COMPACT_THRESHOLD 0.8 · batch 1 · 요청 3개 · temp 0.8 / top_k 20 / top_p 0.95 / seed 0 · n82(256K) · n83(420K).

4.1.2
항목값
4.1.2.1armfullonly(diff off) · ratio1.0~3.0(diff on + 재압축 비율) · headroom10(풀이 찰 때 재압축)
4.1.2.2프롬프트대역마다 원본이 그 길이에 가까운 문항. 256K 는 무절단, 128K·420K 는 본문만 잘라 질문·보기·형식 지시 보존
4.1.2.3생성 상한128K·256K 80,000 · 420K 70,000 (IGNORE_EOS=0)
4.1.2.4KVGPU_MEM_UTIL 0.85 → KV 582,528 token, num_gpu_blocks 3100, cpu_pool 80/200/450 GB
4.1.2.5batch 1 인 이유교착이 아니라 KV 용량. 420K 프롬프트 하나가 GPU KV 약 210,848 token 예산을 채운다 (가설 기각 기록은 4.6)
4.1.3

완료 27셀 (THRESHOLD 0.8, 셀 = 대역 하나의 요청 3개 순차). fullonly 와 ratio1.0 은 정합이라 같은 값.

4.1.4
ctxfullonlyratio1.0ratio1.2ratio1.4ratio1.6ratio1.8ratio2.0ratio3.0headroom10
4.1.4.1128K accept %83.683.681.384.884.387.285.988.589.5
4.1.4.2128K decode tok/s12.2112.4012.7213.1713.1513.3713.2913.3810.72
4.1.4.3256K accept %82.182.180.882.585.382.784.379.884.2
4.1.4.4256K decode tok/s6.346.436.416.366.416.466.375.995.48
4.1.4.5420K accept %88.588.590.086.491.086.786.893.997.7
4.1.4.6420K decode tok/s4.604.794.864.654.924.814.824.834.70
4.1.5
Draft acceptance rate · THRESHOLD 0.8 · 막대 하나가 한 셀
4.1.5.c Draft acceptance rate · THRESHOLD 0.8 · 막대 하나가 한 셀
4.1.6
Decode throughput(prefill 제외) · THRESHOLD 0.8
4.1.6.c Decode throughput(prefill 제외) · THRESHOLD 0.8
4.1.7
fullonly 대 ratio1.0 decode 총 지연 · 막대 위 값은 ratio1.0 의 속도 향상. 해치 = 두 arm 의 출력 token 수가 어긋나 비교 불성립
4.1.7.c fullonly 대 ratio1.0 decode 총 지연 · 막대 위 값은 ratio1.0 의 속도 향상. 해치 = 두 arm 의 출력 token 수가 어긋나 비교 불성립
4.1.8
라운드 단계별 지연(verify · CPU→GPU transfer · draft) · fullonly 대 ratio1.0
4.1.8.c 라운드 단계별 지연(verify · CPU→GPU transfer · draft) · fullonly 대 ratio1.0
4.1.9
  • 기(상황) RCRATIO 를 고정값이 아니라 그 자리에서 정하려면 delta 와 full 을 같은 자리에서 견줘야 한다
  • 승(증상) 420K 는 keep 블록 순(829→1,195)이 accept 순(86.8→97.7%)과 일치. 256K 는 keep 폭이 52블록뿐이라 accept 이 흔들림(79.8~84.3%)
  • 전(원인) accept 의 설명변수는 압축 비율이 아니라 절대 보존 블록 수의 log2(79벤치 13,983요청). 256K 에서 keep 비율이 ratio 에 반응하지 않는 이유는 미규명(THRESHOLD 외의 선택 기준)
  • 결(조치) 비용 모델은 라운드당 비용 × 라운드 수(accept 함수)로 가른다. 변수 목록 원문은 원본 1.1 탭 09_rcratio_cost_variables.md
4.1.10
이미 아는 값측정
4.1.10.1reload블록당 약 0.19 ms. 512K NGB 3100·R1.5 → 5000·R3 에서 reload 중앙 0.330 → 0.118 s, decode −4.1%
4.1.10.2delta 에만 붙는 CPU 비용최적화 전 라운드당 약 186 ms → 후 28 ms (64K +32% → +8%, 128K +41% → +16%)
4.1.10.3full-fallbacknative layer_kv 48 → 124 ms. COMPACT_MAX_GPUBLK_UTIL 0.9 를 0 으로 끄면 512K accept 26.1 → 1.7%
4.1.10.4GPU draft forward두 경로 1~6% 이내 동일. 모델에서 상쇄
4.1.10.5모르는 값ratio → keep 전달 계수가 대역마다 다른 이유 · gather 커널 고정 오버헤드(블록 −55% 에 업로드 시간 −20%) · 장문맥 전송 노출
4.2.1

CompressSpec · Qwen3-30B-A3B-Thinking-2507-yarn2 · Nebius VM RTX PRO 6000 1장(8장 중 0번) · Xeon 6776P · 한 세션에 요청마다 arm 을 실어 모델 로드 1회로 29셀.

4.2.2
항목값
4.2.2.1코어소켓 0 만 · verify 서버 0-91(92코어) · GPU 드라이버 92-95. 메모리 대역폭 소켓당 251 GB/s(읽기) · STREAM Triad 239 GB/s
4.2.2.2max_model_len · 출력 상한524,288 · 20,000 token
4.2.2.3sampling · batchtemp 0.6 · top_p 0.95 · top_k 20 · seed 0 · batch 1
4.2.2.4GPU KV244,992 token · 7,656 블록 · 블록 32
4.2.2.5압축COMPACT_METHOD=block · THRESHOLD 0.8 · 풀 상한 0.9
4.2.2.6프롬프트128K 131072_Q1·Q2 · 256K 262144_Q1·Q2 · 400K 420000_Q4(multi_qa, 429,429 tok) · Q5(structured, 425,046 tok)
4.2.2.7코드feature/compaction-diff-upload-v2 · 001 01ceef4 · vllm d8a4c945
4.2.3
  • 기(상황) 400K 는 처음에 420000_Q1(항생제 내성 CSV 표)을 썼다
  • 승(증상) 모델이 목록을 반복 생성. 8-gram 고유율 35%, 최빈 8-gram 41회 → 반복 구간은 draft 가 전부 맞혀 accept 비교가 무의미
  • 전(원인) structured 도메인의 생성 퇴화(4.1 L40S 400K Table QA 3문항과 같은 현상)
  • 결(조치) RunPod 판 perdoc_512k.csv 에서 eos 정상 종료가 확인된 Q4·Q5 로 교체. 420K headroom10 은 선택 풀 7,976 > GPU 7,656 블록으로 UPLOAD_OOM 이라 막대에서 제외
4.2.4
정합 판정 (수정 후, 양 arm 001 01ceef4e6)fullonly 라운드/토큰/accept합ratio1.0판정
4.2.4.1128K Q1174 / 2,671 / 2,658174 / 2,671 / 2,658일치
4.2.4.2128K Q2103 / 1,513 / 1,501103 / 1,513 / 1,501일치
4.2.4.3256K Q1242 / 3,544 / 3,501242 / 3,544 / 3,501일치
4.2.4.4256K Q2168 / 2,615 / 2,609168 / 2,615 / 2,609일치
4.2.5

라운드별 검증 창·accept 수열·보존 블록 수·KV 지문·draft 제안 token 까지 대조(PARITY OK). 착지 시점 가지치기 507회, 포기 0건.

4.2.6
E2Earm토큰라운드prefill s생성 stok/s라운드당 s
4.2.6.1128K Q1fullonly2,67117442.5326.28.191.87
4.2.6.2128K Q1ratio1.02,67117441.6280.09.541.61
4.2.6.3128K Q2fullonly1,51310343.4183.58.251.80
4.2.6.4128K Q2ratio1.01,513103—169.08.951.66
4.2.6.5256K Q1fullonly3,544242359.1646.25.482.67
4.2.6.6256K Q1ratio1.03,544242—632.05.612.62
4.2.6.7256K Q2fullonly2,615168대기 포함441.95.922.63
4.2.6.8256K Q2ratio1.02,615168—435.06.012.60
4.2.7

128K 판은 진단 로그를 켠 상태라 라운드당 0.2초쯤 불리. 본 측정은 끈다.

4.2.8
RTX PRO 6000 · 29셀 · Draft acceptance · Output throughput · Transfer per verify · GPU forward per round. arm 순서 fullonly · ratio1.0 · 1.5 · 2.0 · 3.0 · headroom10
4.2.8.c RTX PRO 6000 · 29셀 · Draft acceptance · Output throughput · Transfer per verify · GPU forward per round. arm 순서 fullonly · ratio1.0 · 1.5 · 2.0 · 3.0 · headroom10
4.2.9
열 = 128K Q2 · 256K Q2 · 420K Q5. 위 GPU remained blocks, 아래 Transfer per verify. 점선 = GPU 블록 상한 7,656 과 10% headroom
4.2.9.c 열 = 128K Q2 · 256K Q2 · 420K Q5. 위 GPU remained blocks, 아래 Transfer per verify. 점선 = GPU 블록 상한 7,656 과 10% headroom
4.2.10
Round stage latency · 128K Q2 · 256K Q2 · 420K Q5 (verify · CPU→GPU 전송 대기 · GPU draft forward, 일부 겹침)
4.2.10.c Round stage latency · 128K Q2 · 256K Q2 · 420K Q5 (verify · CPU→GPU 전송 대기 · GPU draft forward, 일부 겹침)
4.2.11

420K-Q4 ratio1.5 는 115번째 압축 라운드에서 CPU selection 9,422 > GPU budget 7,656 으로 OOM 처리. 셀별 곡선(accept·pool·delta·post 각 6장)과 stage 그림은 원본 1.1 탭.

4.3.1

CompressSpec arm 비교 (L40S · Qwen3-4B, YaRN 미적용) — MathArena/aime_2025 30문제 순환 · THRESHOLD 0.5 · batch 32 · temp 0.6 · n82. 4.1 스윕과 벤치마크·모델 빌드가 다르고, 아래 SparseSpec 대 vanilla 와도 다른 실험(엔진이 다르다).

4.3.2
단계arm요청생성 상한라운드accept출력 token초gen tok/s판정
4.3.2.1aimepratio1.0652,0001,02554.0%129,680517599.3ok
4.3.2.2aimepfullonly652,0001,06451.8%129,705480512.1ok
4.3.2.3aimep2fullonly652,0001,05353.2%129,787542588.1ok
4.3.2.4aime3ratio1.02002,60016,44252.4%519,2273,634150.4ok
4.3.2.5aime3fullonly2002,60016,28553.0%519,2443,477153.9ok
4.3.2.6aime3ratio2.02002,60015,39656.6%519,2153,704151.8ok
4.3.2.7aime3ratio3.02002,60014,95158.6%519,1923,663158.2ok
4.3.2.8aime1ratio1.020040,96013—0396—fail: util 0.85 cuda-oom (sampler sort, 여유 52 MiB)
4.3.3
  • 기(상황) batch 32 에서 ratio1.0 과 fullonly 의 token 열이 65요청 중 다수 갈렸다
  • 승(증상) fullonly 대 fullonly(같은 설정 재실행)도 갈린다 — 자기 재현 실패
  • 전(원인) arm 이 아니라 batch. batch > 1 이면 드라이버가 요청을 동시에 처리해 순서가 비결정
  • 결(조치) batch 32 에서는 token 단위 정합을 arm 비교의 관문으로 쓰지 않는다. CPU verify 는 KV 업로드 라운드에만 호출되므로(1,062 = full 60 + diff) 짧은 컨텍스트 셀의 처리량은 CompressSpec 처리량이 아니다(미해결)
4.3.4
arm 별 시간축 · 왼쪽 20초 창 출력 tok/s(붉은 점선 사이가 정상 구간) · 오른쪽 동시 요청 수(회색 파선 상한 32)
4.3.4.c arm 별 시간축 · 왼쪽 20초 창 출력 tok/s(붉은 점선 사이가 정상 구간) · 오른쪽 동시 요청 수(회색 파선 상한 32)
4.3.5

SparseSpec 대 vanilla vLLM (baseline · L40S · Qwen3-4B) — AIME25 · OUT cap 81,920 · temp 0.6 / seed 0. 전 셀 완주(b8·b16 100/100, b32 200/200).

4.3.6
AIME25 batch 8 / 16 / 32 · vanilla vLLM 대 SparseSpec · OUT cap 81,920
4.3.6.c AIME25 batch 8 / 16 / 32 · vanilla vLLM 대 SparseSpec · OUT cap 81,920
4.3.7
AIME25 batch 스윕 · vanilla vLLM 대 SparseSpec (Qwen3-4B-Thinking-2507, reqs 100~200)
4.3.7.c AIME25 batch 스윕 · vanilla vLLM 대 SparseSpec (Qwen3-4B-Thinking-2507, reqs 100~200)
4.3.8
3벤치 steady-window throughput · vanilla vLLM 대 SparseSpec
4.3.8.c 3벤치 steady-window throughput · vanilla vLLM 대 SparseSpec
4.3.9

RTX PRO 6000 · Qwen3-30B-A3B · AIME 처리량 (RunPod) — vanilla vLLM 0.14.0 대 SparseSpec. 요청 200 / batch 32 · 출력 40K · temp 0.6 · prefix caching OFF · gpu_memory_utilization 0.85. 판정은 e2e(총 token ÷ 총 wall)와 누적 곡선, 순간값 비교 금지. 결과는 결과 탭 3.x 와 클러스터 16_D2_qwen3-30B-A3B-benchmark_tps.

4.3.10
RTX PRO 6000 · Qwen3-30B-A3B · `out81920_van_b32r128` t=5,840 s · 128/200 완료 · 구간 106 tok/s · 누적 419 tok/s · KV 19%
4.3.10.c RTX PRO 6000 · Qwen3-30B-A3B · out81920_van_b32r128 t=5,840 s · 128/200 완료 · 구간 106 tok/s · 누적 419 tok/s · KV 19%
4.3.11

AIME 2025 prefill KV pruning (Qwen3-30B-A3B-Thinking-2507) — n=30 · greedy · max_new 32,768 · 10/10 셀 완료 (2026-09-23). 원천 /home/shared/JH_MARVEL/dashboard_inbox/aime_kv_pruning/README.txt.

4.3.12
methodKV budgetaccuracycorrectcap hitwall sGPU
4.3.12.1full100%80.0%24/3033,989H200
4.3.12.2h2o75%63.3%19/3054,144H200
4.3.12.3snapkv75%56.7%17/3074,145H200
4.3.12.4streamingllm75%43.3%13/3094,134H200
4.3.12.5h2o50%26.7%8/3044,107H200
4.3.12.6snapkv50%26.7%8/3094,106H200
4.3.12.7streamingllm50%16.7%5/3054,108H200
4.3.12.8h2o25%13.3%4/3069,581RTX PRO 6000
4.3.12.9snapkv25%3.3%1/30153,199H200 #1-20 + PRO 6000 #21-30
4.3.12.10streamingllm25%3.3%1/3026,386RTX PRO 6000
4.3.13
accuracy vs KV cache budget · AIME 2025 · Qwen3-30B-A3B-Thinking-2507
4.3.13.c accuracy vs KV cache budget · AIME 2025 · Qwen3-30B-A3B-Thinking-2507
4.4.1

RTX PRO 6000 · Qwen3-30B-A3B · 5-way (115~144K, 문서 52개, batch 1) — 값은 중앙값. 실패·OOM·상한 절단 0.

4.4.2
시스템Prefill sTPOT s/tokenE2E 정규화 sE2E 실측 중앙 s종류
4.4.2.1vLLM21.660.014467.269.6measured
4.4.2.2TandemSpec21.660.014467.269.8measured
4.4.2.3NEO23.930.0957325.4320.9modeled
4.4.2.4HeadInfer30.910.38721250.61261.3modeled
4.4.2.5SparseSpec32.160.013775.376.3measured
4.4.3

E2E 정규화 = prefill + 3,150 × TPOT (SparseSpec 평균 출력 5,514, 나머지 5,976 token 이라 길이 차이를 뺀다).

4.4.4
  • 기(상황) SparseSpec 은 vLLM 보다 prefill 이 10.50 s 느리고 출력 token 당 0.00075 s 빠르다
  • 승(증상) 상쇄되는 출력 길이 14,000 token. 이 문서 집합의 SparseSpec 출력 중앙값 2,878 → 교차점을 넘는 문서 52개 중 3개
  • 전(원인) 지금 워크로드는 대부분 교차점보다 짧다. 생성 시작 비용을 고정비로 옮기면 교차점 9,516 token (표본 20개일 때 9,304) — 표본에 따라 크게 움직인다
  • 결(조치) E2E 로는 SparseSpec 불리, 이점은 TPOT 에서 본다. 유보 사항 원문 lcp6_06_reservations.md(원본 5.2 탭)
4.4.5
RTX PRO 6000 · Qwen3-30B-A3B · 5-way · 문서 52개
4.4.5.c RTX PRO 6000 · Qwen3-30B-A3B · 5-way · 문서 52개
4.4.6
RTX PRO 6000 TTFT (chunk 2,048, 문서 3개)vanilla vLLM 0.14.1SparseSpec차이
4.4.6.1115,088 tok22.26 s29.52 s+7.26
4.4.6.2128,725 tok28.32 s36.05 s+7.74
4.4.6.3144,467 tok34.27 s44.46 s+10.18
4.4.6.4평균28.29 s36.68 s+8.39 (+29.7%)
4.4.7
  • 기(상황) vanilla 를 FlashInfer·block 32·graph ON 으로 맞추고 SparseSpec TTFT 경계를 prefill 완료로 교정했다
  • 승(증상) 같은 세 문서에서 SparseSpec prefill 이 +29.7%, chunk 당 131.8 ms 격차. graph 설정 차이는 0.2 s 이하
  • 전(원인) persistent attention 본체가 FlashInfer 보다 KV 32K~129K 에서 22~45% 느림 + prefill 2,048 row 전부에 LM-head·top-k/top-p 수행(full-vocab sort 15.3 ms/chunk 확정). attention 내부 원인은 미확정(NCU 비교 진행 중)
  • 결(조치) 버퍼 공식·메모리 분석은 원본 5.3 탭 p6mem_00_memory_buffers.md
4.4.8
Prefill breakdown · SparseSpec vs vanilla · (a) 같은 세 문서 prefill/TTFT, chunk 16,384 / 2,048
4.4.8.c Prefill breakdown · SparseSpec vs vanilla · (a) 같은 세 문서 prefill/TTFT, chunk 16,384 / 2,048
4.4.9

L40S · Qwen3-4B · 장문 상한 (expr_14, LongBench-v2 무절단 87문서 131K~226K, batch 1)

4.4.10
항목값
4.4.10.1성공 / 실패70 / 17 (실패는 전부 용량 초과) · 성공 범위 131,731 ~ 198,211 token
4.4.10.2상한prompt + 생성 이 KV 풀에 들어가는가. mem_fraction 0.70 → 168K, 0.80 → 199K(실측 최대), 0.85 → OOM(풀 바깥 6.89 GiB, 절반이 sampler 임시 버퍼)
4.4.10.3처리량tpot 20~23 ms 로 평탄, prefill 만 45 → 78 s (131K → 198K)
4.4.10.4host 메모리상한을 못 올린다. batch 1 에서 offload 복원 조건이 성립하지 않아 199K 그대로
4.4.10.5확장chunk 2048 → 512 (220~230K, 미검증) · TP=2 (약 450K/rank, distribute/tp.py 수정 필요)
4.4.11
L40S · Qwen3-4B · GPU KV 풀 크기가 그대로 상한 · mem_fraction 0.70 → 0.80 에서 168K → 199K
4.4.11.c L40S · Qwen3-4B · GPU KV 풀 크기가 그대로 상한 · mem_fraction 0.70 → 0.80 에서 168K → 199K
4.5.1

Dynamic Recompaction (decision model v2, 2026-09-16) — GPU resident KV 를 지금 줄일지 판단. token N 과 block B_gpu 로 같은 상태를 표현하고 draft·transfer·metadata·recompaction 을 ms 로 환산.

4.5.2
Benefit = h × [Tattn(B_gpu) − Tattn(B_keep)] + p_full × [Tfull(B_keep) − Tdelta(B_new)] + Tstall
Cost    = Trc(B_keep) + Tmeta + Margin              → RECOMPACT NOW when Benefit > Cost
R*      = 1 + α/(h×ρ) + (T0_rc + Tmeta + Margin) × BW_hbm / (h×ρ×M_block×B_keep)   (memory-bound roofline 닫힌형)
                                                    → RECOMPACT NOW when B_gpu > R* × B_keep
HARD GUARD: B_gpu + B_new > B_cap 이면 비용 비교보다 먼저 재압축
4.5.3
기호뜻
4.5.3.1B_gpu · B_keep · B_new · B_cap현재 GPU KV 블록 · 재압축 뒤 남길 블록 · 이번 delta 블록 · GPU 상한 (pool_blocks · keep_blocks · len(new_cpu_block_ids) · num_gpu_blocks × cap)
4.5.3.2h · ρ · αlookahead(다음 판단 전 draft forward 수, spec_stride 와 같은지 미확정) · KV reread factor(이상적 1) · recompaction traffic factor(read+write 2, 임시 버퍼 포함 4)
4.5.3.3M_kv · M_block2 × L × H_kv × D × dtype (Qwen3-4B 144 KiB/token · 4.5 MiB/block, Llama-3.1-8B 128 KiB · 4 MiB)
4.5.3.4draft attention항상 memory-bound: AI = H_q/H_kv = 4 FLOP/B, L40S ridge ≈ 419 FLOP/B. Tattn = ρ × B × M_block / BW_hbm
4.5.4
  • 기(상황) α=4, ρ=1, h=16 이면 R* ≈ 1.25 로 수렴. 측정이 아니라 roofline 유도값
  • 승(증상) 128K recompaction median 16.6~24.7 ms(B_keep 501~746), 256K 26.1~30.4 ms. α=2 가정 시 128K ≈ 7.7 ms 로 실측의 절반 미만
  • 전(원인) 빠진 항: B_keep 으로 줄이면 accept 이 떨어진다(accept ∝ log2 보존 블록). Benefit 에 음수로 들어가야 하나 미정량화. metadata stage 는 timer 미분리
  • 결(조치) 128K·256K 두 점 회귀로 α·T0_rc 동시 추정 가능. 계측 schema(State·Draft·Transfer·Metadata·Recompact, verify generation 당 1행) 원문은 원본 1.3 탭
4.5.5

Block-level selection 전환 · 설계 v3 (2026-09-16, ai-cluster CompressSpec)

4.5.6
  • 기(상황) GPU selected block table 은 KV group 당 한 row 라 layer 축이 없는데, layer 마다 남기려는 slot 이 다르다
  • 승(증상) block selection 만으로 GPU recompaction 을 제거할 수 없다. 단순 scheduler trim 은 필요한 KV 를 버린다. 강제 interleaving 에서 old generation + 빈 bitmap 승인(keep-map torn publication)
  • 전(원인) P0 셋: 원격 전송 경로에 layer 별 source 필드 없음 · group 공통 GPU 목록으로 layer 별 keep-slot 표현 불가 · keep-map publication 에 process-shared lock 없음
  • 결(조치) 순서 = 전송 계약 연결(S0) → block-native 장부(S1) → keep-map v3(S2) → 조건부 clear-legacy(S3) → layer 별 table(S4) → teacher-forced 검증(S5) → 같은 노드 E2E 3회(S6). COMPACT_METHOD=block 은 스위치 하나로 두고 capability 로 경로 결정. 원격 root /home2/qwg724/001_CompressSpec, 분석 snapshot build/block_selection_audit_20260916/
4.5.7
실험 보고 (2026-09-18)판관측판정
4.5.7.103:51n82 · 32K · 4Bfullonly=ratio1.0 토큰 9663·5515 일치, accept 수열 1,020 라운드 동일통과
4.5.7.203:51n83 · 128K · 4B토큰 10000·1315 일치, accept 수열 756 라운드 동일통과
4.5.7.304:44n82 · 128K→256K→420K 한 세션요청 6개 토큰 일치, 420K 정상 종료통과
4.5.7.409:51Nebius · 128K+256K · 30B요청 4개 토큰 일치. accept 은 173라운드에서 갈림(93.540 vs 93.678%)미해결 → 이후 4.2 정합 판정에서 4셀 PARITY OK
4.5.8
핸드셰이크 이식본 (fullonly / ratio1.0)토큰accepttok/s(prefill 제외)transfer mstransfer 블록
4.5.8.132K n82 req09,66393.8%28.35 / 30.1771.9 / 27.3325 / 111.5
4.5.8.2128K n83 req010,00093.9%15.12 / 16.00146.4 / 63.0685.5 / 280
4.5.8.3128K~420K 한 세션 n82 req01,75085.8%15.38 / 16.34152.3 / 75.9716 / 346
4.5.9
fullonly 대 diff(ratio1.0) · L40S n82 · phase bars (verify · draft · transfer · select · diff plan · blockid+ledger)
4.5.9.c fullonly 대 diff(ratio1.0) · L40S n82 · phase bars (verify · draft · transfer · select · diff plan · blockid+ledger)
4.6.1

CompressSpec 정합 버그 (fullonly 대 ratio1.0, L40S 4B) — 해결 8 · 진행 4 · 미착수 2 · 기각 1.

4.6.2
상태시각현상 → 조치
4.6.2.1완료09-12ratio1.0 전용 KEEP_MAP slack 으로 탈락 토큰이 GPU 에 남음 → 원본 선택 집합만 발행 (COMPACT_KEEPMAP_SLACK=0)
4.6.2.2완료09-12draft 의 EOS 제안으로 reload 가 생략돼 미기록 블록에 attention → 거절에 대비해 항상 reload
4.6.2.3완료09-12CPU 엔진이 검증 주기를 재프리필로 오인해 GPU 잔존 슬롯 맵을 버림(accept 0/16) → draft 창 이하 축소는 허용
4.6.2.4완료09-13낡은 슬롯 맵 항목 때문에 확정된 KV 를 재전송하지 않아 256K 두 arm 갈림 → verified_len 이상 항목 HOLE 로 무효화 (DIFFPLAN_ROW0STALE_RESEND)
4.6.2.5미착수09-13cpu_verify_server_score.py 가 sampling 입력 세 줄을 안 보내 엔진이 greedy 로 → extra_args 에 draft_logprob_pool_ids·rs_seed·rs_temperature 추가
4.6.2.6완료09-13진단 코드가 diff 경로에만 비용을 얹어 성능 비교 방향이 뒤집힘(verify +75.1 ms) → 2단계로 강등, 불필요한 복사 제거 (+11.3 ms)
4.6.2.7완료09-13풀이 포화해 한 블록도 못 채우는 것을 계획기가 전송 실패로 오인, full 폴백이 풀을 4,185 → 633 블록으로 되돌림 → 빈 계획 no-op (DIFFPLAN_EXHAUSTED_NOOP)
4.6.2.8진행09-13400K Table QA 3문항이 반복 루프(accept 98.5%) → 도메인 분리 측정 중, 밴드 제외
4.6.2.9진행09-13잡 취소 직후 재시작한 런이 재현 안 됨 → QUARANTINED_TS 로 격리, 재측정
4.6.2.10진행09-15400K ratio1.6 첫 런에서 라운드 28% 가 약 4.5 s 정지, 재측정 2회 미재현 → 원인 미특정(HTTP 왕복 위치만)
4.6.2.11기각09-15가설 "batch>1 은 교착 때문에 막혀 있다" → 두 교착은 07-07 해결. batch 1 이유는 KV 용량
4.6.2.12완료09-15batch 32 는 자기 재현 불가 → token 정합을 arm 비교 관문으로 쓰지 않음
4.6.2.13진행09-15CPU verify 는 KV 업로드 라운드에만 호출 → 짧은 컨텍스트 셀 처리량은 CompressSpec 처리량이 아님(원인 규명만)
4.6.2.14완료09-15바깥 상태(잡 번호·노드·경로)가 코드 상수로 굳어 하루 5번 조용히 틀림 → 4곳 수정, squeue 로 읽음
4.6.2.15미착수09-15AIME 셀에서 UPLOAD_TRACE 꺼져 KV 사용률 시계열 없음 → 다음 AIME 판에서 켠다
4.6.3

Delta Transfer 결함 (13건, 완료 2) — 원문(문제·현상·원인·조치 4칸)은 원본 7.3 탭.

4.6.4
ID상태심각도내용
4.6.4.1DT-P1완료HIGHplanner padding 을 보존 대상으로 착각, 발행 순서도 pool 순 → 착지 완료 시 keep set 을 selection 으로 한정, argsort 로 token position 순 (keep_map_shm.py, vllm_cpu 5db2aaeb2). 1 GPU 159 라운드 accept 수열 일치
4.6.4.2DT-P2완료HIGHprune_before_landing 뒤 pool 이 survivors ++ delta 인데 keep-map 은 held ++ delta 좌표 → layer 별 held_only 로 ordinal 재사상 (scheduler_recompact.py, vllm a321029c3)
4.6.4.3DT-P3기각HIGHmin-count 통일 가설 → selector 가 이미 level-up(gpu_model_runner.py:4069), min 을 넣으면 매 라운드 full fallback. COMPACT_MIN_COUNT 되돌림
4.6.4.4DT-P4예정HIGHhybrid(SW layer) 모델에서 layer 별 source 목록이 빈 행 때문에 조용히 flat list 로 fallback → temp_buffer.py:528 길이검사에 if r 통일, warn-once
4.6.4.5DT-P5예정MEDIUM절대 발동하면 안 되는 보정(_PAD_LAYERS·_SLOT_ALIGN)이 늘 켜져 정합 붕괴가 조용히 지나감 → detector 로 격상(KEEP_COUNT_SKEW warn-once, assert)
4.6.4.6DT-P6예정LOW옛 정합 수정의 죽은 스위치·함수(COMPACT_KEEPMAP_SLACK 분기, note_upload, _hole_free) → 삭제, 두 env 는 무조건 적용
4.6.4.7DT-P7예정LOWtoken mode 가 부분 유효 블록을 전체 보유로 집계 → block mode 미발동, docstring 기록. token mode 폐기 검토
4.6.4.8DT-S1진행HIGH잠정 종료 요청이 tail 없이 끝나면 보류 landing 이 정리되지 않아 누수 → commit=False 로 폐기 (cpu_verify_engine.py:1993-1997)
4.6.4.9DT-S2진행HIGH잠정 종료 + 미검증 tail 이면 보류 landing 때문에 영구 정지 → landing 을 commit=True 로 먼저 태움 (:1999-2006)
4.6.4.10DT-S3예정LOWprune 대기가 reload-stall watchdog 보다 먼저 return → 분기 순서 교체, 경고 방식은 사용자 결정 대기
4.6.4.11DT-S4예정MEDIUMissued=gen 을 landing 성공 전에 보고 → keep-map 캐시, issued 기록을 착지 성공 시점으로
4.6.4.12DT-S5예정MEDIUMstaged scatter 가 요청 종료 뒤 남의 블록을 덮어씀 → drain 에 liveness 가드, request_finished 에서 purge
4.6.4.13DT-S6예정HIGHcapacity precheck 가 'no room' 과 'cannot tell' 을 구분 못 해 엔진 사망 → PrelandVerdict(reuse, evaluated, why) 로 갈라 PARK
4.6.5

SparseSpec 정합 버그 (SS-01, RunPod RTX PRO 6000) — 원인 확정 · 수정 미적용.

4.6.6
  • 기(상황) 정합 판정은 먼저 같은 입력·같은 seed 에서 자기 자신을 재현해야 성립한다
  • 승(증상) SparseSpec 은 동일 입력·seed 로 반복해도 출력이 달라진다. vanilla 와의 불일치가 아니라 자기 재현 실패
  • 전(원인) 희소 KV 선택의 경계 동점 처리. RAFT radix-select last_filter()(select_radix.cuh:434-440)가 atomicAdd 도착 순서로 동점자를 자르므로 스레드 스케줄링에 따라 같은 score 의 다른 KV token 이 선택된다
  • 결(조치) 결정적 tie-break 를 넣고 자기 재현을 먼저 통과시킨 뒤 vanilla 와 분포 정합을 검증한다
4.6.7

허락 없이 내린 판단 기록 (CompressSpec 정합 작업, 12건) — 2차 의견(Fable)이 확정한 것과 단독 판단을 구분.

4.6.8
시각성격내용근거 · 되돌림
4.6.8.109-12코드 수정diff 경로 keep-map 을 full 과 같이 원본 선택 집합만 발행Fable 확정 · COMPACT_KEEPMAP_SLACK=1 로 원복
4.6.8.209-12코드 수정draft 가 EOS 제안해도 CPU→GPU KV 복사 수행Fable 확정 · 되돌릴 수 있음
4.6.8.309-12코드 수정재프리필 가드가 draft window 이하 감소는 허용단독 판단(로그 관측) · 되돌릴 수 있음
4.6.8.409-13방향 변경수정 범위를 정합성 하나로 축소, 검증 프로토콜 재설계 보류사용자 지시
4.6.8.509-13방향 변경지시받은 256K 재측정을 보류(거절 위치 어긋난 상태)단독 판단 · 이후 nd·pm 단계에서 측정 완료
4.6.8.609-13코드 수정확정 범위 이상 보유 항목 전부 무효화(경계 한 칸 → '이상' 일반화)일반화는 단독 판단 · DIFFPLAN_ROW0STALE_RESEND
4.6.8.709-13코드 수정diff 전용 진단 비용 3가지 제거 (verify +75.1 → +11.3 ms)단독 판단, 20,005 사례 동일 확인 · 되돌릴 수 있음
4.6.8.809-13방향 변경성능 비교 기준을 진단 OFF 로. 이전 수치 폐기짝 실험 실측(verify 1,248.9 → 1,192.3 ms)
4.6.8.909-13수정 후 철회GPU 재압축 torch.cuda.synchronize() 2개 제거 시도실측 기각(2,188 vs 2,181 s) · 되돌림
4.6.8.1009-13코드 수정계획기가 '보낼 것 없음' 과 '못 싣음' 구분 → 빈 계획 no-opFable 코드 확인 · DIFFPLAN_EXHAUSTED_NOOP 기본 0
4.6.8.1109-13방향 변경재현 안 되는 측정 행 1개 전 그림에서 제외 (QUARANTINED_TS)단독 판단 · 수집기 한 줄로 복원
4.6.8.1209-12~13사고사용자가 거부한 실행 명령이 클러스터에서 3번 시작됨(PHASE=ign·sg·rp)원인 미상 · PID 트리로 종료, 오염 가능 행 표시

백업

5.0.1

유료 클라우드 실험 데이터 백업. 위치 /home/shared/CXL_LLM_SIM_JH/Ai-Cluster-New/Marvell_cloud/. 진행 탭은 30초마다 backup_status.json 을 다시 읽는다. 담당: JH 클라우드 백업 세션.

5.1.1

찾는 법

5.1.2
목적방법
5.1.2.1키워드로 찾기`grep -i <모델·버그·노드명> SEARCH_INDEX.tsv \cut -f1,3,4`
5.1.2.2디렉토리를 정한 뒤README.md 색인 표 → 그 디렉토리 ENVIRONMENT.md
5.1.2.3압축본 안(018~021).tar.zst.list 를 grep → tar -I zstd -xf <압축본> <파일> 로 그 파일만 푼다
5.1.2.4디렉토리별 한 줄 요약CATALOG.md (아래 5.2)
5.1.3

복원 시나리오

5.1.4
시나리오절차
5.1.4.1결과·그림 다시 보기 (016)016…/data/results/plot_*.py, 공통 style plot_style.py
5.1.4.2결과·그림 다시 보기 (017)017…/data/workspace/cs/results_archive/make_bundle.sh → bundle 안 redraw.sh. RUNROOT·LIB 를 백업 경로로
5.1.4.3실험 재현_repro/README.md §1 한눈 표 → RUN_RECIPES.md → ENV_VARS.md
5.1.4.4환경 복원 (docker)_docker/README.md §1, Docker Hub private junhyeong0724/marvell-tandemspec tag 3개
5.1.4.5환경 복원 (Nebius conda)015…/data/miniforge3_tar/*.tar.zst 를 원래 prefix(/mnt/filesystem-h8/miniforge3)에서 푼다. pkgs 는 data/miniforge3_pkgs/
5.1.4.6환경 복원 (RunPod env)017…/data/workspace/cs/backup/env-*.tar.zst 를 RESTORE.md 대로. zstd -d 먼저
5.1.4.7코드Nebius 015…/data/CompressSpec·data/cs/sparsespec_git·data/cs/noamx, RunPod 017…/data/workspace/{CompressSpec,repo}
5.1.4.8모델 weight015…/data/cs/{models,hf}, 017…/data/workspace/{models,cs/models,cs/hf}
5.1.5

원문 /home/shared/CXL_LLM_SIM_JH/Ai-Cluster-New/Marvell_cloud/HOW_TO_USE.md

5.2.1

Marvell_cloud/ 디렉토리 한 개가 한 행. 크기는 015·017·018~021·_docker 기록값, 나머지 2026-09-27 du -sh.

5.2.2
번호·이름무슨 실험·자료클라우드·노드·GPU측정일크기핵심 파일주의
5.2.2.1001_rtx_pro6000_sweep장문 컨텍스트 compaction 스윕 29셀 (128K·256K·420K × arm)Nebius RTX PRO 6000 ×12026-09-18~20676 MBdata/rtx_cells.json · data/raw/rtx_raw.tgz · script/collect_cells.py
5.2.2.2002_tandemspec_saturate_throughputTandemSpec saturate 처리량 (AIME25 batch 4~64)Nebius RTX PRO 6000 ×12026-09-19~21582 MBdata/results/*.console·*.csv · data/_run_headers.txt
5.2.2.3003_saturate_socket1_omp_smtsaturate 소켓 1 · OMP 21~64 · SMT 비교 (batch 4)Nebius RTX PRO 6000 ×12026-09-201.1 MBdata/results/*.console · data/_run_headers.txt002 와 같은 하니스
5.2.2.4004_granite_30b_batch_sweepGranite 4.2-30B batch 스윕 (vanilla vLLM 대 SparseSpec, AIME25)Nebius RTX PRO 6000 ×12026-09-20~21189 MBdata/_cells_summary.csv · data/<arm>_<ts>/
5.2.2.5005_magistral_24b_batch_sweepMagistral-Small-2509 batch 스윕 (vanilla vLLM 대 SparseSpec)Nebius RTX PRO 6000 ×12026-09-20~21382 MBdata/_cells_summary.csv · data/<arm>_<ts>/
5.2.2.6006_qwen3_4b_batch_sweepQwen3-4B-Thinking batch 스윕 + RunPod 판 b16·b32·b64Nebius RTX PRO 6000 ×1 · RunPod2026-09-20~211.5 GBdata/<arm>_<ts>/ · data/runpod_sweep_20260921/
5.2.2.7007_longcontext_4way장문 컨텍스트 4-way (CompressSpec·NEO·HeadInfer)Nebius RTX PRO 6000 ×12026-09-21~22378 MBdata/results_archive.csv(77행) · data/{long,medium,breakdown}/e2e_kind=modeled 행은 모델링 값
5.2.2.8008_diagnosticsNebius 박스 진단 (ISPC·cap 탐색·membw·gate)Nebius RTX PRO 6000 ×12026-09-20~21362 MB진단 .sh 76 · .py 17 · 로그 115 · ispc/
5.2.2.9009_compressspec_figures논문 01_intro 그림 스크립트미기록 (vast.ai 추정)미기록88 KBdata/01_intro/*.py · data/script/*.sh측정 데이터 없음
5.2.2.10010_aime_kv_pruningAIME25 prefill KV pruning (StreamingLLM·H2O·SnapKV × 25/50/75%)Nebius RTX PRO 6000 (25%) · ai-cluster n88 H2002026-09-2319 MBdata/*/summary.jsonl · script/plot_ratio_aime.py
5.2.2.11011_medium144_sparsespec_b1SparseSpec batch 1 · medium144 144개Nebius 81.85.4.145 RTX PRO 6000 ×82026-09-24~251.2 GBdata/<ts>/per_request.csv·totals.csv주의 LOG_SS=2 TPOT·E2E 부풀림, 사용 금지
5.2.2.12012_granite_medium20_sparsespec_b1SparseSpec batch 1 · Granite 4.2-30B · Medium 20개Nebius 81.85.4.145 RTX PRO 6000 ×82026-09-25150 MBdata/<ts>/per_request.csv·totals.csv · figs/주의 LOG_SS=2 TPOT·E2E 부풀림, 사용 금지
5.2.2.13013_vanilla126_temp0_cap8192vanilla vLLM · Qwen3-30B-A3B · temp 0 · LongBench-v2 medium 126개Nebius 81.85.4.145 RTX PRO 6000 ×82026-09-25832 KBdata/20260925_061459/per_request.csv·totals.csv
5.2.2.14014_ss20_temp0_chunk1024SparseSpec batch 1 · temp 0 · chunk 1024 · LOG_SS=1 · 20개Nebius 81.85.4.145 RTX PRO 6000 ×82026-09-2595 MBdata/20260925_070231/per_request.csv·totals.csv
5.2.2.15015_nebius_h8_raw_mirrorNebius filesystem-h8 원천 전체 mirror + 코드·models·hf·conda env 8개·pkgsNebius CPU 81.85.2.64 (/mnt/filesystem-h8)2026-09-17~25 측정, 09-26 백업약 206 GBdata/cs/run/ · data/CompressSpec · data/miniforge3_tar/*.tar.zstperf .data 3개 권한 없어 못 받음
5.2.2.16016_ysshin_rtxpro6000_resultsysshin 논문 평가 정리 결과 + CLAUDE_DOCSRTX PRO 6000 (Nebius) · 사본 출처 ai-cluster2026-09-2x77 MBdata/results/plot_*.py · script/CLAUDE_DOCS/
5.2.2.17017_runpod_pro6000_workspace_mirrorRunPod /workspace 원천 mirror + CompressSpec 트리·.so·models·env tar 4개RunPod CPU pod 66.92.198.82:11946 (측정은 RTX PRO 6000 pod)2026-09-08~21 측정, 09-26 백업154 GBdata/workspace/cs/PLAYBOOK.md · cs/backup/env-*.tar.zst·RESTORE.mdenv/(34 GB) 제외, env tar 와 중복
5.2.2.18018_aicluster_breakdown_debuggerCompressSpec phase breakdown·compaction·accept 디버깅 dump 전부ai-cluster L40S(n81·n84)·H200(n88) 등 · g072026-05~09압축 16.8 GB (원천 100.7 GB).tar.zst 41개 + .list · logs/verify_summary.txt2차 10개 md5 는 표본 대조
5.2.2.19019_aicluster_dump_debuggeraccept·score·block·metadata dump, saturate 로그, run10·sweep_testai-cluster L40S(n81~n86)·RTX 6000 Ada(n61) · g072026-05~09압축 0.97 GB (원천 2.77 GB).tar.zst 11개 + .list로그에 HF_TOKEN 평문, 외부 공유 금지
5.2.2.20020_aicluster_baselineSparseSpec vs vanilla vLLM baseline (RULER·AIME·LiveCodeBench·Olympiad·LongContext) · pruning 정확도ai-cluster L40S·RTX 6000 Ada·H2002026-06~09압축 2.7 GB (원천 16.2 GB).tar.zst 19개 + .listarchive/results md5 표본 8%
5.2.2.21021_aicluster_judge_debugger3-mode acceptance (standard·dual·cactus·tas) 결과·dump·dump_archiveai-cluster n90 H200 ×2 · n92 H200 NVL2026-07압축 54.8 GB (원천 248.1 GB)세션별 .tar.zst 50개 · logs/judge_dump_sizes.tsv2차 md5 표본 대조
5.2.2.22022_compaction_sweep_monitorCompaction Sweep Monitor 현황판(job 9f4386c4) 페이지·생성 스크립트g07 job tmp~2026-09-23313 MBdata/job_9f4386c4_tmp/serve/index.html · figs/(54장)
5.2.2.23_repro재현 키트: 러너 스크립트·env 전수·빌드·실행법Nebius·RunPod 러너 사본2026-09-266.7 MBREADME.md §1 · RUN_RECIPES.md · ENV_VARS.md · BUILD.md~/mrun/scripts/ 원본 소실 (scripts/nebius_1.51_mrun/RECOVERY.md)
5.2.2.24_dockerNebius sm_120 기준 docker 이미지 3개 (tandemspec·neo·headinfer)g07 cross-compile · Docker Hub junhyeong0724/marvell-tandemspec2026-09-26이미지 압축 26.5 GB (11.7+7.7+7.2)README.md §1 · images/*.tar.zst·SHA256SUMSsm_120·AMX 실제 실행 미확인
5.2.3

원문 /home/shared/CXL_LLM_SIM_JH/Ai-Cluster-New/Marvell_cloud/CATALOG.md

5.3.1

원천 로그·trace 이전(raw), 스크립트·환경 정리(repro), docker 이미지(docker) 진행 기록.

5.3.5

문서화

6.0.1
  • 문제 문서 설계·코드 청소·환경설정 작업의 현재 상태를 빠르게 확인해야 한다.
  • 현상 환경변수 300개 중 DELTA 42개는 적용했고, 나머지 258개는 계획이다.
  • 원인 이전 설계와 적용 결과가 같은 본문에 섞여 있었다.
  • 결과 현황은 아래 표, 변수 조회는 6.4, 문서 예시는 6.99에서 확인한다.
6.0.2
작업상태다음 확인위치
6.0.2.1Accelerator porting 문서 구조설계Delivery revision과 vendor capability6.1
6.0.2.2DELTA 환경변수 정리적용 (env_clean)16K/32K acceptance 진행 중6.2
6.0.2.3나머지 환경변수 258개계획Category별 이행과 검증6.4
6.0.2.4주석·진단 코드·출력 경로 정리계획적용 범위를 나누어 검증6.2
6.0.2.5Profile·test suite설계설정 우선순위와 suite 계약6.3
6.0.2.6Sidebar·예시 페이지 두 개검토용 초안Porting 독자의 navigation6.99
6.1.1
  • 기준 Astra 재설계(2026-09-30, 대상: custom accelerator 회사의 porting 엔지니어). 원문 .handoff/docs_v2/RESULT.md
6.1.2
  • 목적은 accelerator 엔지니어가 TandemSpec을 이해하고, reference hardware에서 실행한 뒤, 담당할 device role을 이식하고 검증하도록 돕는 것이다.
  • 구성은 Overview → Run on reference hardware → Hardware contracts → Porting guides → Validation and performance → Reference로 정한다.
  • Draft role·Verify role·두 role을 맡는 경우는 같은 contract를 사용하고, 필요한 페이지 경로만 달리한다.
  • 아래는 문서 설계이며, 새 device backend가 이미 구현됐다는 뜻은 아니다.
6.1.3

첫 진입과 완료 기준

6.1.4

처음에는 전체 개념 문서를 읽지 않아도 시작할 수 있게 한다. Overview에서 reference 실행, device role 선택, component map으로 바로 이동한다.

6.1.5
독자의 질문첫 페이지얻어야 하는 답
6.1.5.1TandemSpec은 무엇을 하는가TandemSpec at a glanceSelected KV로 draft하고 full-context KV로 verify하는 구조
6.1.5.2현재 구현을 먼저 실행할 수 있는가Prerequisites and supported configurations검증된 software·model·hardware 조합과 필요한 자원
6.1.5.3우리 chip은 어느 일을 맡는가Choose device rolesDraft·Verify·두 role의 책임과 필요한 capability
6.1.5.4무엇을 구현하거나 연결해야 하는가Hardware-dependent component mapComponent별 입력·출력·invariant·현재 코드·검증 항목
6.1.5.5이식이 맞는지 어떻게 확인하는가Component conformance → Numerical behavior → Lifecycle구조 정합성·수치 동작·통합 동작의 검증 결과
6.1.5.6성능이 충분한가Measure and tune performance같은 workload에서 측정한 latency·throughput·memory·transfer
6.1.5.7어디까지 지원한다고 말할 수 있는가Port acceptance reportRole·model·dtype·shape·동시성별 검증 범위와 제한
6.1.6

최종 sidebar와 페이지 책임

6.1.7

총 36개 페이지로 구성한다. Category는 메뉴 묶음이며 별도 본문 페이지를 추가하지 않는다.

6.1.8
부ID페이지핵심 내용
6.1.8.1OverviewO1TandemSpec at a glance엔진 원리, reference와 port의 구분, 시작 경로
6.1.8.2OverviewO2Request lifecycleResident·speculative mode, prefill, verify, commit, 종료
6.1.8.3OverviewO3Recompression and delta transfer재선택, recall gate, missing KV 전송, 적용 확인
6.1.8.4OverviewO4Correctness modelTarget distribution, greedy·sampling, 수치 가정, 검증 범위
6.1.8.5OverviewO5TerminologyRole·mode·cache identity·통계·metric 용어
6.1.8.6Run on reference hardwareR1Prerequisites and supported configurations검증된 구성, 자원, toolchain, model, 제한
6.1.8.7Run on reference hardwareR2Build the environments and prepare a model두 environment, kernel build, model·tokenizer, 설정 확인
6.1.8.8Run on reference hardwareR3Run your first verified request시작 순서, 실제 verify 실행, committed output, 종료
6.1.8.9Run on reference hardwareR4Capture a reference baselineResident·speculative 실행과 비교용 evidence 저장
6.1.8.10Run on reference hardwareR5Troubleshoot a reference runBuild·layout·verify·output·hang·성능 문제의 경계별 진단
6.1.8.11Hardware contractsH1Choose device rolesRole별 책임과 vendor capability 확인
6.1.8.12Hardware contractsH2Hardware-dependent component mapC01–C17의 소유자·의존성·guide·test
6.1.8.13Hardware contractsH3Device-contract specificationComponent contract의 공통 schema
6.1.8.14Hardware contractsH4KV memory modelLogical position, physical block, slot, layout, 수명
6.1.8.15Hardware contractsH5Communication and synchronizationControl·tensor 경로, completion, ack, 재사용 순서
6.1.8.16Porting guidesP1Bring up the runtime and model executionRuntime·allocation·model runner·eager 실행
6.1.8.17Porting guidesP2Supply model operators선택한 model의 전체 operator coverage
6.1.8.18Porting guidesP3Port draft attention and long-context prefillSelected attention, streamed prefill, 초기 selection
6.1.8.19Porting guidesP4Port verify attentionFull-context attention, query 정렬, score·LSE
6.1.8.20Porting guidesP5Adapt KV layouts and transfersPacking·변환·shared buffer·DMA·completion
6.1.8.21Porting guidesP6Port recompression and cache updatesGate·selection·repack·delta·rearrange·ack
6.1.8.22Porting guidesP7Preserve sampling and attention statisticsDistribution payload, sampling, score·LSE 의미
6.1.8.23Porting guidesP8Enable graphs, batching, and concurrencyGraph replay, batch, request 격리, 실행 순서
6.1.8.24Validation and performanceV1Run component conformance testsComponent별 invariant와 실패 입력 검증
6.1.8.25Validation and performanceV2Validate numerical behavior and samplingTensor 비교, greedy, sampling fixture, 분포 검증
6.1.8.26Validation and performanceV3Validate request lifecycle and recoveryMode 전환, reject, 종료, 취소, 동시 요청, 복구
6.1.8.27Validation and performanceV4Measure and tune performance측정 경계, warmup, 계측 비용, 병목, tuning
6.1.8.28Validation and performanceV5Interpret the reference resultsFigure별 조건·결과·제한·재현 evidence
6.1.8.29Validation and performanceV6Assemble the port acceptance report지원 조합, 검증 결과, 성능, 미해결 사항
6.1.8.30ReferenceF1CLI명령·인자·dispatch·종료 상태
6.1.8.31ReferenceF2Engine and connector configurationField·단위·default·상호 제약
6.1.8.32ReferenceF3Environment variables소유자·read point·유효값·진단 비용
6.1.8.33ReferenceF4Verify control APIEndpoint·request·response·identity·error
6.1.8.34ReferenceF5Tensor layouts and shared buffersKV·distribution·score·LSE·retention map의 표현
6.1.8.35ReferenceF6Outputs and metric definitions결과 schema와 token·byte·time·memory 정의
6.1.8.36ReferenceF7Release compatibility and limitationsComponent 조합, 검증 범위, 제한, migration
6.1.9
Role별 읽기 경로
6.1.10

Role을 아직 결정하지 않았어도 reference 실행과 component 조사는 진행할 수 있다.

6.1.11
경로공통 시작주로 필요한 guide추가 확인
6.1.11.1Draft roleO1 → R1–R4 → H1 → H2P1–P3·P5·P7·P8P6의 device cache rearrangement
6.1.11.2Verify roleO1 → R1–R4 → H1 → H2P1·P2·P4–P8Attention 외 전체 target model 실행
6.1.11.3두 role같은 시작 경로두 role의 guide 전체같은 chip에서도 소유권·completion·ack 유지
6.1.11.4Role 미정O1 → H1 → H2Capability worksheetRuntime·memory·operator·통계 출력 능력 확인
6.1.12
이 구성을 고른 이유
  • Porting을 기존 Guides 뒤에 추가하면 hardware 의존성이 설치·개념·porting 문서에 나뉘어 독자가 경계를 다시 조립해야 한다.
  • 별도 user entrance와 porting entrance를 만들 필요는 없다. 이번 전달 대상은 accelerator 엔지니어이며, 실제 분기는 담당할 device role이다.
  • Mechanism 설명은 O2·O3에서 제공하고, 각 contract와 guide가 필요한 설명으로 연결한다.
  • 이 결정은 수신자가 실제 backend 이식 책임을 가진다는 가정에 의존한다. 완성된 backend의 운영만 맡는다면 navigation 검증에서 이 가정이 틀렸는지 확인한다.
6.1.13

공통 용어

6.1.14

Role·mode·environment와 logical identity·physical placement를 구분한다. Code 이름은 source 연결과 검색 alias로 남긴다.

6.1.15
사용할 용어뜻구분할 기존 표현
6.1.15.1Draft role / Verify role토큰 제안 / full-context target 검증 책임GPU side / CPU side
6.1.15.2Draft device / Verify device해당 role을 실행하는 hardwareReference GPU / CPU와 구분
6.1.15.3Draft environment / Verify environmentRole을 실행하는 software 설치실행 mode와 구분
6.1.15.4Resident mode필요한 KV가 draft device에 있어 speculative verify 없이 실행Bypass
6.1.15.5Speculative modeDraft window를 verify하고 결과를 commit하는 실행Compressed mode
6.1.15.6Verification roundDraft window와 verify·commit 결과의 한 주기Cycle / decode step의 모호한 사용
6.1.15.7Selected KV cacheDraft가 사용하는 KV 부분집합Compressed KV / sparse KV
6.1.15.8Recompression이후 draft에 사용할 KV를 다시 선택선택 의미의 compaction
6.1.15.9Cache repackingKV의 물리적 배치나 packing 변경이동 의미의 compaction
6.1.15.10Retained setDraft device에 있다고 확인된 논리적 KV 집합Held set
6.1.15.11Residency ledgerConfirmed·pending KV와 generation을 추적하는 상태Index map
6.1.15.12Retention map기존 cache slot 중 살아남는 위치를 나타내는 metadataKeep map
6.1.15.13Applied generation소비 장치에서 사용할 수 있다고 확인된 update 세대Landed generation
6.1.15.14Draft distribution payloadDraft sampling 분포를 복원하는 데이터Logprob pool이라는 이름만으로 표현을 단정하지 않음
6.1.15.15Selection threshold남길 KV를 선택하는 목표Selection의 τ
6.1.15.16Recall threshold현재 selected KV를 갱신할지 정하는 기준Gate의 τ
6.1.15.17Retained KV fraction동일 기준의 selected KV / full-context KV보존 비율
6.1.15.18KV reduction fraction같은 기준에서 1 − retained fraction제거 비율 의미의 compression rate
6.1.15.19KV-pool utilization사용 중인 KV pool / 가용 KV poolCache 보존 비율과 구분
6.1.15.20Correction token / Bonus token첫 reject 위치의 교정 / all-accept 뒤 조건부 추가 토큰Target token을 무조건 같은 의미로 쓰지 않음
6.1.16
표기 규칙
  • Hardware 일반 설명에는 role 이름을 쓰고, 현재 구현 설명에 NVIDIA GPU·Intel CPU·CUDA·AMX 등을 쓴다.
  • Logical token position, physical block ID, cache slot을 바꾸어 쓰지 않는다.
  • Selection threshold와 recall threshold는 별도 설정으로 설명한다. 특정 recipe에서 같게 둘 수는 있다.
  • Ratio에는 분자·분모·단위·layer/group 집계·padding 처리 방식을 적는다.
  • Upload·download 대신 출발 memory와 도착 memory를 적는다.
  • Lossless 설명에는 target distribution과 numerical assumption을 함께 적는다.
  • 문서상 contract를 이미 존재하는 plugin API처럼 표현하지 않는다.
6.1.17

Device contract

6.1.18

각 component는 입력·출력만 아니라 memory 수명과 completion 조건까지 정의한다. Reference에서 확인한 동작과 target에서 검증한 동작은 별도 상태로 기록한다.

6.1.19
항목반드시 기록할 내용
6.1.19.1Identity / applicabilityContract ID, role, mode, 필수 feature
6.1.19.2Source / statusRevision·file·symbol·caller·consumer, 검증 상태
6.1.19.3Inputs / outputs수학적 의미, shape, dtype, stride, packing, valid length
6.1.19.4Memory ownershipAllocator·writer·reader·alias·capacity·재사용 조건
6.1.19.5OrderingSubmitted·ready·applied·acknowledged의 의미
6.1.19.6InvariantsIdentity·state·bounds와 허용되는 수치 차이
6.1.19.7Capability / failure지원 shape·dtype·batch·graph, 오류·fallback·cleanup
6.1.19.8ValidationFixture·비교 방법·통과 기준·evidence
6.1.19.9Performance계산량·byte·시간 경계·temporary memory·계측 비용
6.1.19.10Open facts미확정 질문·담당자·막힌 페이지
6.1.20
Hardware-dependent component 목록
6.1.21

D는 Draft role, V는 Verify role, H는 host/control 책임이다. 아래 code 좌표는 component 경계를 찾는 출발점이며 delivery release에서 다시 묶는다.

6.1.22
IDComponent적용주요 code 좌표검증 핵심
6.1.22.1C01Runtime and backend integrationD/Vplatforms, worker/model runnerEager forward와 자원 정리
6.1.22.2C02Whole-model operatorsD/Vmodel_executor, CPU oneDNN dispatchOperator→layer→model 비교
6.1.22.3C03Draft attentionDFlashInfer backend와 patched decode kernelSelected KV·mask·position
6.1.22.4C04Long-context prefill and initial selectionD/HFlashInfer prefill, kv_transfer_utilsChunk 경계와 full KV 보존
6.1.22.5C05Verify attentionVcpu_attn.py, cpu_attn*.hppFull context와 query/group 정렬
6.1.22.6C06Attention statisticsD/V/HScore/LSE export와 readerBase·normalization·validity
6.1.22.7C07Sampling and distribution transportD/V/Hlogprob_worker, verify samplingPayload 표현과 p/q 정렬
6.1.22.8C08KV physical representationD/V/Hamx_kv_layout, cache kernelsPacking과 정확한 round trip
6.1.22.9C09Shared buffers and transfersD/V/Hcpu_gpu, shared-memory handlersCompletion과 buffer 수명
6.1.22.10C10Device cache rearrangementD/Hgpu_recompact, scheduler_recompact겹치는 이동과 늦은 재사용
6.1.22.11C11Selection, recall gate, host repackingV/H_should_compact, _compact_kv_cache, compact_amx_kernelGate 경계와 selection oracle
6.1.22.12C12Delta ledger and retention publicationD/V/Hindex_map, keep_map_shm, keep_map_readerGeneration·ack·publication 순서
6.1.22.13C13Verify control and lifecycleH/D/VVerify server, dispatcher, channelsRequest·job·group·commit 정렬
6.1.22.14C14Execution ordering and graphsD/V/Hcuda_graph, transfer hooks, _lse_syncEager/graph 동등성과 write 완료
6.1.22.15C15Host threading and memory placementH/VCPU platform, OpenMP, NUMA allocation실제 affinity와 memory placement
6.1.22.16C16Timing and observabilityD/V/HBreakdown·trace·output writer비동기 시간 경계와 byte 계산
6.1.22.17C17Parallel execution and collectives조건부Communicator, distributed, rank별 buffer합의된 multi-device 구성만 검증
6.1.23
조사에서 확인한 contract 주의점
  • Verify role은 attention만이 아니라 target model 전체를 실행한다. Attention kernel 제공만으로 verify port가 완성되지는 않는다.
  • AMX KV packing은 vector 경로와 다르다. 같은 tensor shape라는 이유로 byte layout이 같다고 볼 수 없다.
  • 확인한 draft logprob worker는 raw bf16 logits를 전송한다. 이전 자료의 log-probability 설명과 delivery release에서 대조해야 한다.
  • Recall gate는 draft log2 LSE를 natural-log 기준으로 바꿔 비교한다. Query·layer·head 정렬과 aggregation도 contract에 포함한다.
  • LSE completion helper에는 worker와 scheduler가 같은 Python interpreter에 있다는 가정이 있다. Process 구성이 바뀌면 다시 검증해야 한다.
  • Graph replay에서는 일반 layer decorator의 transfer 부작용이 자동으로 실행되지 않아 별도 hook이 필요하다.
  • KV update는 payload 완료, metadata 공개, 적용, ack, 재사용으로 나누어 설명한다.
  • Keep-map generation 검사와 고정 capacity는 source를 확인하되, 주석만으로 publication race가 없다고 결론 내리지 않는다.
  • Native compaction JIT의 -march=native는 build host와 실행 host의 호환성 확인이 필요하다.
6.1.24

Figure 배치와 수정 사항

6.1.25

그림은 설명의 목적에 맞는 페이지에 배치한다. 결과 수치에는 해당 experiment의 model·hardware·configuration·metric 정의를 연결한다.

6.1.26
Figure배치처리
6.1.26.1overview3O1·H1첫 구조 그림으로 사용하고 payload 생략과 bonus 조건을 설명
6.1.26.2overview2P3·O2Layer/chunk prefill 상세에 사용
6.1.26.3timeline2V5·O2개념적 schedule과 memory 비교로 설명
6.1.26.4OptimizeO3·P6그대로 사용. recall check 는 all-accept window 뒤에만 돈다는 조건을 본문에 적음
6.1.26.5fig-aime-kv-budget-accuracyO1 상세·V5압축 검증의 동기를 설명하고 port 정합성 증거와 구분
6.1.26.6fig-batch-vs-kv-budgetH4·V5Capacity 계산 또는 측정의 가정을 확인
6.1.26.7latency_v3V5·V4TTFT·TPOT·E2E와 OOM 조건 연결
6.1.26.8throughput_routingV5·V3Throughput와 requests-in-flight를 구분
6.1.26.9analysis_meanV5·V4Gate 결과와 round-time의 대표 설명
6.1.26.10analysisV5 상세Context별 결과와 측정 설정 연결
6.1.26.11compression_meanV5·H4KV reduction fraction으로 뜻을 명시
6.1.26.12ablationV5Brief와 다른 수치를 raw result로 대조한 뒤 사용
6.1.26.13sensitivityV4·V5w와 threshold의 의미·설정·OOM 조건 연결
6.1.26.14fig-appx-delta-roundsP6·V5α·limit·block size·정책 정의 후 사용
6.1.27
Figure에서 발견한 불일치
  • Optimize 그림은 올바르다: Recall < τ 가 yes 면 recompression, no 면 Skip GPU KV update. (앞선 'yes/no 반대' 지적은 오판, 2026-09-30 그림 확인)
  • Optimize에는 모든 draft가 accepted된 경우에만 skip을 고려한다는 조건도 추가해야 한다.
  • Ablation PDF는 1.00→2.28→2.44→2.54배이고 brief는 1.00→2.46→2.53→2.62배다. 둘 중 하나를 임의로 채택하지 않는다.
  • Compression mean의 97.4%·89.9%는 제거 비율이다. 보존 비율 및 KV-pool utilization과 별도 metric으로 설명한다.
  • Overview의 token arrow는 전체 verification payload를 생략한 표현이다. 필요한 distribution·statistics·completion은 contract로 연결한다.
6.1.28

완성 전에 받아야 할 사실

6.1.29

문서 구조는 지금 확정할 수 있다. 아래 답은 해당 component의 실제 명세와 acceptance 기준을 완성하는 데 필요하다.

6.1.30
담당받아야 할 사실영향
6.1.30.1VendorDraft·Verify·두 role 중 목표와 prefill 배치Guide 적용 범위
6.1.30.2VendorRuntime·compiler·framework integrationBuild와 model 실행
6.1.30.3VendorModel operator·dtype·accumulation·quantization전체 model coverage와 수치 기준
6.1.30.4VendorAttention shape·mask·GQA·score/LSE 출력Attention와 recompression 연결
6.1.30.5VendorMemory capacity·DMA·pinning·coherence·completionKV layout·transfer·synchronization
6.1.30.6VendorGraph·batch·concurrency·multi-device 요구최적화와 lifecycle 검증
6.1.30.7Engine teamLauncher·server·두 engine·kernel의 delivery revision문서의 실제 지원 조합
6.1.30.8Engine teamDistribution payload와 sampler semanticsSampling 정합성
6.1.30.9Engine teamSelection·recall 설정과 aggregationMechanism 설명과 configuration
6.1.30.10Engine teamLayout·block size·keep-map limit·publication 보장Device contract
6.1.30.11Engine teamFigure별 raw result와 수정 asset결과 문서의 신뢰성
6.1.30.12공동Numerical acceptance, workload, latency·throughput·memory 목표Port acceptance report
6.1.30.13공동Model·tokenizer 전달 및 실행 절차외부에서 가능한 reference 실행
6.1.31

작성 순서와 검증

6.1.32

각 단계는 독립적으로 확인할 수 있는 산출물을 남긴다. Engine 구현 변경은 이 문서 설계의 범위에 포함하지 않는다.

6.1.33
순서Tier작업완료 신호
6.1.33.1B1routineDelivery source bundle 고정모든 claim에 source 또는 미확정 항목 연결
6.1.33.2B2routine36개 page manifest와 role 경로 작성Sidebar·page·cross-link 일치
6.1.33.3B3routineGlossary와 alias 적용기존 code 이름으로 올바른 용어 검색
6.1.33.4B4judgmentRole 책임과 C01–C17 contract 확정구현할 항목·소유자·test가 명확
6.1.33.5B5routineReference 실행 경로 작성실제 verify 요청과 evidence 확보
6.1.33.6B6routine8개 porting guide 작성각 guide가 contract test로 끝남
6.1.33.7B7routineRelease reference 연결Producer·consumer schema와 유효 설정 확인
6.1.33.8B8judgmentFigure·numerical·performance claim 대조그림과 acceptance 기준의 근거 확보
6.1.33.9B9routine6.1 교체허용 markdown으로 단독 검토 가능
6.1.33.10B10routineNavigation·정합성·공개 범위 검증Role별 독자가 작업 경로를 찾음
6.1.34
Acceptance에서 반드시 확인할 사례
  • 기존 문서처럼 hardware가 고정된 것으로 보이거나 porting 항목이 없어 구현 범위를 찾지 못하는 문제가 재발하지 않아야 한다.
  • Verify role만 맡는 독자는 CPU attention만 바꾸면 된다고 결론 내리지 않아야 한다.
  • Draft role만 맡는 독자는 verifier를 이식하지 않고도 자신이 지켜야 할 layout·payload·completion 계약을 찾아야 한다.
  • DMA가 늦게 끝나는 경우 control message가 먼저 처리돼 미완료 tensor를 읽지 않아야 한다.
  • 같은 shape지만 다른 AMX/vector packing은 layout 검증에서 구분해야 한다.
  • Delta payload가 비어 있어도 retention 적용과 generation 처리는 필요할 수 있음을 설명해야 한다.
  • Graph replay에서 transfer hook이 빠진 구현은 eager 성공만으로 통과하지 않아야 한다.
  • 같은 seed의 sampled text가 다르다는 사실만으로 distribution 보존 실패라고 판정하지 않아야 한다.
  • Role이 아직 미정이어도 capability 질문과 책임 범위를 찾을 수 있어야 한다.
  • 실제 수신자가 backend 이식이 아니라 운영만 맡는다면 navigation test가 이 구조의 가정을 반증하도록 한다.
6.2.1
  • 문제 설정·진단·주석 정리의 적용 범위를 구분해야 한다.
  • 현상 DELTA 정리는 env_clean에 적용했고, 다른 category와 주석·출력 경로는 계획이다.
  • 원인 기존 본문에는 적용 전 설계와 적용 후 상태가 함께 있었다.
  • 결과 현재 판정은 6.4, 검증 결과는 아래, 이전 설계는 접은 이력으로 보존한다.
6.2.2

6.2.1 현재 결과와 다음 작업

6.2.3
항목상태근거·제한
6.2.3.1DELTA 변수 42개적용 (env_clean)CSV의 after·state 기준
6.2.3.2Batch-1 전후 비교통과두 upload mode에서 bit-identical
6.2.3.3비교 workload완료16K, 요청 2개, 151 verification rounds, accepted 2000/2406
6.2.3.4Unit test통과41/41
6.2.3.5기본 진단 level통과DELTA 진단 line 없음
6.2.3.6Level 3 진단통과이전 marker 68종 모두 출력
6.2.3.7Batch-2Smoke 용도같은 baseline 두 번도 acceptance 89.5%·86.4%
6.2.3.816K/32K acceptance진행 중완료 결과로 표기하지 않음
6.2.3.9나머지 category계획258개
6.2.3.10주석·진단 코드·출력 경로계획아래 작업별 검증 후 적용
6.2.4
  • Batch-1 결과는 cleanup 전후의 동등성 근거다.
  • Baseline vLLM 전체와의 implementation parity나 모든 batch의 결정성을 증명하지 않는다.
  • COMPACT_INDEX_MAP_MAX 기본값은 512→2048로 변경됐다.
  • COMPACT_UPLOAD_PEND와 DIFF_NATIVE는 현재 유지한다.
6.2.5
기존 환경변수 계획 페이지와 preview
환경변수 정리 계획 문서 — 카테고리별로 지금 있는 변수 → 통합 · 이름 변경 · 삭제 20190511 우선 정리 목록 (121개) ↗ · 새 창으로 열기 ↗ · 전체 목록 ↗
6.2.6

6.2.2 공용 설정 체계

6.2.7
  • 목적 로그·dump·시간 계측·출력 경로를 구분한다.
  • 상태 DELTA의 적용 범위를 제외하면 아래 공용 체계는 계획이다.
6.2.8
설정값책임
6.2.8.1LOG_PRINT0–3Domain의 기본 진단 level
6.2.8.2LOG_PRINT_<DOMAIN>0–3COMPACTION·DELTA·DRAFT·VERIFY·KV·ROUTER·PREFILL별 override
6.2.8.3Level 0기본추가 domain 진단을 끈다
6.2.8.4Level 1요약Verification round·step 요약; 진단용 GPU sync·전체 pool scan 없음
6.2.8.5Level 2상세Request·layer 정보와 JSONL trace; 시간 계측 sync 허용
6.2.8.6Level 3무거운 관찰Tensor 통계·fingerprint·전체 pool 비교
6.2.8.7LOG_PRINT_REQreq_id특정 request만 기록
6.2.8.8DUMP종류 목록accept·score·kv·logprob·memcheck·reject·reject_all·metadata·tokens
6.2.8.9CS_OUT경로CS_OUT/<run>/logs/, breakdown/, trace/, dump/; 경로 지정만으로 계측을 켜지 않음
6.2.8.10BREAKDOWN0·rows·light시간 분해 기록
6.2.8.11BREAKDOWN_KERNEL0·inline·profiler·inline+gpu-profilerKernel 시간 계측
6.2.8.12DELTA_STRICT명시적 설정DELTA soft failure를 오류로 처리
6.2.9
이전 설계의 규모·배경·진행 순서
  • 이전 첫 요약은 추가 환경변수 286개, 안 쓰는 후보 48개, 추가 코드 약 3.9만 줄, 한글 주석 84줄, TODO 24개, 주석 처리된 코드 114줄, 진단 코드 31개였다.
  • 공개 엔진 문서가 없고 설정이 CLI·설정 클래스·환경변수에 나뉘어 있었다.
  • 최초 문서 frame은 LLMServingSim 구조를 참고했다. 현재 frame은 6.1의 accelerator porting 대상 설계다.
  • 당시 결과는 문서 구성요소·git 청소 목록·설정 및 test 구조의 설계였고, “코드는 아직 고치지 않았다”는 그 시점의 상태였다.
  • 기존 청소 순서는 위험이 작은 작업부터 #1 환경변수·#3 진단 코드 → #2 주석 → #4 출력 경로였다.
  • 2026-09-30 초기 묶기 설계는 GPU(Astra) 89개와 CPU verify(Fable) 197개, 합계 286개를 대상으로 했다.
  • 그 표의 쪽 표시는 설계 분담이며 실제 실행 process나 변수 작성자를 뜻하지 않는다.
당시 처리GPU(Astra)CPU verify(Fable)합
유지·일부 rename·호환61138199
공용 knob으로 묶기112940
삭제 제안173047
합89197286
  • 당시 로그·trace·dump 스위치는 약 70개, level 방식은 5가지, 출력 경로 변수는 14개였다.
  • 접두어는 COMPRESS_SPEC_, COMPRESSION_SPEC_, COMPSPEC_, CS_ 네 가지였다.
  • CPU 설계에서는 사용자 노출 변수를 197→149개, 로그 스위치 59개를 공용 knob 11개로 줄이는 안을 제시했다.
  • 전체 공용 knob 규모는 약 12개로 설명했다. 이 수치는 적용 후 300개 inventory와 다른 집계다.
  • “디버그·dead 변수는 실제 실행 성능에 큰 영향이 없다”는 초기 설명과, 아래 GPU sync·pool scan 비용 지적을 함께 보존한다. 이번 문서에서 성능 효과를 새로 확정하지 않는다.
  • Astra 이행안은 기준선 → 공용 resolver → 기능 rename·alias → 동작과 로그 분리 → emitter level 분리 → CS_OUT → 삭제 → n82 L40S 전후 비교 순서였다.
  • 당시 비교 배치는 verify 28코어와 GPU engine용 4코어였다.
  • 원문은 RESULT_astra_env.md, RESULT_fable_env.md, 합친 env_regroup.csv이며 위치는 ai-cluster docs/ai_agent/011_env_inventory/였다.
6.2.10
이름·호환·출력 경로에 남은 세부 조건
  • 기능 접두어 계획은 COMPACTION_*, DELTA_*, DRAFT_*, KV_*, VERIFY_*다.
  • 초기 예시는 COMPACT_DIFF_UPLOAD→DELTA_UPLOAD, COMPACT_THRESHOLD→COMPACTION_THRESHOLD, COMPSPEC_RUNAHEAD→DRAFT_RUNAHEAD, COMPACT_TEMP_BUFFER_GB→KV_TEMP_BUFFER_GB, COMPSPEC_BONUS_TOKEN→VERIFY_BONUS_TOKEN이었다.
  • DELTA의 현재 이름과 처리는 6.4를 따른다. 초기 rename 예시를 적용 완료로 읽지 않는다.
  • Alias 계획은 옛 이름을 한동안 경고 한 번과 함께 받고, 셸>.env, 같은 우선순위에서는 새 이름을 우선하는 방식이다.
  • RS_*, LS_*, LAYER_SERIAL_*, DYN_ROUTER*, COMPACT_MAX_GPUBLK_UTIL 등 논문 runner의 일부 이름은 유지한다.
  • BREAKDOWN_KERNEL_PROFILE_MODE, BREAKDOWN_KERNEL_INLINE의 순서로 (1,1)→inline+gpu-profiler, (1,0)→profiler를 보존한다. INLINE 단독으로 profiling을 켜지 않는다.
  • Legacy path와 timestamp 동작은 이행 시 보존한다.
  • ATTN_KV_DUMP_DIR의 계획 경로는 CS_OUT/<run>/dump/kv/<req>_j<job>_<postfix>.json이다.
  • BREAKDOWN_LIGHT_LAT는 breakdown/lat_<role>.json, BREAKDOWN_RUN_DIR는 CS_OUT/<run>/breakdown/{sched,step_<role>,cpu_verify}.jsonl로 연결한다.
  • CPU·GPU log 계획 경로는 logs/cpu_server.log, logs/gpu_client.log다.
  • FSM은 trace/fsm/<req>.jsonl이며 transition마다 open/append/close하는 비용 때문에 handle caching을 제안했다.
  • Recompaction trace 계획 경로는 trace/{reload_trace,verify_trace,recompact_trace,draft_trace}.jsonl이다.
  • 기존 trace writer는 BREAKDOWN_DIR에 append하며 draft_trace는 light 조건을 가진다. analysis/recompact_*.py reader를 함께 확인한다.
  • Logprob dump는 dump/logprob/step{N}_{ts}.pt, score dump는 dump/score/, memory 검사는 dump/memcheck/다.
  • Reject dump의 기존 제안 경로는 dump/accept/reject_distrib.jsonl, full-vocab PT는 dump/accept/reject_pt/다.
  • DUMP 공통 설명의 dump/<kind>/와 reject의 기존 경로 제안은 일치하지 않는다. OUTPUT 구현 전에 경로 계약을 확정한다.
  • CPU profile 도구는 현재 $BREAKDOWN_DIR/B{n}_{DTYPE}_CPU/<ts>를 쓰며 CS_OUT/<run>/breakdown/으로 옮기는 계획이다.
  • TOKEN_DUMP_JSON의 명시적 경로를 보존한다. DUMP=tokens일 때의 선택적 기본 경로는 dump/tokens/<force_name>.json이다.
  • OUT_ROOT의 legacy fallback은 <OUT_ROOT>/held.jsonl이다.
  • Retained set fingerprint와 전체 배열은 각각 trace/held.jsonl, 명시적 DUMP=metadata로 나누는 계획이었다.
  • 이전 DUMP_METADATA_ROUNDS 제안은 generation 범위만 지정하며, 범위 설정 자체가 dump를 켜지는 않는다.
6.2.11
DELTA 감사와 이전 결정의 변경 이력
  • 초기 감사의 “28개 모두 20190511이 추가”는 당시 범위의 기록이다.
  • 논문 runner scripts/longcontext/run_compressspec.sh:53은 shipped defaults를 사용한다고 설명하며 COMPACT_DIFF_UPLOAD=1, COMPACT_RECOMPACT_RATIO=1.0, COMPACT_MAX_GPUBLK_UTIL=0.9를 override로 전달했다.
  • Saturate runner는 COMPACT_INDEX_MAP_MAX=2048을 전달했다.
  • 초기 판정은 ratio·headroom·index map 세 knob와 upload ablation 하나였다.
  • 경계 항목은 COMPACT_UPLOAD_PEND, COMPACT_ACT_RESERVE_GIB였다.
  • Helper reader _armv, _diag, _dlog를 추가한 inventory 재조사에서 480→490개가 됐고 dead 후보는 47→44개가 됐다.
  • 그때 COMPACT_RECOMPACT_RATIO, HELD_ORDER_DIAG, KEEP_SPREAD_DIAG가 dead 목록에서 빠졌다.
  • 새로 확인한 항목은 COMPACT_RECOMPACT_RATIO, COMPACT_ACK_TRACE, COMPACT_PLAN_STAT, KEEPMAP_DIAG, KEEPMAP_SIZE_DIAG, KEEP_SPREAD_DIAG, POOL_SET_DIAG, PRUNE_HOLD_LOG, RECOMPACT_DIAG, UPLOAD_TRACE였다.
  • 최초 본문의 “나머지 25개”, “로그 11개+누락 9개”, 요약의 “17개”는 조사 단계별 표현이다. 현재 42개와 합산하지 않는다.
  • COMPACT_INDEX_MAP_MAX는 vllm_cpu 14036677a에서 기본 512→2048로 runner 값에 맞췄다.
  • 당시 n82 Job 1036985의 전후 E2E 확인 후 적용한다는 계획이 있었으며, 현재 검증 상태는 6.2.1이다.
  • 이전에는 아래 11개를 상수화 대상으로 묶었다: COMPACT_KEEPMAP_SLACK=0, CS_LANDING_PRUNE=1, CS_DRAFT_HOLD=1, CS_DRAFT_HOLD_MAX=64, DIFF_NATIVE=1, DIFF_PARTIAL_RELOAD=1, KEEPMAP_PAD_LAYERS=1, KEEPMAP_STRICT_SLOTS=1, RECOMPACT_SLOT_ALIGN=1, COMPACT_KEEPMAP_SLOT_MULT=2, COMPACT_FINISHED_RESEND=4.
  • 마지막 두 항목은 on/off가 아닌 tuning 상수라는 구분도 있었다.
  • 이후 DIFF_NATIVE는 native→NumPy fallback을 위해 유지했다. 공유한 -march=native build의 SIGILL 위험을 고려한 판정이다.
  • 이후 COMPACT_UPLOAD_PEND도 유지했다. GPU 기본 0·CPU 기본 1 불일치는 미해결이다.
  • COMPACT_ACT_RESERVE_GIB는 코드 상수 1 GiB 로 고정하고 삭제했다(2026-09-30, 러너가 1.0 외 값을 쓴 적 없음).
  • COMPACT_KEEPMAP_SLACK의 당시 setter 76회는 모두 0이었다. 1은 selected set과 delta의 union을 남기는 이전 동작이었다.
  • Landing prune을 끄면 diff 적용 후 prune을 생략하고, draft hold를 끄면 prune 대기 중 draft가 진행한다.
  • Layer padding을 끄면 stale tail, strict slot 검사를 끄면 다른 pool 크기의 map 적용과 KV 손실 위험이 있었다.
  • 초기 rename안은 DELTA_FINISHED_RESEND, DELTA_PRUNE_HOLD, DELTA_PRUNE_HOLD_MAX, DELTA_LANDING_PRUNE, DELTA_PARTIAL_RELOAD, DELTA_KEEPMAP_STRICT_SLOTS, DELTA_KEEPMAP_PAD_LAYERS, DELTA_RECOMPACT_SLOT_ALIGN, DELTA_KEEPMAP_SLOT_MULT, DELTA_KEEPMAP_SLACK, DELTA_INDEX_MAP_MAX, DELTA_UPLOAD_PEND, DELTA_NATIVE였다. 현재 disposition은 6.4로 대체됐다.
  • 초기 fatal/assert 통합안은 DIFF_PAD_SHORT_FATAL, UPLOAD_SKIP_FATAL, CS_PARITY_ASSERT를 LOG_PRINT_DELTA=3에 넣었다.
  • 다른 설계안은 각각 DELTA_PAD_SHORT_FATAL, DELTA_UPLOAD_SKIP_FATAL, DELTA_ASSERT_SERIAL_REQUESTS로 분리했다.
  • 현재 CSV는 세 항목을 명시적 DELTA_STRICT=1로 연결한다.
  • CS_PARITY_ASSERT는 다른 request의 ledger가 남으면 raise하는 serial-request 가정의 검사였다. 동시 요청의 정상 상태와 구분해야 한다.
  • 초기 COMPACT_HOLD_FULL→DUMP_METADATA_ROUNDS 계획은 현재 DELTA CSV의 삭제 판정으로 대체됐다.
  • 초기 LOG_DELTA_SELECTION의 1/2 기능별 분해안과 이후 “값 2만 의미”라는 감사 문구를 이력으로 보존한다. 현재 CSV는 LOG_PRINT_DELTA≥3이다.
  • 초기 COMPACT_DIFF_STAT는 요약을 level 1, 비교·sync timing을 level 2로 분리하는 안이었다. 현재 CSV의 연결은 LOG_PRINT_DELTA≥1이며 세부 emitter 비용을 새로 측정한 결과는 이 문서에 없다.
  • DELTA_COMPACTION_LOG=1과 COMPACT_DIFF_STAT=1의 기존 경로에는 GPU sync 2회가 있었다. Legacy 기능 선택과 새 level 의미를 같은 숫자만으로 대체하지 않는다는 조건을 보존한다.
  • KEEPMAP_SLOT_LOG의 warning은 level 0에서도 남긴다는 판정이다.
6.2.12

6.2.3 주석 정리

6.2.13
  • 대상 v0.14.0 이후 추가한 Python·C++ 코드다.
  • 상태 계획이다. 아래 수치는 기존 조사값이다.
6.2.14
Repo추가한 줄주석 줄한글 주석TODO·FIXME주석 처리된 코드
6.2.14.1vllm32,9274,5038424104
6.2.14.2vllm_cpu6,7421,0530010
6.2.15
적용 규칙
  • vllm·vllm_cpu의 한글 주석 84줄을 영어로 바꾼다.
  • 주석은 두 줄 이내로 두고 긴 설명은 docs로 옮긴다.
  • 주석 처리된 코드 114줄은 삭제하고 Git 기록으로 보존한다.
  • 호출자가 없거나 동작이 바뀐 함수의 docstring을 확인한다. 과거 note_upload() 문제가 점검 사례다.
  • TODO 24개는 issue로 옮기거나 처리한다.
6.2.16

6.2.4 진단 코드 정리

6.2.17
  • 대상 trace 감사에서 남은 문제별 probe다.
  • 상태 계획이며, 변수 삭제와 emitter 삭제를 함께 검토한다.
6.2.18
묶음도입개수예
6.2.18.1hybrid-sw 추적2026-06-07 f369fd17514PR4_*, gemma3 DUMP_*, *_DBG
6.2.18.2pr4-item82026-06-11 vllm_cpu 2ecde1a2b8ALLOC_NEW_COMPUTED_DBG, FREE_BLOCKS_DBG
6.2.18.3해결된 parity 추적2026-09-19 2d7f91b2a·deaf471f39KV_DUMP_*, RECOMPACT_FP_LOG, *_LOG
6.2.19
삭제·유지 판단의 세부 근거
  • 근거는 /envs/ 1.8절과 trace_audit.md다.
  • 초기 47개 삭제 목록의 현재 처리는 6.4에 포함한다.
  • ALLOC_NEW_COMPUTED_DBG, CPU_ATTN_BUILD_DBG, CPU_FWD_READ_HASH, DUMMY_BATCH_DBG, FWD_TENSOR_STATS, INPUT_PROCESSOR_DBG는 횟수가 제한된 probe였다.
  • FREE_BLOCKS_DBG, RESERVE_DBG는 특정 block ID의 free·reserve probe였다.
  • COMPACT_DUMP_INDICES, COMPACT_DUMP_KV는 일회성 layout probe였다.
  • CPU_KV_HASH_DBG는 문제별 block hash였고 기존 진단 setter 하나도 함께 정리하는 계획이었다.
  • DUMMY_BATCH_DBG를 지워도 독립적인 SKIP_DUMMY_BATCH 동작 제어는 유지한다.
  • COMPACTION_IDX_DUMP와 COMPACTION_IDX_EVERY, COMPACTION_IDX_LAYERS는 전체 selected-index writer와 주기·layer filter를 함께 삭제하는 계획이다. 이를 DUMP=accept에 자동 편입하지 않는다.
  • KV_DUMP_DIR는 이전 parity dump family의 경로다. 다른 모든 KV dump의 alias로 확장하지 않는다.
  • KV_DUMP_SEQ는 request prefix·sequence 범위 dump, KV_DUMP_NCT는 tensor 저장과 .cpu()를 포함했다.
  • ATTN_BP_DUMP_SCORE_CHECK는 L×T×H×S fp32 tensor를 유지하는 test-only 비교였다.
  • BREAKDOWN_GPU_EVENT_DEPTH는 4로 고정하는 계획이고, BREAKDOWN_FLUSH_EVERY는 line buffering과 중복이었다.
  • COMPRESS_SPEC_CYCLE_ANNOTATE는 .realmode-run/cycle_map.jsonl에 기록했다. DUMP=accept에도 accepted_token_ids가 있어 중복으로 판정했다.
  • DUMP_EXTEND_BEFORE_VERIFY는 처음 8회, DUMP_SAMPLED_IDS는 처음 32회 probe였다.
  • DUMP_LAST_HIDDEN의 .item()·.cpu(), DUMP_SAMPLED_IDS의 .tolist()는 sync를 수반했다.
  • KV_TRANSFER_DBG는 처음 10회, PR4_8_DBG_EXTENDED의 관련 emitter는 처음 2회 무조건 출력했다.
  • NUMA_VERIFY_DEBUG는 allocation 10,000회마다 print했다.
  • LOGPROB_READ_DEBUG는 08-21 anchor 수정의 계측용이었다. LOGPROB_READ_POS_OFFSET은 legacy-anchor branch 안에서만 읽었다.
  • PAYLOAD_BUILD_DBG env는 제거하되 emitter는 LOG_PRINT_VERIFY=2 아래에 남기는 계획이었다.
  • PR4_DISABLE_COMPRESS_CALL, FAKE_COMPACTION_VERIFY, FAKE_NEEDS_KV_RELOAD, REUSE_ENGINE_RID는 동작을 바꾸는 실험 경로였다.
  • INIT_FILE_PATH는 상대 CPU_VERIFY_DUMP_DIR의 기준 경로였으며 CS_OUT을 절대 경로로 쓰는 계획에서 제거 대상이었다.
  • COMPACT_SCORE_EXPORT_LEGACY는 cpu_attn.py:586의 살아 있는 비교 경로라 초기 dead 판정을 취소했다.
  • LOGPROB_DUMP_DIR는 dump_debugger/logprobs_debugger.py:29의 reader 때문에 유지할 dump 종류로 판정했다.
  • DRAFT_TOKEN_LOG에는 Qwen stop ID 151645·151643이 고정돼 있어 이행 시 model에 맞게 점검한다.
  • VERIFY_DEBUG는 일반 server에서 decode된 draft·verified tail을 출력하지만 score server에는 읽고 쓰지 않는 지점도 있었다.
6.2.20

6.2.5 Trace·출력 경로 통일

6.2.21
  • 목적 기록 위치와 진단 level을 예측 가능하게 만든다.
  • 상태 DELTA 밖의 공용 이행은 계획이다.
6.2.22
대상현재 조사값계획
6.2.22.1출력 경로변수 14개CS_OUT과 고정 하위 폴더
6.2.22.2진단 level방식 5가지LOG_PRINT와 domain override
6.2.22.3기본 반복 로그6곳Level 확인 뒤에 기록
6.2.22.4Env readRequest·round마다 35–45회해석·cache 시점 통합
6.2.22.5_diag()복사 6개공통 해석 계약
6.2.22.6Sync 계측Repacking step당 2회 경로명시적 계측 level로 구분
6.2.23
이전 명칭과 검증 조건
  • 이전 #4 표는 CS_TRACE=0/1/2/3, CS_DUMP, BREAKDOWN=0/rows/light, BREAKDOWN_KERNEL=0/inline/profiler라고 적었다.
  • 현재 공용 설계 명칭은 LOG_PRINT·DUMP이고, kernel 모드에는 inline+gpu-profiler를 포함한다.
  • 이전 폴더 예시는 logs, breakdown, trace, dump/{accept,score,kv,logprob,debug}였다.
  • 당시 예시 경로에 KV_DUMP_DIR=/tmp/qwg_kvdump가 포함됐다.
  • _envcompat로 옛 이름을 경고와 함께 받는 계획이었다.
  • 변경 후 같은 GPU에서 짧은 E2E output과 breakdown을 전후 비교한다.
  • Import 시 cache하더라도 request별 arm override를 잘못 고정하지 않도록 resolver 경계를 확인한다.
6.3.1
  • 문제 실험 조건과 검증 진입점을 일관되게 관리해야 한다.
  • 현상 CLI·환경변수·설정 클래스와 여러 runner가 함께 쓰인다.
  • 원인 실험별 설정과 test 실행 계약이 분산돼 있다.
  • 결과 Profile과 suite를 제안한다. 아직 구현 완료 상태가 아니다.
6.3.2

6.3.1 설정 우선순위

6.3.3
  • 목적 같은 값을 여러 곳에서 정했을 때 실제 적용값을 설명한다.
  • 상태 현재 세 층을 문서화하고 profile 도입을 계획한다.
6.3.4
층위치우선순위
6.3.4.1CLIcompressspec <cmd> …명시한 인자 우선
6.3.4.2환경변수셸 > .envload_dotenv가 기존 셸 값을 덮어쓰지 않음
6.3.4.3설정 클래스CompressionSpecConfig기본값; 일부 field는 생성 시 env read
6.3.5
Profile 제안
  • 실험 조건을 profiles/paper_long.env, paper_batch.env, smoke.env로 묶는다.
  • 제안 진입점은 compressspec run --profile paper_long이다.
  • Profile이 env registry에 없는 이름을 사용하면 시작 시 실패시킨다.
  • Profile을 추가할 때 CLI·셸·profile·.env·class 사이 우선순위를 별도로 확정한다.
  • 위 명령은 설계 예시이며 현재 지원 명령으로 표시하지 않는다.
6.3.6

6.3.2 Test suite

6.3.7
  • 목적 검증 범위·실행 자원·예상 시간을 구분한다.
  • 상태 아래 구성은 계획이다.
6.3.8
Suite검증 내용자원시간
6.3.8.1unitSelection Eq.1·2, delta plan, retention map, ledger ack, rejection samplingGPU 없는 CPU초
6.3.8.2kernelAMX/AVX-512 attention 수치와 참조 구현, tile 경계 w+1CPU 노드분
6.3.8.3apiVerify request·response, version·ack 계약CPU 노드분
6.3.8.4smoke요청 1개, 짧은 context, T=0GPU 1장+CPU socket 1개수 분
6.3.8.5parityT=0의 vLLM token 비교, full/delta token 비교같은 노드 순차수십 분
6.3.8.6perf고정 workload의 breakdown 전후 비교같은 노드수십 분
6.3.8.7artifact논문 figure 재현Cloud시간
6.3.9
Test 배치와 운영
  • 제안 진입점은 compressspec test <suite>이며 suite는 unit·kernel·api·smoke·parity·perf다.
  • Artifact 실행을 같은 CLI에 포함할지는 별도로 확정한다. 기존 표의 artifact 항목은 유지한다.
  • 결과는 CS_OUT/<시각>/test/<suite>/의 CSV와 log다.
  • 실패 시 마지막 50줄을 요약에 붙인다.
  • test/, scripts/, jh_script/ runner를 suite에 흡수하고 나머지는 archive로 옮긴다.
  • Parity·perf는 한 노드에서 순차 실행한다.
  • 실행 전 해당 노드의 다른 process를 확인한다.
6.3.10

6.3.3 장비별 확인

6.3.11
  • 목적 Quickstart 와 offline·online 예제가 GPU·CPU 조합마다 손 설정 없이 도는지 본다.
  • 상태 ISA 별 격리 빌드 후 같은 조건(Qwen3-4B-Thinking-2507 BF16, 16 코어)으로 확인 중이다.
6.3.12

갱신 2026-10-01 20:12 · 결과 results/20260930_qs_matrix/ · 생성 jh_script/claude_script/qs_matrix/hw_matrix.py

6.3.13
장비GPU (cc)CPUISAGPU importCPU importQuickstartAIME 3문항offline SnapKVonline SnapKVoffline StreamingLLMonline StreamingLLMCtrl-C 종료breakdown
6.3.13.1L40SL40S 8.9Xeon Gold 6530AMXOOOOOOOOOO
6.3.13.2L40S · MODEL=HF id (Qwen3-0.6B)L40S 8.9Xeon Gold 6530AMX––––OO––O–
6.3.13.3RTX4090RTX 4090 8.9Xeon Gold 6426YAMXOOOOOOOOOO
6.3.13.4H200H200 9.0Xeon Platinum 8562Y+AMXOOOOOOOOO–
6.3.13.5L40S · AVX-512 경로L40S 8.9Xeon Gold 6530AVX-512 (vec)––––OOOOOO
6.3.13.6H200 · AVX-512 경로H200 9.0Xeon Platinum 8562Y+AVX-512 (vec)––––OOOOO–
6.3.13.7RTX4090 · AVX-512 경로RTX 4090 8.9Xeon Gold 6426YAVX-512 (vec)––––OOOOO–
6.3.13.8RTX6000ADARTX 6000 Ada 8.9EPYC 7313AVX2OOOO¹OOOOO–
6.3.13.9RTX3090RTX 3090 8.6EPYC 7313AVX2OOOO¹OOOOO–
6.3.13.10A6000RTX A6000 8.6EPYC 7413AVX2OOOO¹OOOOOO
6.3.13.11A5000RTX A5000 8.6EPYC 7502AVX2OOOO¹OOOOOO
6.3.13.12A100-80GBA100 80GB 8.0EPYC 7513AVX2OOOO¹OOOOO–
6.3.13.13A100-40GBA100 40GB 8.0EPYC 7742AVX2OOOO¹OOOOO–
6.3.13.144A100A100 40GB 8.0EPYC 7742AVX2OOOO¹OOOOO–
6.3.13.15TITANRTXTITAN RTX 7.5Xeon Gold 5220RAVX-512OOX²––³–³–³–³–³O
6.3.13.16RTX2080TiRTX 2080 Ti 7.5Xeon Silver 4210AVX-512OOXX–³–³–³–³–³–
6.3.14

O 통과 · X 실패 · … 진행 중 또는 대기 · – 해당 없음 또는 미실행

6.3.15

¹ 측정 30행·3행은 모두 기록됐으나, 실행 중 스크립트를 덮어써 판정 줄이 rc=127 로 남았습니다.

6.3.16

² 판정 기준을 고치기 전 기록입니다. 수락 0/752, 출력이 개행 문자뿐이라 실패로 봅니다.

6.3.17

³ RTX 2080 Ti 는 GPU 메모리 부족(모델 7.61 GiB 적재 후 KV cache 가용 -0.98 GiB)으로 제외했습니다. TITAN RTX 는 지원하지 않습니다. TandemSpec 은 FlashInfer attention 을 필수로 쓰는데, 이 GPU(sm_75)에서 FlashInfer 가 틀린 결과를 냅니다(vLLM 단독에서도 FlashInfer 는 깨지고 Triton 은 정상, results/20260930_qs_matrix/turing_diag/). Ampere(sm_80) 이후를 주 대상으로 만든 kernel 이라 Turing 경로가 검증되지 않은 것으로 보이며, 원인 kernel 은 확인하지 않았습니다.

6.4.1
  • 기준 feat/clean_code 현재 코드 (TandemSpec 620cd05, vllm fad20de69, vllm_cpu cf6fc24b2). launcher·예제·verify 서버·두 엔진이 읽는 변수 중 upstream vLLM v0.14.0 에 없던 이름. harness(test/, scripts/) 전용 변수는 제외
  • 개수 사용자 경로·자동 설정·출력 61 · 엔진 기능 조절 105 · 디버그 스위치 34 · 옛 이름 25 · 퇴역 26
  • 근거 전체 목록 g07 011_tandemspec_clean/results/20261007_env_inventory/env_now.csv. 용도 열은 09-30 원자료(read site 확인)에서 가져왔고, 없으면 비움
  • 생성기 model_matrix/dashboard_tools/gen_env_now.py (이 절은 손으로 고치지 않고 다시 생성)
6.4.2

6.4.1 사용자가 정하는 것

6.4.3
변수기본값용도
6.4.3.1MODEL없음 (필수)모델 경로 또는 HF ID, 두 엔진 공통
6.4.3.2EXP_DTYPEfp16bf16 · fp16 · fp32, 두 엔진 공통
6.4.3.3HYBRID_COMPRESS_MODEsnapkvprefill 선택 snapkv · streamingllm
6.4.3.4SERVE_PORT8100online API 포트 (--port 와 같음)
6.4.3.5MAX_TOKENS128offline 예제 생성 길이 (--max-tokens 와 같음)
6.4.3.6HF_TOKEN없음비공개 HF 모델
6.4.4

6.4.2 조정용 (기본값으로 충분)

6.4.5
변수기본값용도
6.4.5.1MAX_MODEL_LEN8192최대 길이, verify 쪽도 따름
6.4.5.2MAX_NUM_SEQS8동시 요청 수. CPU index map 크기도 이 값으로 자동 결정
6.4.5.3GPU_MEMORY_UTILIZATION0.8GPU 메모리 사용률
6.4.5.4SHARED_CPU_POOL_GB8CPU KV pool 크기 (GiB)
6.4.5.5BLOCK_SIZE32KV block 크기. DRAFT_BLOCK_SIZE·VERIFY_BLOCK_SIZE 로 따로 줄 수 있으나 같아야 함
6.4.5.6SPECULATIVE_RUN_STEP16draft window
6.4.5.7COMPRESSION_SPEC_SELECTED_TOKENS128prefill 끝의 선택 budget. launcher 가 EXP_SELECTED_TOKENS 에도 같은 값을 넣음
6.4.5.8COMPACT_COVERAGE0.95coverage threshold τ (선택 + recall gate). 엔진 단독 기본값은 0.7
6.4.5.9COMPACT_GATE_SCORE1recall gate 켜기
6.4.5.10STREAMINGLLM_SINK64StreamingLLM sink token 수
6.4.5.11ENFORCE_EAGER01 이면 CUDA graph 끔
6.4.5.12PORT8000내부 verify 서버 포트
6.4.5.13COMPRESS_SPEC_CORESautodraft·verify 코어 분배 (off 면 분배 안 함)
6.4.5.14COMPRESS_SPEC_DRAFT_CORES4draft 엔진 코어 수
6.4.6

6.4.3 launcher 가 자동으로 채우는 것 (설정하지 않음)

6.4.7
변수채우는 값
6.4.7.1VERIFY_MODELMODEL
6.4.7.2CPU_VERIFY_URLPORT 로 만듦
6.4.7.3LOGPROB_VOCAB_SIZEconfig.json vocab_size
6.4.7.4SCORE_NUM_LAYERSconfig.json num_hidden_layers
6.4.7.5SCORE_NUM_Q_HEADSconfig.json num_attention_heads
6.4.7.6SCORE_POOL_SIZE동시 요청 수 × (길이/128 + 2) × 1.25
6.4.7.7VERIFY_MAX_MODEL_LENMAX_MODEL_LEN
6.4.7.8EXP_SELECTED_TOKENSCOMPRESSION_SPEC_SELECTED_TOKENS 와 같은 값
6.4.7.9VLLM_CPU_KVCACHE_SPACESHARED_CPU_POOL_GB
6.4.7.10VLLM_CPU_OMP_THREADS_BIND코어 분배 결과
6.4.7.11OMP_NUM_THREADS코어 분배 결과
6.4.7.12VLLM_ATTENTION_BACKENDFLASHINFER
6.4.7.13COMPRESSION_SPEC_DECODING_INTERVAL2048
6.4.7.14NUM_GPU_BLOCKS · max_num_seqsGPU 엔진이 시작할 때 /initialize 로 CPU 엔진에 전달 (환경변수 아님)
6.4.8

6.4.4 설치·실행 제어

6.4.9
변수용도
6.4.9.1COMPRESS_SPEC_DRAFT_ENV기존 draft conda env 지정
6.4.9.2COMPRESS_SPEC_VERIFY_ENV기존 verify conda env 지정
6.4.9.3COMPRESS_SPEC_TAGenv 이름 태그
6.4.9.4COMPRESS_SPEC_SKIP_CHECKbuild stamp 대조 생략
6.4.9.5COMPRESS_SPEC_NO_AUTOBUILDstamp 불일치 시 자동 재빌드 거부
6.4.9.6COMPRESS_SPEC_NO_CLEAN실행 전 정리 생략
6.4.9.7LOG_DIR, CPU_LOG, GPU_LOG로그 위치
6.4.9.8READY_TIMEOUTverify 서버 준비 대기 (600초)
6.4.9.9HF_HUB_OFFLINE, TRANSFORMERS_OFFLINEHF 오프라인. 처음 받을 때는 0
6.4.9.10MINIFORGE_DIRconda 위치
6.4.10

6.4.5 로그 · dump · breakdown

6.4.11
변수동작
6.4.11.1DUMP_DIR모든 dump 출력 위치. $DUMP_DIR/<kind> (breakdown, kv, score, verify, metadata, fsm, delta …)
6.4.11.2LOG_PRINT_BREAKDOWN1 phase 단위 breakdown, 2 CPU kernel 계측 추가
6.4.11.3LOG_PRINT_DUMP1 index · accept · FSM, 2 score · attn KV, 3 forward · logits · sampled id
6.4.11.4LOG_PRINT_<DOMAIN>도메인별 로그 0–3: BREAKDOWN, DELTA, DUMP, KV, VERIFY. 없으면 LOG_PRINT
6.4.11.5BREAKDOWN_KERNEL_INLINEkernel 계측 방법. 1 inline (기본), 0 torch.profiler
6.4.11.6BREAKDOWN_PHASES, BREAKDOWN_LIGHT_LATbreakdown 필터·요약 모드
6.4.11.7KV_DUMP_NCT, KV_DUMP_SEQ, COMPACTION_IDX_EVERY, COMPACTION_IDX_LAYERSdump 범위 필터 (켜기는 LOG_PRINT_DUMP)
6.4.11.8COMPRESS_SPEC_TRACE_REQtrace 를 request 하나로 좁힘
6.4.11.9BREAKDOWN_RUN_DIRharness 가 정하는 run 디렉토리 (내부)
6.4.12

6.4.6 엔진 기능 조절 (105개, 실험용 · 기본값 그대로 사용)

6.4.13
카테고리개수
6.4.13.1VERIFY — verify engine39
6.4.13.2COMPACTION — recompression20
6.4.13.3KV — KV offload · pool16
6.4.13.4PREFILL — prefill10
6.4.13.5DRAFT — draft engine5
6.4.13.6DELTA — delta transfer4
6.4.13.7ROUTER — mode 전환4
6.4.13.8HARNESS1
6.4.13.9ETC — 기타1
6.4.13.10미분류 — 09-30 원자료에 없던 변수5
6.4.14
6.4.6.1 VERIFY — verify engine
6.4.15
변수기본값읽는 곳용도
6.4.15.1ACCEPT_MODEstandardverify/utils.pystandard / dual / cactus / tas acceptance rule
6.4.15.2CACTUS_DELTA1.0verify/utils.py
6.4.15.3COMPSPEC_BONUS_TOKEN0verify/cpu_verify_server.pychanges what the GPU appends; behaviour knob
6.4.15.4COMPSPEC_SKIP_WATCH_SECS120vllm/cpu_verify/cpu_verify_engine.pylog-only watchdog threshold (comment :542); still a timing parameter, …
6.4.15.5CPU_VERIFY_TIMEOUT_S500vllm/cpu_verify/_verify_dispatcher.py
6.4.15.6FORCE_ATTN_ISA""vllm/v1/kv_offload/worker/cpu_gpu.py 외 1
6.4.15.7LOGPROB_READ_POS_OFFSET0vllm/cpu_verify/cpu_verify_engine.pyonly read inside the LEGACY_ANCHOR branch
6.4.15.8LOGPROB_SPARSE0verify/test_logprob_stamp.py 외 4
6.4.15.9LOGPROB_SPARSE_CAP128verify/utils.py 외 2
6.4.15.10MAXPOS_OVERRIDE—verify/cpu_verify_server.py 외 1
6.4.15.11NUMA_AWARE_VERIFY_NODES4verify/cpu_verify_server.py 외 5
6.4.15.12RELAX_RESIDUALv1verify/utils.pyread but effect not in the read lines; UNCLEAR: read verify/utils.py …
6.4.15.13RELAX_TAU0.5verify/utils.py
6.4.15.14RS_ALLOW_UNSUPPORTED_SAMPLING0vllm/cpu_verify/channels/temp_buffer.py
6.4.15.15RS_FAST_TRUNC1verify/utils.py
6.4.15.16RS_FAST_TRUNC_MAX_K4096verify/utils.py
6.4.15.17RS_KTH_CHUNKS32verify/utils.py
6.4.15.18RS_KTH_MIN_VOCAB16384verify/utils.py
6.4.15.19RS_Q_FLOOR1e-6verify/utils.py
6.4.15.20RS_ROW_MISMATCHfatal · rejectverify/test_rs_truncation.py 외 1
6.4.15.21RS_STALE_MAX_RATE0.02verify/utils.py
6.4.15.22RS_STALE_MIN_POS200verify/utils.py
6.4.15.23RS_TIE_EPS1e-3verify/utils.py
6.4.15.24RS_TOPP_EPS1e-5verify/utils.py
6.4.15.25RS_TRUNCATE1verify/utils.py
6.4.15.26SKIP_DUMMY_BATCH0vllm_cpu/v1/engine/core.py
6.4.15.27TAS_DELTA0.3verify/utils.py
6.4.15.28TAS_EPS0.09verify/utils.py
6.4.15.29VERIFY_BATCH_WINDOW_MS0verify/cpu_verify_server.py
6.4.15.30VERIFY_DISABLE_HYBRID_KVCM0verify/cpu_verify_server.py0 setters; behaviour knob, must not fold into a level
6.4.15.31VERIFY_DISPATCH_WORKERS""vllm/cpu_verify/cpu_verify_engine.py
6.4.15.32VERIFY_DP_SIZE1verify/cpu_verify_server.py 외 5
6.4.15.33VERIFY_ENFORCE_EAGER1verify/cpu_verify_server.py 외 1
6.4.15.34VERIFY_KV_PREFAULT0vllm_cpu/v1/worker/gpu_model_runner.py
6.4.15.35VERIFY_KV_PREFAULT_ARM_IDLE2.0vllm_cpu/v1/worker/gpu_model_runner.py
6.4.15.36VERIFY_MAX_NUM_SEQS1 · 32 · 4verify/cpu_verify_server.py 외 2
6.4.15.37VERIFY_NUMA_INTERLEAVE1verify/cpu_verify_server.py
6.4.15.38VERIFY_NUMA_LOCAL—verify/cpu_verify_server.py
6.4.15.39VERIFY_PROMPT_LOGPROBS-1verify/cpu_verify_server.py
6.4.16
6.4.6.2 COMPACTION — recompression
6.4.17
변수기본값읽는 곳용도
6.4.17.1COMPACT_BLOCK_KEEP_RATIO0.1vllm_cpu/v1/worker/gpu_model_runner.py
6.4.17.2COMPACT_BLOCK_POLICYmassvllm_cpu/v1/worker/gpu_model_runner.py
6.4.17.3COMPACT_BLOCK_SIZE32vllm/cpu_verify/keep_map_reader.pyslot alignment for the keep map = KV block size; UNCLEAR whether any …
6.4.17.4COMPACT_DISABLE0vllm_cpu/v1/worker/gpu_model_runner.py
6.4.17.5COMPACT_GATE_AGGminvllm_cpu/v1/worker/gpu_model_runner.py
6.4.17.6COMPACT_METHOD? · block · tokenverify/profile_cpu_forward.py 외 5
6.4.17.7COMPACT_NATIVE0 · 1verify/profile_cpu_forward.py 외 2
6.4.17.8COMPACT_SCORE_FP161vllm_cpu/v1/attention/backends/cpu_attn.py
6.4.17.9COMPACT_SCORE_NO_REDUCE0vllm_cpu/v1/attention/backends/cpu_attn.py
6.4.17.10COMPACT_TOKEN_GLOBAL_RANK0vllm_cpu/v1/worker/gpu_model_runner.py
6.4.17.11COMPACT_TOKEN_HEAD_AGGgqa_maxvllm_cpu/v1/attention/backends/cpu_attn.py 외 1
6.4.17.12COMPACT_TOKEN_NUM_RECENT32vllm_cpu/v1/worker/gpu_model_runner.py
6.4.17.13COMPACT_TOKEN_NUM_SINK32vllm_cpu/v1/worker/gpu_model_runner.py
6.4.17.14COMPACT_TOKEN_POOL_K7vllm_cpu/v1/worker/gpu_model_runner.py
6.4.17.15COMPACT_TOKEN_POOL_TYPEmaxvllm_cpu/v1/worker/gpu_model_runner.py
6.4.17.16COMPACT_TOKEN_SCORE_ROWSdraft_first_lastvllm_cpu/v1/attention/backends/cpu_attn.py 외 1
6.4.17.17CP_BATCH_HEAD_REDUCE1vllm_cpu/v1/worker/gpu_model_runner.py
6.4.17.18DENSE_NO_COMPACT—vllm_cpu/v1/worker/gpu_model_runner.py
6.4.17.19SNAPKV_KEY_CHUNK—vllm/v1/attention/backends/flashinfer.py
6.4.17.20SNAPKV_WIN_CHUNK8vllm/v1/attention/backends/flashinfer.py
6.4.18
6.4.6.3 KV — KV offload · pool
6.4.19
변수기본값읽는 곳용도
6.4.19.1ATTN_BP_STREAM_CAP64vllm/distributed/kv_transfer/kv_connector/v1/attn_byproduct_handler/handler.pystream/event pool cap; resource limit
6.4.19.2COMPACT_FULL_COPY_GB8vllm/config/compression_spec_config.py
6.4.19.3COMPACT_TEMP_BUFFER_GB8vllm/config/compression_spec_config.pyconnector memory size, not a compaction knob
6.4.19.4COMPRESS_SPEC_CPU_POOL_HOLD1vllm/cpu_verify/cpu_verify_engine.pyadmission hold on CPU pool capacity; default on
6.4.19.5COMPRESS_SPEC_NO_FREE_SW0vllm_cpu/v1/core/single_type_kv_cache_manager.py
6.4.19.6COMPRESS_SPEC_PIN_FULLKV0vllm_cpu/v1/core/kv_cache_manager.py 외 1
6.4.19.7COMPSPEC_PREEMPT_OFFLOAD0vllm/cpu_verify/compaction_upload/manager.py 외 2
6.4.19.8COMPSPEC_RELOAD_STALL_S120vllm/cpu_verify/cpu_verify_engine.py
6.4.19.9COMPSPEC_RESUME_NEED_GATE0vllm/cpu_verify/cpu_verify_engine.py
6.4.19.10COMPSPEC_RESUME_NEED_MARGIN0vllm/cpu_verify/cpu_verify_engine.py
6.4.19.11COMPSPEC_RESUME_NEED_TIMEOUT_S600vllm/cpu_verify/cpu_verify_engine.py
6.4.19.12CPU_OFFLOAD_POOL_BLOCKS""vllm/cpu_verify/cpu_verify_engine.py 외 3
6.4.19.13NUMA_FIRST_TOUCH0vllm/v1/kv_offload/worker/cpu_gpu.py 외 2
6.4.19.14NUMA_FT_NODES""compressspec/numa_first_touch.py 외 1
6.4.19.15OFFLOAD_PREFIX_CACHE0vllm/cpu_verify/channels/naive_copy.pyrestores a documented-broken 2x-pool behaviour for A/B; 0 setters
6.4.19.16RESERVE_SKIPPED_SW_BLOCKS0vllm_cpu/v1/core/single_type_kv_cache_manager.py
6.4.20
6.4.6.4 PREFILL — prefill
6.4.21
변수기본값읽는 곳용도
6.4.21.1HI_NTB32vllm/v1/attention/backends/headinfer_decode.py
6.4.21.2LAYER_SERIAL_BARRIERstreamvllm/cpu_verify/cpu_verify_engine.py
6.4.21.3LAYER_SERIAL_CHUNKED0vllm/config/scheduler.py 외 2
6.4.21.4LAYER_SERIAL_COVERAGE_BLOCKS—vllm/v1/core/kv_cache_utils.py
6.4.21.5LAYER_SERIAL_K0vllm/cpu_verify/channels/naive_copy.py 외 6
6.4.21.6LAYER_SERIAL_TAIL_BLOCKS16vllm/cpu_verify/cpu_verify_engine.py 외 2
6.4.21.7LS_CHUNKED_VERIFY0vllm/v1/attention/backends/flashinfer.py
6.4.21.8LS_CHUNK_TILE8192vllm/v1/worker/gpu_model_runner.py
6.4.21.9LS_PIPELINE_RELOAD1vllm/v1/attention/backends/flashinfer.py
6.4.21.10LS_RELOAD_MEMCPY1vllm/v1/attention/backends/flashinfer.py
6.4.22
6.4.6.5 DRAFT — draft engine
6.4.23
변수기본값읽는 곳용도
6.4.23.1COMPRESSION_SPEC_MAX_TOTAL_CONTEXT—vllm/v1/core/sched/scheduler.py
6.4.23.2COMPSPEC_DECODE_ATTN_INTERVAL—vllm/v1/attention/backends/flashinfer.py
6.4.23.3COMPSPEC_DRAFT_STALL_S60vllm/cpu_verify/cpu_verify_engine.py
6.4.23.4COMPSPEC_RUNAHEAD""vllm/cpu_verify/cpu_verify_engine.py
6.4.23.5DRAFT_DISPATCH_FULL0vllm/cpu_verify/channels/temp_buffer.pyfixed-window dispatch for parity runs; behaviour
6.4.24
6.4.6.6 DELTA — delta transfer
6.4.25
변수기본값읽는 곳용도
6.4.25.1COMPACT_DIFF_UPLOAD1vllm_cpu/v1/worker/gpu_model_runner.py
6.4.25.2COMPACT_MAX_GPUBLK_UTIL0.9vllm/cpu_verify/compaction_upload/scheduler_recompact.py
6.4.25.3COMPACT_UPLOAD_PEND1verify/cpu_verify_server.py 외 3
6.4.25.4DELTA_STRICT0vllm/cpu_verify/compaction_trace.py 외 4
6.4.26
6.4.6.7 ROUTER — mode 전환
6.4.27
변수기본값읽는 곳용도
6.4.27.1DYN_FORCE_OUT0vllm/cpu_verify/dyn_router.pydev knob; runners pass $LC_DYN_FORCE_OUT
6.4.27.2DYN_ROUTER0vllm/cpu_verify/dyn_router.py
6.4.27.3DYN_ROUTER_HEADROOM_PCT0.10vllm/cpu_verify/dyn_router.py
6.4.27.4DYN_ROUTER_HOLD_STEPS500vllm/cpu_verify/dyn_router.py
6.4.28
6.4.6.8 HARNESS
6.4.29
변수기본값읽는 곳용도
6.4.29.1ARM—vllm/cpu_verify/channels/temp_buffer.py 외 3
6.4.30
6.4.6.9 ETC — 기타
6.4.31
변수기본값읽는 곳용도
6.4.31.1REUSE_ENGINE_RID0verify/cpu_verify_server.pyPR4 item-8 hypothesis toggle (comment :499); 0 setters
6.4.32
6.4.6.10 미분류 — 09-30 원자료에 없던 변수
6.4.33
변수기본값읽는 곳용도
6.4.33.1COMPACT_BLOCK_BUDGET—vllm_cpu/v1/worker/gpu_model_runner.py
6.4.33.2COMPACT_GATE_FALLBACKcompactvllm_cpu/v1/worker/gpu_model_runner.py
6.4.33.3COMPACT_UPLOAD_TIMEOUT_S—vllm/cpu_verify/_compaction_upload_dispatcher.py
6.4.33.4CS_UNPIN_HELPERS2vllm_cpu/v1/worker/cpu_worker.py
6.4.33.5RS_GUMBEL_SPARSE1verify/utils.py
6.4.34

6.4.7 디버그 스위치 (34개, LOG_PRINT_* 흡수 후보)

6.4.35
  • 출력만 늘리는 스위치는 LOG_PRINT_<DOMAIN> 으로 흡수할 수 있다. 동작을 바꾸는 스위치(COMPRESS_SPEC_SYNC_VERIFY, FAKE_*)는 흡수하지 않고 디버그 전용으로 둔다
6.4.36
변수기본값읽는 곳용도
6.4.36.1ATTN_BP_DEBUG_FILL""vllm/distributed/kv_transfer/kv_connector/v1/offloading_attn_bp_connector.pyTRAP: without .env the harness random-fills BP s
6.4.36.2COMPACT_HOLD_DUMP—vllm_cpu/compaction/index_map.py
6.4.36.3COMPACT_SCORE_EXPORT_LEGACY0vllm_cpu/v1/attention/backends/cpu_attn.py
6.4.36.4COMPACT_SCORE_FORCE_OFF0vllm_cpu/v1/attention/backends/cpu_attn.py
6.4.36.5COMPRESS_SPEC_CYCLE_ANNOTATE0vllm/cpu_verify/cpu_verify_engine.pywrites hard-coded .realmode-run/cycle_map.jsonl; 'uncommitted' …
6.4.36.6COMPRESS_SPEC_DEBUG0verify/utils.py 외 3the three == "1" readers fire ONLY
6.4.36.7COMPRESS_SPEC_SYNC_VERIFY0vllm/v1/core/sched/scheduler.pydebug-only but behaviour-altering (serializes draft/verify); never a …
6.4.36.8CPU_KV_HASH_DBG0vllm_cpu/v1/worker/gpu_model_runner.py
6.4.36.9CPU_PROFILE_CHUNK0verify/profile_cpu_forward.py
6.4.36.10CPU_PROFILE_CHUNK_ITERS12verify/profile_cpu_forward.py
6.4.36.11CPU_PROFILE_COMPACT_RATE"" · 0verify/profile_cpu_forward.py
6.4.36.12CPU_PROFILE_CTX_TRUNC0verify/profile_cpu_forward.py
6.4.36.13CPU_PROFILE_MAX_TOKENS32verify/profile_cpu_forward.py
6.4.36.14CPU_PROFILE_PROMPT_LOGPROBS—verify/profile_cpu_forward.py
6.4.36.15CS_STOP_LOG0vllm/v1/core/sched/utils.pyper request per step when near a cap
6.4.36.16DRAFT_DISPATCH_LOG0vllm/cpu_verify/channels/temp_buffer.py
6.4.36.17DUMMY_BATCH_DBG0vllm_cpu/v1/engine/core.py
6.4.36.18EXAMPLE_DIAG_QID1compressspec/cli.py
6.4.36.19FAKE_COMPACTION_VERIFY0.0vllm_cpu/v1/worker/gpu_model_runner.py
6.4.36.20FAKE_NEEDS_KV_RELOAD0vllm/cpu_verify/_fake_verify.pygpu_only fake-verify toggle; 0 setters
6.4.36.21LOGPROB_DUMP_DIR—verify/utils.pyaudit s3.2 lists it under REMOVE; kept because a reader tool exists
6.4.36.22LOGPROB_READ_LEGACY_ANCHOR0vllm/cpu_verify/cpu_verify_engine.pylegacy A/B path (dead_kind C)
6.4.36.23LS_PEAK_PROBE0vllm/v1/core/sched/scheduler.pyone line per free event; no sync
6.4.36.24PR4_8_DBG_EXTENDED0vllm/cpu_verify/channels/naive_copy.pyNOTE the [PR4-8-DBG] emitter at :321-335 is unconditional for the …
6.4.36.25PR4_DISABLE_COMPRESS_CALL0vllm/v1/attention/backends/flashinfer.pybehaviour-altering probe; 0 setters
6.4.36.26PR4_SW_GUARD_DEBUG0vllm/v1/attention/backends/flashinfer.py
6.4.36.27PRESERVE_LOG0vllm/cpu_verify/channels/temp_buffer.py 외 1one line per reload / per all-accept preserve
6.4.36.28REJECT_DISTRIB_DUMP0verify/utils.pytoday needs DEBUG_METADATA_DUMP_DIR too (:1333 ACCEPT_DUMP_DIR); one …
6.4.36.29REJECT_DISTRIB_PT0verify/utils.py
6.4.36.30REJECT_DISTRIB_PT_MAX2000verify/utils.py
6.4.36.31REJECT_DISTRIB_SOURCEserververify/utils.py
6.4.36.32REJECT_DISTRIB_TOPK8verify/utils.py
6.4.36.33RULER_SEQ—verify/profile_cpu_forward.py
6.4.36.34RULER_TASKniah_single_1verify/profile_cpu_forward.py
6.4.37

6.4.8 옛 이름 (25개, 설정하면 경고 후 새 이름으로 동작)

6.4.38
옛 이름새 이름
6.4.38.1ATTN_BP_DUMP_SCORE_CHECKLOG_PRINT_DUMP≥2
6.4.38.2ATTN_KV_DUMP_DIRLOG_PRINT_DUMP≥2 + $DUMP_DIR/attn_kv
6.4.38.3BREAKDOWN_DIR$DUMP_DIR/breakdown
6.4.38.4BREAKDOWN_KERNEL_PROFILE_MODELOG_PRINT_BREAKDOWN≥2
6.4.38.5COMPACTION_IDX_DUMPLOG_PRINT_DUMP≥1
6.4.38.6COMPACT_DUMP_INDICESLOG_PRINT_DUMP≥2
6.4.38.7COMPACT_DUMP_KVLOG_PRINT_DUMP≥2
6.4.38.8COMPACT_GATE_THRESHOLDCOMPACT_COVERAGE
6.4.38.9COMPACT_THRESHOLDCOMPACT_COVERAGE
6.4.38.10COMPRESSION_SPEC_DEBUGCOMPRESS_SPEC_DEBUG
6.4.38.11COMPRESS_SPEC_DUMP_DIR$DUMP_DIR/cspec
6.4.38.12CPU_VERIFY_DUMP_DIR$DUMP_DIR/verify
6.4.38.13DEBUG_METADATA_DUMP_DIRLOG_PRINT_DUMP≥1 + $DUMP_DIR/metadata
6.4.38.14DELTA_COMPACTION_LOGLOG_PRINT_DELTA
6.4.38.15DUMP_EXTEND_BEFORE_VERIFYLOG_PRINT_DUMP≥3
6.4.38.16DUMP_FORWARD_OUTLOG_PRINT_DUMP≥3
6.4.38.17DUMP_LAST_HIDDENLOG_PRINT_DUMP≥3
6.4.38.18DUMP_LOGITS_OUTLOG_PRINT_DUMP≥3
6.4.38.19DUMP_SAMPLED_IDSLOG_PRINT_DUMP≥3
6.4.38.20DUMP_TRACKER_DISPATCHLOG_PRINT_DUMP≥3
6.4.38.21FSM_RUN_DIRLOG_PRINT_DUMP≥1 + $DUMP_DIR/fsm
6.4.38.22KV_DUMP_DIR$DUMP_DIR/kv
6.4.38.23OUT_ROOT$DUMP_DIR/delta
6.4.38.24SCORE_DUMP_DIRLOG_PRINT_DUMP≥2 + $DUMP_DIR/score
6.4.38.25VLLM_CPU_KVCACHE_SPACESHARED_CPU_POOL_GB (사용자 입력일 때만. launcher 는 내부적으로 계속 설정)
6.4.39

6.4.9 퇴역 (26개, 설정하면 경고만 출력하고 무시)

6.4.40
대신 쓸 것퇴역한 이름
6.4.40.1LOG_PRINT_BREAKDOWNBREAKDOWN_FLUSH_EVERY, BREAKDOWN_GPU_EVENT_DEPTH, BREAKDOWN_PER_REQ, BREAKDOWN_SKIP_WARMUP
6.4.40.2LOG_PRINT_KVALLOC_NEW_COMPUTED_DBG, COMPSPEC_OFFLOAD_COVER, FREE_BLOCKS_DBG, INPUT_PROCESSOR_DBG, KV_DST_PTR_DBG, KV_TRANSFER_DBG, NAIVE_STORE_DBG, NUMA_VERIFY_DEBUG, RESERVE_DBG, SAVE_KV_LAYER_DBG, TEMPBUF_DBG
6.4.40.3LOG_PRINT_VERIFYCOMPRESS_SPEC_TRACE, CPU_ATTN_BUILD_DBG, CPU_FWD_READ_HASH, DRAFT_TOKEN_LOG, FWD_TENSOR_STATS, LAST_VERIFY_LOG, LOGPROB_READ_DEBUG, PAYLOAD_BUILD_DBG, VERIFY_BATCH_LOG, VERIFY_DEBUG, VERIFY_DEBUG_PAYLOAD
6.4.40.4자동화 (/initialize · native 고정)DIFF_NATIVE, DELTA_PUBLISH_FULL_KEEPMAP, COMPACT_INDEX_MAP_MAX
6.4.41

6.4.10 정리 후보

6.4.42
항목상태
6.4.42.1디버그 스위치 (6.4.7) 를 LOG_PRINT_* 로 흡수, COMPRESS_SPEC_DEBUG 포함미처리
6.4.42.2EXP_SELECTED_TOKENS → COMPRESSION_SPEC_SELECTED_TOKENS 하나로 (vllm_cpu 와 harness 4개)보류 (사용자 결정)
6.4.42.3COMPACT_COVERAGE 기본값 0.95 (launcher) vs 0.7 (엔진)결정 대기
6.4.42.4EXAMPLE_DIAG_QID 는 compressspec test example 전용, 사용자 경로 아님유지
6.4.42.5옛 이름 (6.4.8) 제거harness 가 새 이름으로 옮긴 뒤
6.5.1
  • 결론 대표 브랜치는 feat/clean_code 하나. dev 위에 얹혀 있고 PR #47(→ dev, OPEN)로 올라가 있다
  • 받는 법 git clone -b feat/clean_code --recursive https://github.com/PSAL-POSTECH/TandemSpec.git
6.5.2

6.5.1 feat/clean_code 구성

6.5.3
저장소커밋dev 대비최근 커밋
6.5.3.1TandemSpec (001)1b24c0c+9로그·환경변수 정리 1개 (1b24c0c), 공개 docs 정리 1개 (12f32ba)
6.5.3.2vllmdbe3a8e+6로그 정리 1개 (dbe3a8e): DUMP_DIR + LOG_PRINT_BREAKDOWN/DUMP
6.5.3.3vllm_cpucf6fc24+6로그·compaction 변수 정리 1개 (cf6fc24)
6.5.4
  • 10-06~07 정리 커밋은 레포마다 하나로 묶었다. 그 전 커밋(09-30 env_clean 등)은 그대로
  • 백업 브랜치 backup/clean_code-pre-squash-20261007(세 레포), backup/clean_code-pre-internal-removal(001)
  • 내부 전달용 파일(handoff, manifest, documents/serve/, *_jh.py)은 history 에서 빼고 .gitignore 로 로컬에만 둠
6.5.5

6.5.2 검증

6.5.6
장비판결과근거
6.5.6.1g07 RTX 3090 + EPYC 75F3 (AVX2)breakdown 2단계화A =2 / B =1 / C 옛 변수 / D 끔 모두 통과, CSV 중복 row 0g07 011_tandemspec_clean/results/20261007_g07_breakdown_level2/
6.5.6.2g07 RTX 3090 + EPYC 75F3DUMP_DIR 도입6/6 통과, 새 방식·옛 방식 캡처와 debugger CSV 생성results/20261006_g07_dump_breakdown/
6.5.6.3g07 RTX 3090 + EPYC 75F3/initialize, native 고정6/6 통과. native vs numpy 400/400 일치. continuous batching 24/24 요청, verify 629건 500 0건, LRU drop 0results/20261006_g07_native_initialize/
6.5.6.4g07 RTX 3090 + EPYC 75F3env_clean 병합6/6 통과results/20261006_g07_env_clean/
6.5.6.5n75 RTX 4090 + Xeon 6426Y (AMX)dev 엔진미완료: CPU 엔진 빌드가 oneDNN 다운로드에서 정체해 중단ai-cluster results/20261006_rtx4090_clean_code/v4/
6.5.7
  • 6/6 = SnapKV·StreamingLLM × offline·online·Ctrl-C 종료
6.5.8

6.5.3 10-06~07 고친 결함

6.5.9
결함증상수정
6.5.9.1HF ID 의 vocab 을 바깥 env 의 transformers 로 읽음RS ROW MISMATCH, verify 전부 실패인데 종료 코드 0config.json 만 받아 직접 읽음
6.5.9.2dev vllm_cpu 가 score 버퍼 모양을 필수로 요구compressspec run 에서 verify 500launcher 가 SCORE_NUM_LAYERS·SCORE_NUM_Q_HEADS 채움
6.5.9.3cpu_verify_server.py 에 /initialize 없음긴 context 에서 "Cannot get 32 free blocks"/initialize 추가, index map 크기 = max(64, 4×max_num_seqs)
6.5.9.4BREAKDOWN_PER_REQ 가 sched.jsonl 줄을 복사CSV 같은 row 5,034개 (request 구간 두 번 집계)기능 제거
6.5.9.5debugger 의 BREAKDOWN_KERNEL_INLINE 기본값 0 (엔진은 1)kernel 계측을 켜도 CPU_FWD_* row 0기본값 1, 기본 모드에서도 inline row 병합
6.5.10

6.5.4 남은 일

6.5.11
항목상태
6.5.11.1PR #47 리뷰·병합OPEN
6.5.11.2빈 step breakdown 기록 (전체 row 의 92.6%)묶을지 결정 대기 (ENGINE_IDLE 하나로 묶기 권장)
6.5.11.3디버그 변수 40개 LOG_PRINT_* 흡수, COMPRESS_SPEC_DEBUG 포함미처리
6.5.11.4launcher 경로 batch별 CPU breakdowncpu_verify_server.py 가 cpu_batch_size 를 안 돌려줌 (score 서버만 지원)
6.5.11.5n75 (AMX) 검증FETCHCONTENT_SOURCE_DIR_ONEDNN 지정 후 재시도 필요
6.5.11.6011 env build stamp예전 SHA. 이후 변경은 Python 뿐이라 COMPRESS_SPEC_SKIP_CHECK=1 로 시험
6.5.11.7예제 기본값 ≠ 제품 설정 (router 꺼짐, τ 0.95)결정 대기
6.5.11.8저장소 구조 (vllm/ 이중 폴더)정리 대상
6.5.11.9GQA 비율 수정 (커밋 b6ff4df77e)미병합
6.5.11.10docs 미반영 결과 (L40S envelope, AIME b16 1.59×)공개 여부 결정 대기
6.99.1
TandemSpec 문서 사이트 — English ↗ · 한국어 ↗
6.99.2
  • 무엇 실제 문서 사이트. 6.1 의 36쪽 구성을 English·한국어로 모두 작성했다(2026-09-30)
  • 주소 docs.jhbae.stream ↗ ↗ · 한국어판 ↗ ↗ (로그인 없음, 오른쪽 위에서 English/한국어 전환)
  • 상태 검토용 초안. 모르는 사실은 페이지마다 "Open question" 으로 남겼다
  • 소스 /home/shared/JH_MARVEL/tandemspec_docs (Docusaurus), 작성 지침 .handoff/docs_site/WRITING_BRIEF.md
6.99.3
파트페이지ID
6.99.3.1Overview한눈에 보기 · 요청 lifecycle · Recompression 과 delta transfer · Correctness 모델 · 용어O1–O5
6.99.3.2Reference hardware 에서 실행준비물 · 빌드 · 첫 verify 요청 · baseline 저장 · 문제 해결R1–R5
6.99.3.3Hardware contract엔진 배치 · component map · contract 형식 · KV memory model · 통신과 동기화H1–H5
6.99.3.4Porting 가이드runtime · operator · draft attention · verify attention · KV layout · recompression · sampling 통계 · graph/batchP1–P8
6.99.3.5검증과 성능conformance · 수치 · lifecycle · 성능 측정 · 결과 해석 · 인수 보고서V1–V6
6.99.3.6ReferenceCLI · 설정 · 환경변수 · verify API · tensor layout · 출력 · 호환성F1–F7

TCO 분석

7.0.1
  • 문제 Marvell 미팅에서 TandemSpec의 TCO 절감 효과와 차세대 Structera 요구사항(matrix unit 등)을 보여 달라는 요청이 나왔다. 제안서에 없는 항목이라 방법론부터 정해야 한다.
  • 현상 현재 결과는 속도 지표(TPOT, tokens/s)뿐이다. 비용 입력값, 다중 GPU vLLM 기준점, 긴 문맥 batch 처리량이 없다.
  • 원인 TCO는 시스템 1시간 비용과 그 1시간에 만든 토큰 수를 함께 알아야 계산된다. 지금까지 측정은 두 번째 항목 일부만 다뤘다.
  • 결과 지표는 SemiAnalysis(InferenceX) 방식의 tokens per dollar로 정했다. 실측 처리량(A)과 소유 기준 시간당 비용(B)만으로 구성 A·B를 비교한다. Structera simulator는 이 절의 범위 밖이다. 논문에는 Appendix로 넣는다.
7.0.2
tokens per dollar = A[시스템 처리량(tokens/s)] × 3600 ÷ B[시간당 비용($/h)]
7.0.3

[KV cache를 GPU에 다 담을 필요가 없다]

7.0.4

아래 두 측면에서 TCO를 분석한다.

7.0.5
  1. KV cache 부담이 작아 vanilla vLLM보다 큰 batch를 운용할 수 있다.
  2. GPU 1장에 들어가지 않는 long context를 TandemSpec은 같은 GPU로 운용할 수 있다.
7.0.6
구성하드웨어메모리 배치처리량 출처
7.0.6.1A. vLLM 다중 GPUKV 용량만큼 GPU를 늘림(TP 2·4·8)전체 KV를 HBM에실측
7.0.6.2B. TandemSpec + XeonGPU 1 + Xeon(AMX) + DDR5압축 KV는 HBM, 전체 KV는 DDR5실측
7.2.1

TCO는 장비를 사서 수명 동안 운영하는 비용 전체다. SemiAnalysis는 아래 항목을 더해 칩 1개 1시간당 비용($/chip-hour)으로 정규화한다.

7.2.2
구분항목설명
7.2.2.1CapEx서버·네트워크GPU, CPU, DRAM, NIC, 스위치. 네트워크는 서버 단위로 배분한다
7.2.2.2CapEx감가상각·이자서버 가격을 수명(보통 4~6년)으로 나눈다. SemiAnalysis 예시는 연 13% 부채
7.2.2.3OpEx전력평균 전력 × PUE × 전기 요금. PUE는 일반 colocation 1.4 이상, 최신 GPU 시설 약 1.25
7.2.2.4OpEx상면(colocation)·유지보수kW당 월 임대료, 부품·인력
7.2.2.5보정가동률가동률이 낮으면 시간당 비용이 오른다
7.2.3
시간당 비용($/h)   = (월 CapEx + 월 전력 + 월 상면 + 월 유지보수) ÷ 730 h ÷ 가동률
tokens per dollar = 시스템 처리량(tokens/s) × 3600 ÷ 시간당 비용($/h)
$ per 1M tokens   = 1,000,000 ÷ tokens per dollar
7.2.4
  • 예시: HGX H100 서버(GPU 8개)는 월 CapEx $7,025 + 운영비 $1,871 → 약 $1.52/GPU-hour. CapEx가 약 79%다.
  • 2026년 InferenceX의 H100 소유 비용은 hyperscaler 약 $1.17/hr, neocloud 약 $1.55/hr이다. 소유 비용과 임대가는 서로 다른 기준이라 섞지 않는다.
  • 처리량과 비용은 시스템 전체 기준으로 센다. GPU 1개 기준이면 CPU·DRAM·CXL 비용이 빠진다.
  • tokens/$는 batch에 따라 바뀐다. 이 절은 같은 batch(긴 문맥 1, 짧은 문맥 8·12·16)에서 시스템끼리 비교한다. InferenceX처럼 사용자당 tokens/s(interactivity)를 맞춘 비교는 하지 않았다.
7.6.1
용어뜻값의 근거
7.6.1.1CapEx서버를 살 때 한 번 내는 구매비(GPU·CPU·DDR5·서버 본체). 5년 할부로 나눠 매달 낸다고 본다부품별 판매가(표의 링크, 2026-10-21 표시가. DDR5는 2026년 가격 급등 전 시세(Counterpoint 2025년 4분기 $450/개)), 5년·연 13%는 SemiAnalysis 예시
7.6.1.2월 전기료서버와 냉방이 쓰는 전기 요금. 전력 × PUE 1.3 × 730 h × 요금PUE는 SemiAnalysis 예시, $0.0977/kWh는 EIA 미국 산업용 평균(2026년 7월) ↗
7.6.1.3월 상면료데이터센터에 서버를 두는 자리·냉방·전원 설비 임대료. 전기 요금과 별도로 kW당 매달 낸다$194.95/kW·월은 CBRE 북미 평균 임대료(2025) ↗
7.6.1.4유지보수·가동률7.2 식의 월 유지보수는 0, 가동률은 100%로 둔다모든 시스템에 같은 값이라 비교에 영향이 없다(가정)
7.6.1.5시스템별 BCPU로 verify·attention을 돌리는 TandemSpec·NEO는 TandemSpec 열, GPU만 쓰는 vLLM·SparseSpec·HeadInfer는 vLLM 열(TP=1, L40S는 TP=2)7.7의 B 열이 이 대응을 따른다
7.6.2

L40S 서버

7.6.3
단계식TandemSpec (GPU 1장)vLLM TP=1 (GPU 1장)vLLM TP=2 (GPU 2장)vLLM TP=4 (GPU 4장)
7.6.3.1서버 구성서버 1대에 GPU만 TP 수만큼 꽂는다L40S 1장 + Xeon Gold 6530 1소켓 + DDR5 256 GBL40S 1장 + Xeon Gold 6530 1소켓 + DDR5 256 GBL40S 2장 + Xeon Gold 6530 1소켓 + DDR5 256 GBL40S 4장 + Xeon Gold 6530 1소켓 + DDR5 256 GB
7.6.3.2① CapEx항목별 구매비 합GPU: $13,879 ↗ × 1 = $13,879
CPU: $2,128 ↗
DDR5: $1,800
(64 GB × 4개, $450/개 ↗)
서버 본체: $9,527 ↗
합계: $27,334		GPU: $13,879 ↗ × 1 = $13,879
CPU: $2,128 ↗
DDR5: $1,800
(64 GB × 4개, $450/개 ↗)
서버 본체: $9,527 ↗
합계: $27,334		GPU: $13,879 ↗ × 2 = $27,758
CPU: $2,128 ↗
DDR5: $1,800
(64 GB × 4개, $450/개 ↗)
서버 본체: $9,527 ↗
합계: $41,213		GPU: $13,879 ↗ × 4 = $55,516
CPU: $2,128 ↗
DDR5: $1,800
(64 GB × 4개, $450/개 ↗)
서버 본체: $9,527 ↗
합계: $68,971
7.6.3.3② 월 CapEx① × 0.022753$621.90$621.90$937.70$1,569.30
7.6.3.4③ 평균 전력항목별 전력 합GPU: 350 W × 1 = 350 W
CPU: 270 W
DDR5: 40 W
(10 W × 4개)
서버 본체: 100 W
합계: 760 W		GPU: 350 W × 1 = 350 W
CPU: 81 W
DDR5: 40 W
(10 W × 4개)
서버 본체: 100 W
합계: 571 W		GPU: 350 W × 2 = 700 W
CPU: 81 W
DDR5: 40 W
(10 W × 4개)
서버 본체: 100 W
합계: 921 W		GPU: 350 W × 4 = 1,400 W
CPU: 81 W
DDR5: 40 W
(10 W × 4개)
서버 본체: 100 W
합계: 1,621 W
7.6.3.5④ 월 전기료③ × 1.3 × 730 h × $0.0977/kWh$70.50$52.90$85.40$150.30
7.6.3.6⑤ 월 상면료③ × $194.95/kW·월$148.20$111.30$179.50$316.00
7.6.3.7⑥ B (시간당 비용)(② + ④ + ⑤) ÷ 730 h$1.151/h$1.077/h$1.647/h$2.789/h
7.6.4

RTX PRO 6000 서버

7.6.5
단계식TandemSpec (GPU 1장)vLLM TP=1 (GPU 1장)vLLM TP=2 (GPU 2장)vLLM TP=4 (GPU 4장)
7.6.5.1서버 구성서버 1대에 GPU만 TP 수만큼 꽂는다RTX PRO 6000 1장 + Xeon 6776P 1소켓 + DDR5 512 GBRTX PRO 6000 1장 + Xeon 6776P 1소켓 + DDR5 512 GBRTX PRO 6000 2장 + Xeon 6776P 1소켓 + DDR5 512 GBRTX PRO 6000 4장 + Xeon 6776P 1소켓 + DDR5 512 GB
7.6.5.2① CapEx항목별 구매비 합GPU: $17,850 ↗ × 1 = $17,850
CPU: $7,764 ↗
DDR5: $3,600
(64 GB × 8개, $450/개 ↗)
서버 본체: $9,527 ↗
합계: $38,741		GPU: $17,850 ↗ × 1 = $17,850
CPU: $7,764 ↗
DDR5: $3,600
(64 GB × 8개, $450/개 ↗)
서버 본체: $9,527 ↗
합계: $38,741		GPU: $17,850 ↗ × 2 = $35,700
CPU: $7,764 ↗
DDR5: $3,600
(64 GB × 8개, $450/개 ↗)
서버 본체: $9,527 ↗
합계: $56,591		GPU: $17,850 ↗ × 4 = $71,400
CPU: $7,764 ↗
DDR5: $3,600
(64 GB × 8개, $450/개 ↗)
서버 본체: $9,527 ↗
합계: $92,291
7.6.5.3② 월 CapEx① × 0.022753$881.50$881.50$1,287.60$2,099.90
7.6.5.4③ 평균 전력항목별 전력 합GPU: 600 W × 1 = 600 W
CPU: 350 W
DDR5: 80 W
(10 W × 8개)
서버 본체: 100 W
합계: 1,130 W		GPU: 600 W × 1 = 600 W
CPU: 105 W
DDR5: 80 W
(10 W × 8개)
서버 본체: 100 W
합계: 885 W		GPU: 600 W × 2 = 1,200 W
CPU: 105 W
DDR5: 80 W
(10 W × 8개)
서버 본체: 100 W
합계: 1,485 W		GPU: 600 W × 4 = 2,400 W
CPU: 105 W
DDR5: 80 W
(10 W × 8개)
서버 본체: 100 W
합계: 2,685 W
7.6.5.5④ 월 전기료③ × 1.3 × 730 h × $0.0977/kWh$104.80$82.10$137.70$248.90
7.6.5.6⑤ 월 상면료③ × $194.95/kW·월$220.30$172.50$289.50$523.40
7.6.5.7⑥ B (시간당 비용)(② + ④ + ⑤) ÷ 730 h$1.653/h$1.556/h$2.349/h$3.935/h
7.6.6

평균 전력과 계수

7.6.7
항목값근거
7.6.7.1GPU 전력TDP. L40S 350 W, RTX PRO 6000 600 W사양
7.6.7.2CPU 전력 (TandemSpec)TDP. Xeon Gold 6530 270 W, Xeon 6776P 350 WCPU로 verify를 돌리므로 최대 전력으로 잡는다(보수적)
7.6.7.3CPU 전력 (vLLM)TDP의 30%. 81 W, 105 W같은 5세대 Xeon(Xeon Platinum 8558U, TDP 300 W)의 idle package 전력 실측 67 W = TDP의 22% (ServeTheHome ↗). vLLM은 scheduler·tokenizer용 core 몇 개를 계속 돌리므로 idle보다 약간 높은 30%로 잡았다. n82 RAPL은 권한이 없어 읽지 못했다
7.6.7.4DDR5 전력64 GB DIMM 1개당 10 W × DIMM 수 (L40S 4개, RTX PRO 6000 8개)64 GB급 RDIMM의 전원 칩(PMIC5010) 평균 전력 상한이 15.3 W다 (Micron DDR5 RDIMM 사양 ↗). 제조사가 모듈 실사용 전력을 공개하지 않아 상한의 약 2/3로 잡았다(가정). 4~8개라 B에 주는 영향은 $0.01/h 수준이다
7.6.7.5서버 본체 전력100 W (팬·보드·NIC·부팅 SSD)NIC 11 W(ConnectX-6 Dx typical, NVIDIA ↗) + NVMe SSD 13.5 W(PM9A3 write 최대, Samsung ↗) = 약 25 W는 사양 근거. 나머지 약 75 W(팬·보드·BMC)는 출처를 찾지 못한 가정이다
7.6.7.60.0227535년(60개월) 감가상각 + 연 13% 이자의 월 상환 계수이자율: SemiAnalysis 예시 ↗
7.6.7.71.3 · $0.0977/kWh · $194.95/kW·월PUE · 전기 요금 · 상면료PUE: SemiAnalysis 예시 ↗, 전기 요금: EIA ↗, 상면료: CBRE ↗
7.7.1

GPU별 최대 context (vLLM, batch 1)

7.7.2
L40S (48 GB GDDR6, 864 GB/s, 350 W)TP=1TP=2TP=4TP=8
7.7.2.1Qwen3-4B-Thinking225K (실측)515K (실측)1,076K2,209K
7.7.3
RTX PRO 6000 (96 GB GDDR7, 1,792 GB/s, 600 W)TP=1TP=2TP=4TP=8
7.7.3.1Qwen3-30B-A3B292K (실측)1,206K3,034K3,345K
7.7.3.2Granite-4.2-30B112K (실측)446K1,116K2,456K
7.7.4
  • 산출: (GPU 메모리 × 0.9 − 가중치 ÷ TP) × TP ÷ 토큰당 KV. 토큰당 KV: Qwen3-4B 144 KiB, Qwen3-30B-A3B 96 KiB, Granite 256 KiB (layer × KV head × 128 × K·V × bf16).
  • Qwen3-30B-A3B TP=8이 TP=4와 비슷한 이유: KV head가 4개라 TP=8에서는 같은 KV head를 GPU 2장이 중복 저장한다. 가중치 몫만 줄어든다.
7.7.5

계산식

7.7.6
E2E (s)          = TTFT + N_ref × TPOT        N_ref = TandemSpec이 그 요청에서 생성한 출력 토큰 수
A (tok/s)        = N_ref ÷ E2E                batch 1 처리량
B ($/h)          = 7.6 표의 ⑥
$/1M tokens      = B ÷ (A × 3600) × 10^6
7.7.7

L40S · Qwen3-4B-Thinking · Ultra(323K~451K) · batch 1

7.7.8
prompt 토큰시스템N_refE2E (s)A (tok/s)B ($/h)$/1M tokens
7.7.8.1322,627TandemSpec2,391479.94.981.151$64.2
7.7.8.2322,627vLLM TP=22,391181.113.201.647$34.7
7.7.8.3371,465TandemSpec2,194525.44.181.151$76.5
7.7.8.4371,465vLLM TP=22,194210.710.411.647$43.9
7.7.8.5400,301 (†)TandemSpec83,23011,325.37.351.151$43.5
7.7.8.6400,301 (†)vLLM TP=283,2304,418.318.841.647$24.3
7.7.8.7450,826TandemSpec694472.11.471.151$217.5
7.7.8.8450,826vLLM TP=2694199.33.481.647$131.5
7.7.9

(†) 두 시스템 모두 생성 상한까지 반복 생성(prompt 자체가 반복 코드). 출력 길이가 길어 $/1M이 낮게 나온다.

7.7.10
$/1M tokens. L40S · Qwen3-4B-Thinking YaRN · LongBench-v2 Ultra 4개 요청(323K~451K) · batch 1
7.7.10.c $/1M tokens. L40S · Qwen3-4B-Thinking YaRN · LongBench-v2 Ultra 4개 요청(323K~451K) · batch 1
7.7.11

RTX PRO 6000 · 긴 문맥 (LongBench-v2 Long·Ultra 구간) · batch 1

7.7.12
모델 · prompt 길이시스템N_refE2E (s)A (tok/s)B ($/h)$/1M tokens
7.7.12.1Qwen3-30B-A3B Long 170K ~ 194KTandemSpec3,950150.126.321.653$17.4
7.7.12.2Qwen3-30B-A3B Long 170K ~ 194KvLLM3,950149.426.441.556$16.3
7.7.12.3Qwen3-30B-A3B Long 170K ~ 194KSparseSpec3,950167.223.621.556$18.3
7.7.12.4Qwen3-30B-A3B Long 170K ~ 194KNEO3,950935.84.221.653$108.8
7.7.12.5Qwen3-30B-A3B Long 170K ~ 194KHeadInfer3,9503,229.81.221.556$354.3
7.7.12.6Qwen3-30B-A3B Ultra 425K ~ 442KTandemSpec3,763942.63.991.653$115.1
7.7.12.7Qwen3-30B-A3B Ultra 425K ~ 442KvLLM3,763OOM———
7.7.12.8Qwen3-30B-A3B Ultra 425K ~ 442KSparseSpec3,763OOM———
7.7.12.9Qwen3-30B-A3B Ultra 425K ~ 442KNEO3,7632,910.31.291.653$355.9
7.7.12.10Qwen3-30B-A3B Ultra 425K ~ 442KHeadInfer3,76310,395.00.361.556$1,200.6
7.7.12.11Granite-4.2-30B Long 46K ~ 55KTandemSpec2,914184.615.791.653$29.1
7.7.12.12Granite-4.2-30B Long 46K ~ 55KvLLM2,914184.615.791.556$27.4
7.7.12.13Granite-4.2-30B Long 46K ~ 55KSparseSpec2,914199.814.591.556$29.6
7.7.12.14Granite-4.2-30B Long 46K ~ 55KNEO2,914501.75.811.653$79.0
7.7.12.15Granite-4.2-30B Long 46K ~ 55KHeadInfer2,9141,692.21.721.556$251.3
7.7.12.16Granite-4.2-30B Ultra 488K ~ 504KTandemSpec8,1902,696.73.041.653$151.0
7.7.12.17Granite-4.2-30B Ultra 488K ~ 504KvLLM8,190OOM———
7.7.12.18Granite-4.2-30B Ultra 488K ~ 504KSparseSpec8,190OOM———
7.7.12.19Granite-4.2-30B Ultra 488K ~ 504KNEO8,1905,193.41.581.653$290.6
7.7.12.20Granite-4.2-30B Ultra 488K ~ 504KHeadInfer8,19024,017.60.341.556$1,271.2
7.7.13
$/1M tokens (log scale). RTX PRO 6000 · LongBench-v2 Long·Ultra 구간 · batch 1. (a) Qwen3-30B-A3B, (b) Granite
7.7.13.c $/1M tokens (log scale). RTX PRO 6000 · LongBench-v2 Long·Ultra 구간 · batch 1. (a) Qwen3-30B-A3B, (b) Granite
7.7.14

RTX PRO 6000 · 짧은 문맥(Short) · concurrency 8, 16 (AIME25, Qwen3-30B-A3B-Thinking-2507)

7.7.15
concurrency시스템A (tok/s)B ($/h)$/1M tokens
7.7.15.18TandemSpec306.91.653$1.50
7.7.15.28vLLM309.61.556$1.40
7.7.15.316TandemSpec415.31.653$1.11
7.7.15.416vLLM409.31.556$1.06
7.7.16
  • A = 출력 토큰 합 ÷ 전체 wall(요청 48·96개, 논문 §4.2.2와 같은 concurrency 8·16).
7.7.17
$/1M tokens. RTX PRO 6000 · AIME25 · Qwen3-30B-A3B-Thinking-2507 · short context · concurrency 8, 16
7.7.17.c $/1M tokens. RTX PRO 6000 · AIME25 · Qwen3-30B-A3B-Thinking-2507 · short context · concurrency 8, 16
7.8.1
항목내용
7.8.1.1파일[TandemSpec_TCO_Appendix.pdf 내려받기](TandemSpec_TCO_Appendix.pdf?v=eb683d12) (4쪽, 2단, 2026-10-22 빌드)
7.8.1.2형식논문 appendix와 같은 acmart 2단, 약어 표는 식 앞, 표 캡션은 표 아래, References는 ACM 형식, 영문
7.8.1.3원본ai-cluster figure/tex/appendix/tco/ (appendix_tco.tex, preview.tex, 표는 make_tables.py가 data/*.csv에서 생성)