מישהו ראה? אני רואה יותר ויותר אנשים שעובדים ככה, יש להם agent ראשי שא…

https://x.com/hilbertspaess/status/2097476196791709843

https://cursor.com/blog/projects

מישהו ראה? אני רואה יותר ויותר אנשים שעובדים ככה, יש להם agent ראשי שאיתן מתכתבים והוא מתכנן אבל הוא רק מנהל עבודה וכל העבודה נעשית בsub agents כאשר כל sub agent רץ ב total isolation אבל משתף מידע דרך context משותף (קבצים לרוב).

יש מישהו שכבר עובד ככה? זה עובד טוב?

Paperclip
עושים את זה ממזמן לדעתי..

השאלה עד כמה אתה סומך על ה coordinator

זה אפילו יותר high level, מה שאני מדבר פה זה באמצע

אתה עדיין מנהל סיישנים לפי feature אבל מדבר עם agent שהוא זה שמדבר עם ה coding agents

אני עושה את זה במידה מסויימת, אפשר לומר 70% מזה. יש לי קצת יותר מעורבות אבל אני מחפש דרכים להפחית אותה.

הבעיה היא חוסר אמון מצדי.. ייתכן שהוא מיותר..
מקווה שבעתיד הלא רחוק כבר אוכל לסמוך

מה אתה עושה?

אני עובד רק ככה. הפרומפט שלי לקואורדינטור מדגיש שהוא responsible ו-accountable גם על עמידה בפיצ'רים שהוגדרו לו וגם על איכות התוצאה. כלומר, ההגדרה שלו היא שהוא אחראי על כך שהתוצאה תואמת את האפיון ושהיא טובה. מכיוון שהוא לא עוסק באימפלמנטציה אלא ב-planning, חלוקת עבודה ו-review, הקונטקסט שלו לא "מלוכלך" עם הדרך לעשות את הדברים.

בנוסף, בדרך כלל אני מחלק את העבודה לאייג'נטים שהם הרבה יותר חלשים מהאייג'נט של ה-planning ושל ה-orchestration. אין שום צורך שהאימפלמנטציה תיעשה על ידי אייג'נט חזק: ברגע שיש אייג'נט חזק שעשה את התכנון המפורט ומעביר אותו לסאב-אייג'נט, הסאב-אייג'נט לא צריך לעשות את עבודת התכנון, שזו בדרך כלל העבודה הכי מורכבת.

יש לי גם כל מיני timeouts מוגדרים: אם הסאב-אייג'נט רץ הרבה זמן, האורקסטרטור מסתכל על מה שהוא עושה כדי לוודא שהוא לא תקוע, לא רץ בלופים וכולי.

בסך הכול אתה יכול לקחת משימה ולהריץ אותה עם שמונה סאב-אייג'נטס במקביל, שזה גם יותר מהר וגם יוצא בדרך כלל הרבה יותר זול. אתה לא צריך לשלם על Opus או על Sonnet שיעשו לך את כל העבודה, אלא משלם 20% Sonnet ו-80% Llama, DeepSeek או מה שבא לך.

יש לי agentic workflow

ו autonomous loop

המידע מועבר גם דרך קבצים

על איזה פלטפורמה אתה עושה את זה? זה הכל subagents שקמים ויורדים פר טאסק?

אם זה פיצ'ר בודד אז אני כבר רץ לתכנון ופיתוח.
היום כבר כל הטקסיות סביב זה פחתה בגלל שהמודלים הרבה יותר חזקים.
אבל אני כן מקפיד על צ'קליסט לוודא שדברים בוצעו כמו שצריך, שיש self-review, ושיש תיעוד של מה שבוצע (למרות שאת זה אפשר להבין כבר מהקומיטים אבל אם כבר זה בוצע אז תיעוד)

אם מדובר במשהו יותר משמעותי אז מראש מייצר כמה מסמכי תכנון ואז autopilot רץ על כולם

Autipilot גם רץ על ממצאים של audits

Security / refactor / critic

כל חודש אני סוקר את כלל הריפוז ומנקה claude.md מדברים לא רלוונטיים ובודק מה בכלל בכל ה workflow עדיין רלוונטי.

יש משהו אחד שחוזר על עצמו תמיד - תיעוד של באגים.

לאורך חודשים של פיתוח רואים שבאגים שכבר היו לא חוזרים על עצמם. הסוכן טוען שזה בגלל ה gotchas שנכנסו ל claude.md בעקבות באגים שטופלו

אני עובד עם omp.
את החלוקה לסאבאייג'נטים האורקסטראטור מנהל לפי מה שנראה לו מתאים.
לפעמים זה אחד, לפעמים זה 10.
הוא מקבל את הדפינישן, ואז בונה את התכנית.
התכנית צריכה להיות סופר מפורטת.
זה כולל את הקבצים שבהם צריך לגעת, ממש אפילו באילו קלאסים, אילו מודולים, איפה צריך לעשות מה ובאילו אלגוריתמים להשתמש: ממש תוכנית מפורטת.

אחרי שהוא בונה את התוכנית הזאת, הוא מחלק אותה לתת-תוכניות מבודדות ומוסר כל תת-תוכנית כזאת ל-sub-agent. ככה אתה לא חייב sub-agents חזקים, אלא יכול להשתמש ב-sub-agent עם המודל הכי חלש שיש, כי הוא כבר מקבל את ההגדרות שלו מוכנות.

יותר מזה: אם אני רואה שיש sub-agent שעושה יותר מדי reading ו-research, אני משדרג בכל פעם את הפרומפט של האורקסטרטור כדי להגיע למצב שהסוכנים מקבלים את הפרומפטים בצורה כזאת שהם צריכים לעשות כמה שפחות לופים של discovery.

זו המטרה שלי: שה-sub-agents ירוצו ממש מהר ויתקתקו משימות, והאורקסטרטור יקבל את העבודה, יעשה עליה review ויחלק להם תיקונים. הוא גם אף פעם לא סוגר sub-agent, אלא מכניס אותו ל-sleep ואז מוסר את התיקונים לאותו אחד. כלומר, התיקונים תמיד הולכים לאותו sub-agent כדי שזה יהיה יעיל ומהיר יותר.

אם זה מעניין מישהו

על איזה חומרה?

על כמה טוקנים ב output?

צריך ממוצע על הרבה טוקנים, או לפחות כמות טוקנים ממוצעת שהוא פולט באיטרציה. זה נותן תמונה יותר ריאלית.

זאת השוואה בעייתית

כנראה ש gemma יש 4b active

ו qwen הוא dense

אם המודל השלישי לא סיים להתחמם ואתה משווה אותו לשניים הראשונים?
בנוסף כמה זכרון פעיל יש לך זמין משפיע מאוד (איזה חומרה?)

נראה לי ששני התחתונים הם dense

והעליון לא

סודק

בודק*

גמה 26 הוא moe

האחרים לא

Omp מאפשר אובזרביליות לשימוש בקונטקסט? יש איזשהו כלי אינטואיטיבי לזה?

למה התכוונת? מה אתה רוצה להשיג?

את. להמנע מלהיות דבאופס של קונטקסט

זה יכול להתפרש בהרבה מאוד מובנים. אני לא כל כך חווה איזושהי בעיה עם הקונטקסט אצלי, אז בגלל זה אני שואל בדיוק: מה הצרות שאת חווה כרגע שאותן את רוצה לפתור?

הרקע שלי הוא לא פיתוח ובכל זאת אני מוצאת שאחוז ניכר מהזמן שלי הולך על מעקב חלונות קונטקסט לאייגנטים וסאב אייגנטים - מבחינת המידע הנגיש להם, קבצים, עלויות, מודלים. שאלה שלי היא האם יש כלים שיכולים לחסוך לי מעקב

Id like to outsource that to an autonomic agent

זה מודלים ישנים בעולם הlocal llm

ברמת העיקרון יש כמה דרכים להתמודד עם זה:

1. אם הדאטה נמצא בתיקיות שונות, אפשר להפעיל את הסוכן מאותה תיקייה ולהגדיר לו שהוא לא יכול לטייל בשום מקום אחר.
2. מעבר לזה, יש את נושא ה-brain, מה שקוראים לו (אני לא כל כך אוהב את השם). ברמת העיקרון מדובר בייצור של מוח, או נקרא לזה דוקומנטציה, שה-agent קורא כשהוא עולה, ואז הוא יודע איפה כל דבר נמצא ואיפה לחפש.

