r/LocalLLaMA•4개월 전•47•46

RTX 5090에서 DiffusionGemma 26B A4B 튜닝 결과

DiffusionGemma 26B A4B results on my 5090

핵심 요약

RTX 5090 환경에서 DiffusionGemma 26B 모델의 최적 파라미터와 성능을 분석한 튜닝 결과입니다.

성능 최적화 — Q4_K_M 양자화 모델이 Q6_K보다 18% 빠르고 컨텍스트 처리 효율이 높음
온도 파라미터 — t-max와 t-min 값을 낮추는 것이 속도 향상의 핵심 요인임
컨텍스트 처리 — Flash Attention 미지원으로 인한 컴퓨팅 버퍼 병목 현상 확인
워크플로우 제안 — 초기 아이디어 생성용으로 활용하고 후속 작업은 전문 모델로 보완함

DiffusionGemma 26B A4B — 튜닝 결과

(참고: 이건 내 튜닝 결과고, 테스트 스크립트랑 보고서 작성은 Deepseek 도움 좀 받음)

https://huggingface.co/unsloth/diffusiongemma-26B-A4B-it-GGUF

시스템

- **GPU**: RTX 5090 (32 GB VRAM), CUDA 13.3
- **Build**: `llama.cpp` PR #24423, GCC-15, Ninja, ccache
- **Flash Attention**: Auto-disabled on SM120 — limits max context
- **Models**: `unsloth/diffusiongemma-26B-A4B-it-GGUF`

모델

| Q6_K | `diffusiongemma-26B-A4B-it-Q6_K.gguf` | 22 GB |
| Q4_K_M | `diffusiongemma-26B-A4B-it-Q4_K_M.gguf` | 16 GB |

최대 안정 컨텍스트

| Quant | Formula | Max ctx | -n limit | VRAM limit |
|-------|---------|---------|----------|------------|
| Q6_K | 16 blocks × 256 + 2048 | 6,144 | -n 4096 | 22 GB model + ~10 GB buffers |
| Q4_K_M | 32 blocks × 256 + 2048 | 10,240 | -n 8192 | 16 GB model + ~14 GB buffers |

컨텍스트는 컴퓨트 버퍼 크기 때문에 제한됨. RTX 5090(SM120)에서는 Flash Attention이 자동으로 꺼져서 풀 어텐션 쓸 때 메모리가 O(n²)로 늘어남. 모델 자체는 262k 컨텍스트까지 지원하는데, Flash Attention 켜면 64k까지는 무난하게 뽑힘.

최적 파라미터

| Parameter | Q6_K | Q4_K_M |
|-----------|------|--------|
| `--diffusion-eb-t-max` | 0.4 | 0.3 |
| `--diffusion-eb-t-min` | 0.1 | 0.05 |
| `--diffusion-eb-max-steps` | auto (48) | 20 |
| `--diffusion-eb-entropy-bound` | 0.1 (default) | 0.1 (default) |
| `--diffusion-eb-confidence` | 0.005 (default) | 0.005 (default) |
| `--diffusion-eb-stability` | 1 (default) | 1 (default) |
| `-ub` / `-b` | auto-derived from -n | auto-derived from -n |

최적 호출 방식

**Q6_K 가장 빠름:**

./build/bin/llama-diffusion-cli \
-m /path/to/diffusiongemma-26B-A4B-it-Q6_K.gguf \
-ngl 99 -n 2048 \
--diffusion-eb-t-max 0.4 --diffusion-eb-t-min 0.1

**Q4_K_M 가장 빠름:**

./build/bin/llama-diffusion-cli \
-m /path/to/diffusiongemma-26B-A4B-it-Q4_K_M.gguf \
-ngl 99 -n 8192 \
--diffusion-eb-max-steps 20 \
--diffusion-eb-t-max 0.3 --diffusion-eb-t-min 0.05

속도 비교

멀티 블록 처리량 (긴 프롬프트, 2048 토큰 생성)

원문

커뮤니티 목록

r/LocalLLaMA•4개월 전•47•46

RTX 5090에서 DiffusionGemma 26B A4B 튜닝 결과

DiffusionGemma 26B A4B results on my 5090

핵심 요약

RTX 5090 환경에서 DiffusionGemma 26B 모델의 최적 파라미터와 성능을 분석한 튜닝 결과입니다.

