OpenAI가 GPT-5.6 Sol 사용량을 수정

헤드라인: OpenAI가 GPT-5.6 Sol 사용량을 수정

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

OpenAI는 ChatGPT Work/Codex의 GPT-5.6 Sol 사용량 소모 문제를 공개적으로 설명하고, 추론(inference) 최적화, 컨텍스트 제한 롤백, reasoning-effort 설정 조정, 과도한 멀티 에이전트 동작 수정 등을 진행했다. 커뮤니티 반응은 “너프”라는 비판과 이례적인 투명성에 대한 긍정 평가로 갈렸다.

AI Twitter Recap

Agent RL 인프라: Prime Intellect의 Verifiers v1와 장기 Rollout

Prime Intellect의 verifiers v1: Prime Intellect가 verifiers v1를 공개했다. 이는 agentic RL 및 evals를 위한 환경 스택의 대대적인 재설계다. 핵심 추상화는 환경을 taskset, harness, runtime으로 나누며, Johannes Hage와 follow-up deep dive가 강조했듯 코딩 및 컴퓨터 사용 에이전트를 이기종 실행 환경에서 지원하는 “bring your own harness” 워크플로를 명시적으로 지원한다. 팀원들은 이를 수개월간의 인프라 현대화 작업과 큰 효율 개선으로 설명했으며, willccbb, mikasenghaas, xeophon이 더 자세한 코멘트를 남겼다.
기술적으로 중요한 이유: 가장 중요한 내부 변화 중 하나는 rollout trace가 이제 message DAG로 저장된다는 점이다. 각 메시지가 전체 히스토리에 반복 복사되는 대신 한 번만 저장되므로, trace 성장이 turn 수 기준 **O(n²)**에서 **O(n)**으로 바뀐다. Prime Intellect에 따르면 이는 장기 멀티모달 rollout과 router replay를 훨씬 실용적으로 만든다. 팀은 또한 구체적인 훈련 구성을 제시했다. 사용자가 제공한 코딩 harness에서 100B reasoning model을 40-turn SWE agent tasks에 대해 1000 RL steps 훈련했고, 6 H200 nodes로 2일 미만이 걸렸다는 주장이다 (willccbb). vLLM도 verifiers의 rollout 경로가 vLLM에서 실행되며 serving과 training 사이의 tokenization drift를 피하기 위해 정확한 token ID/logprob를 사용한다고 언급했다.

Coding Agents, Harness 설계, 작업당 비용 경쟁

Harness가 제품 표면이 되고 있다: 여러 게시물은 모델 품질만이 더 이상 유일한 차별점이 아니며, harness/orchestrator가 점점 결과를 좌우한다는 생각으로 모였다. threepointone’s talk는 “harness is the app”으로 요약됐고, LangChain은 성공하는 에이전트 제품이 범용 wrapper가 아니라 작업 특화 harness에서 나올 것이라고 주장했다. Factory는 사용자가 수정 사항을 말로 다시 설명하는 대신 UI 요소/파일을 가리키는 “design mode”라는 관련 UI 관점을 제시했다. 오케스트레이션 측면에서는 omarsar0이 가격/정책 변동에 대비한 hedge로 모델 간 provider switching을 강조했다.
벤치마크가 token 가격에서 작업당 비용으로 이동 중: skirano는 coding-agent index explorer를 만들고 Terra Max가 Fable 5 Max보다 점수에서 약간 앞서면서 비용은 훨씬 낮다는 식의 주목할 만한 비용/성능 tradeoff를 발견했다. Cognition은 Devin Fusion이 이제 Fable 5를 사용하며, 더 강한 delegation과 judgment가 불필요한 작업을 줄이기 때문에 놀랍게도 Opus 4.8보다 작업당 비용이 낮을 수 있다고 보고했다. imjaredz는 해당 실험의 핵심 수치를 강조했다. **Fable-led runs의 81%**에서 lead model이 코드 수정을 전혀 하지 않았다는 것이다. 이는 비싼 모델도 낭비되는 행동을 피하면 더 저렴할 수 있음을 시사한다.
실전 에이전트 벤치마크가 더 촘촘해지고 있다: Arena는 7.8K real-world agentic sessions를 바탕으로 GPT-5.6 Sol을 에이전트 leaderboard #2에 올렸고, steerability와 task success가 강하다고 평가했다. 이후 Arena는 Grok-4.5를 #13에 배치했는데, 이는 Grok 4.3 대비 큰 상승이다. Artificial Analysis는 장기 지식 작업에서 작업당 비용이 점점 중요한 지표가 되고 있으며, token pricing만으로는 turn 수, verbose 정도, cache hit rate의 효과를 놓친다고 주장했다. Parlance Labs의 별도 평가 작업은 production voice-agent trace의 failure analysis에서 자동 eval 플랫폼과 foundation model을 비교했고, dair.ai는 CLI coding-agent failures의 해부학 논문을 소개하며 최종 pass/fail만이 아니라 run이 복구 불가능해지는 지점에 초점을 맞췄다.

OpenAI GPT-5.6 Sol, Codex 사용량 수정, 제품 표면 확장

