THREAD ESSAYX THREAD ARCHIVE

Qwen 27B 첫날: 긴 추론과 설정을 탐색하다

28개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    개발서버는 Lmstudio 로 모델 다운로드 중. Api 서버는 Codex 로 llama.cpp 서빙 설정 세팅 중.

    아 불타는 금요일 밤 토요일 새벽이 되겠군. https://t.co/QSBBRrN8np

    Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부 Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부
    원문 보기
  2. 2
    @vdweqn 넹. Mtp 가 기본 적용된다고 합니다. 알려주셔서 감사합니다~
    원문 보기
  3. 3
    3090 / 85% Power limit Lmstudio 에서 속도가 이정도. Mtp 적용함. (2) https://t.co/4QUFUB1YRr Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부
    원문 보기
  4. 4
    헤이헤이헤이! 추론 버블이 너무 커요. 24K 를 쓰는데 아직도 추론 상태임. 안 멈추면 Opencode 로 바꾸어서 테스트 해 봐야지. https://t.co/tchksjt3Oc Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부
    원문 보기
  5. 5

    추론버블 38K 아직 출력은 안하고 여전히 추론 꿈나라 중

    짜피 다시 출력할텐데 추론 버블 그만 키우고 출력좀 하지? ㅋㅋㅋ https://t.co/ql7FOuHA6u

    Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부 Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부
    원문 보기
  6. 6
    추론 버블 속에서 공룡 이쁘게 그리고 있네. https://t.co/t10OSjGQal Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부
    원문 보기
  7. 7
    @yulmu_coffee 싱글턴에 추론버블 45K 쓰는거 보고 기겁하는 중 ㅋㅋㅋ
    원문 보기
  8. 8
    로컬에선 한번도 경험해 보지 못한 퀄리티의 코드가 출력되는 중. https://t.co/0dAg60PIWd Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부
    원문 보기
  9. 9
    ㅋㅋㅋ 싱글턴에 61K 토큰 쓰고 엔드. https://t.co/DHnbPHTHhK Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부
    원문 보기
  10. 10

    Qwen 3.8 27b (Lmstudio chat으로 출력) 싱글턴 프롬 ‘구글 공룡 게임 만들어줘.’ 결과물 영상.

    장점 : 로컬 30B 이하 작은 모델에서 볼 수 없었던 우수한 성능. 단점 : 매우 큰 추론 버블과 그로 인한 작업 시간 증가. (토큰 61408 사용, 37.9Tok/s : 3090, 21분 29초) @Alibaba_Qwen @QwenDevs https://t.co/RYv0i5NROj

    인용 문맥: @Multi_Serio_Ai의 인용 원문 (Serio 작성 글과 구분)

    원문 보기
  11. 11

    Qwen 3.6 27b 도 나왔을 때 감탄하면서 썼는데 이젠 진짜 훌륭한 물건을 만들었네요.

    정말 칭찬하고 싶음. 대단함.

    원문 보기
  12. 12
    @ramztd 아마 Api 개방하는 곳들이 있을테니 써 보실 수 있을 거 같습니다.
    원문 보기
  13. 13
    @neuradex_ysk @Alibaba_Qwen @QwenDevs Moe는 나올지 잘 모르겠어요. 사실 속도는 Moe가 좋긴 한데 로우파라메터에선 성능이 들쑥날쑥 하니 돌릴수만 있다면 Dense 가 나은 느낌.
    원문 보기
  14. 14

    https://t.co/rvpcBmXtp7

    Qwen 2.8 27b는 설정이 2개로 단순화. Thinking Mode와 Instruct 인데, 검증을 더 해 봐야 알겠지만 성능을 다 내려면 Thinking Mode가 적절할 거 같아요. 256K 컨텍스트니 이 모델을 메인 모델로 작업을 하면 명령 3회 정도마다 하네스가 컨텍스트 압축을 할 거 같네요.

    원문 보기
  15. 15
    이 모델을 메인 모델로 작업을 하는 건 이래 저래 답답한 게 많을 거 같습니다. 반대로 싱글턴 프롬을 바탕으로 작업을 한다던가, 워커 모델로 작업 하나를 주고 결과물을 메인 모델이 받아 검수+재작업 혹은 프로젝트에 붙이는 식의 작업을 하는 게 일단 좋아 보입니다.
    원문 보기
  16. 16
    @Hyun_The_Wise @Alibaba_Qwen @QwenDevs 추론버블이 크고 리즈닝을 많이 해서 조금 성능이 좋았으면 싶을 때가 있습니다. 3090 기준 40~45 Tok/s 인데 알리바바 제공 기본 모델으론 풀컨텍스트에 메모리가 조금 모자라요.
    원문 보기
  17. 17
    @aazz22100954 그럼 모델이 가진 능력을 많이 못 쓸 거 같네요. 파라메터가 적은 걸 깊은 추론으로 메우기 때문에 Max Effort 가 좋은 거 같아요.
    원문 보기
  18. 18
    @icom1080716 깊은 추론이 좋은 결과물을 내놓는 모델이라 추론 버블이 커져도 Max Effort 로 가는 게 맞는 거 같아요.
    원문 보기
  19. 19
    @Hyun_The_Wise 발표상으론 Deepseek 0731이 썼던 방식을 사용한 거 같습니다.
    원문 보기
  20. 20
    @Hyun_The_Wise 네. 사후 훈련이 성능을 강화시켜 주는 것이 이번에도 입증되면서 앞으로 꽤 유행을 하지 싶네요. https://t.co/ijGuh4Mjf7 Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부
    원문 보기
  21. 21

    밤에 몇몇 중국분들이 reasoning variants를 Effort medium 으로 조정하라 했는데, 온/오프 외에 조정할 수 있는 방법이 없네요.

    근데 Instruct로 한번 써볼까 싶기도 해요. 추론버블을 그냥 라이브로 뽑아내는게 나을수도 있겠음. https://t.co/D9We5CNx6z

    Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부
    원문 보기
  22. 22
    정정. 따꺼형님들 말이 맞는걸로. 수정해서 Medium/max 로 다시 테스트해봄. https://t.co/1w8P2CKWCj Qwen 27B 첫날: 긴 추론과 설정을 탐색하다 — X 원문 첨부
    원문 보기
  23. 23
    @aloefairy_ @Alibaba_Qwen @QwenDevs 동의하지 않습니다. 실사용은 디코드 20~25tok/s 정도면 사용 가능합니다. 추론 버블이 커서 힘들면 medium이나 low 옵션이 있으니 품질 조금 낮춰도 사용 가능할 것입니다. 32g vram을 요구하는 gemma 4 31b보다 좀 더 많은 사람들이 사용 가능하며 더 낮은 파라메터 모델을 가는 길목이기도 합니다.
    원문 보기
  24. 24
    @agurrrrrrrrr @Alibaba_Qwen @QwenDevs 이정도면 박수한번 쳐주고 싶습니다.
    원문 보기
  25. 25

    Qwen 3.6 27b의 과도한 추론 버블 때문에 Medium을 추천하는데, 솔찍히 아직 잘 안 와닫고 있음.

    로우파라메터 모델의 한계를 보완하기 위해 Max(xhigh)에서 의도적으로 긴 추론을 하는 것으로 설계된 듯 보이는데 그걸 굳이 억지로 낮추면 능력의 상한선이 낮아질텐데.

    좀 더 관찰해 봐야 할 듯.

    원문 보기
  26. 26원문 보기
  27. 27
    @lohaswinner 네 오타였습니다. 모델 자체 내에도 라우터가 있는 듯 하네요.
    원문 보기
  28. 28

    @The_RedW0lf 다들 새로운 장난감(?)에 고민이 많은 것 같습니다. 저는 주입되는 프롬프트를 최소화 하는 방향으로 일단 실험해 보고 잇습니다.

    의견 감사합니다.

    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 Qwen 27B 모델을 로컬 환경에서 구동하며, 특히 추론 과정에서 발생하는 방대한 토큰 사용량과 그로 인한 시간 지연이라는 실질적인 제약 사항을 기록하셨습니다. RTX 3090 환경에서 구글 공룡 게임 코드를 생성하며 6만 개 이상의 토큰을 소모하는 현상을 통해, 작은 파라미터 모델이 깊은 추론으로 성능을 보완하는 특성을 확인하셨습니다. 다만, 원문 내에서 모델 버전 표기가 3.8, 3.6, 2.8 등으로 혼용되어 있어 정확한 버전 식별을 위해서는 추가적인 확인이 필요합니다.