성능 최적화 — Q4_K_M 양자화 모델이 Q6_K보다 18% 빠르고 컨텍스트 처리 효율이 높음
온도 파라미터 — t-max와 t-min 값을 낮추는 것이 속도 향상의 핵심 요인임
컨텍스트 처리 — Flash Attention 미지원으로 인한 컴퓨팅 버퍼 병목 현상 확인
워크플로우 제안 — 초기 아이디어 생성용으로 활용하고 후속 작업은 전문 모델로 보완함

DiffusionGemma 26B A4B — 튜닝 결과

(참고: 이건 내 튜닝 결과고, 테스트 스크립트랑 보고서 작성은 Deepseek 도움 좀 받음)

https://huggingface.co/unsloth/diffusiongemma-26B-A4B-it-GGUF

시스템

- **GPU**: RTX 5090 (32 GB VRAM), CUDA 13.3
- **Build**: `llama.cpp` PR #24423, GCC-15, Ninja, ccache
- **Flash Attention**: Auto-disabled on SM120 — limits max context
- **Models**: `unsloth/diffusiongemma-26B-A4B-it-GGUF`

모델

| Q6_K | `diffusiongemma-26B-A4B-it-Q6_K.gguf` | 22 GB |
| Q4_K_M | `diffusiongemma-26B-A4B-it-Q4_K_M.gguf` | 16 GB |

최대 안정 컨텍스트

| Quant | Formula | Max ctx | -n limit | VRAM limit |
|-------|---------|---------|----------|------------|
| Q6_K | 16 blocks × 256 + 2048 | 6,144 | -n 4096 | 22 GB model + ~10 GB buffers |
| Q4_K_M | 32 blocks × 256 + 2048 | 10,240 | -n 8192 | 16 GB model + ~14 GB buffers |

최적 파라미터

| Parameter | Q6_K | Q4_K_M |
|-----------|------|--------|
| `--diffusion-eb-t-max` | 0.4 | 0.3 |
| `--diffusion-eb-t-min` | 0.1 | 0.05 |
| `--diffusion-eb-max-steps` | auto (48) | 20 |
| `--diffusion-eb-entropy-bound` | 0.1 (default) | 0.1 (default) |
| `--diffusion-eb-confidence` | 0.005 (default) | 0.005 (default) |
| `--diffusion-eb-stability` | 1 (default) | 1 (default) |
| `-ub` / `-b` | auto-derived from -n | auto-derived from -n |

최적 호출 방식

**Q6_K 가장 빠름:**

./build/bin/llama-diffusion-cli \
-m /path/to/diffusiongemma-26B-A4B-it-Q6_K.gguf \
-ngl 99 -n 2048 \
--diffusion-eb-t-max 0.4 --diffusion-eb-t-min 0.1

**Q4_K_M 가장 빠름:**

./build/bin/llama-diffusion-cli \
-m /path/to/diffusiongemma-26B-A4B-it-Q4_K_M.gguf \
-ngl 99 -n 8192 \
--diffusion-eb-max-steps 20 \
--diffusion-eb-t-max 0.3 --diffusion-eb-t-min 0.05

속도 비교

멀티 블록 처리량 (긴 프롬프트, 2048 토큰 생성)

지금 같이 볼 만한 글

r/LocalLLaMA•약 16시간 전

NVIDIA, 오픈소스 샌드박스 'OpenShell' 출시: 프롬프트 규칙 대신 실제 런타임 제한 적용, 100개 이상의 기업이 안전 스택에 합류했으나 OpenAI는 불참

NVIDIA가 에이전트 보안을 위한 오픈소스 샌드박스 'OpenShell'을 공개하며 업계 표준화를 주도하고 있습니다.

NVIDIA shipped OpenShell, an open source sandbox that gives local and open agents real runtime limits instead of prompt rules. Over 100 firms joined the safety stack. OpenAI did not.

NVIDIA가 에이전트 보안을 위한 오픈소스 샌드박스 'OpenShell'을 공개하며 업계 표준화를 주도하고 있습니다.

661125

Reddit 원문

r/ChatGPT•약 18시간 전

혈당이 급락하는 동안 ChatGPT 음성 기능이 나를 계속 깨워줬어