יש כמה דרכים להשיג את זה:
• מערכות לניהול זיכרון: הסוכנים פשוט זוכרים איפה הם היו ולאן הם צריכים ללכת.
• ברמת הפרומפטים ל-sub-agents: אני מניח שזו לא כזו בעיה ולא צריך לנהל את זה בצורה אקטיבית. אם כל sub-agent יודע בדיוק מה התפקיד שלו, מה מותר לו לעשות ומה אסור לו לעשות, זה כבר פותר חלק מהעניין, כי בסופו של דבר הוא אמור לקרוא את המידע הזה ברגע שמעבירים לו אותו.

אבל ברמת העיקרון, התשובה לשאלה היא שאין כלי אחד שעוזר להתמודד עם קונטקסט. זה משהו שכל ארגון או בן אדם צריך לבנות לעצמו: את הקונטקסט מנג'ר או את המוח של הסוכנים שלו, שידעו להתנהל הכי טוב עם המערכות שלו.

תודה על התשובה המפורטת

הבעיה שאת מתארת היא בדיוק הבעיה שאנתרופיק, OpenAI וכל מעבדות ה-AI מנסות לפתור.

ברגע שהן יפתרו את זה, זה בדיוק מה שיהיה ה-Artificial General Intelligence: הוא ידע לנהל את הקונטקסט של עצמו, ידע בצורה חכמה איזה פעולה לעשות ומתי, ובגדול – יחליף את כולנו.

חחח או super-intelligence ואז יהיה לו את כל הקונטקסט ;)

לא agi זה כשהו מחליף אותנו
ASI זה כשהוא נפתר מאיתנו

Final Numbers with explenation

מה אתה מנסה לעשות?

ניסיתי להבין אם יש מודל יותר טוב מבחינת רספונסיביות ולוגיק, להחליף את הקיים. בניתי אייג'נט שמבוסס על SONNET שמפעיל אייג'נטים שונים למשימות שונות, והכל מחובר לכל חלק בחברה שלי.

אז לכל אחד בחברה יש סוג של אייג'נט שמאיץ את העבודה השוטפת.

יש פה המון פרמטרים...
קודם כל ollama בדרך כלל הכי איטי. נסה sglang.
מקביליות חשוב?
דבר שני - מה הוא צריך לעשות? לכתוב קוד?
עברית חשוב?

הייתי מנסה גם את:
Ornith 1.5
Thinking off

מקביליות חשוב - קוד לא. עברית לא חשוב.

מקביליות זה vllm

ועדיין המודלים האלה מאוד חלשים

תצטרף לקנפג את הסביבה אבל הייתי מנסה sglang/ornith

זה הכי טוב שהצלחתי להוציא מהקופסה הזאת במהירות שסביר לעבוד איתה

תודה

אם קוד לא חשוב לך, תנסה את qwen 3.6 a3b

זה מודל moe הוא יהיה מאוד מהיר לדעתי, אבל לא ממש טוב לקוד בגלל המבנה שלו

Orinth
מודל מדהים מנסיוני

הסתכלתי עכשיו על 1.5
משום מה אין קואנטיזציה רשמית של Unsloth למודל הזה. זה די מוזר, בדרך כלל הקואנטים שלהם ממש טובים.

יש ב NVFP4

הוא חדש

פחות מ חודש

או קצת יותר..

המודל לא חדש. הקוואנטיזציה הזו אולי אבל עובד לא רע.

מחכה כבר שיוציאו משהו עדכני

עשיתי עכשיו קצת משחקים איתו, מעניין סך הכל. ביצועים לא רעים, אבל אני חושב שמבחינת איכות ה-Qwen נותן איכות יותר גבוהה בינתיים — מודל יותר חזק ויותר חכם.
מבחינת המהירות, האורנית' לדעתי פי 2 עד פי 3 יותר מהיר, בגלל שהוא לא מודל דחוס.

- Model: Ornith-1.5-35B-Q4_K_M.gguf (35B total, 3B active MoE)
- Port 57449
- --parallel 2
- --flash-attn on (twice)
- --no-context-shift
- -c 129792 (context)
- --batch-size 4096
- --ubatch-size 2048
- -ngl -1 (all layers to GPU... actually -ngl -1 means "all layers" in llama.cpp? No — -ngl -1 is not standard. Actually negative ngl means "all layers" via gpu-layers-all which is -1.
Yes, -1 = all layers.)
- --fit off
- --metrics
- --slot-save-path cache
- --kv-unified
- --jinja
- --cache-type-k q8_0
- --cache-type-v q8_0 (then overridden later to q4_1)
- --spec-type ngram-mod,draft-mtp
- --spec-draft-n-max 2
- --spec-ngram-mod-n-match 24, n-min 48, n-max 64
- --chat-template-kwargs {"enable_thinking": true}
- --mmproj ... (multimodal)
- --load-mode mmap+mlock
- --threads 12
- --lazy-mode off
- --verbosity 3


תריץ אותו ב vLLM עם הדגלים האלה:

Read-only check done. The running process is PID 80134, serving Ornith-1.5-35B-A3B-NVFP4.

vLLM flag list

Model / server
- serve ornith-ai/Ornith-1.5-35B-A3B-NVFP4
- --host 0.0.0.0 --port 8000
- --served-model-name ornith-1.5-35b-a3b
- --trust-remote-code
- --tensor-parallel-size 1

Compute backend
- --language-model-only
- --moe-backend auto
- --linear-backend auto
- --attention-backend flashinfer
- --kv-cache-dtype fp8_e4m3
- --gpu-memory-utilization 0.45

Sizing
- --max-model-len 262144 (256K context)
- --max-num-seqs 8
- --max-num-batched-tokens 8192

Optimizations
- --enable-chunked-prefill
- --enable-prefix-caching
- --async-scheduling

Speculative decoding
- --speculative-config {"method":"mtp","num_speculative_tokens":2}
- --reasoning-parser qwen3

Chat / tooling
- --default-chat-template-kwargs {"enable_thinking":false}
- --tool-call-parser qwen3_xml
- --enable-auto-tool-choice
- --seed 0

דקה מוציא לך נתוני bench

Benchmark complete. Results against the live 8081 endpoint (same model I run on):

Single (1)
• Total tok/s: 72.1
• Per-core tok/s: 72.1
• Notes: 200 tokens/req

Double (2)
• Total tok/s: 140.3
• Per-core tok/s: 70.2
• Notes: 400 tokens/req

Quad (4)
• Total tok/s: 223.1
• Per-core tok/s: 55.8
• Notes: 800 tokens/req

8-concurrent
• Total tok/s: 331.1
• Per-core tok/s: 41.4
• Notes: 1,600 tokens/req

על איזה חומרה?

Qwen מגיע ל114 ליחיד ומעל 400 באגרגציה

אבל QWEN3.6-35B-A3B דביל רציני והוא לא ממושמע בגרוש

DGX

למה הפריפיל שלך כל כך איטי על תרד אחד? נראה מאוד מוזר. אתה אמור לקבל באזור ה-1400 פריפיל על סינגל

איפה אתה רואה מספרי פריפיל ?

ה 200 לא מייצג פריפיל?

לא זה טוקנים לבקשה…
חכה דקה אני יוציא גם פריפיל.

וגם מספרים חמים וקרים

Clean. The prefill benchmark now measures real GPU prefill throughput (wall time ≈ prefill time since output is 1 token), with 4 samples per size for stable medians. The model accepted all the way up to 64K (context is 256K).

bench_prefill.py — actual GPU prefill throughput

8K
• Prompt tokens: 10,661
• Wall: 1.65s
• Prefill tok/s: ~6,480

16K
• Prompt tokens: 21,311
• Wall: 3.41s
• Prefill tok/s: ~6,220

32K
• Prompt tokens: 42,610
• Wall: 8.30s
• Prefill tok/s: ~5,130

64K
• Prompt tokens: 85,208
• Wall: 22.4s
• Prefill tok/s: ~3,790

Each size ran 4 samples with <1% variance — these are real, low-noise measurements, and the trend is the correct physical one: prefill throughput falls as prompt length grows (KV-cache build cost compounds).

The corrected picture

- Prefill (clean): 3,790 → 6,480 tok/s depending on prompt length.
- Generation: 88 tok/s (c=1), 55 (c=4), 41 (c=8).
- The gap is real now: prefill is genuinely 70–150× faster than generation, not 2× — and definitely not the contaminated 8–10× you caught. The earlier prompt/TTFT with a 72-token prompt was dominated by frontend/tokenization/first-token overhead; this large-prompt run removes that noise and shows the true GPU decode rate.
- Main useful number stands: c=8 reaches 317.8 aggregate decode tok/s, ~3.6× single-request throughput.

