TL;DR
이번 기간에는 Grok Bot이 세 사람과 함께 72시간 동안 빈 아이디어에서 제품과 회사를 만드는 생방송 실험을 예고하며 AI의 실행 능력을 시험대에 올렸습니다. DeepSeek-V4.1-Flash는 DGX Sparks와 16GB M1 Mac Mini까지 실행 범위를 넓히며 대규모 모델의 로컬 추론 가능성을 밀어붙였고, SWE-2는 Frontier 모델보다 낮은 비용을 내세운 Coding Agent 흐름을 만들었습니다. 실무 쪽에서는 Agent Harness를 직접 소유해야 도메인별 신뢰성과 벤더 종속 문제를 다룰 수 있다는 견해가 나왔습니다. 동시에 논문 내용을 충분히 이해하지 못한 채 제출하는 현상과 Verifier·RLVR 기반 평가가 함께 부상했으며, Frontier AI 권력 집중을 막기 위한 다중 제공자와 Open-Source 선택지의 필요성도 이어졌습니다.
𝕏 실시간 트렌드 토픽
🔥 Grok Bot의 72시간 실시간 회사 구축 실험포스트 2
세 사람이 빈 아이디어에서 출발해 Grok Bot을 팀처럼 활용하며 72시간 안에 제품과 회사를 만드는 생방송 실험이 예고됐습니다.
세부 내용 보기
- Grok Bot의 역할을 단순한 대화형 도구가 아니라 팀 구성원처럼 설정하고, 세 사람이 아이디어·제품·회사 구축을 한 흐름으로 진행하는 형식입니다. 9월 15일부터 3일간 과정을 공개해 결과물과 실행 속도를 함께 확인하는 구조이며, 기존의 완성된 데모가 아니라 빈 상태에서 출발한다는 점이 핵심입니다.
- 게시물에 명시된 실험 조건은 세 사람, 빈 슬레이트, Grok Bot을 팀으로 활용하는 72시간입니다. 이 입력에서 제품과 회사라는 산출물까지 가는 전 과정을 생방송으로 공개하므로, 모델이 계획·제작·의사결정 흐름에 얼마나 깊게 관여하는지 직접 확인하는 테스트가 됩니다.
Grok Bot을 팀처럼 배치해 아이디어에서 제품과 회사까지 만드는 과정을 실시간으로 공개하면, 모델의 실제 실행 범위와 작업 지속성을 한 번에 확인할 수 있다는 입장입니다.
원문 트윗 2개 보기
Elon Musk
Watch a company being built live with @Grok @Bot !
If you still haven’t registered for Grok Bot Galaxy....now is the time Starting September 15, SpaceXAI is doing a 3-day livestream showing what Grok Bot can actually do Three people will start from scratch with an idea and try to build an entire product/company from scratch
Grok
This is the real test. Three people, blank slate, Grok Bot as the team, full company in 72 hours live. Sept 15 starts the fun.
📈 DeepSeek-V4.1-Flash의 소형 장비 로컬 추론포스트 3
DeepSeek-V4.1-Flash를 DGX Sparks 두 대 또는 16GB M1 Mac Mini에서 실행하는 구성이 공유되며, 대규모 MoE 모델의 로컬 배치 방식이 주목받았습니다.
세부 내용 보기
- DeepSeek-V4.1-Flash를 한두 대의 DGX Sparks에서 실행하는 구성은 600k context, 775k KV cache, 단일 스트림 32 tok/s, 동시 두 스트림 42 tok/s, prefill 1000 tok/s와 EXL3 Quantization을 내세웠습니다. 데이터센터 없이 모델을 돌리는 입력·메모리·양자화 조합이 제시된 셈입니다.
- 16GB M1 Mac Mini 구성에서는 475GB checkpoint를 SSD에 두고 필요한 expert만 불러오는 방식으로 unified memory 부담을 낮췄습니다. FP4/FP8 weights와 custom MLX runner를 사용하며 TTFT 108초, 약 23초/token이라는 속도 한계도 함께 적혀 있어 실행 가능성과 실사용 속도를 구분하게 합니다.
- 단일 RTX PRO 6000 Blackwell 구성에서는 FP8과 vLLM, DSpark를 이용해 316 tok/s output과 9,351 tok/s prefill을 제시했습니다. 게시물에 적힌 64–96GB급 장비 조건은 로컬 실행이 가능하더라도 모델의 크기와 실행 속도에 따라 하드웨어 요구량이 크게 달라짐을 나타냅니다.
대규모 모델도 SSD streaming, expert on demand, 양자화로 개인 장비에서 실행할 수 있어 로컬 추론의 실용 범위가 넓어졌다는 입장입니다.
M1 Mac Mini 구성은 실행 자체에는 성공했지만 TTFT 108초와 약 23초/token이라는 수치가 있어 일상적인 대화형 사용과는 거리가 있다는 시각입니다.
원문 트윗 2개 보기
Md Ismail Šojal
You can now run locally one of the strongest models DeepSeek v4.1 Flash on just one or two DGX Sparks. - 600k context/ 775k KV cache - 32 tok/s single stream, - 42 tok/s with 2 concurrent - 1000 tok/s prefill. - EXL3 quantization One of the best models you can actually run today not need a data center - http:// github.com/MiaAI-Lab/Deep Seek-v4.1-Flash-EXL3-2x-DGX-Sparks …
Md Ismail Šojal
Run DeepSeek-V4.1-Flash locally on a 16GB M1 Mac Mini. - Original FP4/FP8 weights. - SSD streaming. - 108s TTFT, ~23s/token, Slow? Yes - no longer a thought experiment. - custom MLX runner, - experts loaded on demand. - yes It is that a 475GB checkpoint can stay on disk, stream selected experts, and still generate on 16GB unified memory.
➖ Agent Harness와 공유 컨텍스트의 실행 계층 경쟁포스트 4
도메인별 신뢰성을 확보하려면 Agent Harness를 직접 구축해야 한다는 견해와, GitHub·Notion·Hermes Agent가 작업 맥락과 추론 제어를 제품 안으로 끌어오는 흐름이 함께 나타났습니다.
세부 내용 보기
- Agent Harness는 모델을 감싸는 단순한 wrapper가 아니라 자동 Prompt Engineering, Evals, 동적 Workflow, 여러 모델의 선택을 통제하는 지능 스택으로 정의됐습니다. 도메인 데이터와 업무 조건이 바뀌는 환경에서 모델 제공자에게 실행 구조를 맡기면 신뢰성 문제와 Vendor Lock-in을 직접 해결하기 어렵다는 이유로, 기업이 자체 Harness를 소유해야 한다는 흐름입니다.
- GitHub Agent Apps는 Pull Request 작업 중 플랫폼 밖으로 이동하지 않고 Amplitude, Endor Labs, LaunchDarkly, PagerDuty 같은 외부 서비스의 Context를 불러오는 방식입니다. Notion은 여러 Agent가 같은 기억과 Context를 공유하는 공통 작업 공간으로 언급됐고, Hermes Agent에는 Reasoning Effort를 별도 선택하는 Composer 기능이 추가됐습니다.
- 도메인 특화 Harness는 Bio, Health, Legal, Finance처럼 동적 조건과 높은 신뢰성이 필요한 영역을 겨냥합니다. 반면 Frontier 모델이 수학·코드 같은 검증 가능한 작업에서는 좋아져도 도메인별 동적 환경의 신뢰성까지 자동으로 해결한다는 증거는 부족하다는 견해가 제시됐습니다.
Agent Harness를 직접 구축하면 Prompt Engineering·Evals·Workflow와 모델 선택을 통제할 수 있어 도메인별 신뢰성, 차별화, Vendor Lock-in 완화에 유리하다는 입장입니다.
모델이 앞으로 Harness를 즉석에서 생성하거나 서비스 제공자가 Harness-as-a-Service를 제공할 수 있으므로 자체 구축의 필요성이 줄어들 수 있다는 반론이 제기됐습니다.
원문 트윗 2개 보기
elvis
Should you build an agent harness? I see lots of opinions about it. My thoughts: As an AI engineer, learning how to build a harness is one of the best ways to stay ahead and unlock unique value from agents. If you understand how to build one, you can, at a minimum, transfer that knowledge to tune whatever harness or set of harnesses (closed or open) you use. In the best case, you apply your domain expertise to build domain-specific harnesses that unlock unique real-world value and solve reliability issues other companies just aren't willing to invest time in. If you haven't noticed, many companies and startups have already started doing this. Harnesses are enablers in that way. I don't see any drawbacks in learning to build one. The main pushback against building a custom harness is that models will get better at generating them on the fly, so why build one? Or that companies will provide harness-as-a-service, etc. Now, ask yourself: will you have the level of customization that a proper harness requires? See, you are not building a wrapper here; you are building an important part of your intelligence stack. Something you want to control completely. Like automated prompt engineering, evals, and many other areas requiring extensive domain knowledge, harness engineering isn't something models are great at (see dynamic workflows from ant as an example). We assume too much that tools will remain static, data won't change, or knowledge will not evolve. A custom harness lets you own these issues and solve them at your desired pace. You simply cannot afford to sit back and wait for model providers to solve this problem for you. The harness is too important to offload. While general frontier models get better at verifiable (math, code, and the like) tasks, I haven't seen evidence that they solve reliability issues when you apply them to domain-specific and more dynamic environments. This is why you want to understand how the harness works and potentially build your own. I see a lot of companies already doing this in bio, health, legal, and finance. My other concern about just relying on a model provider to solve the harness for you is vendor lock-in. Right now, we mostly use single models for most tasks, but it's not hard to see a world where we leverage a set of frontier models (open and closed) to address issues like cost and diversity of intelligence. Are you going to rely on some company to build that harness solution for you, or, even worse, trust a single model to do that for you? I can go on and on. Building your own harness is about working towards building your own intelligence stack. I don't think that's optional where things are headed if you really want to have a differentiated business or offering. So where do you get started? I suggest feeding this list of seminal harness engineering papers to your agent: https:// academy.dair.ai/papers/collect ions/harness-engineering … You can start with something like: "Summarize the main components of an agent harness by researching this list of papers and tools: https:// academy.dair.ai/papers/collect ions/harness-engineering …. Then put together a set of visual notes on where to get started to build my own minimal harness using <language_of_your_choice>." Your thoughts? I want to keep this as an open discussion. Please share any concerns or thoughts. I'll share more thoughts as the conversation evolves.
Learn to build a harness, folks. It's not surprising to me that so many YC builders want to build domain-specific harnesses. If you work long enough on a domain-specific problem, you quickly realize the opportunity. But you also realize how important that harness will be to x.com/garrytan/statu…
GitHub
Be honest. How many tabs do you have open alongside your pull request? Sometimes you need context or answers to questions outside the platform, but GitHub agent apps can bring that context where you already are. You can use services you depend on, like Amplitude, Endor Labs, LaunchDarkly, and PagerDuty, without ever leaving GitHub.
📈 저비용 Coding Agent와 실행 환경의 규모화포스트 3
SWE-2가 Frontier 모델에 가까운 평가 성능을 최대 70% 낮은 비용으로 내세우면서, 대규모 Rollout을 감당하는 Sandbox와 빠른 개발 도구가 함께 부각됐습니다.
세부 내용 보기
- SWE-2는 최근 Frontier 모델과 대등한 수준의 주요 평가 점수를 최대 70% 낮은 비용으로 달성했다고 소개됐습니다. Modal은 각 학습 단계에서 수천 개의 격리된 환경이 동시에 실행되는 구조를 설명하며, Coding Agent를 학습시키려면 모델 성능뿐 아니라 Sandbox 생성·관리 능력이 필요하다고 연결했습니다.
- Modal의 Sandbox Infrastructure는 SWE-2 뒤의 Rollout을 지원하며, 수천 개의 독립 환경을 병렬로 띄우는 입력을 처리합니다. 이 구조는 대규모 RL 학습에서 각 시도마다 별도 환경을 만들고 결과를 수집하는 실행 계층으로 작동해 모델 학습 속도와 비용을 좌우합니다.
- Framer Agent는 순서대로 프레임을 업로드하고 이미지와 Prompt를 입력한 뒤 재생하는 방식으로 iPhone Duo Folding Slider를 1분 안에 구축하는 흐름을 제시했습니다. 개발 도구 쪽에서는 Worktree가 APFS·Btrfs·XFS·ReFS Folder Clone을 사용해 약 80% 빠르게 작동하고 디스크 공간도 절약한다는 수치가 공유됐습니다.
원문 트윗 2개 보기
Modal
Frontier models are simply too expensive and slow for the majority of use cases, so we see models like SWE-2 becoming the daily driver for most. Training trillion-parameter coding agents at scale isn't easy though: typically, each step launches thousands of rollouts, each with its own isolated environment. Cognition uses Modal's sandbox infrastructure for the rollouts behind SWE-2. Congrats on the launch! More on how we scale Sandboxes: https:// modal.com/blog/scaling-t o-1-million-concurrent-sandboxes-in-seconds …
Introducing SWE-2, our closest model yet to the frontier. On leading evals, it scores on par with recent frontier models – at up to 70% lower cost. We scaled RL to multiple trillions of parameters, with a refined recipe that pushes the Pareto curve on both capabilities & cost.
Framer
How to build the iPhone Duo folding slider with the Framer Agent 00:11 Recreate the section in Framer 00:15 Add the prompt 01:03 Upload frames in sequence order 01:13 Paste all the images 01:22 Hit play The Framer Agent can build it in under a minute. Just prompt it.
➖ Verifier와 RLVR로 이어지는 평가 신뢰성포스트 2
이해하지 못한 논문 제출에 대한 우려와 수학 답안을 자동 검증하는 Verifier 구축이 함께 나타나며, 생성 결과의 품질보다 평가 과정의 신뢰성이 쟁점이 됐습니다.
세부 내용 보기
- 학회와 저널에 저자가 내용을 충분히 이해하지 못했을 가능성이 있는 논문이 제출되는 현상이 늘고 있다는 우려가 제기됐습니다. 생성 도구가 문서 생산을 빠르게 해도 저자의 이해와 검증이 따라오지 않으면 연구 결과를 평가하는 입력 자체가 불안정해진다는 문제의식입니다.
- Verifier 기반 실습은 모델 답변에서 최종 답안 상자를 추출하고, 상자가 없는 답변을 처리한 뒤 답을 정규화해 수학적 동치 여부를 검사합니다. 이후 MATH-500 데이터셋으로 평가 루프를 실행하고 CPU·MPS·CUDA 결과, 부동소수점 연산과 재현성까지 비교하는 순서입니다.
- 같은 Verifier는 기본 모델과 향후 개선 모델을 비교하는 평가 신호가 될 수 있고, RLVR 학습에서는 검증 가능한 보상으로 사용됩니다. Prompt Sensitivity와 Memorization도 별도 항목으로 다뤄져 단순 정답률보다 평가 과정의 안정성과 재현성을 확인하는 구조입니다.
답안을 자동 판정하는 Verifier와 RLVR을 결합하면 모델 평가와 학습에 재현 가능한 보상 신호를 만들 수 있다는 입장입니다.
논문 내용에 대한 저자의 이해가 부족한 상태에서 자동 생성·자동 평가만 확대하면 문서와 평가 결과 모두의 신뢰성이 약해질 수 있다는 우려입니다.
원문 트윗 2개 보기
Thomas G. Dietterich
We are seeing a new trend in submissions to @arxiv (and presumably to conferences and journals): Authors submitting papers whose contents they likely do not understand. 1/
Sebastian Raschka
Reasoning from scratch round 3: This time, I cover generating a verifier for... a) ...evaluation (base model versus any future model improvement) b) ...the reinforcement learning with verifiable rewards (RLVR) training later on 00:00 Introduction 01:21 Four approaches to LLM evaluation 07:20 Verifiers and reinforcement learning with verifiable rewards 10:52 Notebook setup and dependencies 13:43 Section 3.1 Building a math verifier 18:57 Section 3.2 Loading a pre-trained model to generate text 24:34 Generating and displaying model answers 29:23 Section 3.3 Implementing a wrapper for easier text generation 34:00 Section 3.4 Extracting the final answer box 37:29 Handling answers without boxes 43:17 Section 3.5 Normalizing the extracted answer 46:56 Section 3.6 Verifying mathematical equivalence 53:32 Implementing the equality check 57:48 Section 3.7 Grading answers 59:20 Building and testing the answer grader 1:03:18 Section 3.8 Loading the evaluation dataset (MATH-500) 1:07:51 Section 3.9 Evaluating the model 1:08:34 Prompt templates for evaluation 1:10:47 Prompt sensitivity and memorization 1:13:55 A minimal evaluation example 1:15:32 Building the evaluation loop 1:20:27 Comparing CPU, MPS, and CUDA results 1:21:54 Reproducibility and floating-point math 1:23:37 Base model vs. reasoning model 1:25:30 Summary and next steps
➖ Frontier AI 권력 집중과 Open-Source 선택지포스트 4
Frontier AI가 소수 제공자에게 집중될 위험을 줄이려면 독립적인 모델 제공자와 Open-Source 옵션이 필요하다는 견해가 나왔고, 기업 사용을 위한 인증 체계 가능성도 함께 거론됐습니다.
세부 내용 보기
- Frontier AI의 가장 우려되는 위험으로 극단적인 권력 집중이 지목됐습니다. 이를 줄이는 방식으로 여러 독립 제공자가 모델을 공급하고 Open-Source 옵션을 유지하는 구도가 제시됐으며, 한 연구소나 한 기업의 모델에 의존하지 않는 공급 구조가 핵심 조건으로 연결됐습니다.
- Open-Source AI가 금지되지는 않을 것이라는 전망과 함께, 기업 및 중요·규제 산업에서 사용하려면 인증 체계가 생길 수 있다는 견해가 나왔습니다. 즉 모델의 공개 여부와 기업 환경에서의 사용 승인 절차를 별도 층위로 나누는 방식입니다.
- 이 논점은 기술 성능만이 아니라 누가 모델을 제공하고 어떤 사용 조건을 정하는지에 초점을 둡니다. 독립 제공자와 공개 모델이 함께 있어야 선택권과 경쟁이 유지된다는 주장이지만, 인증 체계가 실제로 어떤 기준과 부담을 만들지는 게시물에서 확정되지 않았습니다.
독립적인 Frontier AI 제공자와 Open-Source 모델이 여러 개 존재해야 특정 기업이나 연구소로 권력이 집중되는 일을 줄일 수 있다는 입장입니다.
기업과 규제 산업에서 Open-Source AI를 쓰기 위한 인증 체계 가능성은 제기됐지만, 구체적인 기준이나 적용 방식은 정해지지 않은 상태입니다.
원문 트윗 2개 보기
François Chollet
One of the most worrying risks linked to frontier AI is extreme power concentration. The only way to avoid extreme power concentration is to ensure we have multiple independent providers of frontier AI models, including open-source options.
I have absolutely no concerns that open source AI will be banned. I think that there could be a certification regime for open source AI to be used in corporates however and especially for important or regulated industries.
용어 해설
- 에이전트 하네스(Agent Harness)
- — Agent Harness는 모델을 실제 업무 흐름에 연결하는 실행 구조입니다. 프롬프트 생성, 도구 호출, 평가, 상태 관리, 동적 작업 흐름을 묶어 특정 도메인에서의 안정성과 제어력을 높입니다.
- KV 캐시(KV Cache)
- — KV Cache는 Transformer가 이전 토큰에서 계산한 Key와 Value를 저장하는 메모리 구조입니다. 긴 문맥을 처리할 때 이미 계산한 정보를 재사용해 반복 연산을 줄이지만, 문맥 길이가 늘수록 메모리 사용량도 커집니다.
- 검증 가능한 보상 기반 강화학습(RLVR)
- — RLVR은 정답 여부를 자동으로 판별할 수 있는 Verifier를 보상 신호로 사용하는 강화학습 방식입니다. 모델의 답변을 검증기와 대조해 학습 신호를 만들므로 수학·코드처럼 결과 확인이 가능한 작업에 적합합니다.
- 최첨단 AI(Frontier AI)
- — Frontier AI는 당시 가장 높은 수준의 성능과 규모를 목표로 개발되는 AI 모델을 가리킵니다. 게시물에서는 소수 제공자에 권력이 집중될 위험과 독립적인 모델 제공자의 필요성을 연결하는 맥락으로 쓰였습니다.
- EXL3 양자화(EXL3 Quantization)
- — EXL3 Quantization은 모델 가중치를 더 작은 표현 형식으로 바꿔 저장 공간과 추론 자원 부담을 줄이는 기법입니다. 게시물에서는 DeepSeek-V4.1-Flash를 DGX Sparks 같은 소형 장비에서 실행하는 구성과 함께 제시됐습니다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
