qwen-3.8-flash-next-c4

gistfile1.txt

# 2026-09-27 Qwen 서빙 레시피 업데이트·벤치마크 종합 보고서

- 작성일: 2026-09-27, Asia/Seoul(KST)
- 범위: 기존 레시피 기준 측정 → vLLM 0.30 FP8 KV → BF16 KV → C4 고정 MTP3/MTP2 A/B → 설정·vocab·upstream 조사
- 최종 결정: **현 설정 유지 — vLLM 0.30.0 / NVFP4 가중치 / BF16 KV / C4 / MTP2**
- 이 보고서 작성 과정에서는 서버 설정을 변경하거나 재시작하지 않았다.

## 1. 요약

1. vLLM 0.30은 정상 적용됐다. 실행 중 핵심 소스 5개가 공식 v0.30.0 태그와 바이트 단위로 일치했고, v0.30용 MTP 패치와 47k vocab이 양 노드에서 적용된 것을 확인했다.
2. 신규 FP8 KV는 전체 시험 구성에서 기존 대비 출력 처리량 -8.7%, GPU 에너지 효율 -8.6%였다.
3. 신규 BF16 KV는 신규 FP8 대비 출력 처리량 +11.6%, GPU 에너지 효율 +12.2%였다. 기존 FP8 대비로는 각각 +1.9%, +2.6%였다.
4. 단, **BF16만 입력 캐시가 77.22% 적중**했다. BF16의 개선은 캐시 효과를 포함하며, 순수 KV 연산 속도 차이가 아니다.
5. 실제 C4에서 서버 상한 C8→C4 변경 후 처리량은 거의 유지됐다. C4 고정 MTP A/B에서는 MTP2가 영어 +3.1%, 코딩 추론 -2.2%로 큰 차이는 없었다.
6. 현재 KV 풀은 1,520,120토큰이다. 262,144토큰 문맥 5개는 계산상 들어가지만, C5 장문 동시 안정성은 미검증이며 현재 동시 실행 상한은 4다.
7. 다국어 vocab 튜닝은 보류했다. 실제 주 사용처인 영어·코딩 하네스에 집중하기로 했다.

## 2. 최종 운영 상태

| 항목 | 최종 값 |
|---|---|
| 모델 | `nvidia/Qwen3.8-Flash-Next-NVFP4` |
| 가중치 snapshot | `fc694b54fb0174e0913e6adf86691ef85a4ead47` |
| API / served model | `http://127.0.0.1:8888` / `qwen3.8-flash-next` |
| 서빙 노드 | head `gx10-5428` + worker `gx10-3eda` |
| Docker 이미지 | `vllm/vllm-openai:v0.30.0` |
| 이미지 ID | `sha256:91d9b077589e7ebb9399ea8db07787bd40cc04ba96a767f021ffdf3e321ea9a0` |
| 레시피 커밋 | `d23790b440d9a0977951ebbe3883ba44b89814da` |
| 실행 worktree | `/home/gx10-01/Qwen3.8-Flash-Next-Dual-DGX-Sparks-upstream-20260927` |
| 병렬 구성 | TP2 + EP |
| KV / SSM dtype | BF16 KV (`auto`) / BF16 SSM |
| GPU memory utilization | `0.80` |
| 서버 동시 실행 상한 | `max-num-seqs=4` |
| 최대 문맥 | `max-model-len=262144`, 입력+출력 합계 |
| Prefill chunk 상한 | `max-num-batched-tokens=8192` |
| MTP | `num_speculative_tokens=2` |
| Draft vocab | `files/draft_vocab_en_code_47k.txt`, 47,149개 ID |
| Local argmax | `use_local_argmax_reduction=true` |
| MTP 캐시 블록 유지 | `disable_eagle_block_drop=true` |
| MTP 인덱스 공유 | `index_share_for_mtp_iteration=true` |
| CUDA graph | `FULL_DECODE_ONLY`, breakable graph OFF |
| FlashInfer autotune | 각 컨테이너 내부 `/tmp/fi_autotune` |
| YaRN | OFF |