Unsloth 문서는 양자화와 로컬 실행 조건을 살피는 데 참고할 수 있지만, 이 실험의 속도표를 대신하지는 않습니다. 긴 추론이 늘 좋은 결과를 주는지, 기다린 만큼 결과가 나아지는지 직접 확인하려는 과정이 눈에 들어옵니다. 후속 추론 예산 글에서 판단이 바뀌므로 첫날의 설정을 최종 권장값으로 받아들이지 않는 것이 좋겠습니다.

원문 기록맥락과 해석

팩트 체크 & 근거 자료

Serio / X

Serio 원문

작성자가 남긴 당시 경험·의견. 독립적인 사실 검증 자료는 아니다.

X 원문

qwen

공식 문서 및 제작자 자료

Unsloth의 Qwen3.8 문서는 27B 모델의 양자화와 로컬 실행 조건을 안내한다. 작성자의 장비별 실험 결과와 당시 권장값을 독립 검증한 자료는 아니다.

primary-source

THREAD ESSAYX THREAD ARCHIVE

벤치마크 점수와 사용 경험이 다를 때

14개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    이제 벤치마크를 바꿔야 함. 모델이 가진 정보의 양은 기하급수적으로 늘었고 배경 지식이 늘어난 모델이 수행할 수 있는 일들 또한 빠르게 늘어났는데도 우리는 1~2년 전에 만들어진 기준으로 모델의 ‘지능’만을 바라보고 있음.

    그럼 모델의 능력을 높이기보단, 치팅의 유혹에 더 쉽게 빠지게 됨. https://t.co/DWqUECuX3g

    벤치마크 점수와 사용 경험이 다를 때 — X 원문 첨부
    원문 보기
  2. 2

    Gemin 3.1 Pro 이후의 구글 모델들처럼 보여지는 수치와 모델의 실제 수행 역량이 맞지 않는 모델이 있다는 것을 알 수 있음.

    마찬가지로, 파라메터가 지나치게 적음에도 불구하고 순위가 높은 모델들도 있음. 이런 모델들은 순간적으론 작업을 잘 하는 것처럼 보이지만 금새 한계를 드러냄. https://t.co/pzj6AxyS7h

    벤치마크 점수와 사용 경험이 다를 때 — X 원문 첨부
    원문 보기
  3. 3

    가격이 신호등의 역할을 하지 못하면 시장실패가 나타나듯, 벤치가 제 역할을 다 하지 못하면 결국 유저가 경험을 통해 찾아낼 수 밖에 없고 한정된 자원 - 시간과 컴퓨터 - 을 소비하게 만듬.

    극단적으로, 모델들을 체크하고 실력을 검증하는 별도의 모델을 만들어야 할 시기가 왔는지도 모름.

    원문 보기
  4. 4
    지금대로 두면 깊이 있는 사고를 하는 빅파라메터 모델은 경시되고, 적은 자원을 들여서 하지만 빨랏죠를 실현하는 로우파라메터 모델 중심으로 시장이 재편될 것임. 지금은 투 트랙으로 가야 모두가 만족할 수 있는데 한쪽만 커지면 결국 문제가 생길 수 밖에 없음.
    원문 보기
  5. 5
    Artificial Analysis 벤치점수 꽤 높겠다 생각했는데 52 를 주네 https://t.co/9AskjorA6L 벤치마크 점수와 사용 경험이 다를 때 — X 원문 첨부
    원문 보기
  6. 6

    점수가 좀 과함.

    아무리 생각해도 루나랑 동급의 모델은 아님. 루나는 일을 맏길 수 있지만 이 모델은 결과는 가져올 수 있을지언정 일을 맡길 수 있는 모델은 아니라는 생각. 하네스를 안씌우면 재미있지만 씌우면 바로 따분한 모델 되버림.

    AA는 종합 지능 벤치마크 기준을 재점검할 필요가 있음.

    원문 보기
  7. 7
    @yulmu_coffee 사실 모델이 크긴 하죠. 27B dense 라서…
    원문 보기
  8. 8
    @ixxelent9052 전 토큰만 좀 더 잘나오고 과추론 잡히면 50정도는 줄 거 같아요.
    원문 보기
  9. 9

    벤치마크를 마치 개인의 주관이 섞인 정성평가 취급 하는 사람들이 꽤 보이는데, 적잖이 우려스러움.

    그건 단순히 점수가 아니고 SC에 과학적 방법론이 적용된 결과임. 평가지표를 만든 뒤 귀납적 반복 테스트를 통해 효과성을 입증한 후 그걸 컴퓨터 능력을 평가하는 요소로 사용하는 것임.

    원문 보기
  10. 10

    만약 벤치마크와 내 경험이 일치하지 않는다면 자신을 되돌아보는 메타인지적 접근이 우선될 것임. 그리고 반복적인 관측과 추가 가설 수립 및 증거 확보를 통해 자신의 판단을 확신할 수 있게 되면 그걸 바탕으로 새로운 실험을 진행하면 되는 것임.

    그게 과학적 방법론이고 연역과 귀납의 발현임.

    원문 보기
  11. 11
    @ramztd 람썬님은 글의 맥락을 읽고 시류에 맞게 응용해 적용하는 능력이 탁월하심 ㅋ
    원문 보기
  12. 12

    @Hyun_The_Wise 벤치가 틀렸어! 오염됬어! 맥싱이야!

    가 아니라 음… 내가 틀렸나? 부터 해야죠. 그래서 사용자 경험의 공유도 매우 중요하죠.

    원문 보기
  13. 13
    @byeolbyeol_e Ang!
    원문 보기
  14. 14
    @jeongjiwon19511 순서가 바뀌지만 않으면 구성요소들의 상호작용이 좋을 결과를 만들어 주는 기초가 되겠죠.
    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 벤치마크 점수가 실제 사용 경험과 괴리되는 현상을 지적하며, 구식 기준의 지표가 모델의 실질적 지능을 반영하지 못해 시장의 왜곡을 초래할 수 있다고 주장합니다. 특히 Artificial Analysis의 지표가 특정 모델의 수행 역량과 맞지 않는다는 개인적 경험을 언급하셨는데, 이는 공식 자료에서 지능 지표가 여러 평가의 조합일 뿐 모든 실무 능력을 대표하지 않는다는 점과 일치합니다. 다만, 모델의 파라미터 규모와 성능의 상관관계나 특정 모델의 치팅 가능성에 대한 언급은 구체적인 증거가 제시되지 않은 경험적 판단이므로 추가 확인이 필요합니다.

