# Step 3.5 Flash – 고속 추론을 지원하는 오픈소스 LLM

> Clean Markdown view of GeekNews topic #26834. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26834](https://news.hada.io/topic?id=26834)
- GeekNews Markdown: [https://news.hada.io/topic/26834.md](https://news.hada.io/topic/26834.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-02-20T11:21:55+09:00
- Updated: 2026-02-20T11:21:55+09:00
- Original source: [static.stepfun.com](https://static.stepfun.com/blog/step-3.5-flash/)
- Points: 20
- Comments: 2

## Summary

1,960억 매개변수 중 110억만 활성화하는 **희소 Mixture of Experts 구조**로, 고속 추론과 실시간 상호작용을 동시에 구현합니다. 초당 350토큰 생성과 256K 컨텍스트 윈도우를 지원하며, **SWE-bench Verified 74.4%** 로 코딩·에이전트 작업에서 안정적인 성능을 보입니다. 강화학습 기반 **MIS-PO 최적화 기법**을 통해 장기 추론의 일관성을 확보하고, 로컬 환경에서도 프론티어급 추론 능력을 유지하도록 설계되었습니다. 댓글에 보니 평가가 꽤 좋네요.

## Topic Body

- 1960억 매개변수 중 110억만 활성화하는 **희소 Mixture of Experts 구조**로, 고속 추론과 실시간 상호작용을 지원  
- 초당 최대 350토큰의 생성 속도와 256K 컨텍스트 윈도우를 구현  
- **SWE-bench Verified 74.4%** 로 코딩·에이전트 벤치마크에서 안정적 성능을 보이며, **로컬 환경(Mac Studio M4 Max, NVIDIA DGX Spark)** 에서도 실행 가능  
- **도구 활용 기반 추론**과 **멀티에이전트 오케스트레이션**을 통해 금융, 데이터 분석, 연구 자동화 등 실제 업무 시나리오에서 높은 신뢰성과 실행력을 입증함  
- 강화학습 기반의 **MIS-PO 최적화 기법**으로 장기 추론 안정성을 확보하며, 고성능 모델 대비 낮은 비용으로 **프론티어급 추론·행동 능력**을 제공함  
  
---  
  
### 모델 개요 및 성능  
- Step 3.5 Flash는 **고속 추론과 에이전트 기능**을 결합한 오픈소스 기반 **foundation model**로, 평균 벤치마크 점수 81.0을 기록  
  - GLM-4.7(78.5), DeepSeek V3.2(77.3), Kimi K2.5(80.5) 등 주요 모델보다 높은 평균 점수  
- **희소 MoE 구조**로 196B 중 11B 파라미터만 활성화, 효율적 연산으로 실시간 대응 가능  
- **MTP-3** 기반으로 일반 사용 시 100~300 tok/s, 코딩 작업 시 최대 350 tok/s 생성 속도 달성  
- **SWE-bench Verified 74.4%** , **Terminal-Bench 2.0 51.0%** 로 장기적 코드·에이전트 작업에서 안정적 성능 확보  
- **256K 컨텍스트 윈도우**를 3:1 SWA 구조로 구현, 긴 문맥에서도 비용 효율 유지  
  
### 실제 활용 사례 및 도구 활용  
- **도구 기반 추론(tool-augmented reasoning)** 을 통해 수학·코딩·데이터 분석 등에서 성능 향상  
  - Python 실행 통합 시 AIME 2025(99.8), HMMT 2025(98.0), IMOAnswerBench(86.7) 등에서 향상된 점수 기록  
- **주식 투자 시나리오**에서 80개 이상 MCP 도구를 조합해 데이터 수집·분석·알림 자동화 수행  
- **Autonomous Business Intelligence Engine**은 CSV 처리부터 예측까지 자동화, 데이터 품질 격차(1.6배) 식별  
- **Large-Scale Repository Architect**는 대규모 코드베이스를 분석해 설계 패턴과 구현 세부를 연결하는 전문 위키 생성  
  
### 연구 및 에이전트 성능  
- **ResearchRubrics 벤치마크**에서 65.3%로 Gemini DeepResearch(63.7), OpenAI DeepResearch(60.7)보다 높은 점수  
  - 단일 ReAct 기반 루프에서 계획·검색·검증·작성 과정을 수행  
- **Claude Code 환경**에서 데이터 분석 벤치마크 39.6% 달성, GPT-5.2(39.3)보다 근소하게 우위  
- **Multi-Agent Framework**를 통해 Master Agent가 검색·검증·요약 에이전트를 조율, 구조화된 결과 생성  
- **Cloud-Device Synergy**로 Step-GUI와 연동 시 AndroidDaily Hard 벤치마크에서 57점(단독 40점 대비) 기록  
  
### 아키텍처 및 기술적 특징  
- **Sparse MoE 백본**으로 글로벌 용량(196B)과 토큰당 연산(11B)을 분리, **추론 비용과 속도 최적화**  
- **Sliding-Window Attention + Full Attention(3:1)** 구조로 긴 문맥 처리 시 효율 유지  
- **Head-wise Gated Attention**으로 정보 흐름을 동적으로 제어, 수치 안정성 확보  
- **350 tok/s**의 디코딩 처리량을 NVIDIA Hopper GPU에서 달성  
- **INT4 GGUF 양자화 모델**을 통해 **로컬 추론(20 tok/s, 256K 컨텍스트)** 지원  
  
### 강화학습 프레임워크  
- **Metropolis Independence Sampling Filtered Policy Optimization(MIS-PO)** 도입  
  - 중요도 샘플링 대신 **이진 필터링**으로 불안정한 샘플 제거  
  - **truncation-aware value bootstrapping**과 **routing confidence monitoring**으로 장기 추론 안정화  
- 이 구조는 수학·코딩·도구 활용 전반에서 **지속적 자기개선**을 가능하게 함  
  
### 벤치마크 비교  
- Step 3.5 Flash는 Reasoning, Coding, Agentic 세 영역에서 **균형 잡힌 상위권 성능**  
  - AIME 2025: 97.3 / HMMT 2025: 98.4 / LiveCodeBench-V6: 86.4  
  - τ²-Bench: 88.2 / BrowseComp-ZH: 66.9 / ResearchRubrics: 65.3  
- **디코딩 비용**은 128K 컨텍스트 기준 1.0x로, DeepSeek V3.2(6.0x), Kimi K2.5(18.9x)보다 효율적  
  
### 한계 및 향후 방향  
- **토큰 효율성**: Gemini 3.0 Pro 대비 동일 품질에 더 긴 생성 필요  
- **전문성 통합**: 범용성과 전문성의 효율적 결합을 위한 on-policy distillation 연구 진행 중  
- **에이전트형 RL 확장**: 전문 업무·연구 수준의 복잡한 작업으로 RL 적용 확대 예정  
- **운영 안정성**: 장기 대화나 도메인 전환 시 반복 추론·혼합 언어 출력 가능성 존재  
  
### 배포 및 접근성  
- **OpenClaw 플랫폼**과 통합되어 간단한 설치 및 모델 등록으로 사용 가능  
- **API 플랫폼**(영문/중문), **웹·모바일 앱(iOS/Android)** 을 통해 접근 가능  
- **Discord 커뮤니티**를 통해 업데이트 및 지원 제공

## Comments



### Comment 51496

- Author: sftblw
- Created: 2026-02-20T23:28:06+09:00
- Points: 1

이 모델 좀 치네요  
여건이 되셔서 llama.cpp 로 돌려보실 분들은 아래 글타래의 댓글에 있는 프롬프트를 따로 적용해주셔야 합니다. 아니면 여는 <think> 없이 중간에 </think> 하나만 달랑 나오는 문제가 있습니다.  
https://huggingface.co/stepfun-ai/Step-3.5-Flash-GGUF-Q4_K_S/discussions/12  
```  
llama-server \  
  옵션생략 \  
  --jinja \  
  --chat-template-file 경로/step3p5_flash_chat_template.jinja  
```

### Comment 51462

- Author: neo
- Created: 2026-02-20T11:21:55+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47069179) 
- 최근 몇 달 사이 나온 LLM 중 가장 **저평가된 릴리스** 중 하나라고 생각함  
  로컬에서 4-bit quant 버전([Step-3.5-Flash-GGUF](https://huggingface.co/ubergarm/Step-3.5-Flash-GGUF/tree/main/IQ4_XS))으로 테스트했는데, Minimax 2.5나 GLM-4.7보다도 뛰어났음 (GLM은 2-bit만 가능했음)  
  주요 특징은 다음과 같음  
  - **컨텍스트 효율성**이 매우 높음. 128GB Mac에서 256k 컨텍스트 전체 또는 128k 두 스트림을 동시에 실행 가능함  
  - M1 Ultra에서 속도도 좋음 (36 t/s tg, 300 t/s pp)이며, 컨텍스트가 커져도 속도 저하가 완만함  
  - **agentic coding**에 최적화되어 있고, Claude 코드와 호환되도록 훈련된 듯함. Codex만 패치 편집 도구 문제로 예외임  
  200B 파라미터급 모델 중 CLI 하네스에서 실제로 쓸만한 첫 로컬 모델임. pi.dev와 함께 쓰는 중인데 최고의 경험이었음  
  단점으로는 **무한 추론 루프 버그**가 있음 ([관련 이슈](https://github.com/ggml-org/llama.cpp/pull/19283#issuecomment-3870270263))  
  StepFun이 ACEStep(음악 생성 모델)도 만든 회사로 보이며, [ComfyUI 문서](https://docs.comfy.org/tutorials/audio/ace-step/ace-step-v1)에도 언급되어 있음
  - Qwen3 Coder Next를 OpenCode와 함께 테스트해봤는데 꽤 잘 작동했음  
    가끔 도구 호출을 잘못하지만, Qwen이 제안한 temperature=1 설정에서는 멈추지 않음  
    Nemotron 3 Nano는 도구 사용이 부족해서 대부분 shell tool만 쓰는 경향이 있었음  
    전반적으로 **agentic open weight 모델**들이 익숙하지 않은 도구를 잘 호출하지 않는 경향이 있음
  - M3 Ultra(512GB RAM)로 OSS 모델을 돌리는 게 Claude나 Codex 구독보다 **경제적**일지 궁금함  
    이런 계산을 해본 사람이 있는지 묻고 싶음
  - **무한 추론 루프** 문제를 추론 엔진 변경으로 해결할 수 있을지 궁금함  
    내 생각엔 모델 가중치 자체를 수정해야 하는 문제 같음
  - MLX 버전으로 돌려봤는지 궁금함. 이론상 더 빠르겠지만 여러 버전을 받는 게 망설여짐
  - gpt-oss 120b나 20b도 Codex와 잘 작동했음

- 최근 “Walk or drive to the carwash” 트릭의 **추론 과정(reasoning)** 을 흥미롭게 읽었음  
  관련 링크: [gist](https://gist.github.com/lm2s/c4e3260c3ca9052ec200b19af9cfd709), [stepfun.ai 대화](https://stepfun.ai/chats/213451451786883072)

- Terminal-Bench 2.0에서 51.0% 점수를 받았다고 하는데, 그게 정말 ‘**안정적인 장기 작업 처리 능력**’을 보장하는지는 의문임
  - 51%라는 수치만으로는 의미가 크지 않음. 이런 벤치마크는 절대 점수 기준이라 100%가 인간 수준을 의미하지 않음  
    [리더보드](https://www.tbench.ai/leaderboard/terminal-bench/2.0)를 보면 최고 점수가 75%라서 51%는 SOTA의 약 ⅔ 수준임
  - 그 점수는 Gemini 3 Flash와 비슷하지만, 실제로는 모델보다 **에이전트 구성**이 점수에 더 큰 영향을 주는 듯함
  - TerminalBench는 이름과 달리 터미널과 거의 관련이 없고, 대부분 **랜덤 도구 문법 테스트**에 가까움  
    모델이 단순히 명령어 플래그를 암기했을 수도 있음

- 테스트해보니 **환각(hallucination)** 이 심했음. “포켓몬 챔피언 덱 찾아줘” 같은 간단한 질문에서도 부정확했음  
  Opus 4.6, Deepseek, Kimi는 예상대로 잘 작동했음
  - 실행용으로는 중간 크기 모델을 쓰는 게 낫다고 생각함  
  - Gemini 같은 모델은 **검색 기능**을 적극 활용하기 때문에 더 빠르고 정확했을 가능성이 있음

- 최근 공개된 모델로, **Mixture of Experts (MoE)** 구조를 사용해 토큰당 196B 중 11B만 활성화함  
  Kimi K2.5와 GLM 4.7보다 더 많은 벤치마크에서 우세함  
  128GB 머신에서도 4-bit quant 버전으로 실행 가능 ([참고 링크](https://forums.developer.nvidia.com/t/running-step-3-5-flash-on-single-spark/359457/12))
  - 벤치마크 우위가 실제로 의미 있는지 의문임. 나는 **지시 따르기, 긴 문맥 추론, 비환각성**을 더 중요하게 봄  
  - Q4_K_S(116GB), IQ4_NL(112GB), Q4_0(113GB) 중 어떤 게 더 나은지 궁금함  
    [모델 페이지](https://huggingface.co/bartowski/stepfun-ai_Step-3.5-Flash-GGUF) 참고

- 최근 모델들이 벤치마크 점수는 높지만 **토큰 사용량 폭증**이 동반됨  
  진정한 혁신을 위해선 **전력 효율성** 문제를 해결해야 함
  - 단순히 토큰 수뿐 아니라 **토큰당 에너지 효율(tokens/joule)** 도 중요함  
    MoE 구조의 효율적 사용이 tokens/joule과 tokens/sec 모두에 영향을 줌

- SWE-bench Verified는 괜찮지만, 더 나은 **SWE 벤치마크**가 필요함  
  공정한 벤치마크를 만들려면 지속적인 실행 비용이 많이 듦  
  “라이브 벤치마크” 개념은 좋지만 최신 모델을 충분히 반영하지 못함  
  - Terminal Bench 3.0 개발에 참여해달라는 제안이 있었음  
    [문서 링크](https://docs.google.com/document/d/1pe_gEbhVDgORtYsQv4Dyml8uaR7PZBEyVZnBUrs1z0M/edit?pli=1&tab=t.0)

- 파라미터 수보다는 **tokens per dollar/sec**가 더 중요한 지표라고 생각함  
  상위 모델들은 로컬 추론을 지원하지 않기 때문임
  - 오픈소스 모델이라면 **셀프 호스팅**을 고려하는 사람에게는 파라미터 수도 중요함  
  - 파라미터 수는 여전히 **모델 성능의 대략적 지표**임  
    예를 들어 Qwen3 0.6b는 tok/dollar는 훌륭하지만 대부분의 용도에는 부족함  
  - 이 모델은 **$3,000 이하의 머신**에서도 로컬 실행이 가능하다는 점에서 의미 있음

- 간단한 테스트에서 몇 가지 관찰을 했음  
  1) 출력 trace가 매우 장황하고 **LinkedIn 스타일**처럼 문단이 짧았음  
  2) 호스팅 버전의 토큰 출력 속도가 매우 높았음  
  3) **지시 준수도와 출력 품질**이 Opus 4.5 등 주요 모델보다 우수했음

- 그래프의 **x축이 반전**되어 있어서 헷갈렸음  
  - 나도 같은 생각임. 왜 그렇게 했는지 모르겠음  
  - 아마 그래프를 더 좋아 보이게 하려던 것 같지만, 실제로는 그렇지 않음