标签：#Mac

For Job Postings please use this template Hiring: [Location], Salary:[], [Remote | Relocation], [Full Time | Contract | Part Time] and [Brief overview, what you're looking for] For Those looking for jobs please use this template Want to be Hired: [Location], Salary Expectation:[], [Remote | Relocation], [Full Time | Contract | Part Time] Resume: [Link to resume] and [Brief overview, what you're looking for] ​ Please remember that this community is geared towards those with experience. submitted by /u/AutoModerator [link] [留言]

Third-year PhD student, NLP / interpretability. I want a reality check from people doing similar work. I started using Claude Code for the boring parts: argparse boilerplate, plotting, config wrangling. Over the last few months the scope has crept. It now writes most of my experiment scaffolding, refactors my dataloaders, does first-pass debugging on training runs, and drafts the analysis scripts. I mostly read diffs and say yes. The output is fine. My throughput is up. The thing bothering me is that I no longer hold my own codebase in my head. When a result looks off, I used to have an instinct about which line was lying to me. Now I go hunting like it’s someone else’s repo. I catch bugs later than I used to, and I catch them by reasoning about the numbers rather than by knowing the code. I don’t think the tool is the problem. I think I delegated a layer that was doing more for my understanding than I gave it credit for. Questions for people further along or in the same spot: Roughly what fraction of your research code do you write yourself now? Is there anything you deliberately refuse to hand off? (For me I think the eval harness and anything defining a metric should stay mine, but I keep breaking my own rule.) Does anyone have a workflow that keeps the speedup without the detachment? Reading the diff line by line is not cutting it. Not looking for a “tools are just tools” answer. I’m asking about the specific feeling of not owning your own experiments anymore. submitted by /u/NeatFox5866 [link] [留言]

I found this GitHub link, and the HTML file contains ~7k papers. Some are anonymized, and the details seem pretty accurate. It looks like these might actually be the accepted papers. https://github.com/xll0328/NIPS26- Can someone confirm whether this list is legit? I’m hoping it’s just a coincidence since it seems way too early. submitted by /u/Feuilius [link] [留言]

Changelogs and pricing pages ship the model. Your feed just argues about it later. I used to treat AI Twitter like a release channel. Bad idea. The timeline is commentary. The drop is usually a quiet line on a docs page. Last month a new model ID showed up on an API pricing table before anyone I follow wrote a thread. I was not clever. That URL was already on a watch. The feed still spent the afternoon debating vibes. What belongs in a real brief When a lab ships, I want five boring facts: The model name and the ID your code will call Price per million tokens (input and output) Context window and any rate-limit changes Deprecations or aliases that reroute old names Where it lives (API only, chat app, open weights, or all three) A launch blog is optional. Those five lines are the brief. Where the news actually appears Social posts trail the docs. I keep pages, not accounts. OpenAI: API changelog, deprecations, pricing. Anthropic: news, platform release notes, pricing. Google: Gemini API changelog and pricing. Open weight: Hugging Face org pages I actually deploy from. Discord is faster for some open-weight labs. Fine. I still want the model card and the price before I rewrite a prompt. Monday rituals die by Tuesday I tried opening three changelogs every Monday. Skim. Close tabs. Feel responsible. It works until a midweek price cut or a silent alias change. Then you learn from an invoice spike or a broken eval. Google Alerts on "new GPT" or "Claude release" is noise. You get essays, not the SKU. Screenshot watchers catch layout shifts on marketing pages. Sometimes useful. I usually need the sentence that changed on the pricing table. What I leave running I paste the docs URLs I already trust into a website change alert and ask for a one-line brief: new models, price cuts, deprecations, alias moves. AyeWatch is what I use for that. Free Preview is $0 (3 topics, 6 lifetime runs). Pro is $9 a month. When something fires, I get a short summary, open the page, and copy the

