DeepSeek-v4.1-Flash-1017

DeepSeek-v4.1-Flash-1017

huggingface.co ▲ 693 댓글 580 theykk

요약

딥시크가 점수는 올리고 출력과 작업 시간은 줄인 DeepSeek-v4.1-Flash-1017을 공개했습니다.

중국 AI 기업 딥시크가 10월 17일 기존 V4.1-Flash를 손본 업데이트를 웹, 앱, API에 내놓았습니다. 매개변수 7,630억 개 규모의 가중치도 MIT 라이선스로 Hugging Face와 ModelScope에 올렸고, 권장 문맥 길이는 100만 토큰입니다.

왜 중요한가

  • 딥시크는 점수가 오르면서 출력이 짧아져 작업당 비용도 줄었다며 성능과 비용을 함께 개선했다고 내세웁니다.
  • 일부 코딩·에이전트 벤치마크에서 Opus 5와 GPT-5.6 Sol을 앞선 모델을 누구나 내려받아 직접 돌릴 수 있습니다.

핵심 내용

  • 이전 V4.1-Flash보다 Terminal-Bench 4.0은 31.2에서 42.3으로, ProgramBench는 20.3에서 29.1로 올랐습니다.
  • DeepSWE v1.1(77.0)과 Apex Bench v1.1(72.1)은 표의 경쟁 모델보다 높았지만, HLE 등 여러 항목은 Opus 5에 뒤졌습니다.
  • 게임이나 3D 모델 같은 프로젝트를 통째로 만들도록 강화학습(보상으로 행동을 다듬는 학습)과 자기 피드백으로 훈련했다고 밝혔습니다.
  • 이미지와 텍스트를 함께 받으며, 대화 형식은 Jinja 템플릿 대신 함께 제공하는 파이썬 코드로 만들어야 합니다.
  • 자체 검색 엔진 기반 Search·Fetch API도 정식 출시해 1,000회 호출당 0.75달러를 받되, 10월 31일까지는 일부 도구에서 무료입니다.

HN 반응

  • 벤치마크는 최상위 모델에 못 미쳐도 빠른 응답, 공개된 사고 과정, 보안 작업이 막히지 않는 점 덕에 체감이 낫다는 의견이 많았습니다.
  • 개발자가 실제로 쓸 법한 코드를 내놓는다는 호평과 함께, AI가 쓴 코드가 쌓일수록 엉킨다는 우려로 토론이 번졌습니다.

댓글