Two ready-made benchmarks on the system now:
- bench.py — TTFT + decode throughput across concurrency (1/4/8).
- bench_prefill.py — actual GPU prefill rate across prompt sizes (8K–64K).

נחמד מאוד

הוא לא רע הDGX
קטן אבל גדול

הרעיון איתו זה לכתוב אוטומציות או פרומפטים ולציין לו ככלל תמיד דרך ההרמס שהוא יכול לעבוד במקבילות עד 8 (אצלי בכל אופן) הוא כבר יבחר מה ירוץ סיריאלי ומה ירוץ מקביל.

הוא קורא לזה Children משום מה במקום SubAgents

המספרים טובים יותר ב MTP=3 אבל אני מזהה בעיות יציבות אז עד שיוצא תיקון לא נוגע בMTP

הבעיה ביציבות של MTP היא לא עניין של תיקון, זה עניין מובנה בעצם העובדה שמדובר במודל MoE.

במודלים של MoE, ה-MTP כהגדרה יהיה הרבה פחות יציב מכיוון שאתה אף פעם לא יודע לאיזה expert הרשת תלך, ולכן מאוד קשה לחזות את הטוקנים הבאים ולכן הפגיעות יהיו הרבה יותר נמוכות.

MTP עובד טוב בעיקר עם מודלים דנס.

זה נובע אצלי ממקור אחר,
לא תלוי מודל אם כן MOE או לא.

הוא קורס בדחיסת קונטקסט.

לא כל הזמן, לפעמים.

זה ההסבר של אדון Orinth

DGX Spark / GB10 (SM121) → NVFP4 model → Marlin FP4 fallback → FlashInfer → FP8 KV → MTP=3 → long-context / Hermes compaction.

The important points were:

* Once the conversation/context got very long — around the ~65,535-token region in our testing — the MTP path could crash during/around context compaction.
* Running the same long-context path without MTP succeeded, which strongly implicated speculative decoding rather than the model’s context limit or VRAM exhaustion.
* On GB10, our vLLM build was routing NVFP4 through Marlin instead of a native Blackwell FP4/CUTLASS kernel. That was a vLLM/build-support gap on SM121; this exact fallback behavior has also been reported upstream.
* There are also upstream SM121 reports where FlashInfer + MTP causes illegal-memory-access crashes, while changing the attention backend avoids the crash.

מלא אנשים בפורום של Nvidia חוו את זה אני לא היחיד.

ניסית sglang?

עם mtp 3 עובד לי לא רע ובבנצ' מפני כמה שבועות זה עלה כיותר יעיל מ vllm.
אנסה להעמיס עליו compactions לבדוק מה שאתה אומר

אנסה כשתתפנה מכונה 😀
בכל אופן לא חושב שתראה שינוי דרמטי מ vllm.
לכמה Tok/s אתה מגיע על thread אחד?

מעל 100

עם אורינט ?

טוב

אם ככה במקביל 8 אתה תתקרב ל 400

Sglang
יודע לעבוד בקלאסטר ?

לא שזה חשוב כרגע אני עם DGX אחד
אבל מי יודע מה ילד יום

וואי וואי מה התחלתי 🤣🤣

תבורך על זה
כולנו מרוויחים מזה

לגמרי

התחלתי עם קוד לא חשוב לי, וסיימתי עם קוד חשוב מאוד בוא נחסוך בעלויות, וארכיטקטורה שלמה מסביב לזה. עם שני איגנטים לוקאלים, אחד שיעזור בניהול השוטף של החברה, והשני לקודינג, שינווט בקשות מורכבות יותר ל fable ו astra לטובת תכנון, וחקר וכו, ויממש את הקוד בשוטף.

כמו כולנו…

״תאכל…״
״אני לא רעב״
״טוב תביאי עוד פיתה״ 😂

בקטנה כזה

לא הזכרתי את ה pi, ניהול חשבונות אוטומטי וכו.

מהניסיון שלי, תוכנית שהיא יותר מדי מפורטת לפעמים כבר גורמת לבעיות.
צריך למצוא את האיזון בין תוכנית מפורטת מדי לבין מפורטת מספיק.

יש כאן עוד נפגעי Goal Mode של OpenAI ? בחיי שזה סקאם של טוקנים.

אני, אבל התוצאה כלכך טובה שאין לי בעיה לחכות

אתה לא מבין כמה הרגעת אותי עכשיו…

אצלי גם כל שלב עובר review עם קלוד לפני ואחרי כתיבת הקוד
אז בגלל זה לוקח הרבה זמן

כמה צריך לחמם מספר ב019 בהודעות whatsapp לפני שאני מעביר אותו לשימוש של הagent?

רק שתדע שזה אחרי שינוי מלא של סוויטת הבדיקות למצב xdist 8

אחרת הוא רץ שבוע

מסתבר שכיום אני יכול לשים שתי חשבונות whatsapp בתוך אותה תוכנה, אפילו בלי קומבינות

אל תשכח שמי שכותב את התוכנית זה לא אני, זה סוכן שכותב אותה בשפה של סוכן אחר, מבין?

בסופו של דבר ראיתי שככל שהמודל חזק יותר, ככה הוא צריך תוכנית פחות מפורטת. יותר מזה: אם נותנים לו תוכנית מאוד מפורטת, זה מבלבל אותו והוא עושה עבודה פחות טובה. בגלל זה מודלים כמו Astra או Fable צריכים תוכניות מאוד פתוחות, כלומר הם צריכים כיוון ואז הם יכולים לרוץ.

לעומת זאת, מודלים כמו DeepSeek, Qwen, GLM או אפילו Luna צריכים תוכנית מאוד מאוד מוגדרת. אם לא נותנים להם תוכנית מוגדרת הם פשוט מתחרפנים מלקרוא, ואתה תראה שהם מבלים 90% מהזמן בלקרוא את הקוד ולא בלכתוב אותו. מה שקורה זה שבגלל שאת המודלים האלה חייבים לשים על reasoning מאוד מאוד גבוה, הם מתחילים לפקפק בפעולות של עצמם, ולוקח להם המון זמן (אם בכלל) עד שהם מגיעים אשכרה לבצע את העבודה.

לכן אני אומר:

1. כשמדובר בסוכן חזק שמוסר עבודה לסוכן חזק אחר, אפשר לעשות תוכנית לא מפורטת.
2. כשסוכן חזק מוסר עבודה למודל שהוא חלש בהגדרה, צריך לתת למודל החלש תוכנית מאוד מוגדרת.

ככה הוא מתמודד עם זה הרבה יותר טוב, ואת ה-reasoning שלו הוא מבלה בלכתוב קוד נורמלי במקום לנסות להבין מה הפיצ'ר שאתה רוצה לבנות.

יותר זמן מאשר כמות הודעות

מסכים, לא יודע מה זה אומר תוכנית, אני כבר הרבה זמן לא כתבתי מסמך שהוא תוכנית

מדבר איתו 2 דקות על איך מממשים את השינוי, בדרך כלל זה כבר 60% מהדרך לשינוי עצמו

אנחנו לא מחממים

גם אני לא כותב תוכניות, האורקסטראטור (orchestrator) כותב אותן, ואני קורא אותן ועובד איתו עליהן כדי שהוא יתקן אותן. אחרי שאני מאשר לאורקסטראטור את התוכנית, הוא פשוט מריץ אותה.
הוא בעצמו אסור לו לכתוב שורת קוד. זה ליטרלי (literally) יש לו hook שמונע ממנו לכתוב שורת קוד אחת. הרעיון הוא רק אורקסטרציה (orchestration) כתיבת תוכניות וריוויו על עבודה.
בניתי מערכת שלמה מסביב לדבר הזה שעוזרת לי לעבוד עם המודל ועם אנשים נוספים על התוכנית, ובקרוב אני הולך לאפשר לאנשים נוספים להשתמש במערכת הזאת, לא יודע לכמה אנשים, תלוי. נראה כמה השרת שלי יסחוב.

כן לא יודע אני לא עובד ככה 🤷♂️ אין דרך נכונה

בטוח? לא אמרו שצריך? שאחרת נחסמים?

בינתיים לא נחסמים

לקבל הודעות פנימה מכמה מספרים זאת אינדיקציה טובה שזה לא בוט מניסיוני.
לא רק החוצה

איזו תוכנה? אתה עדיין צריך שהמספר יהיה בטלפון, לא?

באפליקצייה וואטסאפ הרגיל, לא business

ה risk surface המרכזי שלך הוא הודעות יוצאות בבת אחת להרבה משתמשים ודיווח על ספאם

כל עוד הוא מקבל הודעות ומגיב, אתה פחות חשוף