작성자가 저혈당 쇼크로 의식을 잃어갈 때 ChatGPT가 음성으로 계속 말을 걸어 깨워준 경험담입니다.

ChatGPT voice kept waking me up while my blood sugar was plummeting

작성자가 저혈당 쇼크로 의식을 잃어갈 때 ChatGPT가 음성으로 계속 말을 걸어 깨워준 경험담입니다.

841214

Reddit 원문

r/ClaudeAI•1일 전

Anthropic이 학습 단계에서 사소한 디테일까지 얼마나 신경 썼는지 보여주는 증거

Anthropic의 모델이 그동안 과도하게 사용하던 em dash(—)를 줄이는 등 세밀한 개선을 이뤄낸 것에 대한 사용자들의 긍정적인 반응입니다.

This is proving how Anthropic was taking even small details seriously during the training phase

Anthropic의 모델이 그동안 과도하게 사용하던 em dash(—)를 줄이는 등 세밀한 개선을 이뤄낸 것에 대한 사용자들의 긍정적인 반응입니다.

1787110

Reddit 원문

커뮤니티 전체 보기

원문

| Context | Q6_K default | Q6_K tuned | Q4_K_M default | Q4_K_M tuned |
|---------|-------------|------------|----------------|--------------|
| -n 2048 (ctx=4096) | 180 tok/s | **213 tok/s** | 174 tok/s | **244 tok/s** |
| -n 3072 (ctx=5120) | 183 tok/s | **209 tok/s** | 175 tok/s | **245 tok/s** |
| -n 8192 (ctx=10240) | — | — | 175 tok/s | **252 tok/s** |

| Metric | Q6_K default | Q6_K tuned | Q4_K_M default | Q4_K_M tuned |
|--------|-------------|------------|----------------|--------------|
| Throughput | 523 tok/s | 523 tok/s | 456 tok/s | **545 tok/s** |
| Steps per block | 6 | 6 | 8 | **6** |

| Quant | -n 2048 | -n 3072 | -n 8192 |
|-------|---------|---------|---------|
| Q6_K | **+18%** | **+14%** | — |
| Q4_K_M | **+40%** | **+40%** | **+44%** |

| t-max / t-min | Q6_K steps/blk | Q6_K tok/s | Q4_K_M steps/blk | Q4_K_M tok/s |
|---------------|----------------|------------|-------------------|--------------|
| 0.8 / 0.4 (default) | 15.8 | 180 | 18.0 | 174 |
| 0.6 / 0.2 | 14.8 | 192 | 16.9 | 188 |
| 0.4 / 0.1 | **13.0** | **213** | 13.2 | 221 |
| 0.3 / 0.05 | 13.5 | 199 | **12.6** | **230** |
| 0.2 / 0.05 | 12.0* | 223* | 15.0* | 260* |

| max-steps | Q4_K_M steps/blk | Q4_K_M tok/s |
|-----------|-------------------|--------------|
| auto (48) | 12.6 | 230 |
| 24 | 12.0 | 236 |
| **20** | **11.4** | **244** |
| 18 | 12.2 | 235 |
| 16 | 12.8 | 228 |

| entropy-bound | Q6_K tok/s | Q4_K_M tok/s | Effect |
|---------------|------------|---------------|--------|
| 0.05 | 152 | 216 | Too selective → more steps |
| **0.1 (default)** | **180** | **230** | Sweet spot |
| 0.15 | — | 240 | Slight improvement on Q4 |
| 0.2 | 158 | 233 | Too noisy → more steps |

| -ub / -b | Q6_K tok/s | Notes |
|----------|------------|-------|
| auto (4096) | **213** | Derived from -n / ctx |
| 512 | 203 | Smaller = less parallelism |
| 8192 | 213 | Larger = no benefit |

**Q4_K_M is the better choice** — 50% more context (10k vs 6k) and 18% fastergeneration (252 vs 213 tok/s at max context).
**Temperature is everything** — lowering t-max from 0.8→0.3 and t-min from0.4→0.05 accounts for virtually all the speedup. The rest of the EB paramsare already well-tuned at defaults.
**Bigger context doesn't slow down Q4_K_M** — speed actually *improves* atlarger context (252 tok/s at -n 8192 vs 244 at -n 2048). The larger batchgives the entropy-bound sampler better signal.
**Flash Attention is the blocker for 64k** — once SM120 support lands inllama.cpp, the compute buffer bottleneck goes away and DiffusionGemma'sfull 262k context should be reachable on a single RTX 5090.