30개 표시 · 전체 580개
  1. OsrsNeedsf2P HN

    벤치마크로 보면 DS가 Sol이나 Gemini보다 낫지는 않습니다. 그런데 이것들을 한동안 다 써 보니, 왜들 DS가 체감상 훨씬 좋다고 하는지 이해가 가기 시작했습니다.

    첫째는 제공업체가 내주는 tok/s와 TTFT입니다. 딥시크는 꽤 좋은 품질로 일을 쏜살같이 해치우기 때문에, 에이전트가 끝나기를 기다릴 일이 없습니다.

    둘째는 개방성입니다. CoT를 볼 수 있고, 사이버 보안 검토 때문에 느닷없이 차단당하는 일도 없습니다. 멈춘 건지, 갑자기 실패하는 건 아닌지 걱정할 필요가 없습니다. 훌륭한 가성비까지 더하면.. 제 다음 구독은 아마 Z.ai가 될 것 같습니다.

  2. Philip-J-Fry HN

    저한테는 너무 똑똑하게 굴려고 하지 않는다는 점에서 더 좋게 느껴집니다. 뭔가를 시키면 개발자가 실제로 쓸 법한 코드를 내놓습니다. 덕분에 제가 머릿속으로 하는 것처럼 소프트웨어를 층층이 쌓아 갈 수 있고, 추상화를 어디에 둘지도 계속 제가 쥐고 있을 수 있습니다.

    최전선 LLM이 있으면 이런 건 전혀 필요 없다고 말하는 사람들도 있을 겁니다. 하지만 기존 소프트웨어를 확장하거나 이미 있는 생태계에 맞는 소프트웨어를 짤 때는 여전히 안내를 많이 해 줘야 합니다. 그리고 제가 보고 나서 되돌린 코드가 컨텍스트 윈도우에 가득 차 있지 않은 편이 낫습니다.

  3. nfw2 HN

    LLM은 복잡하고 서로 충돌하는 요구를 다루는 데 그리 능하지 않은 것 같습니다. 특히 티켓 하나, 또 하나씩 조금씩 늘어나는 경우에 그렇습니다. (공정하게 말하면 사람도 이걸 못하는 경우가 많습니다.)

    제 가설은 LLM이 만든 코드베이스의 엉망진창이 거의 기하급수적으로 커진다는 것입니다. 편법이나 어설픈 추상화가 하나 생길 때마다 프로젝트 전체의 일관성이 조금씩 깎여 나가고, 다음 기능을 만들기가 더 어려워집니다. 하지만 더 중요한 점은, 대단한 능력에도 불구하고 확률 기계인 LLM에게 이 코드의 품질이 낮다는 것을 보여 주게 된다는 것입니다. 그러면 LLM은 품질 낮은 편법을 더 많이 만들어 냅니다.

    그러다 결국 매듭 위에 매듭이 쌓여서, LLM이 자기가 짠 코드에 너무 혼란스러워하는 지경이 되면 직접 풀어야 합니다. 모델이 좋아지면서 이 문제도 나아지는 것 같습니다. 이런 일을 겪는 경우가 점점 줄고 있고, 그래도 득이 훨씬 크다는 점은 여전합니다.

    하지만 저는 Fable 5.1이 채팅 컨텍스트마다 50만 토큰어치의 맥 빠지는 쓰레기를 채워 넣는 사람 손에서 완전히 뇌엽절제를 당한 것처럼 되는 것을 본 적이 있고, 코딩에서라고 그러지 말란 법이 없다고 생각합니다. LLM이 바보를 아주 잘 흉내 낼 수 있다는 이 일반적인 문제가 조만간 해결될지는 잘 모르겠습니다.

  4. jamesbfb HN

    최전선 LLM이 있으면 이런 건 전혀 필요 없다고 말하는 사람들도 있을 겁니다

    정곡을 찌르셨네요. 최전선 모델의 변덕에 따라 개발 방법론이 이리저리 바뀌는 게 요즘 제가 걱정하는 일 중 하나입니다.

  5. trueno HN

    솔직히 저는 별로 걱정되지 않아요. 이건 결국 편법이고, 이 길로 가면 이해하지도 못하고 최전선 모델이 있어야만 손댈 수 있는, 덧붙이기만 하는 테세우스의 배 같은 소프트웨어만 남거든요. 그건 그냥... 갈수록 덧붙이기만 하고 지저분해질 뿐이에요. 지금은 다들 최전선 모델로 얼마나 대단한 걸 만들 수 있나 구경하는 속담 속 전성기쯤이에요. 시간이 지나면 LLM을 제대로 쓰는 사람들 사이에서 예전 설계 철학이 다시 자리 잡고, 계층형 방법론이 왜 중요한지 아는 개발자들과 짝을 이루는 자리도 다시 생길 거라고 봐요... 이 AI라는 게 CEO나 정신 나간 임원들이 생각했던 만능 해결책은 아니었으니까요. 언젠가는 형편없이 설계된 물건의 지원 부담에 질릴 거예요. 저는 "AI는 계속 쓰되, 비싸고 제대로 해내고 싶으니 똑똑한 사람이 써야 한다" 쪽으로 추가 어느 정도 되돌아올 거라고 예상해요. 지금은 많은 회사가 정말 무모하게 굴고 있고, 엉망진창 소프트웨어가 불러올 비용 문제를 아직 제대로 깨닫지도, 체감하지도 못한 것 같아요.

  6. LPisGood HN

    그 "비용 문제"가 그냥 Opus 6.7한테 터진 문제를 고치라고 시키는 게 전부라면요?

  7. state_less HN

    LLM한테 그냥 '그거' 고쳐 달라고 하는 식으로는 숲에서 길을 잃게 됩니다.

    차가 도로를 벗어나 빙글빙글 돌고 있는데, 차량 상태가 점점 보이지 않으니 통제하고 도로로 되돌리기가 갈수록 어려워질 겁니다. 이 자동차와 도로의 비유를 이어 가자면, 앞유리 밖도 제대로 보이지 않게 되고요. 단순하고 닫힌 장난감 문제나 작은 시스템이 아니라면 결국 눈을 가리고 운전하게 됩니다.

    큰 시스템을 만든다는 건 그 시스템을 이해한다는 뜻입니다. 이해하지 못하면 통제력을 잃습니다.

    LLM이 시스템을 이해하도록 도와서 통제력을 어느 정도 되찾게 해 줄 수는 있겠지만, 그러면 "고쳐 줘", "좋게 만들어 줘" 같은 말만 되풀이하는 사람이 아니라 시스템 전문가가 되어 가는 겁니다.

  8. fn-mote HN

    맞아요.

    어떤 면에서는 그게 오늘날의 상황이에요. 숙련된 개발자에게 $$$$를 주고 제대로 하게 하거나, 외주를 줘서 $$만 내는 대신 리뷰 단계를 더 두고, 못 고친 버그와 기술 부채를 잔뜩 떠안거나 둘 중 하나죠.

    그 대신 최전선 모델에게 돈을 내고 정리시키자는 말씀이잖아요. 그게 가능하다면 비용은 숙련된 개발자 정도 수준일 거라고 봐요. 그게 대안이니까요. 최전선 AI 회사들은 그런 식으로 여러분의 일에서 가치를 뽑아 갈 거예요.

  9. hazard HN

    그게 가능하다면 비용은 숙련된 개발자 정도 수준일 거라고 봐요. 그게 대안이니까요

    그런데 이게 맞아떨어지는 길이 두 가지가 있습니다. 최전선 모델 비용이 오르거나, (더 그럴듯하게는) 숙련 개발자 비용이 내리는 경우입니다.

  10. anukin HN

    엔터프라이즈 요금제의 Opus는 결코 싸지 않습니다.

  11. TuringTest HN

    복잡한 시스템에서는 문제가 고치는 속도보다 빠르게 쌓입니다.

  12. huijzer HN

    엉망진창 소프트웨어가 불러올 비용 문제를 아직 제대로 깨닫지도, 체감하지도 못한 것 같아요

    API가 비공개이거나 자동화 시스템이 의존하지 않고 테스트 커버리지가 좋다면, 언제든 리팩터링할 수 있으니 나쁜 코드로도 버틸 수 있다고 생각합니다. 어리석어 보여도 동작하고 (필요하면 나중에 리팩터링, 수정, 개선할 수 있다면) 어리석은 게 아니죠.

  13. swader999 HN

    개발자가 짠 코드에 대해서도 이렇게 말하곤 했어요. 테스트가 있으면 대체로 감수하고 살 수 있다고요.

  14. agile-gift0262 HN

    제 생각에 근본 원리와 "충돌"은 여전히 그대로인데, 많은 사람이 과열된 분위기와 속도감에 취해 잊고 있는 것 같습니다. 업계는 천천히 그것들을 다시 발견하게 될 겁니다.

  15. Abishek_Muthian HN

    저는 최전선 모델을 쓸 때도 부모 댓글이 말한 것처럼 계층형 개발 기법을 쓰고 있습니다. Zed로 에이전트를 한 번에 하나씩만 돌리고요.

  16. brookst HN

    저는 기계적인 기준(DRY, 캡슐화 등)은 테스트 묶음으로 강제하고, 구조는 아키텍처 문서로 잡고, 새 작업은 이 둘에 비춰 리뷰합니다. 눈에 띄는 드리프트는 보지 못했습니다.

  17. ygjb HN

    네, 이게 저를 답답하게 하는 점이에요. 바이브 코딩이나 즉흥적인 프롬프트는 결과가 천차만별이거든요. 명세와 기대치에서 출발하면 늘 검토할 만하고 테스트도 잘 된 코드를 얻어요. 전체 테스트를 자주 돌리면 느려지고 토큰도 더 들긴 하죠. 그래도 5시간 또는 주간 한도에 걸리면 그냥 소매를 걷고 모델 없이 일을 시작해요. 코드가 제가 기대한 대로 짜여 있고, 사람인 제 작업 흐름과 속도에 맞게 설계되어 있으니까요.

  18. foltik HN

    그렇다면 직접 그리 꼼꼼히 들여다보고 있지는 않으신 모양이네요.

  19. mapontosevenths HN

    최전선 모델은 마지막으로 언제 써 보셨어요? 혹시 작년 모델(이나 미국산 오픈 웨이트 모델)만 쓰도록 강제하는 곳에서 일하시는 건 아니고요?

  20. foltik HN

    저는 시스템 프로그래밍에 매일 씁니다. 하나의 해법은 내놓지만, 여러 면에서 최적 해법과 몇 자릿수씩 차이가 나는 경우가 많습니다. 그래도 꽤 쓸모 있지만, 어떤 문제에서는 그 정도로는 부족합니다.

    더 최적에 가까운 해법에 도달하려면 사소한 결정 하나하나마다 사람이 상당히 이끌어 줘야 합니다. 초기 모델이 기본기에서 손을 잡아 줘야 했던 것과 똑같은 일이 더 세밀한 부분에서 되풀이되는 셈입니다. 사람 전문가가 바깥에서 "유레카의 순간"을 넣어 줘야 합니다.

    그리고 제가 써 본 어떤 피드백 루프도 이런 세밀한 부분에 대한 이해를 만들어 내지는 못했습니다. 제가 보기에 그런 건 가중치에 아예 담겨 있지 않습니다.

    소프트웨어 공학의 기본기를 모델링하는 건 쉬웠습니다. 테스트를 통과하는 코드를 짜는 것 같은 일은 RL로 하기 쉬우니까요. 하지만 RL로 하기 쉽지 않은 것들은 증류해 낼 사람이 만든 토큰을 사실상 다 써 버렸습니다.

    일반화에서 어떤 돌파구가 없다면, 기존 학습 말뭉치를 다시 자기 자신에게 먹이는 방식으로 소프트웨어 공학의 세밀한 부분까지 모델링할 수 있을 거라는 확신이 들지 않습니다. 쓰레기가 들어가면 쓰레기가 나옵니다.

  21. jacquesm HN

    제 경험도 그렇습니다. 다만 공정하게 말하면 디버깅은 정말 잘할 수 있습니다.

  22. rjzzleep HN

    저한테는 너무 똑똑하게 굴려고 하지 않는다는 점에서 더 좋게 느껴집니다. 뭔가를 시키면 개발자가 실제로 쓸 법한 코드를 내놓습니다. 덕분에 제가 머릿속으로 하는 것처럼 소프트웨어를 층층이 쌓아 갈 수 있고, 추상화를 어디에 둘지도 계속 제가 쥐고 있을 수 있습니다.

    맞아요! 저만 그런 게 아니었네요. 얼마나 똑똑하게 굴려고 하느냐로 보면 오픈AI가 맨 위고 그다음이 Claude예요. 실제로 Sol을 써 보니 많은 작업에서 제가 뭘 원하는지 모른다고 생각했는지 자꾸 다른 걸 하려고 하더라고요. 올바른 방향으로 다시 슬쩍 밀어 줘도 소용없었고요.

    모델은 결국 만든 쪽의 문화를 그대로 닮나 봐요.

  23. UncleOxidant HN

    제 다음 구독은 아마 Z.ai가 될 것 같습니다

    잠깐만요... 세 문단 내내 DS를 칭찬해 놓고, 다음엔 GLM을 만드는 곳에 구독한다고요? ?

    (저도 동의하는 편이긴 해요. 다만 저는 DS 4.1 flash보다 GLM-5.3-flash를 더 선호하는 쪽이에요.)

  24. Matl HN

    제가 알기로 Z.ai가 DS 접근도 제공하니까 그 얘기인 것 같은데요. DS 자체 플랫폼보다 GLM까지 같이 쓸 수 있어서 가치가 더 크다고 느끼는 걸 수도 있고요. 잘은 모르겠습니다.

  25. saratogacx HN

    다른 모델을 제공하는 건 z.ai 구독은 아닌 것 같습니다(적어도 제 구독에는 안 보입니다). Qwen 토큰 플랜에는 GLM과 딥시크를 포함해 중국 모델이 많이 들어 있어서, z.ai 구독이 끝나갈 때쯤엔 아마 그걸 쓰게 될 것 같습니다.

  26. nfw2 HN

    개방성 때문에 z.ai를 쓰겠다는 얘기였던 게 아닐까요?

  27. jeremyjh HN

    하지만 작업 스타일 면에서는 설명된 것과 전혀 다릅니다. 훨씬 더 Claude에 가깝습니다.

  28. nfw2 HN

    빠르게 읽으면서 저는 열린 CoT가 그 댓글에서 가장 중요한 부분이라고 생각했어요. 아마 저한테 가장 유용할 것 같아서일 거예요.

    추론 과정을 더 효과적으로 디버깅할 수 있으면, 나중에 더 강한 모델에서 돌리더라도 커스텀 하니스를 만들 때 프롬프트 문제를 찾는 데 유용해 보여요.

  29. igetspam HN

    동의해요.

    더 나을 필요는 없고, 거의 같기만 하면 돼요. 저는 요즘 취약점 작업을 많이 하고 있는데(봇이 우리 코드의 익스플로잇을 찾아내기 전에 앞서가려는 거죠), 최전선 모델은 교회 댄스파티의 감독관 같아요. 너무 가까이 가면 자를 들고 나타나서 안전 간격을 지키게 하거든요. 딥시크, GLM, Qwen을 쓰면 제약 없이 거의 비슷한 결과를 얻었어요. 최전선 모델도 여전히 쓰지만, 회사 환경 밖에서라면 돈은 10분의 1만 쓰고 같은 결과를 얻으면서 AI를 속여 가며 일하게 만들 필요도 없으니 만족해요.

  30. proxyscore HN

    네, 저는 claude code로 DS를 돌릴 수 있게 되기 전부터 이렇게 해 왔는데, 품질이 거의 같고 claude가 모자와 신발까지 먹어 가며 DS의 교정을 받아야 했던 경우도 수두룩했어요.

    미국 사람들은 현실 감각이 정말 왜곡돼 있고, 자기 생각을 가진 사람은 드물어요. 인플루언서 소음에 귀를 기울이다가, 스스로 생각하는 사람들이 DS 같은 것의 품질을 알아보고 나면 그제야 그 말을 따라 할 거예요.

Hacker News에서 보기 ↗