LLM-wiki와 많은 AI의 도움을 받아, 저는 dLLM (그리고 네, 여기서 'd'가 꽤 많은 역할을 합니다...) 실험을 진행하고 있습니다. Github-Repo: NeoDiffusion (Neo Diffusion인 이유는 이것이 제 네 번째 시도이기 때문이며, 이번에는 제가 사용할 수 있었던 약간의 Fable로 시작했습니다) - 이 프로젝트를 뭐라고 불러야 할지 모르겠지만, 중요하지는 않을 것 같습니다. 덧붙이자면, 이 저장소(repo)를 공개할 의도는 아니었기에 엉망일 수 있으며, 나중에 정리하도록 하겠습니다. 기본적으로, Apple Silicon을 위해 구축된 엔진을 가지고 arxiv에서 찾은 최적화 기법들을 실험했습니다. 여러분의 즐거움(혹은 그렇지 않을 수도 있는)을 위해 예비 결과와 실험 내용을 공유합니다:

base) | wp1b-logbook.md | | WP-2a 자동 추측 (Auto-Speculation) | 자기 추측 (Self-speculation, S2D2) 또는 초안 그래프 (draft graphs, Spiffy). | M1 MBP (16 GB) / M2 Ultra (192 GB) | S2D2, $\tau \text{span}=8/16$, Spiffy D=3-8 | 수락 (ACCEPT) (S2D2 프리셋, 기본값-off) | S2D2는 스텝당 4.1–9.8개의 수락된 토큰을 생성함. | M1 : 연산 부정적 (compute-negative, ~2배 너비)<br> <br> M2 Ultra (S2D2) : 채팅 +14.6% / 추론(reasoning) +19.8% | wp2a-logbook.md | | WP-2b 스트리밍 dLLM (Streaming-dLLM) | 접미사 가지치기 (Suffix pruning, 2b-1), 동적 임계값 (dynamic threshold, 2b-2), EOS 종료 (EOS exit, 2b-3). | M1 MBP (16 GB) / M2 Ultra (192 GB) | $\alpha=0.6$, 동적 임계값 설정 (dynamic thresholding) | 2b-2 수락 (ACCEPT) (프리셋, 기본값-off) ; 2b-1 해당 없음 (N/A); 2b-3 무효 (NULL) | 블록당 스텝 수: -14.8% (채팅) / -11.3% (추론). | M1 : 연산 부정적 (compute-negative)<br> <br> M2 Ultra : MultiBD 승수로 인해 순 TPS 부정적 (Net negative TPS) | wp2b-logbook.md | | WP-3a JOT 토큰 동결 (JOT Token Freezing) | 조기 수렴된 토큰에 대해 전문가/공유 FFN 연산을 동결함. | M1 MBP (16 GB) / M2 Ultra (192 GB) | v2: 안정적인 K/V 유지, jotK=2, jotThreshold=0.9 | 수락 (ACCEPT) (추론 프리셋) ; Code JOT+Credit 수락 (ACCEPT) | v2는 섭동 연쇄 (perturbation cascade)를 제거함; 스텝: +15% 오버헤드. | M1 : 거부 (REJECT) (CPU-GPU 동기화)<br><br> M2 Ultra : 추론(reasoning) TPS +21.9% | jot-logbook.md | | WP-3b FlashBlock 캐싱 (FlashBlock Caching) | 저수준 MSL Metal 커널 어텐션 (attention) 캐싱. | M1 MBP (16 GB) | 커스텀 MSL 페이지 테이블 (page-table) 커널 | 거부 (REJECTED) (M1) — ⚠️ 판정 무효 (INVALID), 재벤치마크 필요 | $\tau=0$ 하에서 동등성 유지 — 이것이 바로 버그가 숨겨졌던 이유임. .reuseCache 경로가 단 한 번도 실행되지 않음 (2026-07-15). | 동기화 오버헤드: Vanilla 8.55 TPS vs. FlashBlock 5.13 TPS | wp-3b-flashblock-attention-caching.md · gather_qmm_handoff.md | | WP-4a TSCV | 노이즈 해결을 위해 안정적인 꼬리 예측 (tail predictions)에 투표함. | M1 MBP (16 GB) / M2 Ultra (192 GB) | $\alpha=1.0$, $t \text{start}=0.9$, 100개의 GSM8K 테스트 프롬프트 | 수락 (ACCEPT) (기본값-on으로 적용됨) | GSM8K 정확도:<br> <br> M1 : 16% $\rightarrow$ 24% (+8pp)<br <br> M2 Ultra : 15% $\rightarrow$ 21% (+6pp) | 오버헤드 없는 CPU 투표 (<1ms) | wp4a-logbook.md | | WP-4b ICE 프롬프팅 (ICE Prompting) | 동시 사고 (concurrent thinking)를 위한 구조화된 인플레이스 (in-place) 템플릿.