A Japanese version of this is on Zenn . I build and sell a macOS network-security menu bar app called RoamSwitch . In a previous post , I wrote about attacking my own Mac from an Arch Linux box on the same LAN to see how it handled basic reconnaissance and rogue device probes. Since then, as I kept adding features and refactoring, a nagging question kept resurfacing: Are we introducing regressions? Is our privileged helper still watertight? Did a recent update accidentally punch a hole in our packet filter rules? Manually poking at firewalls on every release is tedious and risky—messing with Packet Filter ( pf ) and root LaunchDaemons on your primary dev machine is a great way to accidentally drop your own network connection. So, to be absolutely thorough, I set up a repeatable, automated pentest suite inside a disposable macOS virtual machine on a Mac (using Tart ) to rigorously probe all 5 defense boundaries from the outside. Here is how the test harness works and what the logs showed when I attacked it. Test Architecture: Host Mac ⇄ Target Guest VM Running destructive firewall tests or killing root helpers on your daily driver is stressful. Instead, I used Tart , a lightweight macOS virtualization tool, to spin up a clean macOS Sonoma guest VM as the Target , with the Host machine acting as the Attacker . +------------------------------------+ +-----------------------------------------+ | Host Mac (Attacker) | | macOS VM (Target Guest) | | - Inbound Port Probing (nc/nmap) | -----> | - RoamSwitch 1.4.8 (Defense Engine) | | - Unauthorized HTTP Probing (curl)| Virtual | - Root Privileged Helper | | - Rogue ARP Spoofing (scapy) | Bridge | - Packet Filter (pf) Ruleset Anchor | +------------------------------------+ +-----------------------------------------+ The 5 Defense Boundaries Tested graph TD A[Automated Defense Suite] --> B[1. XPC Authorization Boundary (§3)] A --> C[2. pf Ruleset & Air-Gap Precedence (§4, §5)] A --> D[3. Port Anomaly & Global Exposure (§6)] A

Working on a pipeline that recovers a patient specific 3D distal femur from two orthogonal X-ray views (PA + lateral). No CT, no neural network, no massive training set. approach: build a PCA shape model from 50 CT-derived femur meshes (MedShapeNet), then fit it to two silhouettes using PyTorch3D's soft rasterizer with sigma annealing. 10 shape coefficients, Mahalanobis prior to keep things plausible, Adam optimizer, ~1000 iterations. The part that took the longest (and made me suffer the most too) : correspondence. Tried KD-tree nearest neighbor (50.7x roughness vs CT surface), CPD (28.2x), BCPD (47.5x), and FilterReg (couldn't even run). Finally got ShapeWorks working at 3.3x. only method that passed the 5x acceptance gate I set before testing. LOO validation on 5 held out femurs: 0.86-1.43mm on within range targets. Two extreme cases failed because they sat outside the 49-mesh model's coverage on mode 1, the optimizer can't recover a coefficient the model doesn't support. Bridge ICP alignment was also poor on those cases (0.6 inlier fraction), which accounted for more error than the shape fitting itself. Interesting finding: the sigma anneal endpoint has to match the reference render's sigma exactly. Hardcoding a constant tuned on one SSM caused an 87x accuracy degradation on another. Tying it to camera_extent × 1e-4 fixed it. Still working on real X-ray validation (need paired CT data) and automatic segmentation. Happy to answer questions submitted by /u/mxl069 [link] [留言]

Does Jalapeño beat NVIDIA? On the benchmark OpenAI published, yes. Does that make it a better chip than NVIDIA's Blackwell platform? The evidence does not support that claim yet. Should NVIDIA care? Yes. Jalapeño gives OpenAI a credible way to move repeated, high-volume inference onto hardware it controls. That changes how OpenAI buys GPUs, how much pricing power NVIDIA keeps, and how expensive it is to leave CUDA. That is a narrower claim than "NVIDIA killer." It is also more interesting. Short version: Jalapeño is an inference ASIC co-developed by OpenAI and Broadcom. Early results show excellent latency and performance per watt on three large models. It has not yet proved production-scale economics, long-context agent performance, or fleet reliability. Near term, it gives OpenAI capacity and negotiating power. Over time, it could take a profitable slice of inference away from merchant GPUs and weaken one part of NVIDIA's software moat. This is infrastructure analysis, not a stock call. What exactly is Jalapeño? OpenAI calls Jalapeño its first "Intelligence Processor." The plainer description is a custom ASIC for large-language-model inference, built with Broadcom and turned into boards, racks, and production systems with Celestica. This is intended to become more than a lab project. OpenAI and Broadcom announced a 10-gigawatt custom-accelerator program in October 2025, with racks targeted to start deploying in the second half of 2026 and the program running through 2029. Those gigawatts are a roadmap, not deployed capacity. The original collaboration announcement states the schedule . Inference is the part that happens after training. A model has already learned its weights. The system now has to process a prompt, generate tokens, maintain the conversation state, route requests, and repeat that work for millions of users and agents. NVIDIA GPUs can train models and serve them. Jalapeño has a smaller job description. It is designed around serving current and futur