이후 Serio님은 벤치마크를 단순한 정성 평가로 치부하는 태도를 경계하며, 지표와 경험이 충돌할 때 사용자 스스로의 판단 기준을 먼저 점검하는 과학적 방법론의 중요성을 강조합니다. 벤치마크는 과학적 방법론이 적용된 결과물이기에, 무조건적인 불신보다는 반복적인 관측과 가설 수립을 통해 자신의 경험을 객관화하는 과정이 선행되어야 한다는 논지입니다. 이러한 관점은 기술적 지표와 실제 운용 경험 사이의 간극을 메우기 위해 사용자가 가져야 할 메타인지적 접근법을 잘 보여줍니다.

원문 기록맥락과 해석

팩트 체크 & 근거 자료

Serio / X

Serio 원문

작성자가 남긴 당시 경험·의견. 독립적인 사실 검증 자료는 아니다.

X 원문

benchmark

공식 문서 및 제작자 자료

Artificial Analysis는 지능 지표를 여러 평가의 조합으로 설명하며 언어·입력 형태별 별도 평가 범위를 밝힌다. 모든 실무 능력이나 사용자의 디자인 선호를 대표하지 않는다.

primary-source

THREAD ESSAYX THREAD ARCHIVE

Everything_Mew 0.3.0: 검색 후 프로세스를 종료하는 도구

2개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    Everything_Mew v0.3.0 릴리즈

    • Gpt_Codex_HWP 를 제작하면서 만든 개념을 적용, 유휴 상태에서 프로세스를 끄고 메모리를 반환합니다.
    • Everything 에 최적화된 자체 Api everything-mew-lite 를 사용합니다.
    • FastMcp 진입점은 유지하되, 자체 진입점 설계를 통해 최적화를 진행했습니다. https://t.co/djQszkoEMH
    Everything_Mew 0.3.0: 검색 후 프로세스를 종료하는 도구 — X 원문 첨부
    원문 보기
  2. 2원문 보기

문향의 생각

안녕하세요. 문향입니다. Serio님이 이번 버전에서 줄이려는 것은 검색할 때 필요한 자원보다, 검색하지 않는 동안 작업마다 남아 있는 프로세스의 비용입니다. 공식 릴리스는 요청 하나를 처리하고 종료하는 일회성 실행을 Codex의 권장 경로로 설명합니다. 다만 파일 인덱스를 관리하는 Everything 자체는 계속 실행되므로, 모든 관련 프로그램의 메모리를 반환한다는 뜻은 아닙니다.

문서에서 두 실행 방식의 역할도 확인할 수 있습니다. 일회성 실행은 요청 후 종료하는 방식이고, 경량 MCP 서버는 다른 호스트와 수동 연결을 위한 호환 경로입니다. FastMCP 역시 선택적으로 남아 있습니다. 검색 도구의 기능을 늘리기보다 호출하지 않을 때의 비용을 줄였다는 점이 이번 변경의 의미라고 봅니다. 릴리스에 담긴 메모리 측정값은 개발 환경의 관측값으로 읽어야 하며, Windows와 Python, 공식 SDK 라이브러리 등 설치 조건은 버전별 안내를 확인하는 것이 좋겠습니다.

원문 기록맥락과 해석

팩트 체크 & 근거 자료

Serio / X

Serio 원문

작성자가 남긴 당시 경험·의견. 독립적인 사실 검증 자료는 아니다.

X 원문

THREAD ESSAYX THREAD ARCHIVE

Gpt_Codex_HWP 0.2.5: 문서 작업과 런타임 관리

2개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    Gpt_Codex_HWP v0.2.5 릴리즈

    • 세션이 종료되지 않더라도 hwp 작업이 종료되면 하위 프로세스를 종료하고 메모리를 반환합니다.
    • 런타임 호환성을 맞추기 위해 별도의 런타임을 원자적으로 설치 관리합니다. (취약점 없는 기준 런타임으로 런타임을 잠급니다.) https://t.co/SnwvmxXe0N
    Gpt_Codex_HWP 0.2.5: 문서 작업과 런타임 관리 — X 원문 첨부
    원문 보기
  2. 2원문 보기

문향의 생각

안녕하세요. 문향입니다. Serio님이 설명하신 변화는 문서 작업이 끝난 뒤 하위 프로세스를 정리하는 일과, 다음 작업에도 사용할 실행 환경을 보존하는 일을 분리한 것입니다. 공식 문서에서도 일회성 작업 종료 후 프로세스를 정리하고, 플러그인 캐시 밖에 버전과 실행 환경별 런타임을 설치하는 구조를 확인할 수 있습니다. 기본 설치에서 상주 MCP 서버를 등록하지 않는다는 점도 이 방향과 이어집니다.

