DeepSeek V4.1 Flash 1017 - CED 아키텍처와 네이티브 이미지 이해를 도입한 MoE 모델

벤치마크에서는 DS가 Sol이나 Gemini보다 낫지 않지만, 모두 한동안 써 보니 왜 DeepSeek의 체감 성능이 훨씬 좋다는지 이해되기 시작함.
우선 제공업체의 초당 토큰 수와 첫 토큰 응답 시간(TTFT)이 좋음. 상당히 괜찮은 품질로 작업을 빠르게 처리하니 에이전트가 끝나기를 기다리는 일이 줄어듦.
또 추론 과정 공개가 좋음. 사고 사슬(CoT)을 볼 수 있고 사이버 보안 심사 때문에 갑자기 차단되지 않아, 멈춘 건지 갑자기 실패할지 걱정할 필요가 없음. 가격 대비 가치까지 좋아서 다음 구독은 아마 Z.ai가 될 듯함.

내게는 과하게 영리한 척하지 않는 점이 좋음. 개발자가 실제로 작성할 법한 코드를 만들어 주므로, 머릿속에서 구상하는 대로 소프트웨어를 계층적으로 쌓고 추상화를 어디에 둘지도 직접 통제할 수 있음.
최상위 LLM에는 이런 지도가 필요 없다는 사람도 있지만, 기존 소프트웨어를 확장하거나 기존 생태계에 맞춰 개발할 때는 여전히 상당한 안내가 필요함. 검토 후 되돌릴 코드로 문맥 창을 채우지 않는 편이 나음.

DeepSeek는 과도한 추론 때문에 오히려 가장 오래 걸리지 않나요? 이번 버전은 아직 안 써 봤지만, 이전 버전은 바로 시작하지 않고 끊임없이 고민하고 자문하느라 무엇이든 너무 오래 걸려 크게 실망했음.

저렴하게 쓸 때는 DeepSeek와 Muse를 주로 선택함. 둘 다 기초·중간 난도 작업에는 아주 잘 맞음.

DeepSeek에 구독 요금제가 없다는 걸 꼬집은 건가요? 그렇다면 OpenCode Go가 괜찮아 보이고 DeepSeek 모델도 포함됨. 아직 직접 써 보지는 않았음.

회사 공식 소식은 https://api-docs.deepseek.com/news/news261017에서 볼 수 있음.
새 버전은 여러 코딩 벤치마크에서 크게 개선됐고, 11개 중 10개에서 Sol 5.6을 앞섬. 다만 최신 Sol은 6.1임.
코드 작성에는 다시 DeepSeek를 쓰려 함. Sol을 시험하며 결과에 만족했지만, 이번 버전이면 격차가 상당히 줄어들 듯함. 구현 계획과 코드 검토, 꼼꼼한 검증 질문에는 Opus/Sol을 쓰며, DeepSeek에도 검증 작업을 맡기고 있음.

요즘은 DeepSeek Flash에 Opus 5.5를 자문·검토자로 붙이는 조합이 정말 좋음. 단일 프로젝트만으로도 200달러짜리 Claude Code 구독 한도를 24시간 안에 소진해서, 매일 계정을 바꿔 가며 쓰는 일이 싫었음. 이제 구독에 API 크레딧 200달러가 포함돼 코딩 에이전트 작업 흐름을 완전히 다시 구성함.

단일 프로젝트로 200달러짜리 Claude Code 구독 한도를 24시간 안에 어떻게 소진하나요?

비슷한 상황이라 어떤 작업 흐름으로 정착했는지 궁금함. Opus가 계획을 세우고, 깊은 사고가 필요할 때 호출할 수 있게 하면서 최종 검토도 맡기는 구성인가요?