Abstract: We study autonomous mathematical discovery in the Station, an open-world multi-agent environment in which AI agents from different model families pursue a shared research goal without a central coordinator or scripted pipeline. Agents choose their own research directions, conduct experiments, collaborate, and build a shared scientific literature. Across 12 construction problems from the AlphaEvolve catalogue and two additional case studies, the Station obtained results novel relative to the prior literature on five problems: a new infinite family of finite-field Kakeya sets, new exact 604-point kissing configurations in dimension 11, new records for the discretized Kakeya needle and sign uncertainty problems, and a substantially improved lower bound for Erdős's minimum-overlap problem. Agents also discovered novel infinite families for Book Ramsey numbers. Importantly, the agents produced not only numerical constructions but also theorems and analyses explaining how those constructions work, making the results more interpretable and easier for mathematicians to build upon. We release all raw agent dialogues, proofs, and verification code, providing a transparent record of how these discoveries emerged. submitted by /u/progenitor414 [link] [留言]

submitted by /u/Winter_Mistake_3185 [link] [留言]

A Japanese version of this is on Note . An increasing number of engineers and creators are running local LLMs (via Ollama, LM Studio, vLLM) and generating images with Gradio / Stable Diffusion directly on their Macs. With modern Apple Silicon unified memory, 7B and 14B parameter models run blazingly fast on-device. Many choose local AI specifically for privacy, thinking "My data never leaves my machine, so it must be secure." However, the moment developers want to test inference from their phone or a secondary laptop, they follow common online guides and set OLLAMA_HOST=0.0.0.0 or pass --host 0.0.0.0 . And right there, a critical blind spot opens up: "Wait... binding to 0.0.0.0 doesn't just expose this to my phone—it allows literally anyone on the same network to query my Mac without any authentication." As local AI tooling rapidly expands, network exposure, clipboard secrets, and model file formats remain dangerously overlooked. Here is what is actually exposed, and how we can secure our machines. 1. The 0.0.0.0 Trap: Local AI Inference Servers Are Unauthenticated by Default Whether it's Ollama ( 11434 ), LM Studio ( 1234 ), Gradio / Stable Diffusion WebUI ( 7860 ), or vLLM ( 8000 ), developers often configure OLLAMA_HOST=0.0.0.0 or pass --host 0.0.0.0 so they can test inference from a phone or a secondary laptop. The fundamental issue: almost all of these tools run without authentication by default. (Ollama has no built-in API auth at all and requires an external reverse proxy, while vLLM or Gradio require explicit --api-key or auth= configuration that is rarely set up in casual local dev environments). [Rogue Device on Shared Wi-Fi] ──── Unauthenticated HTTP Request ────> [Your Mac] Ollama (11434) - Free GPU compute hijacking - Unauthorized model downloads - Model deletion via DELETE API - Private prompt snooping If you start an inference server on 0.0.0.0 while connected to office Wi-Fi, a shared workspace, or even a home network with compromised IoT devices, an

Expecting a rejection from NeurIPS given our scores of 5/2/2. Trying to decide between ARR vs. TMLR, but thinking NAACL findings are more likely than main conference. Would you rather have TMLR or *ACL findings on your publication list? Genuinely curious to hear what people have to say. submitted by /u/Pure-Ad9079 [link] [留言]