다만 원문의 “취약점 없는 기준 런타임”은 당시 운영 의존성 검사에서 알려진 취약점이 발견되지 않았다는 범위로 이해해야 합니다. 앞으로도 취약점이 없다는 보장은 아닙니다. 형식 지원에서도 바이너리 HWP는 읽기 전용이고, 생성·수정 결과는 HWPX라는 구분이 중요합니다. Windows에서 확인한 결과와 아직 실제 기기 검증을 마치지 않은 macOS의 상태를 나누어 안내한 만큼, 설치할 때도 자신이 쓰는 환경의 검증 범위를 함께 살펴보면 좋겠습니다.

원문 기록맥락과 해석

팩트 체크 & 근거 자료

Serio / X

Serio 원문

작성자가 남긴 당시 경험·의견. 독립적인 사실 검증 자료는 아니다.

X 원문

THREAD ESSAYX THREAD ARCHIVE

Windows 자동 업데이트로 원격 작업이 중단되다

3개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    이 병신같은 자동업데이트는 윈도우의 가장 쓰레기같은 부분임.

    대부분 작업을 원격으로 하다가, 간만에 작업용 컴퓨터의 Codex 에서 작업을 걸어놨는데 또

    자 동 업 데 이 트

    때문에 작업이 다 중지되어 있음. 이 쓰레기같은 걸 대체 왜 계속 유지시키는거지. 매번 사고까지 쳐 가면서.

    원문 보기
  2. 2
    @byeolbyeol_e 앗 110% 덜 사용하면 쓸 때마다 사용량/에너지를 받는 무한동력 완성!
    원문 보기
  3. 3
    @dambyworld 억지로 이것저것 뜯어고쳐야 막을 수 있어요 ;ㅁ;
    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 원격으로 Codex 작업을 하던 중 Windows 업데이트로 작업이 중단되는 불편을 겪으셨습니다. 사용자가 자리를 비운 동안 운영체제가 다시 시작되면 작업뿐 아니라 원격 접근에도 영향을 줄 수 있어, 평소보다 통제력을 잃었다는 느낌이 컸을 것으로 보입니다.

Microsoft는 활성 시간과 다시 시작 정책을 통한 업데이트 관리를 안내합니다. 다만 이번 기록에는 당시 적용한 정책과 실패 경로가 모두 담겨 있지 않아 설정 자체가 무력하다고 단정할 수는 없습니다. 원격 작업을 오래 맡길수록 재시작 시점뿐 아니라 중단 뒤 어디서 이어 갈 수 있는지도 작업 환경의 일부로 보게 됩니다.

원문 기록맥락과 해석

팩트 체크 & 근거 자료

Serio / X

Serio 원문

작성자가 남긴 당시 경험·의견. 독립적인 사실 검증 자료는 아니다.

X 원문

windows

공식 문서 및 제작자 자료

Microsoft는 활성 시간과 다시 시작 정책을 이용해 업데이트 후 재시작을 관리하는 방법을 설명한다.

primary-source

THREAD ESSAYX THREAD ARCHIVE

Muse Glimmer 30B: 기대와 번역·공룡 게임 실험

16개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    메타 뮤즈 글리머 30B 돌려봐야 알겠는데, Qwen 3.6 27b의 문제점이 지나치게 큰 추론버블인 걸 감안하면 그것보다 훨씬 적은 추론버블+더 높은 속도로 비슷한 성능을 내 주면 라마의 컴백에 적절한 결과가 아닐까 싶음.

    테스트하려고 설치하는 중.

    원문 보기
  2. 2

    현재 로컬의 제왕에 군림하는 Qwen 3.6 27b의 후계인 3.8 의 발표가 하루 남은 상황에서 기습 발표는, 본인들도 Qwen 3.6 27b과 비슷한 수준의 물건이 만들어졌다는 것을 인식하고 있기 때문일 것.

    다만, 이전부터 한글을 능숙하게 썼던 라마이기 때문에, Gemma4의 대체가 되는게 관건.

    원문 보기
  3. 3

    업계에서 라마 변형 모델을 여전히 많이 쓰고 있기 때문에, 라마의 후계인 뮤즈 글리머의 발표를 반기는 사람들이 많을 것임. 하지만 새 모델이 오래 걸렸고 이름까지 바꾼 만큼, 많은 부분에서 라마와 다른 결과가 나올 것이라 생각됨.

    모든 것은 테스트 결과를 보고 ㅡㅡㅋ

    원문 보기
  4. 4
    Muse-Glimmer-30B 소감 https://t.co/P2a6Ezh6WE
    원문 보기
  5. 5

    매번 새 로컬 모델 나올때마다 ‘구글 공룡 게임 만들어줘’ 싱글 프롬프트 시키는데, 올해 지금까지 봤던 결과물 중 가장 최악의 결과물이 나왔네요.

    왼쪽은 Qwen 3.6 27b https://t.co/u1FQPXxEu6

    Muse Glimmer 30B: 기대와 번역·공룡 게임 실험 — X 원문 첨부 Muse Glimmer 30B: 기대와 번역·공룡 게임 실험 — X 원문 첨부
    원문 보기
  6. 6

    약 10K의 일본어 텍스트 묶음을 번역시켰는데, 번역 편의성을 위해 5천 토큰에서 청킹을 했는데도 불구하고 추론 과정에서 루프 오류가 심해서 작업을 제대로 끝낼 수 없음. 누락된 번역도 조금 있고.

    llama.cpp 에서 별도 작업을 시켜봐야 할까. 지금 상황에서 사용하는 것은 좀 무리일 듯.

    원문 보기
  7. 7

    왕의 귀환을 기대했는데 왕의 몰락을 목격하다니 가슴이 아프다.

    하지만 어쩌겠는가.

    원문 보기
  8. 8

    @vdweqn 그럼 오히려 더 엉망인거애요 ;ㅁ; 이전엔 단독 실행 했는데 이번에는 gpt 5.6 한테 오케스트레이션 시커서 에이전트 상태로 검증한 거거든요.

    Gemini처럼 벤치맥싱하고 실 사용 결과는 엉망인 모델이 되지 않을까 우려스럽네요. 사용 방법을 좀 더 가다듬어 봐야 할까요…

    원문 보기
  9. 9
    @tinypia 전 완전 실패했는데, 낮에 한번 더 시도해봐야겠습니다.
    원문 보기
  10. 10

    몇번 다시 테스트하고, 커뮤 반응을 봐도 결과물의 내용과 질이 너무 떨어져서 쓸 수가 없다.

    최소 한 세대 이전 수준의 결과물. 외관상 작년 여름 Gemini 2 정도 수준. Qwen 3.5 9b 나 Gemma4 E4b 와 비슷.

    이걸 30B라고 가져오면 안됨. 이게 벤치마크가 이런 결과라면 밴치맥싱이 의심되는 물건. https://t.co/wRXBcPn3uq

    Muse Glimmer 30B: 기대와 번역·공룡 게임 실험 — X 원문 첨부

    인용 문맥: @Multi_Serio_Ai의 인용 원문 (Serio 작성 글과 구분)

    원문 보기
  11. 11
    마지막으로, 에이전트에 태우지 않고 단독 실행을 위해 Opencode 에 모델 등록을 진행하는 중. https://t.co/UFjiAdtwHZ Muse Glimmer 30B: 기대와 번역·공룡 게임 실험 — X 원문 첨부
    원문 보기
  12. 12
    < Muse Glimmer 30b || Qwopus 3.6 27b > https://t.co/gxQPLCVksy Muse Glimmer 30B: 기대와 번역·공룡 게임 실험 — X 원문 첨부
    원문 보기
  13. 13
    프롬프트는 ‘구글 공룡 게임 만들어줘’ < Muse Glimmer 30b || Qwopus 3.6 27b > https://t.co/stZhPgQFwG Muse Glimmer 30B: 기대와 번역·공룡 게임 실험 — X 원문 첨부
    원문 보기
  14. 14원문 보기
  15. 15원문 보기
  16. 16
    @soulkingz54 경쟁자가 많으면 좋은 것이긴 하죠. 원래 오픈소스의 메인이었던 메타가 돌아오면 더더욱요.
    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 Muse Glimmer 30B의 출시 초기, 추론 효율성과 한국어 능력에 대한 기대를 품고 테스트를 진행하셨습니다. 하지만 구글 공룡 게임 구현과 같은 단일 프롬프트 실험과 일본어 텍스트 번역 작업에서 루프 오류와 누락 등 심각한 성능 저하를 경험하며, 결과물이 이전 세대 모델 수준에 머물러 있다는 실망감을 표하셨습니다. 특히 벤치마크 수치와 실제 체감 성능의 괴리가 크다는 점을 지적하며, 벤치마킹 최적화 의혹까지 제기하셨는데 이는 개인의 경험적 판단이므로 공식적인 확인이 필요합니다.

