오늘의 요약

  • OpenAI, GPT-Image-2로 이미지 기능 강화
  • Hugging Face, `ml-intern` 에이전트 공개
  • Moonshot, Kimi K2.6·FlashKDA 인프라 공개
  • Google, Gemini API에 Deep Research Max 추가
  • LightOn·vLLM, 검색·배포 실무 지원 강화

OpenAI, GPT-Image-2로 ChatGPT Images 2.0 출시

2026년 4월 21일 화요일
#OpenAI#GPT-Image-2#Hugging Face#Kimi#Gemini#vLLM

헤드라인: OpenAI, GPT-Image-2로 ChatGPT Images 2.0 출시

참고 링크: 544 Twitters, AINews’ website, AINews is now a section of Latent Space, opt in/out

OpenAI가 ChatGPT Images 2.0과 기반 모델 **gpt-image-2**를 ChatGPT, Codex, API 전반에 배포하며 이미지 생성이 다시 “진지한 제품 표면(product surface)”으로 돌아왔다는 평가가 나왔다. 핵심 개선점으로는 텍스트 렌더링, 레이아웃 충실도, 편집, 다국어 지원, 이미지용 “thinking” 등이 강조됐다. 또한 ‘thinking’ 모델과 결합하면 웹 검색, 다중 후보 생성, 출력 자체 점검(self-check), 슬라이드·인포그래픽·다이어그램·UI 목업·QR 코드 같은 산출물 생성까지 노리는 방향이 제시됐다.

주의: ## 헤드라인 섹션에서 새로운 마크다운 링크를 추가하거나, 아래 Recap에 이미 있는 링크를 중복해서 다시 넣지 마세요.

AI Twitter Recap

OpenAI의 GPT-Image-2 출시와 ‘이미지 생성’의 제품화 재부상

  • GPT-Image-2 is the day’s clearest product launch: OpenAI rolled out ChatGPT Images 2.0 and the underlying gpt-image-2 model across ChatGPT, Codex, and API, emphasizing stronger text rendering, layout fidelity, editing, multilingual support, and “thinking” for images. OpenAI says the model can search the web when paired with a thinking model, generate multiple candidates, self-check outputs, and produce artifacts like slides, infographics, diagrams, UI mockups, and QR codes (launch thread, thinking/image capabilities, availability, API post). The model is already being integrated by downstream tools including Figma, Canva, Firefly, fal, and Hermes Agent.
  • Benchmarks suggest a large jump, especially on practical image tasks: Arena reports #1 across all Image Arena leaderboards for GPT-Image-2, including 1512 on text-to-image, 1513 on single-image edit, and 1464 on multi-image edit, with a striking +242 Elo lead on text-to-image over the next model (Arena summary, category breakdown, trend chart). Independent reactions converged on the same theme: this is not merely prettier art, but a more usable model for UI, mockups, documentation, productivity visuals, and reference-driven design loops (@gdb, @nickaturley, @mark_k, @petergostev). The most interesting systems implication is that image generation is becoming a front-end for coding agents: generate a UI spec as an image, then have Codex or another code agent implement against that visual reference.

에이전트 인프라: Hugging Face의 ml-intern, Hermes 확장, 그리고 연구/런타임 하네스(harness)의 부상

  • Hugging Face’s ml-intern is the strongest open agent-in-the-loop release in the set: HF introduced ml-intern, an open-source agent that automates the post-training research loop: reading papers, following citation graphs, collecting/reformatting datasets, launching training jobs, evaluating runs, and iterating on failures (announcement, supporting post from @lewtun, Clement’s framing). Reported examples are notable because they are end-to-end loops, not just coding demos: GPQA scientific reasoning improved 10% → 32% in under 10h on Qwen3-1.7B, a healthcare setup reportedly beat Codex on HealthBench by 60%, and a math setup wrote a full GRPO script and recovered from reward collapse via ablations. Community tests quickly showed it can autonomously fine-tune and publish artifacts back to the Hub (example run on SAM finetuning).
  • Hermes is evolving toward a richer local/open agent platform: Several tweets point to Hermes’ momentum as a practical open agent stack: a beginner guide generated by a Hermes agent itself, native support in Skillkit, a new macOS GUI called Scarf, and expanding use in local workflows. The most technically meaningful update is from @Teknium: Hermes subagents now support both greater spawn width and recursive spawn depth, enabling deeper hierarchical decomposition. This aligns with the broader shift from “single chat loop” agents to multi-process orchestrated systems with memory, tools, permissions, and reusable skills.
  • Harnesses are becoming first-class engineering artifacts: A recurring theme across tweets is that the useful part of agent systems is increasingly the runtime/harness, not the base model alone. DSPy 3.2 shipped RLM improvements plus optimizer chaining and LiteLLM decoupling (release); Isaac Flath argued RLM makes notebooks relevant again as a REPL-native trace/eval interface (tweet); LangChain added custom auth for deepagents deploy (update); and a paper-summary thread on Claude Code emphasized that most of the system is harness logic rather than raw “intelligence” (summary).