https://x.com/ErgodicTrace/status/2099000981803745528

כן כן

https://x.com/completeskeptic/status/2099925682726002904?s=46

It’s over?

Hi,
I am looking into which VPSs to use for agentic use cases: agents, MCPs, etc. These are my current findings. Any thoughts, suggestions, preferences from your experience:

שים לב שהמחירים כאן זה רק לקומפוט.
כד להרים משהו שימושי, תצטרך גם במינימום סטורג', ותקשורת.
על כל אחד מהם התשלום בנפרד.
תוסיף אותם להשוואה.
ויש גם את דיג' יטל אושן והוסטינגר.
ויש לך גם פלטפורמות כמו raleway ודימיהם ששווה לבדוק

צודק, אבל יש במחיר כיסוי, הנה טבלה יותר מעודכנת:

הסטורג לגמריי מספיק לי. אתה מוצא את עצמך חורג מהנפח של התקשורת?

מישהו גם אמר לי על Contabo. זולים בערך פי שניים. זה הגיוני?

אני על הרצנר ודי מרוצה..

לא סמכתי על קונטבו. האתר שלהם נראה לי SUS. אבל זה כנראה רק תחושה שלי..

גם עכשיו כשאתה רואה כמה contabo עולה ? 😝

ידעתי שהם יותר זולים

אני משלם 5 דולר בחודש.. על 4GB 2CPU אם אני זוכר נכון..

איזה מכונה אתה מריץ עם הצנר ולאיזה דברים אם זה בסדר לשאול?
הףבעבר הייתי על EC2 לאופנקלו וגם עם הרנס, והיה צפוף על המכונה של ה 2Gb RAM

כלכך מעט זה מתחת למה שהם מוכנים לחייב אותי באשראי אז יוצא שאני משלם פעם בשלושה חודשים

אופנקלו עם שכבת ניהול קבצים וניהול PERSONAL BRAIN

משתמש בו בשביל להקים מוצרי OPEN SOURCE לפני התמעה בסביבת העבודה שלי. בשביל סביבה ISOLATED לגמרי בלי גישה לדברים של העבודה

הדרגת כניסה של ה-4 Ram מספיקה לך?

כן .. לא היה לי בעיה

הוא מריץ בנוסף אליו גם מוצרים שלי שכתבתי ומפיץ לי אותם על גבי TAILSCALE

אני לא SUPER HEAVY USER מניח שיש פה אנשים שיותר מדמים עבודה אינטנסיבית ממני. אם יש אחרים שאומרים שזה לא מספיק אולי לא להסתמך על המילה שלי בנושא..

למה אתה לא מנסה את המכונה החינמית באורקל? היא עם 12 ג'יגה זיכרון

אלי השאלה ?

מאמין שמה שהוא בחינם אני המוצר בו.

לא, לתומר :)

זה ביזנס מודל אחר - הם נותנים לך משהו קטן בחינם ואז כשאתה כבר שם וצריך יותר זה עולה כסף

וזה הצורת חדירה שלהם לשוק כי יש להם מלחמה רצינית מול הקלאודים הישנים

כמו הFREE TIER של AMAZON או האחרות.

הם מאוד מכוונים לסטודנטים וג'וניורים לפני שמצאו את העבודה הראשונה.
הסטודנט של היום, זה הvp של עוד 7 עד 10 שנים

משתמשים בCLOUD שלהם ? איך הוא ?

בדיוק
אתה לא ממש המוצר שם, אין להם קשב להסתכל עלייך בחינמים

אוהב את הנוחות של הCLOUD PROVIDERS הגדולים לארגונים. אבל הם יקרים לכל דבר אחר..

לא מדויק
הם פונים גם לחברות ומציעים להם להיכנס (עם קרדיטים, לא רק עם המכונה החינמית) אבל כן זה בכיוון אחר

בסוף הם עם אותם טריקים כמו הקלאודים הגדולים האחרים

משיחה שהייתה לי בSUMMIT הבנתי שיש להם תמיכה משמעותית באפליקציות JAVA בניה והרצה שלהם בצורה אחרת. (לא בדקתי בעצמי)

כדאי שיהיה להם כי הם הבעלים של ג'אווה ;)

ובחזרה לנושא המקורי - @92105691148426 אני מריץ על המכונה החינמית שם אובונטו שהתקנתי עליו גם gui עם טריקים כי אין gpu במכונה ועליו הרמס ודברים (כמו פיירפוקס, vnc, tailscale)

קרדיטים זה משחק של כולם.
אפשר לקבל בין 100 ל 200k בתכניות של סטארטאפים.

המטרה היא להרגיל אותך להשתמש הרבה ובחינם, ואז יום אחד כשאתה מתחיל לשלם, אתה פתאום מגלה שיש לך חשבונית של 10,000 דולר בחודש כמו כלום.

וזה לא תמיד כולל שימוש במודלים, לפעמים למודלים יש תמחור נפרד של קרדיטים.

כן... נשמע מדויק מאוד

זה בדיוק ככה
הפואנטה שדיברתי על הקרדיטים היא להראות שאתה לא המוצר ב-free tier (או בקרדיטים)
זה לא ג'ימייל או פייסבוק
זאת דרך לגרום לך להתחיל להשתמש ואחר כך לשלם

קראתי (מהטלפון) את הפוסט באיקס ואת הבלוג, מאוד לא ברור.. אני חושב שאולי בכוונה זה כתוב לא ברור.
אולי מהמחשב זה יהיה יותר ברור..
מהמר שמדובר על מודל דיפוזיה כלשהו, ולכן הוא לא מחייב על האאוטפוט טוקנז, ומפה גם הדרישה לסכימה של האאוטפוט

חינם בלי אותיות קטנות?

לא חושב, אתה היום נמצא איפה שהיית נמצא בהתחלה של האינטרנט, כשהיית מקבל מוצר איטי ומעפן ויקר מאוד. יהיה כל כך הרבה iot וכל כך הרבה דברים מבוססי ai וזה יהיה כל כך מהיר כך שהכל יהיה זורם (כמו שהאינטרנט היום) והעלות של זה תהיה כמו האינטרנט של היום (כמה זה 100 שח בחודש?)

חינם באותיות גדולות
הם אומרים איזה מכונה / מכונות אתה יכול וכמה מגבלת סטורג' וזה
אבל הכל נדיב, אני ככה כמה חודשים, לא שילמתי שקל

האם אני לא טועה שהיה כבר מודלים דומים של GEMMA שעשו דבר דומה ? חישוב מקבילי של מספר תשובות בו זמנית ? diffiusion gemma ?
היה שם ירידה באיכות לפי מה שאני זוכר אצלם. לא כלכך הצלחתי להבין את השוני בצורת החישוב המקיבלית שלהם.

אני משתמש בhttp://netcup.com/ לא זוכר מאיפה קיבלתי המלצה ולדעתי הוא יצא יותר זול מ

https://github.com/JustVugg/colibri
מעניין אבל לא נראה שימושי במיוחד.
פספסתי משהו?

מעניין מאד!

https://typesafe.ai/blog/introducing-system-one-models-and-jev

llm classifier at scale

נחמד יש מלא יוזקייסים

לא llm, סליחה

בעוד כמה שנים נצחק על ה-80 טוקנים לשנייה

כמו שהיה פעם אינטרנט בקו טלפון..

משגר פעולה - בום זה מבוצע

האמת שאני לא מרגיש שיש בעיה של throughput

אני יכול לייצר כל כך הרבה קוד, מסמכים, טיקטים, רשומות שאף אחד לא ידע מה לעשות איתם

מבחינתי אולי עדיף שזה אפילו יהיה קצת איטי יותר

כרגע אנחנו עדיין צוואר בקבוק

אני לא חושב

אבל כשלא נהיה יותר צוואר בקבוק

אני לא חושב שאנחנו צריכים יותר שיט

באמת? מדוע?

אני חי בעתיד אחי

תסביר

יש לי אמדשים בכיסים במכנסיים

אני לא צריך עוד slop של llmים

ואם זה לא יהיה slop?

הרי ברור שזה יהיה פחות slop לא?

אנחנו רק בתחילת הדרך

אני רוצה שמשהו יקרה, והוא יבנה לבד תוך שהוא בדק את כל המשמעויות בלי טעויות תוך שנייה

אני לא חושב שslop הוא בעיה של llmים כי הם llmים, אתה יכול להעלים סלופ גם היום

אבל יש לזה עלות

אני גם כבר עייף מאוד מלהגיד למודלים החדשים שהם רק מסתבכים

גם אני

please explain the issue and solution in a single sentence

אבל זה ייפתר ברור לכם