MTP2는 확정적인 성능 승자로 자동 선정된 것이 아니다. A/B 마지막 설정을 사용자가 유지하기로 결정했다. 실서비스의 thinking 여부는 요청의 chat template 설정에 따르며, 오늘 벤치마크는 모두 Thinking ON이었다.

## 3. 작업 순서와 측정 규모

| 단계 | 측정 시각(KST) | 서버 설정 | 본 측정 배치 / 요청 / 출력 토큰 |
|---|---|---|---:|
| 기존 기준: 영어·한국어·코딩 | 10:01–10:54 | 기존 FP8, GMU .835, 상한 C8, MTP3 | 36 / 135 / 276,480 |
| 기존 기준: 중국어 추가 | 10:57–11:21 | 위와 동일한 런타임 | 12 / 45 / 92,160 |
| v0.30 FP8 | 12:12–13:35 | FP8, GMU .80, 상한 C8, MTP3 | 48 / 180 / 368,640 |
| v0.30 BF16 | 13:56–15:11 | BF16, GMU .80, 상한 C8, MTP3 | 48 / 180 / 368,640 |
| C4 고정 A: MTP3 | 15:43–15:51 | BF16, GMU .80, 상한 C4, MTP3 | 6 / 24 / 49,152 |
| C4 고정 B: MTP2 | 16:02–16:09 | BF16, GMU .80, 상한 C4, MTP2 | 6 / 24 / 49,152 |
| **합계** | | | **156 / 588 / 1,204,224** |

위 규모는 워밍업·기능 검사 제외, 시각은 해당 실행의 워밍업을 포함한다. 기존→업데이트 과정에서 이전 worktree와 결과를 보존하고 별도 worktree를 사용했다. 호스트 재부팅 대신 두 서빙 컨테이너를 교체했다.

C4 A/B 조율기는 첫 MTP3 로딩 중 준비 대기 제한을 수정하기 위해 중단·재개했다. 모델 컨테이너는 계속 로딩됐으며 재시작되지 않았다. 당시 본 측정 요청은 시작하지 않았으므로 완료된 결과를 폐기하거나 재측정한 것은 아니다.

## 4. 측정 방법과 공통 제한

- 기존 `bench/decodebench.py` 과제와 40줄 영문 문맥을 동결했다. 한국어·중국어 산문은 동일 산문 과제의 번역이다.
- 최초 세 구성: 영어·한국어·중국어·코딩 × 실제 동시성 C1/C2/C4/C8 × 3회.
- 마지막 A/B: 영어·코딩 × 실제 동시성 C4 × 3회. **서버 상한도 C4로 변경한 뒤 측정했다.**
- 각 조건에서 256토큰 워밍업, 본 측정 요청당 2,048토큰. Thinking ON, temperature 0, 고정 seed, `min_tokens=max_tokens=2048`, `ignore_eos=true`.
- 최초 세 구성의 본 요청 180개가 동일했고, 마지막 두 arm의 24개 본 요청도 서로 동일함을 검증했다. 원본 측정기와 fixture 해시를 보존했다.
- 출력 tok/s = 배치의 API completion token 합계 ÷ 최초 요청 시작부터 마지막 응답 종료까지. Prefill·대기·추론·본문 생성 시간을 포함한다.
- 조건별 합산은 토큰 합계/시간 합계로 계산한다. 회차별 tok/s의 단순 산술평균이 아니다.
- TTFT는 첫 비어 있지 않은 추론 또는 본문 토큰까지의 지연이다. 최종 답변 본문이 보이기까지의 시간과 다르다.
- 입력 토큰에는 캐시 적중이 포함된다. 캐시 토큰을 입력 총량에 다시 더하지 않았다.
- 에너지는 양 노드 GPU의 약 1초 간격 전력을 각 배치 구간에 적분했다. **시스템 전체 전력 아님**, idle 차감 없음. tok/J는 출력 토큰 합계/적분 에너지 합계다.
- `api-token-stats` 스킬의 입력/출력 분리, 캐시 중복 합산 방지, 구간·장비 범위 일치 기준을 적용했다.
- 서버 재시작 사이의 누적 counter를 직접 빼지 않았다. 각 배치의 before/after snapshot을 이용하고 API usage와 대조했다.
- 같은 프롬프트를 반복하고 캐시를 flush하지 않았다. Cold-prefill 또는 cache-neutral 시험이 아니다.
- **코딩 과제는 모든 구성에서 본 측정 출력 전체를 추론에 사용했다. 실제 코드 본문 생성 속도·정확도를 평가하지 못했다.**
- 강제 길이 출력에서 반복 코드펜스가 발생했다. 제거하지 않고 원시 결과에 포함했다. 이는 품질 평가가 아니다.
- 클럭·온도를 강제로 고정하지 않았다. 측정 순서는 고정됐고, MTP A/B도 arm당 한 번 부팅한 순차 시험이다. 작은 차이는 통계적 우위로 확정할 수 없다.