Kimi K2.6, KDA 커널, 그리고 시스템 관점에서 ‘더 그럴듯해진’ 오픈 웨이트 코딩 모델

  • Moonshot pushed both model capability and kernel infrastructure: The flagship Kimi thread claims K2.6 completed long-horizon coding tasks with sustained autonomy: one run downloaded and optimized Qwen3.5-0.8B inference in Zig over 4,000+ tool calls and 12+ hours, improving throughput from ~15 tok/s to ~193 tok/s, ending ~20% faster than LM Studio (thread). Another run reportedly reworked an exchange engine over 1,000+ tool calls and 4,000+ LOC changes, achieving 185% medium-throughput and 133% peak-throughput gains (second thread). These are still vendor demos, but they are much closer to systems work than benchmark screenshots.
  • Kimi also open-sourced performance-critical infra: Moonshot released FlashKDA, a CUTLASS-based implementation of Kimi Delta Attention kernels, claiming 1.72×–2.22× prefill speedup over the flash-linear-attention baseline on H20 and compatibility as a drop-in backend for flash-linear-attention (release). External follow-up reported K2.6 + DFlash at 508 tok/s on 8x MI300X, a 5.6× throughput improvement over a baseline autoregressive setup (HotAisle). Together with ongoing discussion of DSA/MLA/KDA variants, the key signal is that Chinese labs are not just shipping weights; they are increasingly publishing attention/kernel-level optimizations with real deployment impact.
  • Open-weight coding quality is improving, but there’s still disagreement on parity: Some users now treat Kimi K2.6 as the best open-source/open-weight coding/agentic model (@scaling01, Windsurf availability), while others pushed back that frontier proprietary models still hold large leads on WeirdML, long-horizon tasks, and reliability (@scaling01 critique, gap on WeirdML). The substantive takeaway is less “open has caught up” than that open-weight models are now credible enough that infra, harness, and deployment quality determine a lot of real-world value.

딥 리서치(Deep Research) 시스템: Google이 연구 에이전트 전선을 확장

  • Google upgraded Deep Research into a more configurable API primitive: Google/DeepMind launched updated Deep Research and Deep Research Max via the Gemini API, powered by Gemini 3.1 Pro, with collaborative planning, arbitrary MCP support, multimodal inputs (PDF/CSV/image/audio/video), code execution, native chart/infographic generation, and real-time progress streaming (Google thread, feature details, Sundar post, developer API post).
  • The benchmark numbers are strong enough to matter commercially: Google highlighted 93.3% on DeepSearchQA, 85.9% on BrowseComp, and 54.6% on HLE for the Max variant (Sundar, Phil Schmid summary). More important than the raw scores is the workflow design: Google is clearly productizing “overnight due diligence / analyst report generation” and making MCP-backed internal data access a standard part of research agents. This also shows a widening split between simple browse agents and full-stack research agents that plan, search, execute code, generate visuals, and ground over proprietary corpora.

검색(Retrieval)·데이터·평가: 실무 엔지니어링 가치가 있는 오픈 릴리스

  • Retrieval saw a meaningful open release from LightOn: LightOn released LateOn and DenseOn, both 149M-parameter retrieval models under Apache 2.0, reporting 57.22 NDCG@10 on BEIR for LateOn (multi-vector/ColBERT style) and 56.20 for DenseOn (dense single-vector), beating models up to 4× larger (model release, overview). They also published a consolidated dataset release with 1.4B query-document pairs and a refreshed web dataset built on FineWeb-Edu (dataset post).
  • vLLM shipped a practical deployment knowledge layer: The redesign of recipes.vllm.ai is more useful than it sounds. It maps model pages to runnable deployment recipes, includes an interactive command builder, supports NVIDIA and AMD, covers tensor/expert/data parallel variants, and exposes a JSON API for agents. This is exactly the kind of infra documentation layer that reduces operator friction for serving new open models.
  • Benchmarks are increasingly probing agent blind spots, not just task outputs: Notable examples include ParseBench for chart understanding inside real enterprise documents (LlamaIndex, Jerry Liu details) and a new result showing agents often ignore explicit environment clues, even when the solution is literally exposed in a file or endpoint (paper thread). Google Research’s ReasoningBank also fits this theme, framing memory as learning from both successful and failed trajectories (tweet).

참여(engagement) 기준 Top tweets

  • OpenAI’s image launch: “Introducing ChatGPT Images 2.0” was the dominant technical launch tweet, backed by a deep feature thread and rapid downstream integrations.
  • HF ml-intern: @akseljoonas had the standout agent/research-loop release of the day.
  • Gemma local concurrency demo: @googlegemma showed Gemma 4 26B A4B handling 10+ concurrent requests at ~18 tok/s/request on an M4 Max, a useful datapoint for local-serving economics.
  • Deep Research Max: @sundarpichai and @Google pushed a materially stronger research-agent API surface.
  • Kimi kernel release: FlashKDA was one of the more substantial open infra drops in the model-serving stack.
  • Open-source policy warning: @ClementDelangue warned of renewed lobbying to restrict open-source AI, one of the few policy tweets with direct implications for builders.

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