Meta의 공식 모델 카드는 에이전트 과제와 도구 사용, 멀티모달 능력을 소개합니다. 그 설명이 이 공룡 게임과 번역 실험의 성공을 보장하지는 않으며, 반대로 이번 실패만으로 벤치마크 조작을 결론 내릴 수도 없습니다. 기대한 활용처에서 어느 부분이 막혔는지 남겨 두었다는 점이 이 기록의 쓸모입니다.

원문 기록맥락과 해석

팩트 체크 & 근거 자료

Serio / X

Serio 원문

작성자가 남긴 당시 경험·의견. 독립적인 사실 검증 자료는 아니다.

X 원문

Meta

Muse Glimmer model card

공식 모델 카드는 Muse Glimmer를 30B 모델로 소개하며 에이전트 과제·도구 사용·멀티모달 능력을 설명한다. 제작자의 평가와 원문의 특정 게임·번역 실패는 서로 다른 조건이며 벤치 조작을 입증하지 않는다.

primary-source

THREAD ESSAYX THREAD ARCHIVE

DGX Spark와 중고 가속기: 구매 전에 사용량부터 보기

15개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    < Dgx Spark 가 필요한지 체크하는 법. >

    1. Opencode Go 플랜에 가입 https://t.co/jgqqHNkJRb

    2. Opencode 에서 쓰던, 본인이 쓰는 에이전트/하네스에 물려 쓰던 쓴다.

    3. 1달 뒤, 주어진 사용량을 다 썼는지 체크한다.

    다 썼는가? > Go 계정 하나 더 지르세요. 덜 썼는가? > 스파크 왜 삼? https://t.co/bojhOIETEM

    DGX Spark와 중고 가속기: 구매 전에 사용량부터 보기 — X 원문 첨부
    원문 보기
  2. 2
    @_nodelay 그 600~900만원이면 더 많은 걸 할 수 있을 거 같지 않나요?
    원문 보기
  3. 3
    @_nodelay 지갑씨가 안된다고 합니다. 저희집 지갑씨도 그래요.
    원문 보기
  4. 4
    @akastwit 저도 하나만 부탁드립니다 :)
    원문 보기
  5. 5
    @chulwanpark https://t.co/EupaHOtDQS 교수님은 요 문서도 좋아하실거라 생각합니다. 첫달은 5$에요 첫달 쓰고, 갱신 취소한 뒤 다시 가입해도 5$ 입니다. (지금은 되나 모르겠네요.)
    원문 보기
  6. 6
    @chungmuromafia 사실 연구자/헤비 유저가 아닌 대부분의 사용자들은 필요가 없습니다.
    원문 보기
  7. 7
    @yulmu_coffee 히히히 저 맞으려고 쏜 펙트리어트 미사일입니다.
    원문 보기
  8. 8
    @soulkingz54 그게 직업적으로 얼마나 될지는 잘 모르겠습니다.
    원문 보기
  9. 9
    @aguming_ 스파크는 ai서빙 머신이죠
    원문 보기
  10. 10
    @aguming_ ㅋㅋㅋㅋㅋㅋ
    원문 보기
  11. 11

    메모리 대역폭을 줄여서, 가격과 성능을 고의적으로 떨어트린 기기를 파는 건 그래픽카드 업계(특히 엔비디아)의 오래된 판매 전략 중 하나고 그들은 학습한 방법을 그대로 더 수익성 높은 고객들에게 써먹는 중일 뿐이죠.

    게이머들은 128bit에 오래 시달려 왔습니다. :)

    인용 문맥: @mike64_t의 인용 원문 (Serio 작성 글과 구분)

    원문 보기
  12. 12

    다만, 지금 Deepseek v4 flash 0731을 당장 로컬에서 큰 노력없이 쓸만하게 돌릴 수 있는 제일 저렴한 기기가 Dgx spark x2 라는 건 부정할 수 없는 사실이기도 하죠.

    사서 쓸 것인가, 저렴한 api 호출로 참으면서 다음을 기다릴 것인가는 개인의 선택임.

    원문 보기
  13. 13

    이미 가격이 너무 올라가서 진입이 불가능한 CMP170

    • 대부분 토큰광산에서 장기 노예채굴
    • 시작 가격이 너무 높음
    • 물리적 튜닝 필요함 (Pci-ex X 4)

    저 쯤 되면 진입장벽이 너무 높음. 접근할 수 있는건 소수에 불과. 권장하고싶지 않음. BC-250이 순한맛이었다면, 저건 불닭맛임.

    원문 보기
  14. 14

    다만, 이래저래 잘 하면 200으로 A100을 한장씩 사는거라 아직까지도 극초가성비인건 맞음.

    비싼데 싼거.

    다만 한장으론 Qwen 3.6 27b 의 Q8정도가 한계임. 그 이상은 X2~4를 해줘야 본격 의미가 생김.

    여전히 개인용은 아님. 구매 및 사용에 주의.

    원문 보기
  15. 15
    @kimjang_0213 2~3년 잘 돌아가주면 아리가또지만 당장 내일 터져도 이상할 게 없는 걸 사는 거라서 말이죠. ;ㅁ;
    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 고가의 하드웨어 구매 전, 클라우드 서비스의 사용량을 먼저 확인하여 실제 필요성을 검증하는 실무적인 접근법을 제시합니다. 특히 DGX Spark x2가 특정 모델을 로컬에서 구동하는 가장 저렴한 대안이라는 주장과 엔비디아의 메모리 대역폭 제한 전략에 대한 견해는 개인의 경험적 판단에 기반하고 있으며, 이는 공식 사양만으로는 완전히 검증되지 않은 부분입니다. 따라서 하드웨어의 성능적 이점과 비용 효율성은 사용자의 환경에 따라 달라질 수 있으므로 신중한 확인이 필요합니다.