OpenAI가 Codex/Sol 사용량 소모를 투명하게 설명: 가장 큰 운영 관련 thread는 thsottiaux에서 나왔다. 그는 ChatGPT Work/Codex의 GPT-5.6 Sol에 대해 몇 가지 수정을 설명했다. 추론(inference) 최적화로 약 10% 더 많은 사용량을 제공하고, billing/usage 부작용 이후 context limit을 372k에서 272k로 rollback했으며, 일부 실험적 reasoning-effort(“juice”) 변경을 되돌리고, high/xhigh 설정에서 과도하게 동작하던 multi-agent behavior를 수정했다. theo의 커뮤니티 reverse-engineering은 긴 context, subagent spawning, fast mode가 severe burn의 원인으로 겹쳤을 가능성을 제기했지만, 그는 이후 follow-up에서 billing 세부사항 하나를 정정했다. 반응은 인식된 “nerf” narrative에 대한 비판(ns123abc)과 이례적인 투명성에 대한 칭찬(theo, sama)으로 갈렸다.
사용자들은 강한 코딩/컴퓨터 사용 능력을 보고 중: schrockn을 포함한 여러 실무자는 OpenAI가 coding model에서 앞서 나갔다고 주장했다. gdb는 startup prospecting, web design, mobile work, site generation을 위한 ChatGPT Work와 Codex workflow를 반복적으로 선보였다. 특히 눈에 띄는 사용자 demo로는 Star_Knight12가 Sol in Cursor로 Blender 경험 없이 Blender MCP를 설정하고 떠 있는 MacBook을 렌더링한 사례, petergostev가 GPT-5.6 Sol Ultra로 SQL에서 Doom-like game을 만든 사례가 있었다.
제품 수준 확장도 계속: ChatGPTapp은 ChatGPT가 EEA의 WhatsApp으로 돌아왔고, 추가 시장에서 Kakao/Viber 지원을 제공한다고 발표했다. OpenAIDevs는 OpenAI Build Week 제출을 열었다. OpenAI ecosystem 전반에 대해 gdb는 이 순간을 “you can just create things”라고 짧게 요약했다.

Open Models, Inference Systems, Quantization

Transformers↔vLLM 통합으로 중복 모델 구현 작업 제거: Clement Delangue는 open-inference 사용성의 큰 개선을 소개했다. Hugging Face Transformers 모델을 이제 vLLM에서 native speed로 실행할 수 있으며, 종종 hand-written implementation과 같거나 더 빠르다는 것이다. 이것이 넓게 일반화된다면, 각 새 architecture를 연구/훈련용으로 한 번, high-performance serving용으로 또 한 번 구현해야 했던 오래된 부담을 줄이고, 새로운 open model architecture의 채택을 실질적으로 가속할 수 있다.
Quantization은 여전히 큰 lever: waterloo_intern은 기존 접근법, NVIDIA의 ModelOpt까지 능가한다고 주장되는 새로운 quantization 방법을 예고했다. 더 나은 layerwise precision assignment를 더 빠르게 찾고, 더 aggressive quantization과 더 높은 benchmark score를 낸다는 설명이다. 보완적으로 Unsloth는 GGUF, NVFP4, FP8을 포괄하는 LLM quantization and deployment AWS guide를 공개했다. nrehiew_는 fp4 RL / fp4 serving에 대한 실무 코멘트를 남기며, low-bit post-training이 제한적인 품질 손실로 cheap serving을 가능하게 할 수 있다고 주장했다.
GLM-5.2와 local/open coding stack이 계속 traction 확보: 여러 사용자가 실제 workflow를 open 또는 semi-open setup으로 옮겼다고 설명했다. juanjucm은 GLM-5.2를 coding-agent workflow에 사용하는 내용을 정리했고, TheZachMueller는 실제 업무 pipeline 하나를 Claude에서 GLM 5.2 NVFP4와 Kimi K2.7 Code NVFP4를 8xB200 node에서 사용하는 stack으로 이전했다고 보고했다. wall-clock latency는 느리지만 몇 cent로 더 dense한 report를 얻었다는 설명이다. nutlope도 GLM 5.2 기반으로 재구축한 LlamaCoder v4를 출시했다.

Agent Tooling의 Security, Privacy, Data Control

Grok Build code upload 논란: 가장 중요한 security story는 IntCyberDigest와 hrkrshnn에서 나왔다. 이들은 xAI의 Grok Build CLI가 coding task에 필요한 범위를 훨씬 넘어 private code와 secrets를 포함한 전체 repository를 Google Cloud bucket에 업로드했다고 주장했다. 비판은 scope, silent server-side mitigation, retention/deletion guarantee의 불명확성에 집중됐다. 이는 agent tool이 실제로 무엇을 전송하는지, opt-out UX가 wire-level behavior와 왜 달라질 수 있는지에 대한 더 넓은 논의를 촉발했다.
xAI의 응답은 ZDR과 privacy control을 강조: SpaceXAI는 zero data retention을 사용하는 team의 경우 trace와 code data가 retained되지 않으며, API key 사용은 ZDR을 준수하고, /privacy command로 retention을 비활성화하고 이전에 sync된 data를 삭제할 수 있다고 답했다. 이는 일부 operational question에는 답했지만, default behavior, prior upload, disclosure norm에 대한 community concern을 완전히 해소하지는 못했다.
Trust boundary가 open-vs-closed 논쟁의 중심이 되고 있다: 여러 게시물은 이 사건을 넘어 논의를 확장했다. mchiang0610와 jmorgan는 open model이 단순히 비용 문제가 아니라 human-AI learning loop에 대한 control과 institutional knowledge를 내부에 유지하는 문제라고 주장했다. Arav Srinivas는 Perplexity가 Grok 4.5를 Computer harness에 빠르게 통합한 이유 중 하나가 ZDR availability였다고 말했다.

Continual Learning, Multimodal Systems, Research Directions