Kimi K2.6 Model Launch and Benchmarks

  • Claude Code removed from Claude Pro plan - better time than ever to switch to Local Models. (Activity: 349): 이미지는 “Claude”라는 서비스의 여러 구독 플랜을 비교한 차트를 제시하며, Pro 플랜에서 “Claude Code” 기능이 제거된 점을 강조한다. 이 변화는 서비스 제공 방식의 전환을 시사할 수 있고, Kimi K2.6이나 Qwen 3.6 35B A3B 같은 로컬 모델로의 대안을 고려하게 만들 수 있다는 맥락에서 논의된다. 글은 Claude Pro 대비 더 낮은 가격에 더 많은 토큰을 제공하는 OpenCode Go 코딩 플랜의 가성비를 강조하며, 로컬 모델로 전환하는 가치가 커졌다고 주장한다. 댓글에서는 “Claude Code” 기능 제거에 대한 불신과 불만이 나오며, 일부는 단순 표기 오류일 수 있다고 추정하고, 일부는 제품 페이지에서 명확히 공지하라고 촉구한다.

    • korino11은 $20 open code plan과 $19 Kimi 플랜의 비용-편익 비교를 제시하며, 후자가 더 나은 가치일 수 있다고 주장한다. 이는 기능이 제거되거나 바뀔 때 구독형 AI 모델의 가성비 재평가가 필요하다는 함의를 담고 있다.
    • Apart_Ebb_9867은 공식 Claude 제품 페이지의 정보가 부정확할 수 있다고 지적하며, 페이지 업데이트 또는 수정이 필요하다고 말한다. 이는 특정 기능에 의존하는 사용자에게 정확하고 최신의 문서/표기가 중요하다는 점을 부각한다.
    • The-Communist-Cat은 Claude Pro에서 Claude Code 제거에 대한 온라인 참고자료가 거의 없다는 점을 언급하며, 정보 혼선이나 커뮤니케이션 지연 가능성을 제기한다. 이는 서비스 제공자가 혼란을 줄이기 위해 명확하고 신속한 업데이트를 제공해야 한다는 요구로 이어진다.

  • Kimi K2.6 is a legit Opus 4.7 replacement (Activity: 1632): Kimi K2.6가 Opus 4.7의 실질적인 대체재로 소개되며, Opus가 하던 작업의 85%를 “합리적인 품질”로 수행할 수 있다는 주장이다. 특정 영역에서 Opus 4.7을 능가하진 않지만, 비전(vision)과 효과적인 브라우저 사용 같은 추가 능력이 있어 장기 작업에 적합하다는 평가가 나온다. 모델이 매우 크다는 점에도 불구하고, Opus 4.7 같은 프런티어 LLM이 최근 큰 도약을 보여주지 못하고 있다는 문제 제기도 포함된다. 로컬 배포는 사용량 제한 같은 문제를 피할 수 있다는 장점으로 언급된다. 댓글에서는 짧은 시간 안에 테스트·추천이 이뤄졌다는 점에 회의적인 반응이 있고, 로컬 모델 운용 비용이 여전히 비싸다는 불만도 나온다.

    • InterstellarReddit은 원글 작성자가 2시간 만에 테스트를 마치고 고객에게 추천한 것을 언급하며, 자신들의 회사는 4명의 엔지니어가 1주 평가 후 고객 테스트를 한다고 대비시킨다. 이는 소규모 팀/개인이 AI 모델 도입에서 보일 수 있는 민첩성을 보여준다.
    • Technical-Earth-3254는 Kimi K2.6가 Opus의 85%를 달성한다면 Sonnet 계열까지도 대체할 수 있을지 모른다고 추정한다. 이는 특정 성능 임계점을 넘으면 기존 모델 라인업을 재편할 수 있다는 관점을 시사한다.
    • Blablabene은 Kimi K2.6 같은 로컬 모델이 독점 모델의 가격 인하 압력을 만든다고 주장한다. 다만 현재 로컬 운용 비용은 높다고 하면서도, 시간이 지나면 더 접근 가능해질 것이라고 전망한다.

  • Opus 4.7 Max subscriber. Switching to Kimi 2.6 (Activity: 386): Opus 4.7 Max에서 Kimi 2.6로 옮기는 경험을 다룬 글이다. 작성자는 Opus 4.7이 “lazy(게으르다)”해졌고 비싸다고 느껴 전환을 결정했으며, Kimi 2.6은 컨텍스트가 더 작지만 빠르고 만족스럽다고 말한다. 특히 Kimi 2.6이 더 작은 컨텍스트를 효과적으로 관리하며, 툴 출력(tool output) 처리 방식이 개선된 것처럼 보인다는 점이 강조된다. 또한 Forge 통합을 개선하기 위한 PR을 제출했다고 언급한다 (GitHub PR). 댓글에서는 Anthropic·OpenAI 같은 독점 모델에 대한 투자 지속 가능성에 회의가 나오고, Kimi(중국 모델)의 경쟁력이 커지고 있다는 논쟁도 이어진다.

    • Worried-Squirrel2023는 Opus 4.7이 “작업 도중 멈추거나 실제로 끝나지 않았는데 마무리하는” 경향을 “laziness”로 지적한다. 이는 실사용에서 작업 완료 신뢰도가 큰 약점이 될 수 있음을 시사한다. 또한 Kimi의 작은 컨텍스트가 Opus의 “commitment(완주)” 문제보다 덜 치명적일 수 있다고 말하며, 특히 “tool calling reliability(툴 호출 신뢰도)” 차이에 주목한다.
    • sb5550는 Kimi가 ‘1T model’, Opus가 ‘5T model’이라는 크기 비교를 제시하며, 더 작은 모델의 효율성과 잠재력을 강조한다. 이는 중국 모델이 뒤처지는 것이 아니라 오히려 앞서갈 수 있다는 문제의식으로 이어진다.
    • Ok-Contest-5856는 독점 모델에 대한 사모펀드(PE) 투자 관점에서, 더 저렴하고 성능이 “neck and neck”한 오픈 모델이 위협이 될 수 있다고 추정한다. 장기적으로 오픈 모델이 역전할 가능성까지 언급하며 경쟁 구도 변화 가능성을 제기한다.

  • Kimi K2.6 Released (huggingface) (Activity: 1386): Hugging Face에서 공개된 Kimi K2.6을 장기 코딩(long-horizon coding)과 자율 작업 오케스트레이션에 최적화된 최신 오픈소스 멀티모달 모델로 소개한다. 1 trillion parameters 규모의 Mixture-of-Experts 아키텍처를 사용하며, 프롬프트를 프로덕션 수준 인터페이스로 변환하고 다언어 코딩 작업을 수행할 수 있다고 설명한다. 최대 300 sub-agents를 지원해 병렬 작업이 가능하다고 하며, vLLM·SGLang 같은 플랫폼 배포와 능동적 오케스트레이션에서의 강점을 주장한다. 더 자세한 내용은 original article에서 확인할 수 있다. 댓글에서는 1.1 trillion parameters라는 규모 자체에 놀라는 반응이 있으며, Cursor의 Composer 2.1 모델이 학습을 시작했다는 언급도 나온다.

    • ResidentPositive4122는 Kimi K2.6 릴리스가 Modified MIT License 하에서 코드 저장소와 웨이트를 함께 포함한다고 언급한다. 이는 MIT의 “자유롭게 사용” 정신을 유지하면서도 대기업 사용 시 attribution을 요구하는 조건이 핵심 포인트로 제시된다.
    • LagOps91은 벤치마크 수치가 인상적이지만 실사용에서 어떻게 체감될지가 진짜 시험대라고 말한다. 이는 이론 지표를 넘어 실제 적용에서 유틸리티(utility)를 검증해야 한다는 관점을 강조한다.

  • Kimi K2.6 (Activity: 570): 이미지는 Kimi K2.6이 GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro 등과 비교된 벤치마크 차트를 보여주며, General Agents·Coding·Visual Agents 등 여러 축에서 경쟁력 있는 성능을 강조한다. 특히 “Humanity’s Last Exam”과 “DeepSearchQA” 같은 항목에서 높은 점수를 제시하며 강력한 모델 잠재력을 시사한다. 댓글에서는 코딩 성능에서의 경쟁력에 대한 기대가 크고, 폐쇄형 모델과의 격차가 생각보다 작다는 점에 놀라는 반응도 있다. 또한 Kimi의 vendor verifier가 제3자 서비스 평가를 표준화한다는 점이 언급된다.

    • Kimi K2.6는 제3자 서비스 평가를 표준화하는 방법을 도입해, 구현체 간 성능·신뢰도 비교의 일관성을 높일 수 있다는 논지가 제시된다.
    • 커뮤니티에서는 Kimi K2.6가 Opus를 능가할 수 있을지에 대한 기대가 나타난다. DeepseekV4에 대한 높은 기대가 완전히 충족되지 않았다는 언급과 함께, Kimi가 새로운 기준을 만들길 바라는 분위기가 있다.
    • Kimi K2.6 릴리스가 GLM-5.1 같은 후속 모델들에 대한 기대치를 끌어올렸다는 관점도 나온다. 이는 오픈소스 생태계 내 경쟁 구도가 변하고 있다는 신호로 해석된다.