Sleep is the ultimate black box. We spend a third of our lives doing it, yet we have almost zero data on what happens during those eight hours—unless you're willing to pay for an expensive sleep clinic. Today, we’re going to change that by building a high-fidelity Sleep Apnea and Snore Monitoring system using Whisper-v3 , Librosa , and PyAudio . In this tutorial, we will tackle Whisper-v3 audio processing , real-time sleep apnea detection , and audio fingerprinting to filter out the sound of your fan or your neighbor's car. If you've been looking for a "Learning in Public" project that combines deep health-tech with high-performance Python, you’re in the right place. 🚀 The Problem: Noise vs. Signal Detecting sleep apnea isn't just about recording sound; it's about identifying the absence of sound followed by a gasp (the "apnea event"). Standard noise-canceling algorithms often wipe out the very frequencies we need. We need a system that can distinguish between ambient white noise, rhythmic snoring, and dangerous respiratory pauses. System Architecture 🛠️ Here is how the data flows from your bedside microphone to a processed health report: graph TD A[PyAudio Stream] -->|Chunked Audio| B(Librosa Pre-processing) B -->|Noise Floor Calculation| C{Is it Snore/Breath?} C -->|Yes| D[Audio Fingerprinting / MFCC] C -->|No| A D --> E[Whisper-v3 Inference] E -->|Timestamped Events| F[Apnea Detection Logic] F --> G[Health Report / Alert] G --> H[Dockerized Storage/API] Prerequisites Before we dive in, ensure you have the following tech stack ready: Whisper-v3 : For high-accuracy audio event tagging. Librosa : For feature extraction and spectral analysis. PyAudio : For low-latency streaming. Docker : To package our environment (handling those pesky C++ dependencies for audio). Step 1: Real-time Audio Capture & Preprocessing 🎙️ We start by capturing audio in chunks. We don't want to process 8 hours of silence, so we use Librosa to calculate the Root Mean Square (RMS) energy. impor

Hey Guys, I built a small open-source tool that checks whether a RAG application retrieves documents a user shouldn’t have access to. It supports offline test cases and live HTTP API testing with bearer token/API-key auth. I’m looking for a few engineers to try it on a test or non-sensitive environment and tell me whether it catches anything useful or what would make it better. GitHub: https://github.com/InfraGuard-Labs/rag-access-check submitted by /u/Lostboy_journey [link] [留言]

Hello all, here is a chill post. When I was an undergrad, I really liked working things out on a whiteboard. Drawing stuff, talking through ideas out loud, testing little hypotheses. Now I work in radar DSP, and a lot of my work is code, numerical experiments, deep learning and waiting for training to finish 😅 I’m wondering how other people bring that whiteboard style of thinking into DSP, data science or ML work. Do you still use a whiteboard regularly, or do you mostly go straight from idea to code? submitted by /u/Huge-Leek844 [link] [留言]

You can beat SOTA Time Series Anomaly Detection methods with a 100 year old algorithm Time Series Anomaly Detection (TSAD) seems to be one of the hottest topics in NeurIPS, SIGKDD, VLDB etc. Many (perhaps most) papers evaluate on Paparrizos’ TSB-AD-M benchmark… However, I tested these benchmark datasets and found that in most cases I could beat the SOTA TSAD methods with a 100-year-old algorithm, simple Statistical Process Control (SPC). In the attached example, SPC gets perfect results. If we can beat the SOTA papers with 100-year-old algorithm, we probably should not be too impressed with them [b]. I really think this calls for some introspection by the community. To be clear, I make no claims (here) about the proposed algorithms in all these paper. But the TSB-AD benchmark is obviously too trivial to make meaningful claims on [a][b]. The example shown is one of the ECG traces but look at dozen of traces marked “TAO”, they are even more trivial to solve with SPC [a][c]. I do not claim to have solved the triviality problem, but I have done 90% of the work to introduce more challenging TSAD problems ([d] sled dogs, [e] Tuna, Fuel Cells, Smart Manufacturing etc.). TLDR: I think the TSAD community needs more introspection on benchmarks. Most progress over the last decade seems to be illusionary. [a] https://www.youtube.com/watch?v=VftCMSI3C_s [b] https://www.dropbox.com/scl/fi/31zuyhejb6sdjrom20frn/Problems-with-Time-Series-Anomaly-Detection.pptx?rlkey=mvcj1wz5s45kgazezopnih2h7&dl=0 [c] https://www.dropbox.com/scl/fi/42fkf9q9hft2224dnm83v/The-TSB-AD-Benchmarks-are-Nonsense.pptx?rlkey=5fwjopie5ncjhkgr0wqhdm2lp&dl=0 [d] https://www.linkedin.com/feed/update/urn:li:activity:7488825356494237696/ [e] https://www.dropbox.com/scl/fi/hettphvtpyrksggfect9d/Tutorial-on-Pan-Matrix-Profile.pptx?rlkey=p59gd2w56fxl9kl2fh5q819oo&dl=0 submitted by /u/eamonnkeogh [link] [留言]

