Tinkering with DFlash2: How to Speed Up Local AI Models
Quick Summary
Tinkering with DFlash2: How to Speed Up Local AI Models를 중심으로, 일반 디코딩은 토큰 하나를 생성할 때마다 모델의 전체 가중치를 메모리에서 다시 읽기 때문에, 로컬 GPU에서는 계산보다 메모리 대를 핵심 판단 포인트로 압축 정리한다.
영상 보기
클릭 전까지는 가벼운 미리보기만 먼저 불러옵니다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론
Tinkering with DFlash2: How to Speed Up Local AI Models를 중심으로, 일반 디코딩은 토큰 하나를 생성할 때마다 모델의 전체 가중치를 메모리에서 다시 읽기 때문에, 로컬 GPU에서는 계산보다 메모리 대를 핵심 판단 포인트로 압축 정리한다.
📌 핵심 요점
- 일반 디코딩은 토큰 하나를 생성할 때마다 모델의 전체 가중치를 메모리에서 다시 읽기 때문에, 로컬 GPU에서는 계산보다 메모리 대기가 속도 병목이 되기 쉽다.
- 투기적 디코딩은 작은 드래프터가 여러 토큰을 미리 제안하고 큰 모델이 한 번에 검증하지만, 기존 순차형 드래프터 역시 토큰별 전방 패스를 수행한다는 한계가 있다.
- DFlash는 여러 빈칸을 한 번에 채우는 블록 확산 방식으로 초안을 병렬 생성하지만, 각 위치를 독립적으로 추정해 후보 간 일관성과 블록 후반부 정확도가 약해진다.
- DFlash 2는 위치별 상위 16개 후보에서 가장 일관된 경로를 고르는 선택기와, 직전 위치의 정보를 전달하는 2탭 합성곱을 추가해 경로 불일치와 suffix decay를 함께 줄인다.
- Muse Glimmer 30B와 DGX Spark를 사용한 C1 실험에서 처리량은 기본 모델 4.3, DFlash 12.29, DFlash 2 15.12 tokens/s였으며, DFlash 2는 DFlash보다 약 23% 빨랐다.
🧩 배경과 문제 정의
로컬 AI 모델은 폐쇄형 연구소의 최상위 모델에 가까워지고 있지만, 개인 GPU에서 실행할 때는 데이터센터보다 느린 경우가 많다. 핵심 병목은 토큰마다 전체 모델 가중치를 메모리에서 다시 읽는 일반 디코딩 구조다.
투기적 디코딩은 작은 드래프터가 여러 토큰을 미리 제안하고 큰 모델이 한 번에 검증해 이 병목을 완화한다. DFlash는 초안 블록 전체를 한 번에 생성하지만, 위치별 독립 추정 때문에 후보들이 서로 맞지 않거나 블록 후반부의 품질이 떨어지는 문제가 남는다. 영상은 DFlash 2가 이 두 문제를 어떻게 보완하는지 설명하고 DGX Spark에서 직접 비교한다.
🕒 시간순 섹션별 상세정리
1. 로컬 AI의 성능 기회
- 개인용 GPU나 DGX Spark에서도 강력한 모델을 실행할 수 있지만, 로컬 모델은 데이터센터 실행보다 대체로 느리다는 문제를 제시한다. [00:34]
- 모델 재학습 없이 속도와 품질을 개선하는 기술이 오픈소스 커뮤니티와 개인 개발자 수준에서도 발전하고 있다고 강조한다. [01:04]
2. DFlash 2 소개와 실험 계획
- Inco AI가 기존 DFlash에 이어 DFlash 2를 공개했으며, 영상은 두 방식의 차이를 설명한 뒤 직접 성능을 비교하겠다고 예고한다. [02:13]
- 기본 모델, DFlash, DFlash 2의 세 구성을 DGX Spark에서 실행해 속도와 성능 차이를 확인하는 것이 실험의 목적이다. [02:17]
- 에이전트용 지식 기반과 자동화 템플릿을 제공하는 Agent Wikis 프로젝트를 짧게 소개한 뒤 본론으로 돌아간다. [02:57]
3. 일반 디코딩의 메모리 병목
- 언어 모델은 토큰 하나를 생성해 문맥에 붙인 뒤 다음 토큰을 예측하며, 각 예측에는 한 번의 전방 패스가 필요하다. [03:11]
- 전방 패스마다 전체 가중치를 메모리에서 읽기 때문에, 예시의 60GB 모델에서는 GPU가 계산보다 메모리 전송을 기다리는 시간이 길어진다. [03:54]
4. 투기적 디코딩의 기본 구조
- 투기적 디코딩은 작은 별도 모델인 드래프터가 다음 토큰 여러 개를 미리 추정하고, 큰 모델이 한 번의 패스로 후보들을 일괄 검증하는 방식이다. [04:54]
- 큰 모델이 동의한 후보만 유지되므로 실제 속도 향상은 제안 개수보다 수용된 토큰의 수와 수용률에 좌우된다. [05:10]
5. DFlash의 블록 확산 방식
- 일반 드래프터도 토큰을 순차 생성하므로 작은 직렬 병목이 남으며, DFlash는 여러 빈칸을 한 패스에서 동시에 채워 초안 블록을 만든다. [06:11]
- 이미지 확산이 전체 그림을 한꺼번에 다루는 것처럼 전체 토큰 블록을 생성한다는 의미에서 block diffusion이라는 이름을 사용한다. [06:35]
- 다만 각 위치가 독립적으로 추정되므로 개별 후보가 그럴듯해도 서로 일관된 문장을 이루지 못할 수 있다. [06:54]
6. 얕고 넓은 드래프터의 구조
- DFlash 드래프터는 큰 모델보다 폭이 좁은 모델이 아니라, 같은 폭의 트랜스포머 블록을 52개 대신 5개만 사용하는 얕은 모델로 드러난다. [08:03]
- 블록 크기 16에서는 한 번에 16개 위치를 채우지만, 5개 층만 거치므로 뒤쪽 위치가 앞 위치의 결정을 학습할 기회가 적어 블록 후반부가 약해진다. [08:49]
7. 수용 길이와 후보 목록의 가능성
- 성능은 큰 모델 실행 횟수당 생성된 토큰 수로 측정되며, DFlash 2의 개선은 이 수용 길이를 높이는 데 집중된다. [09:40]
- 첫 위치의 최상위 후보 정확도는 85.4%지만 정답 토큰이 상위 16개 안에 있을 확률은 99.5%로, 정답이 없기보다 후보 순위 선택이 잘못된 경우가 많다고 보여준다. [10:53]
- 따라서 첫 후보가 틀렸다고 블록을 폐기하기보다 이미 존재하는 후보 목록에서 더 적합한 답을 고르는 접근이 가능하다. [11:52]
8. 경로 선택기가 일관성을 복구하는 방법
- DFlash 2는 각 위치의 후보 16개를 유지하고 인접 후보 쌍을 채점한 뒤, 전체적으로 가장 일관된 경로를 선택한다. [12:28]
- 순차적으로 전체 어휘를 다시 예측하는 경쟁 방식 DSpark와 달리 기존 후보에서 선택하며, 영상은 이를 약 40배 적은 파라미터로 가능한 접근이라고 보여준다. [12:58]
9. Suffix decay와 깊이 확장의 한계
- 블록 끝으로 갈수록 후보 자체가 나빠지는 현상을 Inco는 suffix decay라고 부르며, 5개 층으로 16개 위치를 연결하기에는 용량이 부족할 가능성을 제시한다. [13:21]
- 층을 3개에서 15개로 늘리면 뒤쪽 위치의 수용 성능이 65%에서 78.7%로 오르지만, 파라미터가 3배가 되고 시간이 15.2% 늘어난다. [13:56]
- 깊이를 일괄 추가하면 이미 성능이 좋은 앞 위치에도 불필요한 용량을 투입하므로 정밀한 해결책이 되지 못한다. [14:10]
10. 2탭 합성곱으로 후반부 보강
- DFlash 2는 각 위치가 현재 위치와 바로 이전 위치를 참조하게 하는 작은 합성곱을 추가해 인접 토큰 사이의 정보를 전달한다. [14:34]
- 5층 모델의 일곱 번째 위치 성능은 72.9%에서 합성곱 적용 후 77.6%로 올라갔고, 파라미터 증가는 3%에 그쳤다. [14:51]
- 이 방식은 10개 층을 추가했을 때 얻는 효과의 대부분을 회복해 suffix decay가 주로 국소적 연결 문제였음을 시사한다. [15:00]
11. DFlash 2의 구성과 추가 비용
- 최종 구조는 위치별 상위 16개 후보에서 일관된 경로를 찾는 선택기와, 각 위치가 한 칸 뒤를 참조하는 2탭 합성곱으로 요약된다. [15:23]
- 실험용 체크포인트에서는 합성곱 약 1억1,090만 개와 선택기 약 1억510만 개를 합쳐 약 2억1,600만 개의 파라미터가 추가된다. [15:47]
- 디스크 용량은 약 400MB, 사이클당 시간 증가는 약 1.3%이며 설정에는 top-k 16, selector rank 256, kernel size 2, group size 16이 사용된다. [16:19]
12. DGX Spark 실험과 최종 판단
- Muse Glimmer 30B의 동일 리비전과 서버 설정을 고정하고, 기본 모델·DFlash·DFlash 2를 격리된 환경에서 실행해 속도와 수용 지표를 비교한다. [19:10]
- C1 처리량은 각각 4.3, 12.29, 15.12 tokens/s였고, DFlash 2는 기본 모델보다 3.5배, DFlash보다 약 23% 빨랐으며 수용 길이도 3.251에서 4.112로 증가했다. [21:22]
- DFlash 2는 같은 토큰 예산에서 더 적은 검증 패스를 요구했지만 시작 시간과 메모리 사용량은 늘었고, 발표자는 DGX Spark의 지연시간 민감형 Muse Glimmer 서비스에 DFlash 2를 권하며 실험을 마친다. [23:44]
🧾 결론
- DFlash 2의 성능 향상은 더 많은 초안 토큰을 무작정 생성한 결과가 아니라, 후보 수용 길이와 수용률을 높여 목표 모델의 검증 패스를 줄인 결과다.
- 실험 대상인 Muse Glimmer 30B를 DGX Spark에서 지연시간에 민감하게 서비스한다면 세 방식 가운데 DFlash 2가 가장 실용적인 선택이었다.
- 추가 파라미터와 시작 시간, 메모리 사용량이라는 비용이 있으므로 가용 메모리가 빠듯한 환경에서는 처리량뿐 아니라 상주 메모리까지 함께 평가해야 한다.
📈 투자·시사 포인트
- 로컬 AI 경쟁력은 모델 크기만이 아니라 투기적 디코딩, 후보 선택, 메모리 접근 최적화처럼 추론 단계의 소프트웨어 기술에 의해 크게 달라질 수 있다.
- 기존 모델을 재학습하지 않고도 처리량을 높일 수 있다는 점은 개인용 AI 장비와 온디바이스 추론의 활용 범위를 넓히는 요인이다.
- 오픈소스 커뮤니티와 전문 AI 기업이 공개한 최적화 기법을 개인이 수천 달러 수준의 장비에서 검증할 수 있어, 데이터센터 밖 추론 생태계의 혁신 주기가 빨라질 가능성이 있다.
- 실제 도입 판단에서는 최고 속도보다 대상 모델용 드래프터의 존재 여부, 수용 효율, 동시성별 성능, 메모리 여유를 함께 봐야 한다.
⚠️ 불확실하거나 확인이 필요한 부분
- 결과는 DGX Spark와 Muse Glimmer 30B라는 특정 조합에서 나온 단일 실험이므로, 다른 GPU·모델·양자화 설정에서도 3.5배 향상이 재현된다고 단정할 수 없다.
- 영상은 품질 테스트도 수행했다고 설명하지만, 출력 품질이나 정확도에 관한 구체적인 결과는 제시하지 않는다.
- 전사에는 DFlash, Dlash, D flash와 DGX·DJX가 혼재하므로 제품명과 일부 고유명사는 원문 자료를 통해 재확인필요가 있다.
- 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
- 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
- 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.
✅ 액션 아이템
- 동일한 모델 리비전과 서버 설정을 고정한 뒤 기본 모델, DFlash, DFlash 2를 같은 프롬프트 세트로 재실험한다.
- C1과 다중 동시성 조건별로 tokens/s, acceptance length, acceptance rate, 검증 횟수를 함께 기록한다.
- DFlash 2 적용 전 시작 시간, 피크 상주 메모리, 체크포인트 추가 용량이 장비의 메모리 한계 안에 들어오는지 확인한다.
- 속도 측정과 별도로 세 구성의 출력 정확성·일관성·실패 사례를 비교해 품질 저하가 없는지 검증한다.
❓ 열린 질문
- 경로 선택기와 2탭 합성곱의 효과는 코드 생성, 수학 추론, 일반 대화처럼 과제 유형이 달라져도 동일하게 유지되는가?
- 블록 크기와 드래프터 깊이를 바꾸면 속도, suffix decay, 추가 메모리 사이의 최적점은 어디에 형성되는가?
- DFlash 2용 드래프터가 아직 없는 로컬 모델에 이 기법을 적용하려면 어느 정도의 학습 비용과 데이터가 필요한가?