## 5. 최초 세 구성: 출력 처리량 전체

단위: 동시 요청 합산 output tok/s. 모두 MTP3이며 서버 상한은 C8이다.

| 영역 | 실제 동시성 | 기존 FP8 | v0.30 FP8 | v0.30 BF16 |
|---|---:|---:|---:|---:|
| 영어 | C1 | 40.04 | 42.33 | 43.19 |
| 영어 | C2 | 73.72 | 69.67 | 70.31 |
| 영어 | C4 | 108.64 | 110.79 | 114.24 |
| 영어 | C8 | 177.51 | 154.77 | 175.12 |
| 한국어 | C1 | 24.63 | 21.24 | 25.56 |
| 한국어 | C2 | 39.90 | 38.30 | 39.00 |
| 한국어 | C4 | 66.59 | 61.48 | 64.77 |
| 한국어 | C8 | 100.55 | 85.16 | 98.75 |
| 중국어 | C1 | 26.84 | 21.34 | 29.79 |
| 중국어 | C2 | 41.89 | 44.74 | 46.17 |
| 중국어 | C4 | 69.31 | 61.23 | 66.66 |
| 중국어 | C8 | 109.67 | 94.89 | 107.37 |
| 코딩 추론 | C1 | 45.79 | 47.82 | 51.45 |
| 코딩 추론 | C2 | 77.71 | 74.60 | 86.17 |
| 코딩 추론 | C4 | 129.66 | 117.65 | 140.37 |
| 코딩 추론 | C8 | 200.21 | 183.68 | 214.27 |

### 전체 시험 구성의 가중 집계

| 지표 | 기존 FP8 | v0.30 FP8 | v0.30 BF16 |
|---|---:|---:|---:|
| 본 측정 출력 토큰 | 368,640 | 368,640 | 368,640 |
| 본 측정 입력 토큰 | 193,950 | 193,950 | 193,950 |
| 합산 출력 tok/s | 85.91 | 78.44 | 87.55 |
| 합산 입력 tok/s, 캐시 포함 | 45.20 | 41.27 | 46.06 |
| GPU 출력 tok/J | 2.569 | 2.349 | 2.636 |
| 본 측정 GPU 에너지 | 143.49 kJ | 156.92 kJ | 139.83 kJ |
| 본 배치 시간 합계 | 4,290.82초 | 4,699.58초 | 4,210.78초 |

배치 시간 합계는 워밍업·배치 사이 대기를 제외한다. 입력 tok/s도 해당 배치 구간 기준이며 순수 prefill 커널 처리량이 아니다. 서로 다른 동시성·영역을 합친 값이므로 특정 실사용 트래픽의 예상 처리량으로 해석하지 않는다.

## 6. 캐시 적중과 TTFT

### BF16에서만 캐시가 적중한 이유

| 항목 | 기존 FP8 | v0.30 FP8 | v0.30 BF16 |
|---|---:|---:|---:|
| Attention 캐시 블록 | 1,664토큰 | 1,664토큰 | 832토큰 |
| 본 측정 캐시 적중 입력 | 0 | 0 | 149,760토큰 |
| 전체 입력 대비 적중률 | 0% | 0% | 77.22% |