| M1 MBP (16 GB) / M2 Ultra (192 GB) | Dynamic $B = \text{prompt} + \text{gen}$, $\tau_{\text{ans}}=0.9$, $N_t=4$ | ACCEPT (Served Preset) — ⚠️ +4pp는 통계적으로 유의미하지 않음 | GSM8K (M2 Ultra): 15% $\rightarrow$ 19% (+4pp), 하지만 paired McNemar p=0.481 (11개 획득 / 7개 상실); 7-arm sweep 중 유의미한 수준에 도달하는 팔(arm)이 없으며, 그리드는 비단조적임 ($N_t$ 2/3/4 $\rightarrow$ 7%/15%/19%). | 추론 집약적 프리셋(reasoning-heavy presets)에 대해 승격됨; 더 높은 스텝 수 (71.7 대 38.3) | wp4b-logbook.md | | WP-4d Credit Decoding | 크레딧 피드백 행렬(credit feedback matrix)을 통해 최상위 예측을 강화함. | M1 MBP (16 GB) / M2 Ultra (192 GB) | $\beta=0.9$, $\gamma=1.0$, $\alpha=1.0$ (Γ-only boost) | ACCEPT (Landed Default-On) — ⚠️ +1.8%는 프로세스 간 드리프트 하한선(cross-process drift floor) 미만임 | 모멘텀 필터(Momentum filter)가 임계값 커밋(threshold commits)을 가속화함. 동일한 비교가 두 번의 깨끗한 실행 사이에서 +6.2% $\rightarrow$ +1.8%로 이동함 (추론 부호가 반전됨, +3.5% $\rightarrow$ −0.3%). 블라인드 품질 게이트(blind quality gate)는 실행되지 않음 (§0은 $\le$0.5pp를 요구함). | M2 Ultra (chat) : +1.8% TPS (49.04 대 48.19 TPS 베이스라인) | wp-4d-credit-decoding.md | | WP-6a MoE Adaptive Dispatch | 시퀀스 길이 $T$에 기반한 동적 인덱스 정렬 분기(Dynamic index sorting branch). | Mac Studio M2 Ultra | Mini crossover $T=192$, Flash crossover $T=128$ | ACCEPT (Landed Default-On), 하지만 비활성 상태(dormant) | 프리필(Prefill) GPU 정렬 가속: $T=2048$에서 최대 $14.32\times$ 향상. | 디코딩 중 정렬 직렬화 오버헤드(sorting serialization overhead) 방지 ($T \le 128$) | wp-6a-moe-adaptive-dispatch.md | | WP-6b Module Attribution | testModuleAttribution을 통한 Studio에서의 모듈별 지연 시간(latencies). | Mac Studio M2 Ultra | 6회 웜업 반복(warm repetitions) | 철회됨 (RETRACTED) | $19 \times 2.33 = 44.3$ ms = 27.5 ms 순전파(forward)의 161% — 불가능함. | 해당 없음 — 측정된 시간은 예산(budget)으로 사용 불가 | wp-6b-m2-ultra-module-attribution.md · gather_qmm_handoff.md | | WP-6c In-Situ Attribution | 고장 난 마이크로벤치마크(microbench)를 교체: 실제 순전파(forward) 내부에서의 인과적 절제(causal ablation).

