AI 와 개발에 관한 기록
-
M4 Max 128GB에서 DeepSeek V4.1 Flash 1017 Q2, 128K 위치에서 생성 초당 16~18토큰
340GiB짜리 DeepSeek V4.1 Flash 1017 Q2를 통합 메모리 128GiB인 M4 Max에서 SSD 스트리밍으로 돌려, 32K씩 128K까지 쌓는 작업을 소설·코드 각 3회 쟀습니다. 128K 위치 생성은 16~18 tok/s였습니다.
-
macOS에서 스크립트로 띄운 Chrome을 강제 종료하면 실행마다 2.1GB가 남습니다
설치된 Google Chrome을 QA 스크립트로 띄웠다가 SIGTERM이나 SIGKILL로 끝내면 앱 번들 사본이 하나씩 남습니다. 3주 동안 138개, 약 289GB가 쌓여 디스크가 찼습니다. 원인과 종료 방식별 측정, 막는 법입니다.
-
Strata 엔진은 128K에서 생성이 2~4배 빨랐지만, 실사용에서는 원래 엔진으로 돌아왔습니다
EVO-X2에서 Strata v0.1.40을 llama.cpp와 비교했습니다. 단일 요청에서는 128K 생성이 2~4배, 첫 토큰이 4.5배 빨랐지만, 두 요청을 동시에 받으면 출력이 깨졌고 하루 실사용 시험에서는 본문 없이 끝나는 답이 나와 원복했습니다.
-
ComfyUI 0.38의 정식 H3 가속 셋을 Blackwell에서 비교했습니다
ComfyUI 0.38에 들어온 정식 sparse attention, INT8 attention, w6a8 가중치를 RTX Pro 6000 Blackwell에서 3회 중앙값으로 비교했습니다. 정식 sol-attn이 기존 커스텀 패치보다 빨랐고, INT8 attention과 w6a8은 속도 이득이 없었습니다.
-
두 대화가 각각 128K를 쓰면, 캐시와 동시 요청은 어떻게 되나
EVO-X2에서 llama-server 슬롯 두 개에 각각 약 120K토큰짜리 대화를 올려 캐시 재사용과 동시 요청을 쟀습니다. 후속 질문은 99.9% 캐시를 써서 2초 안에 답했고, 두 요청이 겹치면 생성 속도가 떨어졌습니다.
-
M4 Max에서 Qwen3.8 Flash Next를 oMLX로 돌리면 128K에서도 초당 56토큰
M4 Max 128GiB에서 oMLX 정식 0.7.0과 MLX oQ4e 가중치로 32K씩 누적해 128K까지 쟀습니다. 생성은 128K에서도 56 tok/s 안팎, 새로 넣는 32K의 prefill은 780 tok/s 안팎이었습니다.
-
Blender 그레이박스 영상으로 MiniMax H3의 카메라를 지시하면 무엇이 전달되나
카메라 움직임만 담은 Blender 프리비즈를 H3 Ref2VA의 참조 영상으로 넣고, 참조 영상을 뺀 대조군과 시드 3개로 비교했습니다. 타임코드는 프롬프트가, 프레이밍과 주시의 안정성은 참조 영상이 만들었고, 좌우 궤도는 전달되지 않았습니다.
-
llama-server 스트리밍에서 이모지 토큰 ID가 빠지는 이유
llama-server의 /completion을 stream과 return_tokens로 쓰면, 한 글자가 여러 토큰으로 나뉠 때 본문은 멀쩡해도 원본 토큰 ID 일부가 전달되지 않습니다. 2024년 12월 도입된 코드부터 있던 경로입니다.
-
128GB 두 대 비교, M4 Max와 Ryzen AI Max+ 395에서 Qwen3.8과 DeepSeek V4.1
통합 메모리 128GB인 Mac Studio(M4 Max)와 EVO-X2(Ryzen AI Max+ 395)에서 같은 Qwen3.8 가중치를 각 하드웨어 담당자가 고른 대표 설정으로 같은 작업에 돌렸습니다. M4 Max가 prefill 1.9~3.0배, 생성 2.0~3.3배 빨랐습니다.
-
3주 뒤 다시 잰 Qwen3.8, llama.cpp 업데이트로 prefill 최대 61% 향상
ROCm 버전을 올려서는 나지 않던 향상이 llama.cpp 코드 업데이트로 나왔습니다. upstream 비교, 실제 문맥 32/64/96K 측정, 128K+vision 검증, HIP와 Vulkan 비교를 정리했습니다.