Continual learning이 first-class systems problem으로 재부상: ysu_nlp는 모든 조직이 자체 human-AI learning loop를 소유하는 세계가 continual learning 해결에 달려 있으며, 현재 접근법인 memory/RAG, domain post-training, task RL은 아직 충분하지 않다고 주장했다. 이 주제는 skyfallai의 새 작업에서도 반복됐다. 이들은 world가 reset되지 않는 real-world RL을 위한 persistent enterprise simulation인 Morpheus를 소개했고, fchollet는 이를 stationary episodic RL보다 실제 deployment에 더 잘 맞는 benchmark라고 지지했다.
LLM을 위한 “sleep and dreaming”: behrouz_ali와 공동저자들은 LLM이 short-term memory를 long-term memory로 consolidate하는 sleep phase와 recursive self-improvement를 위한 dreaming phase가 필요할 수 있다고 제안했다. 이들은 Knowledge Seeding을 도입하고 continual learning/reasoning task에서 이점을 보고했다. 이는 현재 continual-learning recipe에 대한 더 넓은 불만과 맞물리며, Rich Sutton과 협력자들의 새 venture인 Oak Lab이 오늘날의 표준 LLM pipeline이 아니라 경험에서 배우는 animal-like intelligence를 추구하는 흐름과도 이어진다.
비-LLM-agent 연구도 폭넓게 발표: 주목할 항목으로는 modular system에서 decentralized physical self-recognition과 repair를 위한 Sakana AI’s Smart Cellular Bricks, visual demonstration에서 reasoning/dynamics/planning을 직접 학습한다고 설명된 ByteDance’s UniVR-34B, historical inference workflow를 위한 Google DeepMind’s Predicting the Past skill, 300K+ anonymized conversations 분석을 바탕으로 Claude의 expressed values가 model과 language에 따라 어떻게 달라지는지 연구한 Anthropic’s research가 있었다.

Top tweets (by engagement)

OpenAI Codex/Sol usage fixes: thsottiaux on GPT-5.6 Sol usage, context, “juice,” and multi-agent fixes
Grok Build privacy incident: IntCyberDigest on full-repo uploads to xAI cloud buckets
OpenAI response tone and user treatment: sama: “come for the best model, stay because we don’t treat you with contempt”
Prime Intellect rollout efficiency: willccbb on training a 100B reasoning model for 40-turn SWE RL on 6 H200s in under 2 days
Anthropic values research: Anthropic on model/language-dependent value expression across 300K+ conversations
Transformers + vLLM interoperability: Clement Delangue on running Transformers models in vLLM at native speed

AI Reddit Recap

/r/LocalLlama + /r/localLLM Recap

E-Waste GPU Inference Benchmarks and Fixes

I benchmarked 15 “E-Waste” GPUs with Modern Workloads (Activity: 462): 1년간의 homelab benchmark가 custom Dockerized suite인 gpu_box_benchmark를 사용해 퇴역 NVIDIA Tesla GPU(K80/M10/M40/M60/P40/P100/V100/T40)를 LLM, CV, Blender, Whisper 및 관련 workload에서 테스트했다. 전체 graph는 저자의 blog에 있다. 핵심 결과는 V100 16GB가 전반적인 value가 가장 좋고 T40 성능에 접근했으며, P40이 LLM에서 P100을 앞섰고, M60은 Whisper에서 예상보다 강했으며, 4U chassis에서 multi-GPU scaling은 대체로 linear했고, cheap X99 + Xeon platform은 EOL software/power-efficiency caveat에도 card를 대체로 충분히 feed했다는 것이다. Commenter들은 이 benchmark가 정말 “modern” workload를 겨냥하는지 의문을 제기하며, small model과 ResNet-style test는 더 큰 model을 위한 cheap pooled VRAM이라는 핵심 value proposition을 제대로 테스트하지 못한다고 주장했다. 요청된 follow-up에는 power/noise 측정과 여러 V100/P40-class card에서 Qwen 3.x 27B/35B MoE 같은 model의 long context prompt processing/token generation metric이 포함됐다.
Benchmark 범위 비판: 여러 commenter는 benchmark suite가 현재 high-VRAM use case를 대표하지 못한다고 주장했다. ResNet과 small model은 “cheap VRAM” GPU를 평가하기에 부족하다고 했고, Qwen 3.6 27B/31B MoE/35B A3B 같은 더 큰 최신 LLM으로 pooled VRAM 구성이 이를 실행할 수 있는지, 150k ctx 같은 long context에서 prompt-processing (PP) 및 token-generation (TG) throughput을 요청했다.
P100/P40 기술적 정정: 한 기술적 correction은 관련 fp32 patch가 동작을 바꾸지 않는 한 Tesla P100이 보통 Tesla P40보다 빨라야 한다고 지적했다. P100의 HBM bandwidth가 P40 memory bandwidth보다 약 3배 높기 때문이다. 이는 benchmark가 software/kernel 차이를 설명하지 않고 P40이 앞선다고 보이면 memory-bound workload가 잘못 표현됐을 수 있음을 뜻한다.
P102-100 제안: 한 commenter는 현재 약 $50에 구할 수 있고 idle power가 약 10 W로 낮으며 cooling이 쉽다고 알려진 P102-100 mining GPU 추가를 제안했다. 이들은 Qwen 3.6 35B에서 generation 약 40 tokens/s에 도달하지만 prompt processing은 약 100 tokens/s로 매우 느리다고 주장하며, 흥미롭지만 bottleneck이 있는 e-waste inference option이라고 평가했다.
Your $80 Tesla P100 has been doing silently noisy math in llama.cpp for years. Three lines fix it, for free. (Activity: 426): llama.cpp/turboquant용 3줄 CUDA arch-gating patch가 sm_60 Tesla P100 처리를 기존 sm_61 Pascal exemption과 맞추도록 변경했다. 이를 통해 throughput 개선 없이 logit noise를 증가시켰다고 보고된 “fast fp16” 경로를 피한다. 이 패치는 llama-cpp-turboquant v0.3.0로 release됐고, TheTom/llama-cpp-turboquant#212와 spiritbuun/buun-llama-cpp#80에 merge됐으며, upstream tracking은 ggml-org/llama.cpp#25593에서 진행 중이다. 작성자는 Qwen3.6-27B / WikiText-2에서 fp32-reference logits 대비 median KLD가 0.0023에서 0.000001로 개선됐고(~2300×), top-token agreement가 96.5%에서 99.9%로 증가했으며, prefill은 변하지 않고 decode는 8k context에서 약 1.4% 빨라졌다고 보고했다. 한 commenter는 독립적으로 P100에 patch를 적용해 mean KLD 0.0122 → 0.000000, top-token match 95.09% → 99.997%를 봤다. 주장된 scope는 구체적으로 Pascal sm_60 P100이다. GTX 10-series/P40 sm_61은 이미 exempt였고, Volta+는 다른 kernel을 사용해 영향이 없다고 주장되며, Blackwell control에서는 perplexity/decode behavior가 bit-identical이었다고 한다. 댓글은 대체로 지지적이었고, 이를 작지만 의미 있는 correctness fix로 봤다.
P100 검증 결과: 한 commenter는 patch를 테스트하고 Tesla P100에서 큰 numerical-accuracy 개선을 보고했다. stock llama.cpp CUDA는 mean KLD = 0.0122, 95.09% same top-token이었고, patched/control path는 mean KLD = 0.000000, 99.997% same top-token이었다. 이는 sm_60에서 fp16 fast-math path를 비활성화하면 model behavior를 예측 불가능하게 바꾸지 않고 distribution-level noise를 제거한다는 주장을 뒷받침한다.
기술적 메커니즘 요약: 또 다른 commenter는 llama.cpp의 CUDA backend가 강한 fp16 throughput을 가진 것으로 분류된 GPU에서 fast fp16 math mode를 활성화한다고 요약했다. GTX 10-series/P40 같은 sm_61 card는 이미 제외됐지만 sm_60 P100은 아니었다. 주장은 P100의 실제 inference가 fp16-vector-unit-bound가 아니라 memory/GEMM-bound이므로 fp16 path가 측정 가능한 speedup 없이 quantization 같은 numerical error를 더한다는 것이다. 제안된 3줄 patch는 fp32 대비 KL divergence를 약 2300x 줄이면서 속도 손실이 없다고 한다.
Multi-GPU P100 관심: 3x P100 setup을 가진 한 P100 사용자는 자신의 llama.cpp build에서 patch를 테스트할 계획이라고 했고, Qwen 3 27B, quantization behavior, MTP를 실험한 경험을 언급했다. 이는 fix가 multi-GPU P100 inference와 다른 quantization/model configuration에 일반화되는지 검증하려는 관심을 보여준다.