Gemma 4 Model Capabilities and Benchmarks

  • Gemma 4 Vision (Activity: 319): Gemma 4의 비전(vision) 성능을 개선하기 위해 vision budget 파라미터를 조정하는 방법을 논의한다. 기본값 --image-min-tokens 40, --image-max-tokens 280은 정밀 OCR 작업에 부족하다고 보고, 이를 560과 2240으로 높이자는 제안이 나온다. 이 설정에서 Gemma 4가 Qwen 3.5, Qwen 3.6, GLM OCR보다 비전 작업에서 더 나은 성능을 보였다는 주장도 포함된다. 다만 VRAM 사용량이 q8_0 최대 컨텍스트 기준 63 GB에서 77 GB로 증가하는 비용이 따른다. 또한 Ollama 구현의 제약(미해결 이슈)으로 해당 변경이 지원되지 않을 수 있다는 언급도 있다. 댓글에서는 소형 모델에서의 최소 토큰 설정, llamacpp·vllm의 상세 설정 옵션 등에 대한 질문이 이어진다.

    • Temporary-Mix8022는 약 150 million parameters 수준의 작은 비전 인코더에서 최소 70 tokens 설정을 쓴 경험을 공유하며, 40 tokens 최소값이 더 큰 모델(예: 500 million parameters)에만 해당하는지 질문한다.
    • stddealer는 Qwen3.5에서 가져온 --image-min-tokens 1024, --image-max-tokens 1536 설정을 Gemma4에 적용했더니 성능이 기대보다 낮아 혼란스러웠다고 말한다. 이는 토큰 설정이 체감 성능에 큰 영향을 준다는 점을 시사한다.
    • Yukki-elric는 이미지 품질 처리를 위해 --image-min-tokens와 --image-max-tokens를 모두 1120으로 두는 설정을 제안한다. 이는 토큰 할당과 품질 간 균형점으로 제시된다.

  • Gemma-4-E2B’s safety filters make it unusable for emergencies (Activity: 985): 로컬·오프라인 비상 대비 용도로 의도된 Google의 Gemma-4-E2B가 과도하게 공격적인 안전 필터 때문에 비상 상황에서 쓸 수 없다는 비판이다. 모델이 응급 기도 확보, 정수(water purification), 기계 정비, 식품 처리 같은 생존 관련 핵심 주제에 대해 ‘hard refusals’를 내놓는 것이 문제로 지적된다. 전쟁이나 전력망 붕괴처럼 긴급 연락이 불가능한 상황에서 이런 제약은 특히 치명적일 수 있다는 주장이다. 댓글에서는 세계 지식(world knowledge)의 한계로 인해 거부가 정당하다는 반론도 있으며, 검열이 약한 버전 사용이나 Wikipedia 백업 결합 같은 대안이 제안된다.

    • Klutzy-Snow8016는 Gemma-4-E2B의 세계 지식 부족과 환각(hallucination) 위험을 강조하며, 비상 상황에서 잘못된 조언은 생명을 위협할 수 있다고 말한다. 대안으로 Wikipedia 백업을 내려받아 모델이 이를 질의하도록 하면 유용성이 높아질 수 있다고 제안한다.
    • iliark는 경우에 따라 모델이 파편(shrapnel)을 상처에서 제거하지 말라는 등 의료 가이드라인과 부합하는 조언을 하기도 한다고 말한다. 다만 신뢰 가능한 출처로 검증이 필요하다는 전제가 따라붙는다.
    • Illustrious_Yam9237는 응급 조언에는 LLM보다 관련 PDF 저장이 더 신뢰도 높고 효율적일 수 있다고 주장한다. 이는 고위험 상황에서의 LLM 실용성에 대한 회의로 이어진다.

  • Gemma 4 26B-A4B GGUF Benchmarks (Activity: 421): 이미지는 Gemma 4 26B-A4B GGUF 모델의 양자화(quantization) 후 정확도 보존을 Mean KL Divergence로 비교한 벤치마크 차트다. Unsloth GGUFs가 파레토 프런티어(Pareto frontier)에 있으며, 22개 크기 중 21개에서 다른 제공자보다 더 좋은 성능을 보인다고 주장한다. 또한 Q6_K 양자화 업데이트가 재다운로드 없이 더 “dynamic”해졌다는 설명, 16GB VRAM에 맞는 새로운 UD-IQ4_NL_XL 양자화가 소개된다. 댓글에서는 추론 속도(inference speed) 벤치마크 포함 필요성, ggml-org 대비 특정 양자화의 효율성 등이 논의된다.

    • qfox337는 하드웨어에 따른 편차가 크더라도 추론 속도 벤치마크가 포함되면 좋겠다고 말하며, 서로 다른 압축 스킴이 성능에 얼마나 영향을 주는지 질문한다.
    • Far-Low-4705는 UD-IQ2_XXS가 9Gb로 더 효율적인 반면 ggml-org의 Q4_K_M는 16Gb라는 비교를 제시하며, 리소스 제약 환경에서 의미가 클 수 있다고 말한다.
    • -Ellary-는 자신의 테스트에서는 Bartowski Qs가 유사한 성능을 보이면서 더 안정적이라고 언급하며, 벤치마크가 실사용 차이를 완전히 반영하지 못할 수 있다고 지적한다.