입력 길이는 영어 1,076, 한국어 1,085, 중국어 1,076, 코딩 1,073토큰/요청이었다. FP8에서는 입력이 한 블록보다 짧아 재사용하지 못했고, BF16에서는 요청당 832토큰을 재사용했다. 메트릭과 API usage의 cached token 합계가 일치했다. 본 시험에서는 prefix hit/query 비율도 같은 집계값이었지만, 일반적으로 입력 캐시 적중률과 별도 지표다.

### 요청별 TTFT 중앙값

각 칸: 기존 FP8 → 신규 FP8 → 신규 BF16, 단위 초.

| 영역 | C1 | C2 | C4 | C8 |
|---|---|---|---|---|
| 영어 | .519 → .395 → .197 | .787 → .624 → .241 | 1.723 → 1.367 → .557 | 3.111 → 2.439 → .808 |
| 한국어 | .528 → .393 → .211 | .799 → .628 → .310 | 1.741 → 1.377 → .569 | 3.142 → 2.460 → .844 |
| 중국어 | .525 → .395 → .208 | .794 → .627 → .332 | 1.731 → 1.370 → .567 | 3.111 → 2.433 → .819 |
| 코딩 추론 | .518 → .402 → .210 | .785 → .623 → .324 | 1.723 → 1.822 → .563 | 3.101 → 2.434 → .801 |

원본 runner의 summary에는 배치 중앙값들의 중앙값도 저장돼 있다. 위 표는 응답 파일 전체의 요청별 중앙값을 사용하므로 일부 C2/C4 값이 runner summary와 다를 수 있다.

## 7. GPU 에너지 효율 전체

단위: GPU-only output tok/J. 각 칸은 기존 FP8 → 신규 FP8 → 신규 BF16.

| 영역 | C1 | C2 | C4 | C8 |
|---|---|---|---|---|
| 영어 | 1.355 → 1.413 → 1.449 | 2.316 → 2.159 → 2.232 | 3.212 → 3.247 → 3.382 | 5.088 → 4.206 → 5.023 |
| 한국어 | .789 → .696 → .832 | 1.233 → 1.198 → 1.218 | 1.955 → 1.836 → 1.907 | 2.877 → 2.416 → 2.842 |
| 중국어 | .872 → .705 → .960 | 1.293 → 1.428 → 1.442 | 2.023 → 1.859 → 1.969 | 3.130 → 2.661 → 3.108 |
| 코딩 추론 | 1.456 → 1.587 → 1.679 | 2.378 → 2.358 → 2.713 | 3.772 → 3.553 → 4.136 | 5.700 → 5.017 → 6.128 |

## 8. C4 고정 MTP3 vs MTP2

서버 `max-num-seqs=4`, 실제 C4, BF16 KV, GMU 0.80, 동일 47k vocab. 초안 길이만 변경했다. 기능 검사는 각각 C1 1건+C4 4건으로 5/5 통과했고, 별도의 본 측정은 C4만 수행했다.

| 지표 | 영어 MTP3 | 영어 MTP2 | 코딩 추론 MTP3 | 코딩 추론 MTP2 |
|---|---:|---:|---:|---:|
| 출력 tok/s | 113.54 | 117.07 | 138.98 | 135.93 |
| 3회 범위 tok/s | 111.70–116.42 | 115.56–117.87 | 132.93–150.80 | 134.11–137.14 |
| 입력 tok/s, 캐시 포함 | 59.65 | 61.51 | 72.82 | 71.22 |
| TTFT 중앙값(초) | .568 | .554 | .572 | .561 |
| GPU 출력 tok/J | 3.427 | 3.592 | 4.136 | 4.107 |
| 입력 캐시 적중률 | 77.32% | 77.32% | 77.54% | 77.54% |
| 초안 토큰 수락률 | 43.69% | 50.00% | 59.98% | 69.10% |
| 초안 1회당 평균 수락 토큰 | 1.311 | 1.000 | 1.799 | 1.382 |