וואוווו מממש!

In a single line

אני חושב שזה רק יהיה גרוע יותר

קבוע אצלי

לא חושב..

אני גם מרגיש שזה הולך ונהיה יותר גרוע

כל הllmים היום לא מאומנים כדי שאתה תקרא את הטקסטים שלהם

הם מאומים בrl לחתור למגע

אני גם לא אצטרך

שפת קוד נועדה לבני אדם.
מחשב יכול לכתוב בבינארי / אסמבלי

בסוף אני לא צריך לראות מה הוא כתב.

אני צריך שיבצע את זה בצורה רובסטית

ונכונה

אני חושב שslop זו בעיה של קונטקסט שהוא לא משותף לך ולמודל, הוא מקבל שם החלטות ממוצעות כי אתה אומר לו ״ברררר מהר יותר״

כן אבל אם בבסיס הוא יפלוט יותר טוקנים הוא לא יצטרך להתפשר

בעיני אנחנו עדיין בהתחלה של ההתחלה

זה ברור

כן אולי יותר טוקנים יכול לפתור את זה

עכשיו הוא יוצר יותר slop והשוק והתחרות תפתור את זה

או שהגדולים יחליטו לשים רגולציה כדי למנוע תחרות

כן יש לי מלא יוזקייסים לtypesafe, וכולם מגיעים מזה שהוא מהיר וזול

ראיתי שכבר בונים כאלו על qwen

Jev isn't LLM, it isn't gen ai, it's a decision layer.

כן ברור, עקרונית בvector space שיש לך שליטה עליו אתה אמור להיות מסוגל לעשות כזה מעל llm עם log probs

אמנם הסתברויות של טוקנים הם לא הסתברויות של קלאסיפיקציה אבל אתה תקבל משהו בשכונה

הם לא חשפו את הארכיטקטורה, אבל ממה שקראתי ליד והצא׳ט משערך זה לא ממומש כך. גם בסוף זה לא רץ על כל ה-dictionary שלך. זה רץ על סטרקט שאתה מייצר בזמן אמת. אני חושב שפה הכח שלו. יש לו את הכח של LLM עם קלאסיפיקציה שאתה מגדיר ברגע הקריאה.

כן מה נקרא tool calling with constrained decoding, לא אומר שזה מה שהם עשו, אבל אני בטוח שמחר יהיו 1000 כאלו בhugging face עם probabilities שמבוססים על הvector space שלך

הם עשו משהו אחר כדי לגרום לinference להיות כל כך זול, זה בטוח לא llm בצד של הdecoding

זה כנראה לא. אני לא הייתי מנוון את זה לזה. מה שאתה אומר זה Rule based מבחינה אלגוריתמית ואני חושב שמה שהם עשו יותר מקביל למימוש אלגוריתמי על מלא אבל באמצעות רשת.

יש לזה הצדקה במלא use cases של decision making בכלל בלי קשר ל-LLM .

אם אני מבין נכון, בצורה פשוטה, ל jev יש מוח של פרונטיר. כלומר הוא לא מודל סיווג כמו Bert.
אתה מגדיר את כל סכימות הפלט שאתה מחפש בצורה דטרמניסטית והוא ממלא אותה בצורה מדויקת בלי לפלוט מלא טוקנים לא רלוונטיים.

אבל יכולת ההבנה שלו היא של פרונטיר.

לכן עלות ה output שלו הוא אפס, ויש רק עלות ל input

זה לא עובד, אבל אני מניח שאפשר לקחת ללמ ולבנות אימון שיגרום לזה להיות יותר calibrated

כן קליברציה

מנסיון

אם יש לך גישה לvector space

הסתברויות של הטוקנים לא calibrated בשיט

פשוט כי confidence זה מונח מאוד בעייתי בשפה גם אם היית רוצה להגדיר את המטריקה הזו

בשונה מהמקרה של predictive models שמתאמנים על סיגנלים שברור בהם נכון ולא נכון, המודל יכול להיות מאוד confident אבל הוא לא הבין בכלל מה אתה מבקש ממנו

ואז גם אם הטוקנים היו calibrated זה שווה ל...

רוב הכשלים של קלסיפיקציה זה בכלל שהיוזר לא יודע להגדיר בצורה ברורה מה הוא רוצה

(אנחנו מתעסקים בבעיה הזו כבר 4 שנים)

וזה מחמיר ככל שאתה בדומיין ספציפי + נותן ליוזר להגדיר סכמה

עלות output אפס כי זמן/עלות compute עליהם היא מזערית. היום output עולה סדר גודל יותר כי prefill מהיר בסדר גודל או שתים מdecode בגלל שאחד זה batched והשני זה single או במקרה הטוב mtp של כמה

בסוף זה חשבון פשוט של תפוקה לאורך זמן חלקי עלות

מה שתיארת זה בדיוק ברט.. אתה מגדיר קלאסים ומקבל הסתברויות, פשוט עושים טריקים כדי לתת לזה להיות גמיש

נניח יש מייל מלקוח לתמיכה.

אז יש מראש קטגוריות ל-
* נושא שיחה (מוגדרים מראש)
* האם יש איום נטישה (כן / לא)
* רמת דחיפות (1 עד 5).

Jev יודע למלא את זה.

עדיין לא קראתי את הבלוג הטכני אגיע לזה בערב אבל אני אופתע אם זה מאוד שונה מדברים כמו gliner gliclass, פשוט אף אחד לא אימן אנקודרים גדולים והם כנראה עשו את זה, מאז ומעולם ידוע שהם הרבה יותר חזקים בtoken level tasks

תן לשני מומחים להחליט האם יש איום נטישה ותקבל אי הסכמה של 20-30%

באופן נאיבי זה נשמע מקסים 🙂

העניין הוא ש jev לא פולט טקסט

קראתי

גם bert לא פולט טקסט..

הוא פולט תשובות לפי סכימה מוגדרת

נכון

ואפשר גם לקחת qwen ולא לתת לו לפלוט טקסט ועדיין להשתמש בlogits של כל טוקן בסכמה שכתבת מראש

בסגנון של speculative decodding, תכתוב את כל האופציות ותחשב הסתברויות לכל אחד מהרצפים

אבל bert לא יכול לסווג 10 נושאים.. לרוב יאומן למשימה בודדת אלא אם אתה משרשר

זה יהיה יחסית זול לסרוק מרחב של אופציות

ממש לא נכון

יכול גם יכול

פה הם נותנים מובנה.

לא הייתי מזלזל במה ש jev מביא..

נשמע מעניין בכל אופן

@107684007252205
@144646630064147
קרא את זה ואת ההתכתבויות האחרונות בנושא וההבדל בין זה ל LLM רגיל ולמודל כמו Bert

‏קראתי. TL;DR של הבלוג + איפה זה נופל בדיון שלכם:
‏
‏🔷 מה Jev
‏מחלקת מודלים חדשה ("System One") מ-TypeSafe (דיוגו אלמיידה, לשעבר OpenAI/InstructGPT). לא אוטורגרסיבי — פולט את כל הסכימה במקביל בשאילתה אחת. אין מחרוזות בכלל, רק טיפוסים עם הסתברויות. קלט $0.042/MTok, פלט חינם, 70-500ms.
‏
‏🔷 מול LLM רגיל
‏זה בדיוק ההבדל שאוריאל תיאר: אין decode סדרתי, רק prefill + ראש פלט מקבילי. מכאן ה-40x-200x. גם אפס type errors — לא by training אלא מתמטית, המרחב מוגדר מראש.
‏
‏🔷 מול BERT — רגב צודק חלקית
‏המכניקה אכן משפחת אנקודרים/GLiNER. שני הבדלים אמיתיים: (1) סקייל — אנקודר בגודל פרונטיר, מה שבאמת אף אחד לא עשה; (2) RLCD — RL על קליברציה, לא על preference או verifiable reward. זה הטיעון המרכזי שלהם.
‏
‏🔷 לגבי הקליברציה
‏הם לא טוענים שהלוג'יטים מכוילים "מעצמם" — הם אימנו על זה ישירות. אבל ה-eval שלהם משווה לממוצע הסתברויות של Astra+Fable, לא ל-ground truth. כלומר הבנצ'מרק מודד הסכמה עם מודלים גדולים, לא צדק. הבעיה שרגב העלה — ששני מומחים לא מסכימים על "איום נטישה" ב-20-30% — לא נפתרת פה, היא רק מועברת למודל הרפרנס.
‏
‏✅ ההימור: מהירות ומחיר אמיתיים ומוכחים. הקליברציה — צריך לראות בשטח.
‏
‏(responded in 40s)