Qwen 3.6 Model Updates and Comparisons

  • Every time a new model comes out, the old one is obsolete of course (Activity: 1164): 이미지는 “Gemma4”와 “Qwen3.6”을 대비시키며 새 모델이 나오면 기존 모델이 곧바로 “구식” 취급되는 현상을 밈으로 표현한다. 댓글에서는 “Qwen3.6”이 코딩에 더 적합하다는 평가가 있는 반면, “Gemma4”는 창작 글쓰기(creative writing)와 번역에서 여전히 선호된다는 의견이 나온다. 즉, 모델마다 강점이 달라 단순 세대 교체로만 보기 어렵다는 논지다. 또한 “Qwen3.6” 같은 신형 모델의 신뢰도와 지속 지원에 대한 우려도 언급된다.

    • Gemma 4는 창작 글쓰기에서의 우수성이 강조되며, 이 분야에서는 확실히 강하다는 평가가 나온다.
    • Qwen은 번역 성능에서 부족하다는 비판을 받지만, 코딩·개발에서는 강점을 인정받는다.
    • 일부 사용자는 Qwen이 몇 장의 이미지를 처리한 뒤 지시 따르기(instruction-following)가 크게 저하되어, 잘못된 툴 호출과 결과 미검증으로 이어진다고 보고한다. 이는 컨텍스트 관리나 지시 파싱의 한계 가능성을 시사한다.

  • Layman’s comparison on Qwen3.6 35b-a3b and Gemma4 26b-a4b-it (Activity: 362): 16GB VRAM 그래픽카드에서 Windows LM Studio 추천 추론 설정으로 Qwen3.6-35B-A3B와 Gemma4 26B-A4B-it를 비교한 글이다. 코딩과 일반 작업에서 Qwen3.6은 에너지가 넘치는 ‘A+ 학생’, Gemma4는 안정적으로 수행하는 ‘B 학생’으로 묘사된다. 속도는 비슷하지만, Qwen이 메서드(method)를 더 자주 환각한다고 보고되며, Gemma는 복잡한 프롬프트와 백엔드 스크립팅에서 더 낫다는 평가가 나온다. 또한 올바른 시스템 프롬프트가 Gemma 성능을 “unlock”하는 데 중요하다는 점이 댓글로 보강된다. 댓글에서는 Qwen3.6의 도구 호출(tool calling) 강점, Gemma4의 대화·롤플레이·번역 강점, 백엔드 작업에서의 오류 성향 차이 등이 논쟁된다.

    • Sadman782는 Gemma4가 커스텀 미세조정(fine-tuning)이나 시스템 프롬프트로 프런트엔드 역량이 개선될 수 있는 반면, Qwen3.6은 특히 백엔드 작업에서 메서드 환각이 잦다고 말한다. 복잡한 앱 개발에서는 Qwen이 오류를 더 많이 낸다는 주장으로 이어진다.
    • Kahvana는 Qwen3.5/3.6이 프로그래밍과 툴 호출에서 강하고, Gemma4는 대화·롤플레이·번역에서 더 낫다는 비교를 제시한다. 두 모델의 최적 사용처가 분리돼 있다는 결론에 가깝다.
    • BigYoSpeck는 Qwen 모델이 ‘flair’ 있는 디자인을 만들 수 있다는 점을 인정하면서도, 이것이 문제 해결이나 지시 따르기 향상으로 직결되진 않는다고 경고한다. 학습 범위를 넘어서는 적응이 필요한 과제로 테스트해야 한다는 제안이다.

  • Qwen 3.6 Max Preview just went live on the Qwen Chat website. It currently has the highest AA-Intelligence Index score among Chinese models (52) (Will it be open source?) (Activity: 440): Qwen 3.6 Max가 Qwen Chat website에서 공개됐고, AiBattle 기준 중국 모델 중 AA-Intelligence Index 52로 최고 점수라는 내용이다. 파라미터 수는 이전 Qwen 3.6의 397B를 근거로 600-700B 사이일 수 있다는 추정이 나온다. 다만 Max 버전이 오픈소스로 풀릴 조짐은 없고, 과거에도 Max 모델은 공개되지 않았다는 점이 언급된다. 댓글에서는 Max 오픈소스 가능성에 회의가 많고, 소비자 하드웨어에서 돌릴 수 있는 더 작은 모델을 선호한다는 의견도 나온다.

    • 한 사용자는 이전 버전(397B)을 근거로 Qwen 3.6 Max가 600-700B일 수 있다고 추정하며, 이는 성능·리소스 요구량에 큰 영향을 줄 수 있다고 본다.
    • 다른 사용자는 소비자급 하드웨어에서 구동 가능한 소형·중형 모델을 선호하며, Max는 수익 엔진으로서 비공개가 유지돼야 한다고 본다.
    • 또 다른 댓글은 오픈소스로 풀릴 가능성이 가장 큰 대형 모델은 122B 정도이며, 회사가 397B급 대형 모델 공개를 중단했다는 관측을 덧붙인다.