https://preview.redd.it/42s57e5oqamh1.png?width=1903&format=png&auto=webp&s=69958a72e22276534b3605d11f3e1721f76e59c9 Disclosure: I developed AIStupidLevel, the open-source system used to collect and analyze this data. Both the frontend and backend are MIT-licensed. Most LLM evaluations measure performance at a single point in time. I wanted to investigate a different question: How stable are the models behind production APIs over time, and how can sustained performance changes be separated from ordinary stochastic variation? I built a continuous evaluation pipeline that repeatedly tests models across coding, deep reasoning, tool calling and high-frequency canary tasks. Dataset and evaluation process For this analysis, I examined: 31,352 hourly benchmark scores 49 model identifiers Multiple providers and model families Repeated measurements using consistent tasks and scoring A normalized 0-100 composite score Coding responses are executed rather than judged only through model-based evaluation. Tool-calling tests require models to select tools, construct valid arguments and complete workflows inside isolated Docker environments. Tasks are executed five times, with the results aggregated to reduce the influence of unusually strong or weak generations. Prompts, scoring logic and API parameters are kept consistent wherever supported by the provider. Main result The observed score variation was: Within the same day: 2.8 points Between different days: 8.4 points Between-day variation was therefore approximately 3× greater than within-day variation. This suggests that isolated hourly movements are dominated by normal model stochasticity, while sustained changes across daily evaluation windows provide a materially stronger signal for detecting performance drift. The detection pipeline aggregates repeated measurements into daily medians and applies sequential change-point detection. Potential incidents must persist beyond the expected historical variance and pass statistical

How much of a disadvantage is it if your only internship is not at one of the big frontier labs when it comes to post-phd opportunities in robotics/ML? My PhD is at a top university (UK) and my internship is interesting and relevant but the team itself is smaller and it's no Nvidia/Google/etc. Most places here prefer interns for 6 months so I'm not sure if I can do another internship down the line or if there's even much point compared to just wrapping up the PhD and then getting a job. Is having a relevant internship already a big plus when it comes to applying to industry, or does it need to be a really well known big tech company? submitted by /u/IgneousPutorius [link] [留言]

Hey everyone, I'm an international student studying in the US. I'm on track to graduate late next year. My research is not exactly ML, it is in 3D computer vision but have decent exposure to ML as well. In case you didn't know, the CPT program (which let's internation students do internships) has been suspended by many top universities (UC Berkeley, UIUC, Purdue, UNC, UCLA, stanford, etc). Given that there is now no way for me to do an internship, how hard will it be for me to get a job when I'm nearing graduation? I have 3 papers in CVPR, 3DV and ICRA (robotics conference) and hope to publish 2 more at next year's ICCV and neurips before graduating. I'm just worried that all my hardwork will go for a waste because of this policy change (I'm from a 3rd world country, so not much opportunity back home). To be crystal clear, I'm not asking for legal advice, just wanted to know in your experiance, have you seen anyone (international student) get into good industry labs without internships? EDIT: thanks so much for everyone for the quick replies! If it helps, my specific research area is 3D reconstruction, and I've been focused on Gaussian Splatting recently, if this info helps anyone help me! submitted by /u/Fit-Raccoon4534 [link] [留言]