‏קראתי את הפוסט ואת ההתכתבות. בעיניי, הוויכוח פה הוא פחות על “האם אפשר להחזיר JSON במקום טקסט” — את זה אפשר לעשות גם עם BERT וגם עם LLM רגיל — ויותר על מה המודל אופטם לעשות, ומהו ממשק הפלט הבסיסי שלו.

ההשוואה בקצרה:

- LLM רגיל: מקבל טקסט ומייצר רצף טוקנים, אחד אחרי השני. אפשר לבקש ממנו להחזיר JSON או תשובות מתוך סכימה, אבל בפועל הוא עדיין מייצר מחרוזת שצריך לפרסר ולאמת. הוא יכול לטעות בסכמה, להוסיף טקסט, או להיות לא עקבי בהסתברויות שלו.
- BERT / encoder: לא מייצר טקסט אוטורגרסיבי. הוא קורא את כל הקלט במקביל ומפיק ייצוגים. מעליו אפשר להוסיף ראשי סיווג, למשל “נושא”, “דחיפות”, “נטישה”. לכן הטענה ש-BERT חייב להיות מאומן למשימה אחת אינה מדויקת: אפשר לעשות multi-task או multi-label, עם כמה ראשים. אבל בדרך כלל צריך להגדיר מראש את הראשים, הקטגוריות והאובייקטיב של כל משימה.
- Jev / System One: לפי התיאור, זה מודל שנבנה מלכתחילה כדי לקבל state לא-מובנה ולהחזיר ערכים מובנים, טיפוסיים והסתברותיים, כאשר השאלות והאפשרויות מוגדרות כחלק מה-query. הוא לא “כותב תשובה שנראית כמו JSON”; הפלט שלו הוא API מובנה שהמודל לא יכול לחרוג מהטיפוס שלו.

כלומר, בדוגמה של מייל תמיכה אפשר לבקש מ-Jev בבת אחת:

text
{
topic: ...,
churn_risk: ...,
urgency: ...
}


וכל שדה יכול להחזיר גם הסתברויות/ביטחון. זה מתאים ישירות ל-routing או ל-`if` בקוד, בלי להפעיל parser על טקסט.

החידוש הנטען של TypeSafe הוא בשלושה רבדים:

1. אדריכלות ודגימה – במקום decode סדרתי של טוקנים, הם טוענים שכל ההחלטות המוגדרות מוחזרות במקביל. זה מסביר את יתרון ה-latency, במיוחד כשיש הרבה שאלות בלתי־תלויות.
2. אימון למטרה אחרת – LLM רגיל מאומן להפיק טקסט שבני אדם מעדיפים; Jev מאומן ל-“calibrated decisions”: שההסתברות 80% באמת תהיה נכונה בערך 80% מהמקרים.
3. ממשק type-safe – האפשרויות החוקיות מוגדרות מראש ולכן אין type errors. אבל חשוב לדייק: זה לא אומר שאין טעויות סמנטיות. Jev עדיין יכול להחליט לא נכון אם המייל עמום; הוא פשוט לא יחזיר ערך שאינו חוקי בסכמה.

לכן רגב צודק בנקודה העקרונית: אפשר לקחת Qwen או מודל אחר, להגדיר מראש את כל האפשרויות, להשתמש ב-logits או constrained decoding, ולא להציג טקסט בכלל. ואפשר גם לעשות זאת עם BERT, GLiNER או מודל classification ייעודי.

אבל זה עדיין לא בהכרח הופך אותם ל-Jev. השאלות החשובות הן:

- האם המודל אומן מראש לעבוד עם סכימות דינמיות והרבה החלטות שונות?
- האם ההסתברויות שלו calibrated או רק softmax שנראה כמו confidence?
- האם הוא מחזיר את כל ההחלטות באמת במקביל, או שעושים decoding/סריקה של רצפים אפשריים?
- האם הוא שומר על איכות של מודל frontier במשימות שלא אומנו כ-classifier ספציפי?
- האם היעילות נשמרת גם כשיש סכימה גדולה ושאלות תלויות זו בזו?

הבדל חשוב נוסף: BERT קלאסי בדרך כלל מחזיר embedding או logits על output head קבוע. Jev, לפי הפוסט, אמור לקבל שאלות/אפשרויות כחלק מהקלט ולהיות יותר “פונקציית החלטה כללית” — מעין מודל foundation שממפה:

text
unstructured state + typed questions
→ typed probabilistic decisions


אז הניסוח הכי הוגן הוא:

> Jev לא ממציא את עצם הרעיון של סיווג, logits או structured output. החידוש הוא ניסיון להפוך את זה ליכולת foundation כללית, calibrated ויעילה מאוד, במקום לחבר לכל משימה classifier נפרד או לעטוף LLM גנרטיבי ב-parser.

ובעניין “לא פולט טקסט”: גם BERT לא פולט טקסט, ולכן זו לבדה לא הבחנה. ההבחנה היא ש-Jev מתיימר להיות ממשק החלטות מובנה וגמיש, עם כמה סוגי שאלות באותה קריאה, הסתברויות מכוילות ובלי עלות decode סדרתי. את הטענות על היעילות והכלליות עדיין צריך לבדוק מחוץ לדוגמאות ול-evals שהחברה בחרה להציג.

https://fastino.ai/blog/gliner2-5-span-free-information-extraction

אם אני צריך לנחש בלי לקרוא כלום - עשו אנקודר בגודל כמה עשרות מיליארדים של פרמטרים בסקייל גדול + אימון שהlogits יהיו calibrated + משהו בסגנון ^ בשביל סכמות

יש פה הרבה עבודה לא טריויאלית

זה אני מסכים

אין פה שום דבר ״groundbreaking״ זה לחבר כמה רעיונות בצורה נכונה (שזה קשה בפני עצמו don't get me wrong)

התחלת להיות מנומס איתם?
Are you scared NOW? 😉

אבל יש כבר עבודות יפות של להפוך דקודר לencoder אחרי אימון - אז יש מצב שאפשר לשחזר משהו דומה בהתבסס על qwen 3.8 27b עם קצת עבודה חכמה

מסכים

כך או כך, יש לזה הרבה מאד שימושים.

You are preaching to the quire

זה הליבה של מה שאנחנו פותרים כבר 4 שנים

יש לזה מיליארד שימושים, העולם לא מתחיל להבין

בעוד כמה שנים נגיד איזה מטומטמים היינו בקיצור

או שאתה צוחק עלינו כבר עכשיו @132401057505440

בתור סטארטאפ שהיה שמח שהעולם יבין... זה לא עוזר לי שהוא לא מבין

אז יותר בוכה מצוחק 🙂

אבל הבעיה האמיתית שהם ייתקלו בה ישר זה שלרוב היוז קייסים זה פשוט לא יעבוד out of the box, בדיוק כמו שfrontier models ממש טובים בלעשות 80 במשימות האלה ולא טובים ב95

(הם גם מאוד יקרים אבל במציאות זאת בעיה מסדר שני)

אבל ננסה את זה בטוח, מעניין כמה טוב זה עובד 🙂

חח אני אריץ dev rage מתישהו ואבדוק את הטרנד

אין רעיונות חדשים בעולם, זה הכל מחזור של רעיונות קיימים בסידורים שונים ודומיינים שונים

הנה יוז קייס https://x.com/ryanvogel/status/2100218045549412499?s=46

יש למישהו הזמנה לאינסטינקט?

https://x.com/nielsrogge/status/2100239244501430438?s=46

https://app.instinct.com/invite?t=kywjogcebq7av4ohhmqrmcneli

אני דוקא חושב שזה רפרנס רלוונטי. גם אם לא מדויק טכנית.

כן Comparable.. תלוי יוז קייס כמובן וכו׳

https://app.instinct.com/invite?t=kywjogcebq7av4ohhmqrmcneli

לא הבנתי הוא כבר יצא? איך יש לו גישה?

יש waitlist כל מני אנשים בx קבלו גישה

אחרון שלי בנושא להיום 😂

יש framework מומלץ ל scheduling או reminders עבור pi? או לתפור לבד?

https://pi.dev/packages

בטוח שיש פה לפחות 10

יש לך מועדפת?

לא 🤷♂️

תודה. הסוכן כותב לי בעצמו בסוף...

כן זה הכי טוב

חחח... דוגמא מה לא לעשות עם Jev :) 😂

מה? הנה הוא גם llm

DLLM

.... Dyslexic LLM

מעניין אם הוא היה מוסיף עוד שאלה שמסמנת להפסיק את הג'ינרוט האם זה היה מביא תוצאה טובה