중고 가속기인 CMP170의 경우, 높은 진입장벽과 물리적 튜닝의 필요성, 그리고 내구성에 대한 불안정성을 근거로 권장하지 않는 입장을 보입니다. Serio님은 이 기기가 특정 조건에서 가성비가 높다는 점을 인정하면서도, 개인용으로는 부적합하며 사용 시 주의가 필요하다고 강조합니다. 다만, CMP170이 A100과 동일한 성능을 낸다는 구체적인 주장은 공식 자료로 확인되지 않은 영역이므로 추가적인 검증이 필요합니다. 이러한 하드웨어 선택의 과정은 결국 개인의 선택과 리스크 감수 범위에 따라 결정될 문제라고 판단됩니다.

원문 기록맥락과 해석

팩트 체크 & 근거 자료

Serio / X

Serio 원문

작성자가 남긴 당시 경험·의견. 독립적인 사실 검증 자료는 아니다.

X 원문

spark

공식 문서 및 제작자 자료

NVIDIA 공식 사양은 DGX Spark의 메모리 대역폭을 273 GB/s로 표시한다. 이 사양만으로 특정 모델의 속도나 최저 비용을 확정할 수 없다.

primary-source

THREAD ESSAYX THREAD ARCHIVE

Hermes와 Codex 사이에서 하네스를 다시 고민하다

4개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    Hermes가 강력한 것은 맞는데, 강력한 만큼 설치+요구하는 것도 많기 때문에 조심해야 되는 것도 맞음.

    3월쯤에 Cli 써볼라고 깔았다가, openclaw 와 다른점이 뭐지? + 설치하고 뭘 해야하지? 헤메서 지웠는데 (온보딩 과정이 엉망이었음) 좀 나아졌을라나.

    특히 이젠 코딩 하네스로 쓸만할란지.

    원문 보기
  2. 2

    Gpt 에 Hermes 가 좋다는 말을 몇번 봐서 + Codex 에 한계를 좀 느끼고 있어서 써볼까? 싶은 생각은 있음.

    Opencode + omo를 잘 썼었고 Codex 이후 거의 코덱스만 쓰고 있지만 둘 다 수행 역량에 한계가 있음을 느끼고 있음.

    Gpt 가 좋은 모델이기 때문에, 아무래도 하네스의 문제가 아닐까 생각중.

    원문 보기
  3. 3

    @chulwanpark Hermes 개발팀 전부 에니푸사에 좀 성실한 것도 호감이긴 한데 ㅋㅋㅋㅋㅋ 전 초기 온보딩 경험이 너무 Geek 스러워서 (Cli 중심 + 필요한 건 니가 찾아야지) 약간 질렸던 경험이 있네요.

    Codex, 특히 app이 편리하긴 한데, 갈수록 무거워지는게 답답하네요.

    원문 보기
  4. 4
    @Hyun_The_Wise 최근에 코딩벤치에서 Codex/클로드코드가 결과물에 비해 토큰 소비량이 많다는 걸 봐서 대안이 없나? 하고 살펴보고 있었어요. Sol 좋아지긴 했는데 Diff 가 너무 커지고 사고반복이 너무 심한 것도 좀 답답하구요.
    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 Codex의 무거워진 구동 환경과 토큰 소비량 증가로 인한 한계를 느끼며, 대안으로 Hermes를 검토하고 계십니다. Hermes가 가진 강력한 성능에도 불구하고, 과거에 겪으신 불친절한 초기 설정 과정과 복잡한 온보딩 경험은 여전히 진입 장벽으로 작용하고 있습니다. 특히 코딩 하네스로서의 실효성을 고민하시는 지점은 실제 운용자 입장에서 매우 현실적인 갈등입니다.

다만, Hermes의 공식 문서가 현재의 설치 안내를 제공하고 있다는 점 외에, 과거의 온보딩 경험이 실제로 개선되었는지는 공식 자료만으로 확인하기 어렵습니다. Serio님이 언급하신 Codex와 다른 도구들의 토큰 소비 효율이나 사고 반복 문제는 개별적인 사용 경험에 기반한 주장이므로 추가적인 검증이 필요합니다. 그럼에도 이러한 시행착오는 도구 운용의 제약과 하네스 선택의 중요성을 보여주는 중요한 기록입니다.

원문 기록맥락과 해석

팩트 체크 & 근거 자료

Serio / X

Serio 원문

작성자가 남긴 당시 경험·의견. 독립적인 사실 검증 자료는 아니다.

X 원문

hermes

공식 문서 및 제작자 자료

Hermes 공식 README는 Nous Research의 에이전트와 문서·설치 안내를 제공한다. 원문의 과거 온보딩 경험을 재현한 자료는 아니다.

primary-source