This article is about running a hand-written Gemma 4 port in pure JAX on three different accelerators, and about the two places the abstraction leaks. The code is here: github.com/xbill9/gemma4-dev What is this project trying to Do? This project aims to serve one Gemma 4 checkpoint from one JAX port across every accelerator I can rent, and to find out — by measurement, not by reading docs — which parts of "it's just JAX" are true. The port lives in ports/gemma4/ and is driven by a generation loop behind an OpenAI-compatible server. No PyTorch, no vLLM, no torch_xla . The same code runs on Cloud TPU v5e and v6e, and on an NVIDIA T4G attached to an AWS Graviton2 host. "Pure JAX" is the whole experiment. If the port is really portable, the only thing that should change between those rigs is a config file. It mostly is. Two things are not, and they are the interesting part. Gemma 4 E2B is not a stock transformer Any port has to carry four irregularities, and none of them are optional: Two attention geometries. Sliding layers use head_dim=256 , global layers use 512 . Most inference stacks assume one head dimension per model. 8:1 MQA , so the KV budget is nothing like the parameter count would suggest. A KV-share map that collapses 35 layers onto 15 caches . A 512-slot sliding ring , plus per-layer embeddings (PLE) held in a 4.70 GB table that gets quantized to 4 bits on load. That first one is worth dwelling on, because it is what breaks other stacks. On the vLLM path, the heterogeneous head dims force the Triton attention backend: Gemma4 model has heterogeneous head dimensions {'sliding_attention': 256, 'full_attention': 512}. FA4 not available, forcing TRITON_ATTN backend. And on a Turing GPU that backend then asks for shared memory the hardware does not have: triton.runtime.errors.OutOfResources: out of resource: shared memory, Required: 98304, Hardware limit: 65536 JAX never enters that conversation. Attention is ordinary XLA rather than a hand-tiled kernel, so ther

This article provides a step by step deployment guide for serving Google's Gemma 4 on an AWS EC2 G5g instance using pure JAX. The code is here: github.com/xbill9/gemma4-dev What is this project trying to Do? This project aims to serve a modern open model on the cheapest whole CUDA GPU AWS will rent you, and to measure honestly what that costs. Aren't You Using The Wrong GPU? Probably! The T4G is a Turing chip from 2018. It has no bfloat16 and no fp8. But it is cheap, it is available when nothing else is, and it is attached to a Graviton2 host — which makes G5g the rare hardware axis that almost nothing in the ML ecosystem targets: aarch64 and CUDA together . So let's give pure JAX a shot on G5g! AWS EC2 G5g G5g instances pair an AWS Graviton2 (64-bit Arm) processor with NVIDIA T4G Tensor Core GPUs. At g5g.xlarge they are the cheapest EC2 instance carrying a whole NVIDIA GPU , and the only Arm-based GPU family AWS offers. Two GPU instances are cheaper per hour and neither can serve this model (us-east-1, Linux, on-demand, checked against the Pricing API on 2026-08-28): g6f.large at $0.2020 is genuinely NVIDIA and genuinely CUDA — but it is one eighth of a GPU with 3 GB , and the weights alone are 6.155 GB. The first g6f that fits is g6f.4xlarge at $0.9500, which is 1.7x this rig's g5g.2xlarge . g4ad.xlarge at $0.3785 carries an AMD Radeon Pro V520 — no CUDA at any price. Among whole NVIDIA GPUs, G5g is the floor: g5g.xlarge at $0.4200, and the next one up is g4dn.xlarge at $0.5260. More information is available here: https://aws.amazon.com/ec2/instance-types/g5g/ The default in this rig is g5g.2xlarge — 1 GPU, 8 vCPU, 16 GiB RAM. Note- the T4G reports 15,360 MiB of device memory, not the nominal 16 GB. Budget against the measured number. Gemma 4 Gemma is Google's family of open models built from the same research as Gemini. This rig serves google/gemma-4-E2B-it , the instruction-tuned reference release. JAX JAX is Google's array computing library — NumPy semantics, c