일주일쯤 전 “업계는 왜 DeepSeek 4.1 Flash에 열광하지 않는가?”라는 글을 봤음. 중국 모델에 오래 관심은 있었지만 초기 Qwen 외에는 써 보지 않았고, 평소에는 Luna를 쓰다가 필요하면 Terra나 Sol로 올렸음. 6 버전의 출력은 너무 이해하기 어려워 모두 5.6을 사용함. OpenRouter에 남아 있던 95달러로 DeepSeek Flash 4.1을 시험해 보니 이제 그 글을 쓴 마음을 이해할 것 같음.
여러 차례 작업 흐름을 다듬은 끝에, 먼저 Luna에 계획용 프롬프트를 주고 구체적인 질문으로 내 아이디어를 끌어내도록 함. 전체 구상이 잡히면 Sol에 검토를 요청하고, 지적받은 부분을 Luna가 다시 질문함. Sol이 구현 준비가 됐다고 할 때까지 반복함.
이후 지정한 디렉터리에 상세 구현 계획인 PLAN.md, 구현 단계용 PHASES.md, 설계 결정 기록인 DECISIONS.md, 추가만 가능한 구현 일지 DIARY.md를 생성함. 뒤의 세 파일은 Luna가 용도를 설명하는 머리말만 넣고 실제 내용은 구현 에이전트가 작성함. 새 Pi 세션에서 DeepSeek 4.1 Flash로 전환한 뒤 이 디렉터리를 가리키면 빠르게 구현을 진행함.
지난주에는 이 방식으로 C64 데모의 캡처·분석·디컴파일 파이프라인을 만듦. VICE의 추적 로그를 Clojure로 받아 최적화된 바이너리 형식으로 저장하고, VIC·SID·CIA·메모리에 무엇을 언제 썼는지 래스터 라인과 사이클 단위로 분석함. 쓰기 패턴에 따라 압축 해제·로더·화면 효과·음악 구간을 분리한 뒤, 일반 ASM과 메모리 내부 표현으로 왕복 변환할 수 있는 S식 문법으로 디컴파일함. 이제 에이전트가 데모 효과의 세밀한 타이밍까지 설명할 수 있음. 첫 시험으로 Fairlight의 유명 인트로를 클린룸 방식으로 재구현하도록 했고, 음악 루틴과 데이터까지 S식 어셈블리로 이틀 만에 완성함. 이 과정에서 파이프라인도 개선했으며, 마지막으로 어셈블러·링커·패키저를 만들어 PRG 생성과 VICE 실행까지 연결함.
또 C와 비슷한 DSP 언어의 S식 표현을 JVM·JS·WASM에서 실행할 DSP 커널로 컴파일하는 컴파일러를 만듦. 약 600개 테스트로 세 대상의 동작을 Clojure 참조 인터프리터와 대조함. i32·f32·f64, 배열·구조체·일반적인 제어 흐름과 발진기·필터·LFO·딜레이·코러스 등을 지원함. 완성되면 Clojure/Script로 Synth1·Surge XT·Vital 같은 신시사이저를 만들고, 브라우저에서 JS나 WASM으로 DSP 커널을 컴파일해 AudioWorklets로 구동할 수 있게 됨.
DeepSeek는 명확한 지시만 있으면 단계를 거듭하며 계속 결과물을 냄. 계획 과정이 이를 대부분 해결하지만, 가끔 적절한 순간에 방향을 잡아 주면 효과가 큼. Clojure의 REPL도 강력함. 지금 보는 결과는 PG의 LISP 글인 「Beating the averages」를 실감하게 해 줌.
핵심은 에이전트에 start_jvm과 clojure_eval 두 도구만 주는 것임. HTTP 서버 시작, ClojureScript 컴파일, 의존성 추가, C64 데모 캡처, spel을 통한 Playwright 실행 등은 가벼운 Clojure 네임스페이스의 API로 구현함. 상위 네임스페이스와 함수에는 문서 문자열을 넣고, 실제 구현은 하위 네임스페이스에 두어 얇게 유지함. AGENTS.md에서 이 API 네임스페이스들을 안내하면 최소한의 문맥으로 기능을 발견할 수 있음. 모든 작업을 clojure_eval로 수행하니 호출과 결과 확인이 매우 빨라 에이전트의 속도와 잘 맞음.

조건이 완전히 같지는 않지만, 200개 넘는 파일이 바뀐 C++ 게임 엔진 코드를 네 에이전트에 검토시켜 봄.
DeepSeek API의 deepseek v4.1 flash는 20분 동안 유효한 P1 하나와 관련 없는 P2 하나를 찾음. TP2 DGX Sparks에서 실행한 glm 5.3 flash NVFP4는 1시간 5분 동안 P3 문서 문제 하나를 찾음. gpt 5.6 sol은 5분 30초 만에 유효한 P1·P2를 하나씩 찾았고, gpt 6.1 sol은 4분 30초 만에 유효한 P1 두 개와 P2 하나를 찾음. 네 모델이 발견한 항목은 서로 겹치지 않았음.
발견 사항을 모아 DeepSeek와 gpt 6.1 sol에 수정 계획도 요청함. 테스트에서 원소 191개가 기존 버퍼 128개를 넘친 사례에서, Sol은 여유를 두고 256으로 늘리려 했지만 DeepSeek는 테스트를 통과하도록 정확히 191로 맞추려 함.
DeepSeek의 토큰 생성 속도는 인상적이고 계속 일하고 있다는 느낌을 줌. 하지만 실제 검토 시간은 약 4배였고, GPT 6.1 Sol보다 적게 발견했으며 수정 계획도 못했음. 토큰 수는 비교하지 못했음. 10점 만점이라면 DeepSeek는 6.5점, 6.1 Sol은 7.5~8점 정도로 평가하겠음.

내장 웹 검색 API 가격이 OpenAI의 10분의 1임. 별도 API로도 출시하면 좋겠음.

시험해 보니 검색 품질이 들쭉날쭉함. Microsoft 제품 검색에서는 공식 소개 페이지를 못 찾았고, 잘 알려지지 않은 오픈소스 패키지는 Debian 저장소가 상위에 나왔지만 홈페이지도 상위 10개 안에는 들어갔음.
그래도 자체 검색을 만든다는 점은 반가움. 요즘 검색 서비스를 직접 만드는 곳이 많아지는 게 좋음.

이 모델과 아직 완전히 공개되지는 않은 Kimi K2.8을 주력 코딩 모델로 쓰는데, 비용 효율이 매우 좋음. 특히 DeepSeek는 Svelte 작업을 정말 잘함.
현재는 각각 deepseek-harness와 kimi-code에서 사용 중인데, opencode 같은 도구에서는 어떨지 궁금함.