יש למישהו קוד הזמנה ל muse? אשמח

אתה בארץ? לא זמין בארץ עדיין פעם אחרונה שבדקתי.

מוז קוד זמין, הזמנות לא זמינות

VPN לא יעזור ? 🥲

https://x.com/gregpr07/status/2100411066966749359

בדיוק קיבלתי גישה

אשחק איתו בערב

מעניין אותי אם זה סתם הייפ או שיש כאן משהו

כן אני גם קיבלתי

מה בונים? :)🦫

אתה והנמלים שלך

מה צריך realtime בantseed

תוסיף אותו לראוטר זה כן

בסוף אני לא רוצה לכתוב את הקוד שמגדיר ל jev את סכימת הפלט, אז אני כן צריך llm לעניין..
השאלה אם זה ממש שובר את כל הדינמיות של llm.

למרות שיש מלא use cases באמת שזה נחוץ

לא הבנת מה אנחנו עושים אה? 🙈

זה לא רק סכמת הפלט
מהסתכלות של כמה דקות (גם אני קיבלתי גישה הבוקר) נראה שיש לך בסוף 3 צורות של תשובות בלבד:
כן / לא
אפשרויות
ציון התאמה

זה לא שאתה יכול להגיד לו תוציא לי json של ה-api ליצירת calendar event או דברים כאלה

מרגיש לי (שוב, בהסתכלות של 5 דקות) שזה יותר דומה לאמבדינגס ומה שאתה יכול לעשות איתם

אני אשמח להבין מה לעשות איתו, אבישי תן לי פרומפט

זה לא openrouter רק על בלוקציין?

אבל אין דבר כזה להוסיף, זה כל אחד מוסיף את עצמו, אין שליטה

אה לא ראיתי איך מוסיפים אם צריך תמיכה בפרוטוקול או מה עשית אל תגזים

אבל עוקב

חחח

זה טורנט

במקרה שלך זה קלאסי ל routing לא?

אתה מתכוון routing decision?

לפי רמת מורכבות פרומפט או בקשה

שחף תשתמש בו למודרציה ברילטיים

בגדול כן, אבל זה משהו שמישהו יצטרך לבנות ולהנגיש

או guardrail לספאמרים

וגם לנטר את ספקי המודלים.. שה peers באמת נותנים מודל טוב או תשובה טובה.. מגדיל אמינות ל antseed

מבחינת ארכיטקטורה שום דבר מזה לא מתאים אצלנו אבל אנשים יכולים לבנות דברים כאלו

אין לנו שרתים, כלום לא עובר דרכנו

הבנתי

זה טורנט 🤷♂️

אם שום דבר לא עובר דרככם אז באמת צריך לחשוב

זה אחלה יוסקייס כללי.

לבדוק ש llm עונה כמו שצריך.

בטח ספקי מודלים ישתמשו.

אם זה מהיר וזול.

ניטור בקשת משתמש וניטור מענה למשתמש

כן, הסיוט שלי זה לתמוך בטראפיק בפרודקשן, אחרי כל כך הרבה שנים שכבר נהייתי דבאופס הגיע הזמן לכתוב רק קוד ולא לנהל שרתים

Smart

הטוויטר מוצף עכשיו בשימושים ב jev.

מעניין שם היום

אני מתחיל לשחק גם בדיוק

נראה שלעשות ראוטינג בין מודלים זה קלאסי?

החלטות דיסקרטיות עם משקל גבוה של אימפקט ושצריך מהירות real time

זה פשוט קלאסיפייר חכם מאד בשורה התחתונה

במקום קלאסיפייר טיפש, קלאסיפייר עם מוח של frontier

כמו שLLM זה word completion ברמה ממש גבוהה..

נראה לי זה מתאר את זה בחסר

ממש

אם עד עכשיו הבעיה בקלאסיפיירים היה שהם טיפשים, עכשיו יש אחד מאד חכם

ואם רציתי קלאסיפייר חכם הוא היה יקר

כבר עשיתי כמה שימושים ב LLM כקלאסיפייר.. כדי שזה יעבוד מצויין ובצורה אמינה מהניסיון שלי היה חייב מודלים חזקים

זה הולך לרוקן הרבה תוכן מהמעבדות

בסוף יש הרבה החלטות דיסקרטיות בחיים של סוכן

בחירת מודל, בחירת כלי

אני ניסיתי בעבר בעצמי לעשות routing

בעוזר שלי בוואטסאפ

ומודלים חלשים פשוט היו גרועים בזה אז ויתרתי

כל כלי כתיבת קוד יאמצו את זה כדי להוזיל לעצמם עלויות.. אם באמצע עבודה המודל צריך לעשות curl פשוט, הוא לא ישתמש ב fable בשביל זה

השאלה אם יבנו של עצמם או ישתמשו בשלהם ?

מודל מאוד מעניין.. אין מה להגיד .. יש כמה יוסקייסים די מעניינים לעשות איתו. ביצוע בדיקות GUARDRAILS לפני העברה של QUERY

אני תמיד חושב על היוזקייס של קונטקסט גדול עם איזו משימה שבסוף המודל כתב איזה סקריפט. והיוזר מגיע אחרי כמה שעות ורוצה להריץ שוב את הסקריפט, יוזקייס קלאסי של חזרה לאותה שיחה אבל בגלל שעבר זמן אין כבר קאש ואתה משלם על כל הקונטקסט למודל ממש יקר כשכל מודל טיפש היה יכול לקרוא לטול שיריץ את הסקריפט.

בכמה כסף קונים אותם ?

וזה נראה לי ממש נפוץ, מגיע אחרי יום run it again ומשלם על מאתיים אלף טוקנים לפייבל

ועושה את זה עכשיו כל יום 🤦♂️

מדויק..

אני חושב שכל הנושא הזה של מיון בקשות הוא קלאסי לזה, אפשר לשפר נוטיפיקיישנס ליוזרים, ככה שאנשים / סוכנים בארגון יקבלו רק את מה שרלוונטי אליהם, דברים בעולמות של סופורט ולאן הפנייה צריכה להגיע

בגדול זה כאילו אמור להיות כלכלי ומהיר עכשיו להריץ שאילתות על לוגים/ledgers

כבר רוצה לחבר אותו להחלטות סקייל.. יכול להיות מגניב
לא צריך לכוונן כל סרוויס וכו׳ וכו׳….

היי, אני נפגש בשבוע הבא עם סוכנות שיווק פורטוגזית שמחפשת פתרונות AEO ללקוחות שלהם. אשמח להפניות לחברות ישראליות שעובדות בתחום ויכולות להיות רלוונטוית

https://x.com/ryanlightbourn/status/2100290788731261043/video/1?s=46

פאקינג מדהים

אני רוצה לראות עוד פרק זה מדהים

הוא אומר שזה עלה לו 2500 דולר ובערך 3 שבועות של עבודה במצטבר

What the fuck? Did I just see 😅

גם אני שאלתי את עצמי תוך כזה שאני צופה... ולא יכול להפסיק..

https://github.com/DevMortimer/pi-warden

מישהו ניסה?

למה לא lamacpp יותר מהיר לספארק
והשאלה הגדולה מה גודל הקונטקסט וכמה חלונות?
הרצתי את qwen3.8 אבל חלון הקונטקסט קשוח

השאלה למה מודלים כאלה ישנים😅

יש qwen 3.8 27b

https://www.instagram.com/reel/DdWPAGNSCmf/?stkn=

https://www.facebook.com/share/p/1Gxe7Fryio/

תכף ייצוצו מלא כאלה

הדברים המרכזיים שמייק מעלה בפוסט:

1. ההבטחה ל"אפס הזיות" - אמינות מבנית אינה ערובה לאמינות לוגית. הוא לא הוזה תשובה שלא קיימת במרחב האפשרויות, אבל הוא בהחלט יכול לטעות.

2. המעבר לג'נרוט מקבילי מביא לביצועים חזקים מאוד ואפס עלות על טוקנים בפלט מצד אחד. מצד שני המחיר הוא שאין שום אפשרות ל-Chain of Thought (CoT). המודל לא יכול "לחשוב בקול", לפרק בעיה לגורמים או להצדיק את הבחירה שלו.

הרצתי בלילה טסטים על בערך 40 פייפליינים שנכשלנו
ניסיתי שיגיד אם זה כישלון בגלל בעיות תשתית או בעיה אפליקטיבית.
⁨Jev⁩ הגיע ל-⁨81.6%⁩ דיוק מול ⁨86.8%⁩ של ⁨Opus 5⁩, והוא זול פי ⁨185⁩ ומהיר פי ⁨2.4⁩.
כששולחים ל-⁨Opus⁩ רק את המקרים שבהם ⁨Jev⁩ לא בטוח (‏⁨18%⁩ מהמקרים), מקבלים את הדיוק המלא של ⁨Opus⁩ ב-⁨19%⁩ מהעלות וב-⁨60%⁩ מהזמן.