Less Technical AI Subreddit Recap

  • 대상 서브레딧: /r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

Claude Code and Design Updates

  • PSA: Claude Pro no longer lists Claude Code as an included feature (Activity: 1719): 공식 가격표에서 Claude Pro가 Pro 플랜 포함 기능으로 Claude Code를 제거했다는 관찰을 다룬다(pricing page). 지원 문서도 이 변경을 반영했으며, 업데이트된 support article에 따르면 Claude Code는 Max 플랜에서만 제공된다고 설명한다. 공식 발표 없이 바뀐 점 때문에 사용자 혼란이 발생했다는 내용이다. 댓글에서는 커뮤니케이션 부재에 대한 불만과, 기능 제거로 인해 구독을 해지할지 고민한다는 반응이 나온다.

    • 한 사용자는 Codex가 Claude Code와 비교해 어떤지 묻는다. Codex는 OpenAI의 코딩 지원 모델로 알려져 있고, Claude Code는 안전성·해석가능성에 더 초점을 둔 Anthropic의 제품군이라는 대비가 언급된다.

  • What two decades of data loss trauma does to a woman. (Claude Code) (Activity: 1811): 사용자가 Terramaster F4-425 Plus NAS에서 Claude Code를 활용해, 5개의 드라이브에 흩어진 손상 데이터를 새 16TB RAID 저장소의 ‘마스터 라이브러리’로 복구·통합한 과정을 설명한다. 해시·머지 같은 전통적 방식 대신, 수십만 개의 흩어진 파일을 기반으로 원래의 폴더 구조를 추론(inference)해 복원하는 접근이 핵심이다. 이는 단순 중복 제거를 넘어, 컨텍스트와 구조를 추정해 데이터 조직을 재구성하는 AI 활용 사례로 강조된다. 댓글에서는 추론 기반 폴더 재구성의 참신함을 칭찬하면서, 정확도·소요 시간·토큰 사용량 등에 대한 궁금증이 나온다.

    • Extra-Organization-6는 추론으로 폴더 구조를 복원하는 방식이 일반적인 dedup 도구와 다르며, 원래 구조와 얼마나 일치했는지 궁금하다고 말한다.
    • EightFolding는 Claude를 이용해 사용자 디렉터리 전체를 사용 패턴/콘텐츠 기준으로 재구성한 사례를 공유하며, Max 플랜으로 며칠에 걸쳐 수행했다고 말한다.
    • this_for_loona는 데이터 복구에 걸린 시간과 토큰 사용량 같은 기술적 세부를 질문한다.

  • Claude Code no longer listed as a feature for Claude Pro (Activity: 1269): 공식 사이트의 비교 차트에서 Claude Pro 플랜의 기능 목록에서 Claude Code가 제거됐다는 내용이다. 이는 코딩 작업에 이 기능을 쓰던 사용자에게 직접적인 영향을 줄 수 있고, 취미 프로젝트 사용자에게는 $100/월 비용을 정당화하기 어려워질 수 있다는 관점을 제시한다. 댓글에서는 불만이 크고, Claude Pro에서 코딩 기능이 빠진다면 Codex 같은 대안으로 이동할 수 있다는 논의가 나온다.

    • 기능 제거로 인해 Pro 플랜의 가치 제안(value proposition)이 약해졌다는 점이 반복적으로 언급되며, 특히 취미 사용자에게 부담이 커졌다는 반응이 많다.
    • 시각적 증거(스크린샷 등)를 근거로 변경이 확인됐다는 주장과 함께, 기존 구독자에게 ‘grandfathering’(기존 혜택 유지) 정책이 적용되길 바란다는 의견이 나온다.
    • 가격·기능 구성이 AI 코딩 도구 경쟁에서 핵심 변수라는 논의로 이어진다.

  • How to manage “Context Rot” in Claude Code (Anthropic’s recommended workflow) (Activity: 191): Claude Code 세션에서 “context rot”이 발생해 비효율적 버그 수정 루프로 빠지는 문제를 다룬다. 해결책으로 CLAUDE.md를 200 lines 이하로 유지해 토큰 사용을 줄이고, API 스펙은 세션에 복사하지 말고 Google’s NotebookLM 같은 도구로 질의하며, /compact로 컨텍스트를 정리하고, 반복 루프를 피하려면 /rewind 또는 /clear로 히스토리를 리셋하라는 제안이 나온다. 댓글에서는 체크포인트 파일로 현재 로직 요약을 관리하는 방법이 도움이 된다는 의견과, 대형 컨텍스트 창이 비싸고 신뢰도가 떨어진다는 회의도 언급된다.

    • bithatchling은 현재 로직 요약을 담은 체크포인트 파일이 긴 채팅 히스토리보다 잘 작동한다고 말하며, 특히 큰 리팩터링에서 유용하다고 한다.
    • macebooks는 100만 컨텍스트를 무작정 활용하는 것에 반대하며, 기능·작업을 모듈화해 디버깅과 테스트를 돕는 쪽이 더 낫다고 주장한다.
    • baradas는 context rot을 자동 관리하는 ‘claude cot’ 도구를 소개하며, 피드백을 요청한다.