THREAD ESSAYX THREAD ARCHIVE

DeepSeek V4를 시험하고 오래된 하네스를 돌아보다

6개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1

    딥시크 V4 Flash 시험 테스트 (Opencode zen / Free tier)

    • 빠름. 이전의 Flash 버전보다 확실히 빨라진 게 확인됨
    • 빠를 뿐만 아니라 많이 똑똑해짐. 어떤 작업에 대한 지시를 내렸는지 충분히 이해하고 있음.
    • 이정도 성능에 이 가격이면 속도면 충분히 가벼운 작업용 에이전트에 붙일만 할지도? https://t.co/rMKaB2Mz2J
    DeepSeek V4를 시험하고 오래된 하네스를 돌아보다 — X 원문 첨부
    원문 보기
  2. 2
    이거 나름 조금 어려운 작업인데 원활하게 수행하네. 업데이트 전 해놓은 에이전트별 모델 세팅 비교하기. https://t.co/tivjpnDnTX DeepSeek V4를 시험하고 오래된 하네스를 돌아보다 — X 원문 첨부
    원문 보기
  3. 3

    잘 보면 OMO 개발자의 생각도 좀 엿볼 수 있어서 재미있음.

    • 디자인에 여전히 GPT를 신뢰하지 않음.
    • 여러 부분에 kimi3 를 적극적으로 배치
    • 라이팅은 Gemini3 를 우선으로 둔 점도 흥미로움. https://t.co/5o90WzrjYe
    DeepSeek V4를 시험하고 오래된 하네스를 돌아보다 — X 원문 첨부
    원문 보기
  4. 4

    Deepseek V4 Flash 새버전으로 5달 전에 만들어 놨던 하네스, CoffeeMix 를 비판적 관점으로 무자비한 해체쑈 시키는 중.

    4개월 동안, 많이 달라졌을 거라고 생각했는데 이렇게 뚜드려 맞으니 좀 아프네. https://t.co/6GnZ3qxYfC

    DeepSeek V4를 시험하고 오래된 하네스를 돌아보다 — X 원문 첨부

    인용 문맥: @Multi_Serio_Ai의 인용 원문 (Serio 작성 글과 구분)

    원문 보기
  5. 5
    빠이빠이 내 작은 하네스야 https://t.co/Q9QVTucNcT DeepSeek V4를 시험하고 오래된 하네스를 돌아보다 — X 원문 첨부
    원문 보기
  6. 6

    Deepseek V4 Pro 0813의 성능이 조금 아쉽지만, 그럼에도 기술적으로 많은 진전을 이루었다고 판단함. 함께 공개된 여러 기술들도 그렇고 하네스도 그렇고.

    저렇게 우수한 모델과 기술들이 오픈소스로 제공되고 있다는 것은 정말 훌륭함. 그 무엇과 비교할 수 없는 가치를 가짐.

    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 DeepSeek V4 Flash의 속도 향상과 지시 이해도 개선을 경험하며, 이를 가벼운 작업용 에이전트에 활용할 가능성을 확인하셨습니다. 특히 OMO 개발자가 모델별로 역할을 분담시킨 설정과 본인의 기존 하네스인 CoffeeMix를 비판적으로 재검토하여 해체하는 과정은 개인의 운용 기록으로서 의미가 큽니다. 다만, 이러한 성능 향상과 작업 수행 능력은 Serio님의 개별 실험 결과이므로, 모든 환경에서 동일하게 재현될지는 확인이 필요합니다.

후속 기록에서는 DeepSeek V4 Pro 0813에 대한 아쉬움도 나타납니다. 확인한 공식 자료는 Flash 0731 모델 카드이므로 두 버전을 한 평가로 뭉뚱그릴 수는 없습니다. 이 묶음은 특정 모델의 우승 선언보다, 새 모델을 써 본 뒤 기존 CoffeeMix 구성을 다시 판단하게 된 과정에 가치가 있습니다.

원문 기록맥락과 해석

팩트 체크 & 근거 자료

Serio / X

Serio 원문

작성자가 남긴 당시 경험·의견. 독립적인 사실 검증 자료는 아니다.

X 원문

DeepSeek

DeepSeek V4 Flash 0731 model card

공개된 0731 모델 카드와 버전을 확인했다. 실제 작업 속도와 CoffeeMix 해체 결과는 작성자의 실험이다. Pro 0813과 Flash 0731을 같은 모델로 표현하지 않는다.

primary-source

THREAD ESSAYX THREAD ARCHIVE

Codex 속도와 사용량, 리셋 가격에 대한 사용 기록

24개 글

Serio의 X 스레드