Chinese AI Stack: Usage, Weights, Chips

China’s DeepSeek developing its own AI chip, sources say (Activity: 576): Source들은 DeepSeek이 자체 AI accelerator를 개발 중이라고 전했다. 이는 중국 내 Nvidia GPU 접근 제한과 domestic training/inference hardware 필요에 대한 대응으로 보인다. 댓글에서 제기된 핵심 기술 제약은 chip design 자체만이 아니라 leading-edge semiconductor manufacturing 접근이다. 인용된 한 견해는 *“Nvidia is at zero in China”*라고 하면서도 DeepSeek이 advanced fab 없이 중국 밖에서 성공할 가능성은 낮다고 주장했다. Commenter들은 대체로 경쟁을 긍정적으로 봤지만, 한 기술적 관점은 >32GB VRAM과 >1TB/s bandwidth를 $5k 미만에 제공하는 high-memory consumer accelerator라면 비효율적이거나 어색한 memory configuration으로 만들어져도 팔릴 것이라고 했다.
제조와 시장 접근 제약: 한 commenter는 제조와 market-access 제약을 강조했다. leading-edge fab에 접근하지 못하면 DeepSeek은 중국 밖에서 competitive AI silicon을 판매하기 어려울 가능성이 높고, Nvidia의 중국 내 position은 export control로 사실상 제약된다고 설명했다. 또 다른 기술적 관점은 high-memory-bandwidth accelerator에 대한 consumer demand였다. >32GB memory와 >1TB/s bandwidth를 $5k 미만에 제공하는 가상의 card는 많은 DDR channel과 ~800W power draw 같은 비효율적 구현이어도 매력적일 수 있다고 봤다.
Chinese AI Models Seize OpenRouter’s Top Five as OpenAI and Google Vanish From the Top 10 (Activity: 561): image는 OpenRouter’s AI Model Rankings의 technical dashboard screenshot이다. monthly token-usage share에서 Chinese-affiliated model이 상위 5개 position을 차지하고 표시된 top 10 중 7/10을 차지한다. Chart는 OpenRouter usage가 6월 말로 갈수록 급증해 weekly token이 대략 60T에 도달하는 모습을 보여주며, DeepSeek, MiMo, MiniMax, Hy3 model이 Western frontier model보다 앞서 있다. Anthropic Claude는 6위와 8위에 나타나고, OpenAI와 Google은 없다. 의미는 platform-specific하다. OpenRouter는 이것이 사용자들의 실제 사용을 반영한다고 말하지만, 이는 OpenRouter traffic을 측정한 것이지 global LLM adoption이 아니다. Commenter들은 이 ranking을 순수 capability benchmark라기보다 cost/practicality의 증거로 해석했다. *“It’s hard to compare benchmarks, but easy to compare bills.”*라는 반응도 있었다.
OpenRouter의 역할: 여러 commenter는 OpenRouter를 practical model-selection layer로 봤다. common API 뒤에서 여러 open/source-available model을 테스트한 뒤, unit economics가 맞으면 OpenRouter를 계속 쓰거나 winning model을 self-host할 수 있다는 것이다. 핵심 기술 concern은 operational stability였다. 사용자들은 OpenAI/Anthropic이 pricing, model behavior, model availability를 갑자기 바꿀 수 있어 reproducibility와 long-term deployment planning이 어려워진다고 봤다.
비용이 benchmark보다 실행 가능한 metric: 한 commenter는 *“it’s hard to compare benchmarks, but easy to compare bills”*라고 말했고, 다른 commenter는 **deepseek-v4-flash**와 **mimo-v2.5**가 OpenRouter에서 매우 저렴해 hardware capex는 물론 전기료보다도 inference cost가 낮다고 주장했다. 또 다른 commenter는 중국의 낮은 전기요금이 inference economics에 실질적으로 영향을 주며, 특히 California 같은 proposed US datacenter location과 비교된다고 말했다.
Aggregator traffic의 한계: 한 commenter는 OpenRouter ranking이 OpenAI와 Google Gemini usage를 과소대표할 수 있다고 했다. 많은 고객이 aggregator가 아니라 provider에서 직접 해당 model에 접근하기 때문이다. 이는 OpenRouter의 top-model distribution이 전체 access channel의 market share라기보다 aggregator-native demand와 price/performance experimentation을 더 반영한다는 뜻이다.
Xiaomi quietly uploaded MiMo-V2.5-DFlash — official DFlash weights are now on Hugging Face (Activity: 389): Xiaomi가 official MiMo-V2.5-DFlash weights를 Hugging Face의 XiaomiMiMo/MiMo-V2.5-DFlash에 업로드했다. 전용 dflash/ directory와 별도 MTP model이 포함돼 있다. Poster는 non-DFlash MiMo-V2.5-class model이 300B+ params이며 2×24GB GPU에서 RAM/VRAM offload로 약 8–10 tok/s로 실행된다고 보고했고, DFlash가 throughput을 대략 두 배로 늘릴 수 있다고 추측했다. 또한 llama.cpp가 현재 MTP layer를 identify/use하는 데 어려움을 겪지만, 별도 DFlash/MTP artifact는 지원하기 쉬울 수 있다고 언급했다. Commenter들은 MiMo 2.5를 “incredible and underrated”라고 묘사했지만, 한 benchmark 관련 주장은 정정됐다. SWE-rebench에서 DeepSeek V4 Flash와 Pro 사이에 위치한다는 비교는 이 약 284B Flash/DFlash-sized model이 아니라 MiMo Pro(1T, A42B)를 가리킨 것이었다.
MiMo variant 혼동: 한 commenter는 처음에 MiMo-V2.5-DFlash를 swe-rebench에서 DeepSeek V4 Flash/Pro와 비교하며 284B임에도 1.6T 사이에 들어간다고 주장했지만, 이후 이것이 1T A42B로 설명된 MiMo Pro와 혼동한 것이라고 정정했다. 유용한 takeaway는 DFlash, Flash-sized, Pro model naming이 겹쳐 MiMo variant의 benchmark/performance claim을 잘못 attribution하기 쉽다는 점이다.
DFlash 실제 속도 관심: DFlash support가 llama.cpp에 들어오면 GGUF/local inference 조건에서 실제 tok/s gain을 측정하려는 관심이 있다. 한 commenter는 VRAM offload가 충분하지 않고 inference가 system RAM으로 spill되면 speculative-decoding-style speedup이 떨어질 수 있으므로, practical benchmark는 ideal accelerator throughput과 mixed VRAM/RAM execution을 구분해야 한다고 경고했다.
DFlash의 성격 질문: 한 commenter는 DFlash가 더 작고 가벼운 distilled variant라는 의미의 별도 “Flash” model이라기보다, base model의 output distribution을 보존하면서 generation을 가속하는 MTP/speculative decoding mechanism에 가까운지 물었다. 이 구분은 released weights 해석에 중요하다. DFlash는 reduced-capacity model family member가 아니라 inference-speed augmentation일 수 있다.