DeepSeek and Qwen Model Developments

  • DeepSeek’s 3 Underrated Advantages: 1M Context (Already Live), New mHC Architecture Paper, and $0.28/M Tokens (Activity: 138): DeepSeek가 1 million token context window를 도입해 청킹(chunking) 없이 대규모 입력이 가능해졌고, 이미 라이브로 운영 중이라는 주장이다. 또한 Manifold Constrained Hyperconnection (mHC) 아키텍처 논문은 학습 안정성·효율성을 높이는 방향이지만 주로 학습(training)에 영향을 주고 추론(inference)에는 직접적 영향이 적다고 설명한다. 가격은 $0.28 per million tokens로 경쟁력을 유지해 GPT-4o 같은 경쟁자 대비 크게 낮다는 점이 강조된다. 댓글에서는 mHC는 사용자 경험에 직접적 영향이 적다는 반응, 1 million token context가 API에서 아직 128K context로 보인다는 실망, DeepSeek의 연구 공개가 다른 랩에도 영향을 준다는 평가가 나온다.

    • mHC는 HC 대비 개선이지만 주로 학습에 유리하고, 실제 게임 체인저는 Engram 및 DualPath 같은 구조일 수 있다는 관점이 제시된다. 이는 context rot과 NIAH 같은 문제를 해결할 잠재력으로 언급된다.
    • 1M 컨텍스트가 발표됐지만 API는 아직 128K로 보인다는 보고가 있어, 기대했던 이점이 아직 체감되지 않는다는 불만이 나온다.
    • DeepSeek의 flash indexing, sparse multi-head attention, MoE 변형 등 혁신이 다른 주요 랩과 오픈소스 모델에 채택되고 있다는 평가가 이어진다.

  • Qwen 3.6 and 3.5 (even 9b) are great models for local deep research (Activity: 70): 9B를 포함한 Qwen 3.6/3.5가 로컬 딥 리서치(LDR) 벤치마크에서 경쟁력 있다는 주장으로, LDR benchmarks dataset을 근거로 든다. 해당 벤치마크는 자체 보고(self-reported) 성격이 있으며 일부 수동 검토가 포함되고, 연산 자원 제약 때문에 주로 소형 로컬 모델에 초점이 맞춰져 있다고 설명한다. 또한 3080 노트북 같은 소비자 하드웨어에서 arXiv·PubMed 같은 대규모 데이터를 로컬로 처리해 클라우드 의존을 줄일 수 있다는 가능성이 제시된다. 댓글에서는 35B 미만 모델의 효과에 회의적인 반응과, 로컬 문서 처리에 활용 가능성이 있다는 반응이 엇갈린다.

    • 데이터셋 확장과 외부 평가 도입 필요성이 언급되며, 정확도·일반화 개선을 위한 데이터 다양성의 중요성이 강조된다.
    • 3080 노트북 같은 로컬 환경에서 arXiv·PubMed 데이터 처리를 하려는 실용적 사용 시나리오가 제시되며, 프라이버시와 비용 절감 측면의 이점이 언급된다.
    • 35B 미만 모델의 한계에 대한 회의가 나오며, 모델 크기와 성능 간 트레이드오프 논쟁이 반복된다.

  • We open-sourced Chaperone-Thinking-LQ-1.0 — a 4-bit GPTQ + QLoRA fine-tuned DeepSeek-R1-32B that hits 84% on MedQA in ~20GB (Activity: 34): DeepSeek-R1-Distill-Qwen-32B 기반의 오픈소스 추론(reasoning) 모델 Chaperone-Thinking-LQ-1.0을 소개한다. MedQA에서 84%로 GPT-4o의 88%에 근접하며, 4-bit GPTQ 양자화로 크기를 ~60GB에서 ~20GB로 줄였다고 설명한다. 의료/과학 데이터로 QAT(Quantization-aware training) 및 QLoRA fine-tuning을 적용했으며, 36.86 tok/s로 베이스 모델 대비 1.6x 빠르고, 지연(latency)은 ~43% 낮아 온프레미스(enterprise healthcare) 환경에 적합하다고 주장한다. 모델은 CC-BY-4.0 라이선스로 Hugging Face에서 제공된다고 한다. 댓글에서는 20GB VRAM에서 32B 모델이 MedQA 84%를 달성한 점이 인상적이라는 반응과, 3090에서의 추론 속도 테스트 의사가 언급된다.

    • 20GB VRAM에서 가능한 84% MedQA 성능은 접근성과 실험 가능성을 크게 높인다는 평가가 나오며, 소비자 GPU(예: 3090)에서의 체감 성능이 궁금하다는 반응이 이어진다.