לא בדיקת מעבדה

מגניב מאוד

טירוף

זול פי 185, והגיע לדיוק של 81%

אני רואה בעתיד המאוד קרוב את הסונאט שלי מוחלף ב Jev

בעצם הבחירה היא בלאק בוקס?

עוד בעיה היא בעיות שדורשות רצף של בחירות אחת אחרי השנייה.

הבחירה היא בלאק בוקס לגמרי.

לגבי רצף של בחירות- הוא מתמודד אצלי מדהים עם לוגיקה מורכבת בפרומפט. תנסה.
עוד אלטרנטיבה היא כמובן לשרשר קריאות בקוד. עדיין ממש זול וגם לא רעיון רע בכללי להשען בפייפליין על engineering איפה שאפשר.
(גם קצת מקל את בעית ה explainability)

הם כותבים במפורש שהוא לא טוב בsequencing אמיתי, לא כמו אייג׳נטים מעל המודלים הגדולים, הוא יכול לעשות דברים בזמן אמת אבל אל תשלח אותו לעשות רצף פעולות מעל דפדפן שדורש הרבה שלבים

יש האקים כמו שמעיין כתב למעלה

חלק עבדו לי

אבל לא מושלם יש לזה גבול עליון די בסיסי ביכולות

זה יעבוד אבל בbenchmarkים אמיתיים הוא לא עומד מול המודלים הגדולים. רצף פעולות ארוך זה לא הפורטה של המודל הזה. אבל בגלל המהירות זה קצת משנה את הכללים, כי אולי עכשיו נוח יותר פשוט לדבר בקול רם

כן לגגמרי.

אז השילוב של מודל real time הקודם של openai עם jev מאוד מעניין

בנינו את הבנמצארק הראשון לwebmcp. אני בדיוק מעדכן אותו עם jev.

יש פער גדול בין הדמואים המפוצצים ב-X לבין המציאות.

בערך ב80 אחוז מהתוכן בx חח

הוא לא באמת טוב computer use שהוא general purpose

אה! אתה העידן של webmcp!

כל הכבוד לכם

חח כן the webmcp guy

אנחנו נפרסם היום את התוצאות על הבנצמארק עם jev. מאוד מעניין מה שיצא

בסדר רליס ראשון, עכשיו יש להם את כל הדאטה בעולם

אני חושב שזאת בעיה מבנית אבל אני לא בטוח

בניתי harness שכן יש לו גישה לwebmcp והשתמשתי בmercury 2.5 בנוסף על jev והגעתי לתוצאות משוגעות

אבל בלי webmcp הוא אהבל לגמרי אני לא מצליח לגרום לו להצליח בבנצמארק

משפט אופוס, אבל יש מצב, זה כבר באמת לא הפורטה שלי

בינתיים

בתאוריה אני פשוט יכול לשבור את זה בלתת לו מסע של סוכן שצריך לקרוא ל-10-15 כלים

מה זה מרקורי?

זה מודל קטן שיצא לפני 8 ימים. הוא עושה מעל 1000 טוקנים לשנייה ומשתמש בdefusion

בגלל שג׳ב לא יכול לגנרט טקסט arbitrary אז בשביל לקרוא לכלים עדיף יהיה עוד מודל שעוזר לו

מסתבר שזה יכול להיות מודל ממש קטן וממש מהיר כי רוב הליפט של החשיבה של המודל בסוף היא לבחור את הכלי (ברוב המקרים אני מניח)

אה ואו ואז להשתמש בjev כdriver?

לא חשבתי על זה

כן הוא בוחר את הכלי ואז מרקורי אומר לו את הארוגמנט

אתה כנראה תרצה דבר כזה אם אתה רוצה לאפטם משהו לעלות מאוד מאוד נמוכה

מעניין.
קצת יותר יקר - אבל גם reasoning יותר חזק אם זה נדרש - כדי לנתח טקסטים ב near real time שילבתי jev עם qwen על cerebras שנותן בערך 1500 tps אפקטיבי. (הם מדברים על 2000 אבל לא הגעתי לזה).
אנסה את מרקיורי.

לי היוזקייס הכי מעניין הוא map reduce עם קלאסיפיירים, זה באמת משנה את הכללים של המשחק באיזורים האלו

יש לjev פולבק לllm אם רוצים להעביר לאופוס למשל במצב של חוסר ביטחון

ברור זה דרמה :)

ואו אצלכם זה בכלל משוגע

עכשיו צריך לשכתב מלא שיט 🫣

אני מוכן להתערב שduckdb עם jev יהיה מטורלל

כבר ניסיתי

לא צריך לשכתב ככ הרבה, זה לא טוב לדברים שבאמת צריכים reasoning
זה יותר מאפשר לעשות routing חכם בין מנוע יותר זול למנוע full power

ובעצמו לפעמים יכול להיות המנוע הזול

חח שגעת, זה הולך להיות מנוע הnlp הכי חזק שיש בסביבה

אני עוד צריך לבדוק לעומק את הקליברציה אבל

עשית כבר חשבון כמה יעלה לעשות טאסקים של nlp על דאטה גדול ככה?

אנחנו עושים כבר, זה תלוי כמה קריאות jev צריך בפועל למשימות
הניחוש שלי הוא שהוא יהיה בסדר לקונטקסט קצר מאוד וגרוע ככל שזה מתארך - שזה בעייתי כי דאטא הוא לא 3 משפטים כמו כל הדמואים היפים
ב3 משפטים ומשימת סנטימנט יש מודלים טובים בזה כבר שנים זה לא מועיל

בקיצור זה דורש בדיקות לעומק. בבדיקות שטח על משימות שדורשות ניואנס זה לא עובד

בטח לא multi needle reasoning

אבל לשיפור של משימות deep research לדעתי זה יהיה מעולה

בתור tool זול

שיש סוכן דרייבר שיודע לשאול עם פירוק טוב

טוב, מניח שמפה הדרך היא לעלות אפסית לקונטקסט גדול, אם זה מתקדם בקצב של הסייקלים של המודלים הגדולים אז תוך שנתיים כל התחום נראה אחרת

כן ניתוח אייג׳נטי והוא מפרק את השאילתות לדברים לעיסים

מטריד מאוד :)

פייסבוק יקנו אותם או משהו

https://x.com/kunchenguid/status/2100846644304773541?s=46

לדעתי תוך חודש יש מקבילה אופן סורס אין פה שום ip אמיתי

אם היה הם היו מפרסמים קצת יותר פרטים

בדיוק מה שעבר לי בראד

בראש

כנראה שזה לא יקח שנתיים

אין moat ברשתות יותר

יש כל כך הרבה אנשי9 שמתעסקים בזה שתוך שנייה הכל עובא

גופי הביון מאשרים את ההודעה הזו

כמובן רשת ניורונים בכללי וLLM בפרט, כולם לומדים אחד את השני

אפילו הmoat של קרנלים מאופטמים זה הולך ונעלם

מה גם שלא יהיה קשה לייצר מהם דאטא..

החלק היחיד שצריך לפצח זה calibrated confidence, כל השאר כבר יש באופן סורס באיכות דומה

זה בדיוק הבעיה עם moat בllm, תמיד אפשר לעשות distillation ורוב הgain במודלים האלה זה data וtasks

הmoat זה הקונפיגורציה - סקילים, זיכרון, אמון בharness שמספקים אבטחה טובה, זמינות וכו

בharness של חברות 'נותנות בחינם בוודאות אין

אני בדעה שאין moat בכלל, זה הכל gtm וexecution אצל הלקוח
מה שמייצר ערך וקושי לזוז

אני נוטה להסכים עם רגב

באופן כללי

נוטה להסכים, כן יש בנתיים moat בחומרה

וככל הנראה יש moat בתשתיות כבדות של חומרה ותוכנה

יש גם moat בדיסטריביושן

אנשים שהם לא early adopters לא זזים מהר לשום מקום

צריך לזכור גם שהשוק נפתח שוב ל category makers שיהיו שם נרדף לפתרונות מסוגים חדשים כשהשוק יחליט.

המציאות הוכיחה בהתייצבות של עידן האינטרנט/מובייל שגם זה moat.

אתה תכוון ב פעמים?

מפיצים

או בכללי שיווק וgtm?

שיווק וgtm, אבל אם אתה כבר ענק יש לך moat