주요 댓글

r/localllama

대체로 코딩 성능이나 지능 면에서 실망스럽다는 반응이 많으며, 빠른 속도보다는 정확한 결과물이 중요하다는 의견이 지배적입니다.

vllm, nvidia/diffusiongemma-26B-A4B-it-NVFP4 사용 중.
결과:
GPU KV 캐시 크기: 945,291 토큰
262,144 토큰 요청 시 최대 동시성: 3.61배
~500 tok/s. (400와트 제한)

하지만 pi와 opencode에서는 처참하게 실패함.
claude code를 사용해 결과를 좀 뽑아봤지만, Qwen3.6 27b에는 한참 못 미침.

정확함. 구글 블로그에서도 Gemma4 12B보다 지능이 5% 낮다고 나옴. 특정 작업 파인튜닝용으로는 좋아 보임.

그 이상으로, 스트리밍을 비활성화해서 전체 응답이 마지막에 한 번에 나오게 해야 할 것 같음.
확인해 봤는데 내가 언급한 코딩 에이전트 중에는 그걸 지원하는 게 없음.

vllm으로 테스트해 보니 여전히 스트리밍 중임, 아마 256 토큰 단위로 끊기는 듯. 스트리밍 지원 안 하고 싶으면 구현은 아주 쉬움. 그냥 스트리밍하는 척하다가, 다 준비될 때까지 아무것도 안 보내면 됨...

이걸 추측 디코딩(speculative decoding)에 사용할 수 있을까?

하지만 pi와 opencode에서는 처참하게 실패함.

(아직) 툴 호출 지원이 안 됨. 어떤 벤치마크에서도 제대로 작동 안 할 거임.

코딩 아이디어를 위한 내 워크플로우 이론은 Diffusion(초기 스캐폴딩 및 아이디어 생성) -> Deepseek flash(코드 대부분 작성, 전체 코드베이스 인식) -> Deepseek Pro(디버그 및 정리) 순서임.

아이디어-코드 생성기로서 작은 모델의 문제는, 큰 모델이 전체를 다시 써서 고쳐야 할 정도로 아이디어가 형편없다는 점임. 하지만 큰 모델이 요구사항을 포함해 상세한 가이드를 짜주면 첫 번째 구현 단계에서는 작동할지도 모르겠음.

흠, 그런 식으로 생각해 본 적은 없는데, 내가 순서를 잘못 잡고 있는 건가?

더 큰 모델이 계획과 초기 구조를 잡게 하고, 작고 빠르지만 멍청한 모델이 나머지를 완성한 뒤, 다시 큰 모델이 디버깅 및 정리하게 하는 방식이 나한테는 아주 잘 먹혔음. 어차피 토큰 소모 대부분은 그 중간 단계에서 일어나니까.

내 생각엔 반대가 돼야 할 것 같음. 큰 모델이 매우 상세한 계획을 세우고 모든 걸 검토하는 거지(어떤 코드 모듈을 어떻게 수정할지, 단순히 일반적인 방향성만 제시하는 게 아니라). 그러고 나서 도구 호출 능력이 충분히 좋은 작은 유틸리티 모델이 투입되어 코드를 작성하고 테스트를 실행하는 식이지. 그 후 작은 모델이 모든 걸 다시 큰 모델로 보내는 거야. 목표는 큰 모델의 컨텍스트 윈도우를 아끼는 거니까. 작은 모델로 시작하면 큰 모델이 결국 모든 걸 다시 해야 할 수도 있음 …

길이 제한으로 뒷부분이 생략된 댓글입니다 · 원문에서 전체 보기 →

Diffusion 모델은 mtp처럼 초안을 작성함.

124b 모델에 적용하면 정말 좋을 것 같지 않아?

이건 코딩 에이전트라기보다는 일반적인 비서나 대량 데이터 처리 모델에 더 가까워 보임.

Qwen 27B는 덴스 모델임. 공정한 비교를 하려면 MoE 35B랑 비교해야지.

원문r/LocalLLaMA