- 영어 MTP2: 처리량 +3.1%, GPU 효율 +4.8%.
- 코딩 추론 MTP2: 처리량 -2.2%, GPU 효율 -0.7%.
- MTP2의 수락 비율이 높아도 생성 단계당 수락 토큰이 더 많다는 뜻은 아니다. 제안 길이가 3→2로 달라진다.
- 회차 범위가 겹친다. 코딩 MTP3의 높은 3회차도 제외하지 않았다. 작은 차이만으로 확정적인 승자를 선정하지 않았다.
- **C4 제한의 MTP2/MTP3에서 C1 본 측정은 미실시다.** 부팅 기능 검사를 C1 성능 벤치마크로 대체하지 않는다.

### 영어·코딩 C4의 하루 전체 비교

| 구성 | 서버 상한 | 영어 tok/s | 코딩 추론 tok/s |
|---|---:|---:|---:|
| 기존 FP8/MTP3 | C8 | 108.64 | 129.66 |
| 신규 FP8/MTP3 | C8 | 110.79 | 117.65 |
| 신규 BF16/MTP3 | C8 | 114.24 | 140.37 |
| 신규 BF16/MTP3 | C4 | 113.54 | 138.98 |
| 신규 BF16/MTP2, 최종 유지 | C4 | 117.07 | 135.93 |

서버 상한 C8→C4는 실제 C4 처리량을 크게 바꾸지 않았다. 부팅마다 프로파일링·튜닝이 새로 이루어졌으므로 작은 차이를 동시성 상한 변경의 단독 효과로 단정하지 않는다.

## 9. KV 용량과 C5 가능성

| 구성 | 엔진 보고 KV 토큰 용량 |
|---|---:|
| 기존 FP8, GMU .835, C8/MTP3 | 4,244,096 |
| 신규 FP8, GMU .80, C8/MTP3 | 2,612,653 |
| 신규 BF16, GMU .80, C8/MTP3 | 1,479,518 |
| 신규 BF16, GMU .80, C4/MTP3 | 1,487,297 |
| 신규 BF16, GMU .80, C4/MTP2 | **1,520,120** |

기존→신규 차이는 런타임·GMU 등 복합 변경을 포함한다. 같은 신규 C8/MTP3에서 BF16 풀은 FP8보다 43.4% 작았다. C4/MTP2는 C4/MTP3보다 32,823토큰(약 2.2%) 늘었다.

현재 풀 기준으로 세션당 최대 입력+출력 262,144토큰을 모두 사용하고, 세션 간 prefix 공유가 없다고 가정하면:

| 동시 사용 | 필요 토큰 | 계산상 잔여 |
|---|---:|---:|
| C4 | 1,048,576 | 471,544토큰 / 31.0% |
| C5 | 1,310,720 | 209,400토큰 / 13.8% |
| C6 | 1,572,864 | 52,744토큰 부족 |

- **C5는 계산상 가능하지만 검증되지 않았다.** MTP3에서도 용량상 5개가 들어갔으므로 MTP2가 처음 C5를 가능하게 만든 것은 아니다.
- 현재 동시 실행 제한은 4다. 다섯 번째 동시 요청은 스케줄러에서 대기할 수 있다. 세션을 다섯 개 개설하는 것과 다섯 요청을 동시에 실행하는 것은 다르다.
- `max-num-seqs=5`로 바꾸면 그래프·메모리 프로파일이 바뀌어 실제 KV 풀이 달라질 수 있다.
- KV 풀 여유는 시스템 RAM 여유가 아니다. 토큰 용량 계산만으로 호스트 OOM·드라이버 할당 실패를 배제할 수 없다.
- 측정한 것은 짧은 문맥이며, C4 또는 C5에서 모두 262K를 사용한 부하 시험은 아니다.
- 사용자 결정: **C4/MTP2 현 상태 유지. C5 전환하지 않음.**

## 10. 레시피·vLLM·MTP·vocab 조사

### 최근 6개 커밋

조사 시 원격 HEAD와 로컬 실행 worktree 모두 `d23790b`였다. 커밋 이력 순서이며 작성일 정렬과 다를 수 있다.