Local AI Runtime and Visualization Experiments

Local Image to 3D (<2gb RAM, <20s, Apple Silicon, iPhone) (Activity: 990): 연결된 GIF(image)는 Modelr의 technical demo로 보인다. Modelr는 Apple Silicon과 제한적 iOS에서 local image-to-3D generation을 위해 Hunyuan3D-Shape와 Hunyuan3D-Paint를 port한 open-source Swift/MLX app이다. 작성자는 M4 Max에서 FP16 benchmark를 보고했다. hy3d shape는 peak memory 5.6–7.3GB를 사용해 약 21–22s, hy3d paint는 훨씬 무거워 231–344s와 약 38–39GB를 사용했다. Quantized Q4/Q8 run은 PyTorch/CPU overhead가 아니라 MLX를 통해 lower-memory Mac/iPhone 사용을 가능하게 하는 것으로 설명된다. 댓글의 주요 기술 caveat는 licensing이다. 생성 asset이 현재 Hunyuan3D license 아래에서 크게 제한될 수 있어, open-source tooling에도 commercial/practical use가 제한될 수 있다는 것이다.
Hunyuan3D 라이선스 우려: 한 commenter는 output이 Hunyuan3D license에 크게 constrained될 수 있다며 Tencent의 Hunyuan3D-2.1 license에 직접 link했다. 이들은 강력한 local image/text-to-3D tooling에도 field가 아직 non-permissive “community” license에 제한돼 있다고 했지만, Hunyuan3D-3가 더 permissive한 terms로 이동할 수도 있다고 추측했다.
Interactive Jacobian-Lens visualizer and live steerer for GGUF models on llama.cpp (Activity: 374): 이미지는 meme이 아니라 technical UI screenshot이다. qwen2.5-1.5b-instruct에서 시연된 llama.cpp용 interactive Jacobian-Lens visualizer/steerer for GGUF models의 J-Lens web interface를 보여준다. Project igorbarshteyn/jlens-gguf는 model 관찰과 j-space swapping / abliteration / steering을 수행하기 위한 native GGUF server를 추가하며, dense 및 MoE GGUF를 지원한다. lens memory overhead는 model size의 약 1/8로 scaling된다고 보고된다. 예를 들어 large quantized Qwen model 같은 160 GB GGUF에는 약 20 GB의 추가 RAM이 든다. Commenter들은 original GGUF와 lens tensor를 merge하는 것, heavily quantized model을 diagnose/repair하는 데 tool을 사용하는 것, 이것이 “targeted live adapters” 또는 real-time steering workflow를 가능하게 할 수 있다는 점에 초점을 맞췄다.
GGUF 병합 요청: 한 기술적 요청은 tool이 original GGUF와 Jacobian-lens tensor를 merge하도록 지원해 달라는 것이었다. 이는 별도 visualization/steering sidecar가 아니라 self-contained GGUF artifact를 원한다는 뜻이다. 이를 위해서는 lens tensor가 existing llama.cpp GGUF tensor/metadata convention 내에서 어떻게 serialize, name, load될지 정의해야 할 가능성이 높다.
Quantized model repair 가능성: 한 commenter는 Jacobian-lens 접근법이 heavily quantized model repair에 유용할 수 있다고 제안했다. 즉 aggressive GGUF quantization으로 생긴 behavior나 representation damage를 live steering/adapter로 보정하는 방식이다. 다른 commenter는 larger dataset이 lens를 제대로 mapping하는 데 필요한지 물으며 data requirement concern을 제기했다. 이는 learned 또는 estimated Jacobian mapping이 너무 적은 activation data로 calibration될 경우 brittle할 수 있기 때문이다.
I got Gemma 4 running directly inside Godot using only GDScript and Vulkan compute shaders (Activity: 364): 이미지는 engine 내부에서 local GGUF LLM을 실행하는 Godot 4.7 debug chat UI를 보여주며, 약 46.99 tok/s를 보고한다. Context상 ironic한데, in-app model response는 GDScript + Vulkan compute shaders로 GGUF loading/inference를 구현하는 것이 “extremely complex”라고 말하지만, project가 바로 그것을 시연하기 때문이다. Post에 따르면 experiment는 Vulkan compute로 model math를, GDScript로 GGUF loading, tokenization, sampling, KV cache, UI를 처리하며 gemma-4-E2B-it-Q4_K_M.gguf를 실행한다. Code는 github.com/asallay/godot-llm에 있고, 한 model로 제한되며 CUDA를 쓰는 llama.cpp보다 약 10× 느리다고 한다. Image 댓글은 대부분 속도보다 proof-of-concept에 감탄했으며, native extension, ABI issue, sidecar server를 피하는 점이 local NPC/LLM demo를 단일 Godot export로 더 쉽게 배포하게 만들 수 있다고 봤다.
Godot 단일 배포 장점: 기술적으로 중요한 점은 demo가 GGUF loading, KV-cache management, sampling을 GDScript + Vulkan compute shaders를 통해 Godot 안에서 전부 구현한 것으로 보인다는 점이다. native-extension ABI issue나 별도 inference server를 피한다. 한 commenter는 성능이 약 10x 느려도 deployment simplicity가 중요하다고 주장했다. 단일 Godot export가 local LLM-driven NPC demo를 다른 사람이 실제로 실행 가능하게 만들 수 있기 때문이다.

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 Fable 5 Access and Business-Model Backlash