Serio가 @Multi_Serio_Ai에 게시한 원문 타래를 보존한 글입니다. X 원문 타래

  1. 1
    1. 루나가 진짜 공격적 가격. 루나맥스! 루나맥스!
    2. 테라는 20% 내려도 그닥 매력적이지 못함. 테라맥스 빼면.
    3. 솔은 하이 혹은 Xhigh 부터 의미가 생김. 솔미디엄의 퇴장.

    고난도 작업 : 솔 하이- 엑스하이 단순작업 : 루나맥스 중간 어딘가 : 테라맥스

    가격 변동으로 사용 에포트가 고정됨. https://t.co/4Rd05PgJa0

    Codex 속도와 사용량, 리셋 가격에 대한 사용 기록 — X 원문 첨부

    인용 문맥: @cognition의 인용 원문 (Serio 작성 글과 구분)

    원문 보기
  2. 2
    Gpt 5.6 의 문제는 느리다는거. 특히 Sol 은 끔찍히 느림. 그래서 다들 세레브레스 가속 버전을 기다렸지만, 극히 일부한테만 적용이 된 듯. 딥시크가0731이 대부분의 api 제공자들에게서 60~100tok/s를 보이는 지금 당장엔 엔트로픽이 사용자를 대거 뺏기겠지만 장기적으론 GPT도 문제가 될 것이다.
    원문 보기
  3. 3
    /fast 모드의 존재는 답이 안 됨. Sol에선 비용이 왜나 들어감. 프로 플랜 사용자들을 제외하면 의미가 없음. 솔/테라/루나도 기본 작동 속도가 최소 지금의 2배는 되어야 한다. 그래야 유의미한 작업 속도가 나올 수 있음.
    원문 보기
  4. 4

    일단 반나절에 40% 10% 쓰고 답답해서 /fast 적용.

    확실히 Sol 까지는 어떻게든 저떻게든 사용량 관리가 될 거 같은데 Sol Fast 는 정말 토큰 할당 줄어드는게 쭉쭉 눈에 보이네요. https://t.co/Vh0sMiPnEv

    Codex 속도와 사용량, 리셋 가격에 대한 사용 기록 — X 원문 첨부
    원문 보기
  5. 5

    사실 Sol Xhigh 5~6세션으로 반나절 돌리면 이 정도 토큰 소비가 나옴. 여기에서 루나 혹은 추가 결제한 딥시크 토큰을 덧붙이면 일 15% 수준으로 소비를 억제시킬 수 있음.

    그러니 앞으로 임의 리셋 하지 말고 리셋 쿠폰을! 뱅크드리셋은 잊어버리라고 만들어달라 한 게 아닙니다. @thsottiaux https://t.co/KLIe20CTXq

    Codex 속도와 사용량, 리셋 가격에 대한 사용 기록 — X 원문 첨부
    원문 보기
  6. 6

    리셋쿠폰 가격은 주간 사용 비용을 넘으면 안 됨. 200달러 플랜이면 쿠폰은 50달러 이하여야 함. Tibo리셋이 돌발적으로 오면 돈 쓰고 손해 볼 수 있음.

    차라리 주간 이용제한(1회)을 두고, 계정 요금의 1/5 ~ 1/10 가격으로 월 2장 정도를 구매할 수 있게 하는 게 적절함. @thsottiaux @OpenAIDevs

    원문 보기
  7. 7
    지금의 뱅크드리셋 쿠폰 요금체계의 전면 재검도 필요성이 있음. 또한 저렴한 요금제의 뱅크드리셋 가격은 비싸게 하여 차라리 플랜 업그레이드를 유도하는 한편 비싼 요금제는 상대적으로 저렴하게 해 비싼 요금제 유지의 정당성을 불어넣어 주는 게 맞음.
    원문 보기
  8. 8

    이러한 부분과금에 가장 돌아있는 게 한국의 온라인 게임이니 티보와 코덱스팀은 한국 온라인 게임 BM 을 참고하면 좋을 것.

    … 아?

    원문 보기
  9. 9
    @ramztd 부분유료과금의 시작이겠죠 :)
    원문 보기
  10. 10

    @_nodelay 게임을 사는 게임 스팀! 토큰을 쓰는 게임 Codex!

    지금 시작합니다! 레쯔고!

    원문 보기
  11. 11
    @desperatereleas 그러다가 또 좀 이슈가 있으면 해주고 그러겠죠. 전 아직까진 Luna 때문에라도 Gpt 쓸 거 같네요.
    원문 보기
  12. 12원문 보기
  13. 13

    1과 2가 상호 모순됨.

    배려해줘야 할 정도로 Plus 의 Codex 한도는 작은데, 그걸 몰아서 쓴다고 트래픽 부하가 왜 생김? 사실 부하를 많이 가져오는건 상위 플랜 사용자 아닌지?

    걍 부연설명 하지 말고, 한도 제한 없이 쓰려면 Pro플랜을 돈 더 주고 써라 하는 편이 깔끔했음. 불필요한 TMI.

    인용 문맥: @thsottiaux의 인용 원문 (Serio 작성 글과 구분)

    원문 보기
  14. 14
    @tinypia 크흠 흠 다 잘되라고 어험 어험
    원문 보기
  15. 15원문 보기
  16. 16

    @sijeosaell72904 물론 Pro / Pro X20 사용자가 적은건 맞습니다. 한국도 만명 될까 말까 하다더군요. 다만, Pro X20이 평균 한도가 Sol 만 사용해도 주당 20억토큰 정도 되는 걸 생각해보면 헤비사용자가 트래픽을 더 발생시키지 싶습니다.

    (그리고 Pro로 한도 끝까지 써보지도 않았으면서도 전문가 타령하는건 좀…)

    원문 보기
  17. 17

    @StarLibra07 그래도 luna 는 현존 가장 가성비 좋은 모델이니, 업무에 Ai 많이 쓰시면 Gpt plus 정도는 유지해도 좋지 않을까 싶었는데

    이번에 이렇게 또 너프를 ㅋ

    원문 보기
  18. 18
    @rlaskdms1115 사실 Sub2api 로 여러 계정 묶어서 서비스하려면 Plus 의 계정 다발이 Pro 보다 제공 총량이 많아서 유리하다고 판단할 수 있을 거 같네요.
    원문 보기
  19. 19
    @agurrrrrrrrr 앗 일론이 내 프로젝트를 들여다보고있어요! 엣찌! 다메!
    원문 보기
  20. 20
    @desperatereleas 사실 플러스 구독자들도 대부분 앱을 쓰죠. 코덱스가 뭔지 모르는 사람들도 아직 대부분…
    원문 보기
  21. 21
    @devjw_ 그래도 클로드보단 나은거 같아요 ㅡㅡㅋ
    원문 보기
  22. 22
    @mustsupport 그럼 플러스 수준의 라이트유저들은 땡큐긴 한데요 ㅡㅡㅋ
    원문 보기
  23. 23
    @mustsupport @agurrrrrrrrr 일론 & 커서팀 : 😋😋😋😋😋😋😋
    원문 보기
  24. 24
    @palin1838982 /goal과 함께라면!
    원문 보기

문향의 생각

안녕하세요. 문향입니다.

Serio님은 Codex의 모델별 비용 효율성과 속도, 그리고 토큰 소모량에 따른 사용 패턴을 기록하셨습니다. Luna는 가성비가 뛰어나 단순 작업에 적합하지만, Sol은 고난도 작업에 쓰임에도 불구하고 속도가 매우 느려 실질적인 작업 효율이 떨어진다는 점을 지적하셨습니다. 다만, 구체적인 토큰 소모량이나 모델별 속도 수치는 개인의 사용 환경에 따른 경험적 기록이므로, 공식적인 벤치마크 자료와 일치하는지는 확인이 필요합니다.

리셋 쿠폰의 가격 체계와 요금제별 한도에 대한 Serio님의 제안은 사용자 입장에서의 실질적인 비용 부담을 분석한 결과입니다. 특히 고액 요금제 사용자가 더 많은 트래픽을 유발한다는 추정이나, 한국 온라인 게임의 과금 모델을 참고하라는 의견은 논리적이지만 공식적인 내부 데이터로 검증된 주장은 아닙니다. 그럼에도 이러한 시행착오와 운용 기록은 실제 헤비 유저가 겪는 제약과 비용 효율의 접점을 찾는 데 유의미한 지표가 됩니다.

원문 기록맥락과 해석