| Mac Studio M2 Ultra | attr-* arms; 4 rounds, 288+180+108+72 rows | 방법론 확립 (ESTABLISHED); 예산 측정됨 | gather_qmm 42.9%, routed-MoE 56.3% (재현값 56.2/56.3), attention 14.3%, router 1.7%, lm_head ~3%. | 제어(Control)가 서비스된 베이스라인(baseline)을 +0.1–1.4% 범위 내에서 재현함 | gather_qmm_handoff.md | | WP-6d blockLength Sweep | 순전파(forward)당 더 많은 토큰에 걸쳐 전문가(expert) 바이트를 분할 amortize함. | Mac Studio M2 Ultra | arm별 오버라이드에 따른 $B \in {32, 64, 128}$ | 반박됨 (REFUTED) | steps/block $7.78 \rightarrow 13.36$ (1.72배) vs 손익분기점 1.18배. | $B{=}64$: −21.3%; $B{=}128$: −66.1% | gather_qmm_handoff.md | | WP-6e Router Reuse | 스텝(step) 간 라우팅(routing) 재사용 (80%의 전문가 세트 중복 측정됨). | Mac Studio M2 Ultra | routerReuseSteps $\in {2, 4, 999}$ | 반박됨 (REFUTED) — 그리고 fused-router 아이디어를 무산시킴 | $N{=}2$일 때 steps/block 1.35배. reuse-999는 라우터의 실제 한계 비용(marginal cost)을 0.48 ms = 1.7%로 산출함 (ablation 결과는 13.2%로, 7.7배 과장됨). | $N{=}2$: −14.3%; $N{=}4$: −24.1% | gather_qmm_handoff.md | | WP-6f Case B Probes | gather_qmm이 대역폭 제한(bandwidth-bound)인가? 역양자화(dequant)가 병목(bottleneck)인가? | Mac Studio M2 Ultra | .moeFixedExperts 프로브; --dequantize-experts (FP16, 31.5 GB) | CASE B 유효함 (ALIVE) — 유일하게 살아남은 레버(lever) | 7배 적은 바이트 $\Rightarrow$ 25% 더 느림 (대역폭 제한이 아님). FP16 (4배의 바이트, 역양자화 없음)은 1.50배 더 느림 $\Rightarrow$ 양자화(quantization)의 정당성이 입증됨. 4-bit gather 시간의 ~7.5 ms (~27%)는 바이트를 이동시키는 것이 아님. | 4-bit 11.92 ms @162 GB/s vs FP16 17.86 ms @433 GB/s | gather_qmm_handoff.md | | WP-6g Routing Distribution | 루프라인(roofline)의 핵심이 되는 고유 전문가(distinct-expert) 수를 측정함. | Mac Studio M2 Ultra | --dump-routing, 246회 순전파(forwards), speculationK=1 | 완료 — 두 모델을 뒤집음 | 레이어당 57.3개의 고유 전문가 (모델 예측값은 162 / 111). 단계(phase)에 따라 다름: 49.6 (높은 노이즈) $\rightarrow$ 64.2 (낮은 노이즈). 스텝 간 자카드(Jaccard) 유사도 80%. | 해당 없음 (레이어별 리드백; 구조상 타이밍 측정은 무효) | gather_qmm_handoff.md | (그리고 맞습니다, 이 표는 AI가 생성했습니다) 더 많은 실험을 수행하고 문제들을 수정할 예정입니다.

그러니 좋은 아이디어나 제안이 있다면 언제든 말씀해 주세요! 이 저장소(repo)의 목표는 다음과 같습니다:

• 내 기기에서 동작하는 확산 엔진 (diffusion engine)을 갖고 싶습니다.
• 확산 모델 (diffusion models)에 대해, 그리고 그것들이 어떻게 작동하는지 등에 대해 더 많이 알고 싶습니다.
  이 프로젝트를 계속 업데이트할까요, 아니면 거의 모든 AI 저장소들처럼 방치하게 될까요? 글쎄요, 지켜봐야겠죠...
  덧붙이자면, 제가 포맷팅을 망쳐놓았을 수도 있고 꽤 여러 번 수정해야 할 수도 있으니 양해 부탁드립니다. 여러분의 질문에 대해서는 제가 이해하는 범위 내에서 답변하고, 그 후에 AI 답변을 추가하여 적어도 일관성 있고 정보가 풍부한 답변을 드릴 수 있도록 노력하겠습니다.
  submitted by /u/DunklerErpel [link] [comments]