Is Anthropic shooting themselves in the foot by pulling Fab 5 from subscriptions tonight? (Activity: 1656): image는 DeepSWE 1.0에 대한 dark-themed benchmark bar chart다. claim된 coding-agent performance에서 “Fable/Fab 5 max”가 66.1%로 선두이고, GPT 5.5 xhigh 64.31%, Grok 4.5 62.0%, Opus 4.8 max 55.75%, **Opus 4.7 max 40.12%**보다 앞선다. 이 post는 Anthropic이 Fab 5를 subscription에서 제거하고 metered token billing only로 만들 경우, 강한 benchmark position에도 developer mindshare를 잃을 위험이 있다고 주장한다. 특히 competitor가 flat-rate plan에서 비슷한 coding performance를 제공하면 더 그렇다는 것이다. 댓글은 이를 “classic footgun”으로 묘사하며, unpredictable API billing이 개인 developer를 위축시키고, 이들이 종종 내부 enterprise champion이 된다는 점을 강조했다.
Subscription/API split 우려: 여러 commenter는 Anthropic의 subscription/API split을 technical adoption-risk issue로 봤다. Fab/Fable 5가 predictable subscription에서 제거되면 power user는 unpredictable API spend를 받아들이기보다 Codex의 $200 plan, GPT-5, 또는 더 저렴한 alternative로 옮길 수 있다는 것이다. 핵심 concern은 pricing뿐 아니라 subscription으로 prototype을 만들고 나중에 enterprise budget approval을 이끄는 internal champion을 잃는 것이다.
성능 비교 반박: 한 commenter는 graph가 **Sol 5.6 xhigh**를 누락했기 때문에 misleading하다고 주장했다. 그들은 Sol이 “way above 5.5 xhigh”라고 했다. 또 다른 commenter는 현재 workflow를 Opus calls와 GPT-5 사이에 나누고 있으며, Fable 5 hype가 Sol 5.6 대비 과장됐을 수 있다고 제안했다.
Anthropic, I think you really need to react. You’re slowly losing ground. (Activity: 1731): image는 OpenAI subscription/product change를 강조하는 X post screenshot이다. Plus/Business/Pro의 5-hour usage limit 임시 제거, “GPT 5.6 Sol” efficiency improvement, 6M active users, incoming usage reset이 포함돼 있다. Post context에서는 troubled “Fable” rollout, unclear quota handling, “Sonnet 5”의 더 높은 token consumption, model availability와 limit에 대한 last-minute communication 이후 Anthropic/Claude가 consumer experience에서 뒤처지고 있다는 증거로 사용된다. Commenter들은 대체로 competitive-pressure framing에 동의하며, OpenAI가 현재 cost, reset, communication, model quality에서 이기고 있다고 주장했다.
OpenAI 우위에 대한 사용자 반응: Commenter들은 OpenAI의 최근 우위를 lower cost, more frequent usage-limit reset, better communication, improving model quality의 조합으로 봤다. 한 사용자는 구독 이후 OpenAI가 “like 20 resets”를 제공했다고 주장했다. 여러 사용자는 Anthropic의 현재 consumer offering이 OpenAI 대비 약해지고 있으며, 특히 $200/month tier 사용자에게 그렇다고 말했다.
Enterprise 우선순위 우려: 반복되는 technical/product concern은 Anthropic이 consumer/prosumer capacity보다 enterprise, government, corporate accounts를 우선시하는 것처럼 보인다는 점이었다. 사용자들은 Mythos, Fable, Opus, Sonnet 같은 Anthropic의 model/tier lineup을 언급하며, 경쟁력을 유지하기 위해 Fable을 Opus와 같은 비용으로, Opus를 Sonnet과 같은 비용으로 만드는 pricing realignment를 제안했다.
Reset policy 비판: 사용자들은 last-minute Fable 5 extension 처리와 더 명확한 reset policy 변경 부재를 비판했다. OpenAI의 최근 움직임에 대응하려면 “weekly reset” 또는 더 predictable한 capacity management가 더 credible하다고 주장했다. 불만은 raw model capability보다 quota reliability, pricing transparency, paying subscriber를 위한 service predictability에 더 가깝다.
Subscriptions is less than 5% of revenue, they might not care enough to keep Fable around (Activity: 1162): 이미지는 1Q24부터 4Q26까지 quarterly revenue mix를 추정한 financial projection table, “Anthropic: the P&L behind the IPO”이다. 이 표는 API revenue가 Anthropic의 projected revenue를 지배하고, consumer/business/enterprise subscription은 small minority로 남는다고 보여준다. 이는 subscription이 <5% of revenue라는 post의 주장을 뒷받침한다. 또한 Anthropic이 2024–2025년의 큰 operating loss에서 2026년 profitability로 이동한다고 예측하며, 추정이 정확하다면 “Fable” 같은 subscription product가 API/enterprise growth보다 전략적으로 덜 중요할 수 있음을 시사한다.
Subscription의 전략적 가치: 여러 commenter는 subscription product가 직접 revenue center라기보다 loss leader이자 market-signal channel로 작동할 수 있다고 주장했다. 개인 developer usage는 그 developer가 직장에서 같은 tooling을 옹호할 때 enterprise/API adoption으로 전환될 수 있다. 핵심 technical/business dynamic은 Codex/Fable 같은 consumer coding tool이 developer preference와 workflow familiarity를 통해 enterprise procurement에 영향을 줄 수 있다는 점이다.
수치 신뢰성 의문: 한 commenter는 reported “<5% of revenue” figure의 신뢰성을 의심했다. Private company의 이런 숫자는 audited public financial이 아니라 estimate일 가능성이 높다는 것이다. 따라서 OpenAI가 Fable 같은 product를 유지할지에 대한 전략적 결론은 revenue breakdown source와 methodology가 명확하지 않은 한 조심스럽게 다뤄야 한다는 implication이다.
I’m paying $200/month, and after tomorrow, I can’t access Anthropic’s best model with my sub? (Activity: 1447): $200/month Anthropic subscriber가 new/best model “Fable”이 Opus보다 serving cost가 높다면 access를 제거하지 말고 subscription 안에 유지하되 더 높은 usage/token multiplier를 적용해야 한다고 주장했다. Post는 이를 unit-economics/control problem으로 framing한다. Anthropic은 더 빠른 quota burn으로 cost exposure를 cap하면서도 frontier model 접근을 보존할 수 있다는 것이다. Commenter들은 Anthropic이 결정을 되돌릴 수 있다고 예상했고, 일부는 access가 제거되면 cancel하겠다고 말했다. 주목할 만한 견해 하나는 frontier model이 fixed-price consumer subscription에 bundle되기보다 점점 API-only가 될 수 있다는 것이다.
Frontier model의 API-only화: 한 commenter는 Anthropic의 변화가 frontier model이 increasingly API-only가 될 수 있음을 보여준다고 봤다. top-tier model access를 fixed-price consumer subscription에서 분리한다는 의미다. 기술적 implication은 provider가 가장 비싼 model을 $200/month subscription 같은 capped monthly plan으로 노출하기보다 metered API pricing을 선호할 수 있다는 것이다.
Yuji Tachikawa, one of the world’s leading theoretical physicists, reports Claude Fable solved a problem that he and his collaborators had gotten stuck on for the past 6 months (Activity: 2989): leading theoretical physicist인 Yuji Tachikawa가 Claude Fable이 자신과 collaborators가 약 6 months 동안 막혀 있던 theoretical-physics problem 해결을 도왔다고 X에 올린 것으로 전해졌다(original tweet, now deleted). 그는 이후 그 post를 삭제한 이유가 claim을 retract해서가 아니라 끌어들인 attention의 성격 때문이라고 말했다(follow-up). Reddit thread는 reported claim과 linked screenshot 외에는 problem, solution, prompt process, verification을 평가하기에 충분한 technical detail을 제공하지 않는다. Commenter들은 AI-assisted research의 evaluation standard를 논의했다.
AI-assisted research 평가 기준: 한 commenter는 “one shot”으로 풀지 못했다는 이유로 결과를 dismiss하는 것은 human collaborator에게 적용되는 것보다 unfairly stricter한 standard라고 주장했다. 다른 commenter는 model이 “I wonder if…” 같은 speculative reasoning을 사용한 것으로 보인다고 강조했다. 이는 frontier LLM이 established understanding을 넘어 hypothesis를 explore할 수 있는지와 관련이 있을 수 있다. Thread 자체는 physics problem, verification process, benchmark-style evidence에 대한 detail을 제공하지 않으므로 technical substance는 이 model behavior 해석에 제한된다.