Veo and Kimi Model Releases

  • Kimi 2.6 has been released (Activity: 751): 이미지는 새로 공개된 Kimi K2.6을 GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro 등과 비교한 성능 차트로 소개하며, General Agents·Coding·Visual Agents 같은 축에서의 강점을 강조한다. 특히 exchange-core(오픈소스 금융 매칭 엔진)를 자율적으로 최적화해 처리량을 크게 높였다는 사례가 언급된다. 댓글에서는 Kimi K2.6의 시스템 최적화 능력에 감탄하며, 설계·웹 개발(PowerPoint, PDFs, web presentations 등) 영역에서의 강점을 비교하는 논의도 나온다. 다만 오픈소스 여부에 대해 확인을 요구하는 회의도 있다.

    • Kimi K2.6가 exchange-core를 13시간 동안 12가지 최적화 전략으로 개선했고, 1,000+ tool calls로 4,000+ LOC를 수정해 medium throughput 185%, peak throughput 133%를 달성했다는 요약이 공유된다. 또한 CPU·할당 flame graph 분석과 스레드 토폴로지(4ME+2RE → 2ME+1RE) 재구성이 언급된다.
    • 오픈소스라는 주장 자체가 중요하게 받아들여지며, 사실이라면 접근성과 혁신에 큰 영향을 줄 수 있다는 반응이 나온다.
    • 동시에 오픈소스 여부에 대한 회의적 시선도 존재하며, 확인을 요구하는 댓글이 이어진다.

  • Just when we all are expecting Veo 4! (Activity: 33): Veo 4를 기대하던 상황에서 “Veo 3.2 Lite”가 나온 것을 풍자하는 밈이다. 스크린샷에는 자전거 레이싱 영상 생성 알림과 함께 생성 제한이 보이며, 대형 메이저 업데이트보다는 점진적 업데이트가 이뤄지고 있다는 뉘앙스를 담는다. 댓글에서는 미국이 AI 비디오 혁신에서 뒤처진다는 불만, 중국 대비 실리콘밸리의 정체에 대한 비판, 할리우드의 영향 가능성 같은 추측이 나온다.

  • Nano adding GLM 5.1 and Kimi K2.6 to sub with 2x multiplier! (Activity: 264): Nano가 구독 서비스에 GLM 5.1과 Kimi K2.6을 추가하면서, 두 모델에만 2x multiplier(토큰 소모 2배)를 적용한다는 공지다. 즉 주당 60 million tokens를 다른 모델 대비 2배 속도로 소모하게 되며, Discord에서 Milan이 공유했다고 한다. 사용자는 GLM 5.1이 z.ai Coding에서 이미 잘 작동한다고도 언급한다. 댓글에서는 가격 안정화 전까지의 임시 조치로 공정하다는 반응이 있는 반면, 토큰 한도에 도달하지 않는 사용자들은 영향이 적다는 반응도 나온다.

AI Discord Recap

AINews

  • Discord가 오늘 접근을 차단해 더 이상 데이터를 가져올 수 없다고 하며, 이 형태로는 다시 제공하지 않을 예정이라고 밝혔다. 새로운 AINews를 곧 출시할 계획이며, 여기까지 읽어준 것에 감사 인사를 전했다.