| 커밋 | 주요 변경 | 적용 판단 |
|---|---|---|
| `d23790b` | v0.30 문서: BF16 기본, breakable graph OFF, FP8 opt-in | 일치 |
| `1940295` | v0.30 기본 KV를 BF16으로 변경 | 적용 |
| `34e7400` | breakable CUDA graph 비활성화 | 양 노드 적용 |
| `8d59a56` | v0.30 FP8 KV backport | FP8 시험에서 적용, 현재 BF16에는 불필요 |
| `cb0edd8` | v0.30 실행 경로·draft vocab 이식 | 적용 |
| `50afcd2` | GMU .835→.80 | 적용 |

### 실행 코드 확인

- 설치 버전 `0.30.0` 확인.
- `vllm/models/qwen4_exp/nvidia/`의 `model.py`, `qsa.py`, `indexer_qsa.py`, `ple_layer.py`, `ops/ple.py`가 공식 v0.30.0 소스와 동일했다.
- PLE/QSA의 옛 패치가 새 구현을 덮어쓴 정황 없음. MTP만 레시피가 의도한 축소 vocab 패치를 사용한다.
- `torch.compile mode=0`은 잘못 빠진 최적화로 판단하지 않았다. upstream NVIDIA 경로에서 torch.compile을 제거한 변경과 부합한다.
- CUDA graph는 `FULL_DECODE_ONLY`로 사용하며 캡처 로그를 확인했다. Breakable graph OFF는 Dual-Spark 레시피의 명시적 권고다.
- QSA 상태 backend는 fused multi-step draft decode를 지원하지 않아 초안 사이 metadata 재구성 경로를 사용한다. MTP가 꺼진 것은 아니며 단순 누락 옵션으로 확인되지 않았다.
- QSA **인덱서 캐시 FP8**은 메인 KV dtype과 별도 선택 기능이다. 현재는 BF16이다. upstream GB300 실험을 GB10의 보장된 가속으로 일반화하지 않았고 옵션을 변경하지 않았다.
- 모델·vocab·패치 적용은 확인했지만, 각 커널의 실제 시간 비중을 측정하는 GPU 프로파일링은 하지 않았다.

### Vocab 및 MTP 검증

- 기본 vocab 47,149개 ID, 중복 없음, 전체 vocab 248,320 범위 안에 있음.
- 저장소 HEAD 파일과 동일. 양 컨테이너의 vocab 및 MTP 패치 해시 동일.
- vocab SHA-256: `20e36b6e8eae2598019298959a578ef8adc2948bbed7189e43a8da9b9d84a0b1`.
- TP shard별 ID: head 45,734 / worker 1,415. 기본 vocab의 알려진 분포이며 파일 오류가 아님.
- `MTP draft vocab: 47149 of 248320` 및 local argmax 사용 로그 확인. `Unknown ... VLLM_MTP_DRAFT_VOCAB` 경고는 패치 전용 환경변수의 기본 등록 목록 부재 때문이며 실제 소비·적용은 확인했다.
- v0.30 draft-vocab 패치 테스트 4/4 통과.
- MTP3·block-drop 비활성화·인덱스 공유·local argmax는 권고대로 적용했으며, 마지막 A/B에서 MTP 길이만 2로 변경했다.

### 다국어 조사 결과와 보류 결정

BF16/MTP3 전체 측정의 출력 텍스트를 동일 tokenizer로 재토큰화했을 때:

| 영역 | 추론 텍스트 vocab 포함률 | 최종 본문 vocab 포함률 | 실제 초안 토큰 수락률 |
|---|---:|---:|---:|
| 영어 | 96.47% | 89.37% | 41.7% |
| 한국어 | 80.69% | 15.26% | 7.5% |
| 중국어 | 35.74% | 33.71% | 13.4% |
| 코딩 추론 | 98.35% | 본문 없음 | 59.8% |

재토큰화 포함률은 실제 생성 token ID의 직접 기록이나 MTP 수락률과 동일한 지표가 아니다. 다만 영어·코드용 vocab이 다국어에 불리하다는 근거다. 기본 vocab은 잘못 적용된 것이 아니며, 실제 하네스가 영어·코딩 위주라는 사용자 판단에 따라 다국어 vocab 재구성은 보류했다.