AI Coding: Prototype Hype vs Production Reality

Why the majority of vibe coded projects fail (Activity: 1785): 이미지(jpeg)는 “vibe coded” AI prototype이 실패하는 이유를 설명하는 dark-mode social post다. localhost demo가 production system으로 오해되는 경우가 많고, mature Slack/Discord-like app에는 distributed systems, scaling, reliability, message ordering, storage, search, observability, years of iteration이 필요하다는 주장이다. Title context에서 핵심 technical gap은 code generation 자체가 아니라 MVP 이후 필요한 engineering을 과소평가하는 데 있다. Commenter들은 대부분 project가 Slack 수준으로 scale하지 못해서가 아니라 일반적인 startup reason, 즉 product value 부족, marketing, sales 때문에 실패한다고 반박했다.
실패 원인은 scaling만이 아님: 여러 commenter는 “vibe-coded” project가 보통 product/value와 go-to-market reason 때문에 실패한다고 주장했다. “Slack-level” infrastructure로 scale하지 못해서가 아니라는 것이다. 기술적 implication은 많은 AI-generated MVP가 곧 basic implementation bar를 넘을 수 있고, differentiation은 domain fit, workflow integration, software가 high-value problem을 해결하는지에 더 좌우될 수 있다는 점이다.
SMB/internal workflow 기회: 반복되는 theme은 최고 use case가 billion-user SaaS platform이 아니라 small, domain-specific internal software라는 것이다. Commenter들은 capable model로 빠르게 만든 custom HubSpot-like CRM 같은 SMB tool이 $15k+ 연간 비용을 절감할 수 있으며, small team만 serve하면 되므로 hyperscale architecture가 필요 없다고 말했다.
Hyper-niche operational tools: 한 commenter는 많은 successful project가 public-scale testing을 필요로 하지 않는다고 강조했다. 극히 niche한 operational tool은 3–10명만 사용해도 manual work, EUC process, governance overhead를 대체해 company에 연간 최대 $100k를 절감할 수 있다는 주장이다.
Honest question: What are you building that you need fable 5 so badly? (Activity: 1030): Poster는 Claude Pro의 대부분 Opus 4.8, workplace의 Opus 4.6 / Sonnet 5만으로도 homelab automation과 dbt, long SQL/query parsing, near-real-time joins, thousands of schemas/integrations, 대략 150B events/day를 처리하는 pipeline 같은 large-scale data-engineering work를 처리하는데, 어떤 workload가 Fable 5 upgrade를 정당화하는지 물었다. 새 model의 top technical use case로는 multi-agent VFX/AAA game pipeline automation이 언급됐다. obscure하고 duct-taped artist tooling 전반에서 prompt specificity와 hand-holding이 줄어 cognitive load가 낮아진다는 설명이다. 또 다른 use case는 adversarial language/rhetorical analysis로, Fable이 여러 interpretive frame을 유지하면서 critique하는 능력 때문에 가치 있다고 평가됐다.
VFX/AAA game pipeline 자동화: 17 years 경력의 VFX/AAA games software engineer는 artist를 unblock하기 위한 ad hoc production pipeline과 obscure tooling issue를 다루는 데 Fable과 Sol을 사용한다고 설명했다. 이 환경에서는 code가 product 자체가 아니라 artist-facing task를 푸는 수단인 경우가 많다. 그는 “five agents”를 동시에 실행하며, engineering-hostile production environment에서 prompt-detailing과 hand-holding을 줄여 cognitive load를 낮추는 model을 높게 평가했다.
Adversarial critique 사용: 한 commenter는 Fable을 주로 coding이 아니라 adversarial testing, language analysis, rhetorical critique, paper-writing에 사용한다고 했다. Fable은 “multiple frames at once”를 유지하고 비판하는 데 더 낫다고 묘사하면서도, GPT 5.6 Sol도 같은 종류의 multi-perspective critique task에서 “very, very good”해지고 있다고 언급했다.
Staff engineer로서의 Fable: 한 senior big-tech engineer는 Fable의 가치를 Opus나 Sonnet보다 더 나은 code generation이 아니라 “staff engineer”처럼 행동하는 데 있다고 봤다. ambiguous requirement를 명확히 하고, high-level architecture를 만들고, implementation을 orchestrate하는 능력이다. 그의 framing에서 Opus는 moderate ambiguity 아래 “senior engineer” coding에, Sonnet은 더 명확한 task의 “junior engineer” execution에 잘 맞고, frontier model은 사용자가 더 많은 systems-level 및 cross-functional problem solving을 위임할 때 유용해진다.
Did not expext Fable 5 to be this good!✨ (Activity: 1273): Post는 Fable 5로 low-poly city asset folder에서 대략 3 afternoons 만에 browser-based Three.js FPS를 만들었다고 주장했다. Fable은 map creation을 처리했다. Demo는 Heroku에 host되어 있으며 single/multiplayer FFA/TDM, desktop/VR play, flying cars, rocket launcher와 rail gun 같은 Quake-style weapon을 지원한다고 설명됐다. 참조된 Reddit video는 403 Forbidden block 때문에 접근할 수 없었다. Top comments는 대체로 non-technical했다. 한 commenter는 칭찬이 “justified”라고 했고, 다른 commenter는 “last week’s Fable”과 닮았다고 농담했으며, 또 다른 commenter는 gameplay/aesthetic을 Forsaken과 비교했다.

오늘의 요약