공식 문서의 높은 코딩 tok/s는 거의 동일한 `clamp_NN` 함수 50개를 만드는 고수락률 합성 과제다. 우리의 Thinking ON 추론 과제와 절대 속도를 직접 비교해 패치 누락으로 판단하지 않는다.

## 11. 안정성 및 출력 품질 한계

- 본 측정 156배치/588요청에서 요청 오류·KV 선점·외부 트래픽/카운터 불일치 0건. GPU 에너지 기록 모두 유효.
- 신규 FP8, BF16, C4/MTP3, C4/MTP2의 각 **벤치마크 구간**에서 새 `NV_ERR_NO_MEMORY`/OOM-kill 관련 경고 없음.
- 그러나 **부팅 중 메모리 경고는 존재**했다. 성공적인 측정과 구분해야 한다.

| 부팅 구성 | head NV_ERR_NO_MEMORY | worker NV_ERR_NO_MEMORY |
|---|---:|---:|
| v0.30 FP8, C8/MTP3 | 1 | 1 |
| v0.30 BF16, C8/MTP3 | 1 | 2 |
| v0.30 BF16, C4/MTP3 | 3 | 1 |
| v0.30 BF16, C4/MTP2 | 1 | 1 |

일부 로딩 시 journald memory-pressure 메시지도 기록됐다. 부팅 경고를 무해하다고 단정하거나, C4 고정으로 완전히 해결됐다고 주장하지 않는다. 최종 기능 검사와 벤치마크는 통과했다.

반복 코드펜스 꼬리 감지 요청 수(본문 마지막 500자 내 5회 이상 코드펜스 반복, 해당 요청 제외 없음):

| 영역 | 기존 FP8 | 신규 FP8 | 신규 BF16 |
|---|---:|---:|---:|
| 영어 | 8/45 | 3/45 | 7/45 |
| 한국어 | 6/45 | 4/45 | 4/45 |
| 중국어 | 11/45 | 10/45 | 20/45 |

마지막 C4 A/B의 영어에서는 MTP3 4/12, MTP2 1/12건이었다. 코드 과제에서는 모든 출력이 추론이어서 해당 본문 꼬리 검사가 코드 품질을 평가하지 못한다.

upstream에서 과거 nightly의 MTP 반복 붕괴 이슈도 확인했으나, 다른 빌드·조건의 보고다. 이번 `ignore_eos` 강제 길이 반복 현상을 그 버그로 확정하지 않았다.

## 12. 유지 결정 및 미실시 항목

### 확정

- 현재 BF16 KV/C4/MTP2 유지. GMU .80, 영어·코딩용 47k vocab 유지.
- 다국어 최적화 보류. 실사용 영어·코딩 하네스 중심으로 후속 검증.
- 기존 측정기·fixture·원시 응답·전력 표본·환경 스냅샷 보존.
- 벤치마크용 임시 전력 샘플러는 종료됐다. 측정용 영구 수집 서비스를 추가하지 않았다.

### 아직 하지 않은 것

- C4 제한 서버에서 MTP2 vs MTP3의 **C1 본 측정**.
- C5 설정 재부팅 및 장문 동시 부하 시험.
- C4의 4개 요청 모두 최대 문맥을 채우는 안정성 시험.
- 자연 종료를 허용한 실제 코드 생성·수정·도구 호출 하네스 평가.
- 캐시 조건을 동일하게 맞춘 FP8/BF16 순수 비교.
- 반복 재부팅·순서 교차를 포함한 MTP A/B 재현 시험.
- 전체 vocab 또는 다국어 vocab A/B, FP8 인덱서 시험, GPU 커널 프로파일링.

향후 우선순위 제안: 현 구성 유지 상태에서 실사용 하네스 정확도·코드 본문·다중 턴 지연을 먼저 검증하고, 추가 설정 변경은 별도 승인 후 수행한다.

## 13. 결과 파일과 재현 근거

### 주요 보고서

- [기존 4영역 보고서](baseline-with-chinese/REPORT.md), [집계 JSON](baseline-with-chinese/report.json)
- [신규 FP8 summary](updated/results/updated-fp8-20260927T031204Z/summary.json)
- [신규 BF16 summary](bf16/results/updated-bf16-20260927T045605Z/summary.json)
- [C4 MTP A/B 보고서](c4-mtp-ab/REPORT.md), [세부 비교 JSON](c4-mtp-ab/comparison.json)
- [업데이트 사전 검토](RECIPE_UPDATE_REVIEW.md), [v0.30 최초 배포 결과](deployment/RESULT.md)

초기 README와 배포 보고서의 “아직 미실행” 문구·C8 유지 계획은 각 작성 시점의 기록이다. 최종 상태와 오늘 완료 내역은 이 일일 보고서를 따른다.

### 원시 측정 디렉터리

- `results/baseline-20260927T010133Z/`
- `chinese/results/baseline-chinese-20260927T015727Z/`
- `updated/results/updated-fp8-20260927T031204Z/`
- `bf16/results/updated-bf16-20260927T045605Z/`
- `c4-mtp-ab/mtp3/results/c4-mtp3-20260927T064349Z/`
- `c4-mtp-ab/mtp2/results/c4-mtp2-20260927T070232Z/`

각 디렉터리에 protocol/fixtures, 요청 JSON, 응답 JSON, SSE, before/after metrics, trials, 전력 표본 및 환경 스냅샷을 보관했다. `.prom` 파일의 MTP 카운터 delta로 수락률을 재계산할 수 있다.

### 실행기 및 상태

- 원본 동결 측정기: `run_benchmark.py`
- 어댑터: `run_chinese.py`, `run_updated.py`, `run_bf16.py`, `run_c4_mtp_arm.py`
- 마지막 조율기: `coordinate_c4_mtp_ab.py`
- A/B 보고서 재생성: `python3 summarize_c4_mtp_ab.py` — 서버 재시작 없이 저장된 결과만 읽어 집계 파일을 생성한다.
- A/B 상태: [c4-mtp-ab/status.json](c4-mtp-ab/status.json), `complete`
- 배포 근거: `deployment/before-v030/`, `after-v030/`, `before-bf16/`, `after-bf16/`, `before-c4-mtp-ab/`, `c4-mtp3-ready/`, `c4-mtp3-after/`, `c4-mtp2-ready/`, `c4-mtp2-after/`
- 배포 스냅샷에는 컨테이너 환경변수 등 비공개 정보가 포함될 수 있으므로 외부 공유 전 검토한다. 이 보고서에는 인증정보를 싣지 않았다.

## 14. 조사한 upstream 자료

- [Dual-Spark 레시피 변경 이력, d23790b](https://github.com/MiaAI-Lab/Qwen3.8-Flash-Next-Dual-DGX-Sparks/blob/d23790b/CHANGELOG.md): 최근 커밋, 기본값, 합성 코드 벤치 한계.
- [Dual-Spark README, d23790b](https://github.com/MiaAI-Lab/Qwen3.8-Flash-Next-Dual-DGX-Sparks/blob/d23790b/README.md): v0.30 실행 경로, 지원 범위, draft vocab 설명.
- [vLLM v0.30.0 공식 릴리스](https://github.com/vllm-project/vllm/releases/tag/v0.30.0): QSA/PLE 및 모델 실행 최적화.
- [PR #54517: PLE 커널 융합](https://github.com/vllm-project/vllm/pull/54517), [PR #54513: QSA prefill/decode 경로 분리](https://github.com/vllm-project/vllm/pull/54513).
- [PR #55272: NVIDIA 경로 torch.compile 제거](https://github.com/vllm-project/vllm/pull/55272).
- [PR #54890: FP8 QSA 인덱서 캐시](https://github.com/vllm-project/vllm/pull/54890): 메인 KV와 별도 기능, GB300 실험을 GB10 보장 성능으로 일반화하지 않음.
- [PR #54713](https://github.com/vllm-project/vllm/pull/54713), [PR #53945](https://github.com/vllm-project/vllm/pull/53945): speculative decoding과 prefix cache 상태 보존 수정.
- [Issue #55357](https://github.com/vllm-project/vllm/issues/55357): 다른 nightly 빌드의 반복 붕괴 보고. 우리 현상과 동일하다고 확정하지 않음.