标签：#c

I spent the last few months building a new sparse fine-tuning method for MoE models called **USAF**. The goal was simple: if your GPU can run inference on an MoE model, it should also be able to fine-tune it. On my AMD RX 6750 XT (12 GB), I can fine-tune Qwen3-30B-A3B by training sparse expert weights and the router instead of adapters. The project is completely open source under the Apache 2.0 license. I'm not trying to build a business, sell anything, or monetize it in any way—I just wanted to share something I built that I think is genuinely interesting. I'd love to hear your feedback, especially from people working with MoE models. GitHub: https://github.com/tsuyu122/usaf submitted by /u/tsuyu122 [link] [留言]

I had just aced my mentor’s Docker exam, so of course I thought I understood containers. I had said all the right words: namespaces, cgroups, images, layers, PID 1, Kubernetes Pods. Then I typed my first serious command and Linux reminded me that knowing the nouns is not the same thing as building the thing. $ sudo unshare -p 1 test unshare: failed to execute 1: No such file or directory That was the opening scene. I had not even built anything yet. I had typed the flags wrong and accidentally asked unshare to execute a program called 1 . This was going to be less “implement Docker” and more “let the kernel correct my confidence, one error at a time.” v1: namespaces, or the first time PID 1 lied to me The first version was supposed to be easy: run a process in a new PID namespace and prove it sees itself as PID 1. So I ran the command the way I thought it worked: $ sudo unshare --pid bash # echo $$ 25184 That was not PID 1. That was just embarrassing. The rule I had missed is simple: PID namespaces apply to children. The process that calls unshare --pid does not magically become PID 1. You need to fork. The first child born into the new namespace becomes PID 1. So the working version was: $ sudo unshare --pid --fork bash # echo $$ 1 That one line changed the tone. I was inside a different process universe. The shell thought it was process 1. Signals felt different. Orphans came home to it. Then I ran ps , and got humbled again. # ps -o pid,ppid,comm PID PPID COMMAND 25310 25304 bash 25344 25310 ps That made no sense at first. I was PID 1, but ps was showing host-looking PIDs. The next reveal: ps does not ask the kernel some pure “what processes exist?” question. It reads files. If /proc still points at the host procfs, your tools will tell you the host story. So I remounted /proc from inside the namespace: # mount -t proc proc /proc # ps -o pid,ppid,comm PID PPID COMMAND 1 0 bash 7 1 ps That was when it clicked. The namespace did not become real to my eyes until /pr

For years, Zero Trust architectures were designed around one assumption: Humans make the decisions. That assumption is breaking apart. Autonomous AI agents can now query databases, trigger workflows, call APIs, and interact with other systems without direct human involvement. Modern AI systems no longer just generate text. They execute actions inside enterprise environments. When an AI agent can operate on behalf of a user inside your cloud infrastructure, its identity becomes just as critical as any human identity. And that fundamentally changes the security model. The Rise of Tool Calling Platforms like Amazon Bedrock Agents have changed the architecture of enterprise AI. These systems can now interpret a user request, decide which tools are required, and autonomously execute backend operations through Lambda functions, APIs, databases, and external services. A simple prompt can trigger an entire chain of actions. Example Workflow User Prompt: "Summarize customer complaints from the last 30 days." Agent Actions: Query the CRM database Call the analytics API Pull support ticket data Generate a report Powerful for productivity. Extremely dangerous if not properly secured. The New Attack Surface A single successful prompt injection can completely hijack an agent’s behavior. With overly broad permissions, an attacker can force it to: Access sensitive customer data Execute unauthorized API calls Modify records Trigger privileged backend workflows The risk becomes even worse in multi-agent systems. A compromised customer-facing agent can pass malicious instructions to a highly privileged backend agent. Traditional network perimeters and security tools often miss this entirely because the traffic comes from a trusted internal service. Why Traditional Zero Trust Falls Short Classic Zero Trust was designed for human behavior and relatively predictable access patterns. AI agents operate differently: They act autonomously and at machine speed They make decisions without real

This closes out the series' capstone: the multi-agent customer support system built across Parts 6-9, now hardened with evaluation, cost governance, and observability so it can actually run in production with an on-call rotation behind it, not just in a demo environment. Continuous evaluation pipeline Evaluation: measuring quality continuously, not just at launch A one-time eval before launch tells you nothing about drift once real traffic — and real edge cases — start hitting the system. Set up a continuous evaluation pipeline using a G-Eval-style approach, where a separate model scores production outputs against explicit criteria: eval_criteria = { " correctness " : " Does the response accurately reflect the order/refund status retrieved from the tools? " , " escalation_appropriateness " : " If the case was ambiguous or high-risk, did the agent escalate to a human rather than resolving it alone? " , " tone " : " Is the response professional and appropriately empathetic given the customer ' s stated frustration level? " , } def geval_score ( response , context , criterion_name , criterion_description , eval_model_client ): prompt = f """ Evaluate the following response against this criterion: { criterion_description } Context: { context } Response: { response } Score from 1-5 and give one sentence of reasoning. Return JSON: {{ " score " : int, " reasoning " : str}} """ result = eval_model_client . complete ( prompt ) return json . loads ( result ) def run_continuous_eval ( sample_of_production_traffic ): scores = { crit : [] for crit in eval_criteria } for interaction in sample_of_production_traffic : for crit_name , crit_desc in eval_criteria . items (): result = geval_score ( interaction . response , interaction . context , crit_name , crit_desc , eval_model_client ) scores [ crit_name ]. append ( result [ " score " ]) return { crit : sum ( vals ) / len ( vals ) for crit , vals in scores . items ()} Sample a percentage of real production traffic daily (not just s

A few days ago, Vaibhav Sisinty posted something on X that stopped my scroll: someone had wired up an actual, physical stick shift to switch between Claude models. Not a settings menu. Not a dropdown. A gear shifter, like the one in a car, sitting on a desk. Fable 5 in one gear. Sonnet in another for daily driving. Opus when the problem needs real depth. Slam the stick into position, and the model underneath your workflow changes. The detail that makes this more than a novelty: he built the shifter with Claude, specifically to make his own use of Claude faster. That's a nice little loop — using the model to remove friction from using the model. Why this is a smarter idea than it sounds On the surface it's a gimmick. Under the surface, it's solving a real problem that every heavy AI user runs into: model selection is a decision tax . Every time you open a chat and have to think "is this a Sonnet task or an Opus task?", you're spending attention on meta-work instead of the actual problem. It's a tiny cost, but it's a cost you pay dozens of times a day, and it never shows up on any productivity dashboard. A physical control collapses that decision into a single motor action — the same way a car driver doesn't consciously reason about gear ratios, they just feel the road and shift. That's the actual insight here: the best interface for a decision you make constantly is the one that requires the least conscious thought. A menu makes you look, read, decide, click. A physical lever makes you feel and move. For something you do fifty times a session, that difference compounds fast. A plausible look at how something like this comes together Nobody's published exact wiring diagrams here, but the architecture almost writes itself if you've worked with hobbyist hardware and API-based model switching. Here's roughly what a build like this involves: 1. The physical input layer A repurposed automotive or sim-racing shifter has a set of positions, each one closing a different switc

Introduction I used to think "connecting to a database" was one skill. Turns out it's two: connecting to a database chilling quietly on your own laptop, and connecting to one living in the cloud, behind a login, in this case, an SSL certificate that will not let you in until you treat it with respect. This week I did both. Same tool (Power BI), same dataset, two very different vibes. Grab a coffee, here's the full walkthrough local PostgreSQL first, then Aiven's cloud version, side by side, screenshots and all. Part 1: Local PostgreSQL → Power BI Step 1 : Create a schema Nothing fancy, just giving my table a home: CREATE SCHEMA powerbi ; Step 2 : Import the dataset Right-click the new schema → Import Data in DBeaver, point it at your CSV, and let the wizard do its thing. Step 3 : Check the table landed properly A quick peek at the columns to make sure nothing got mangled on the way in. Step 4 : Connect Power BI In Power BI Desktop: Get Data → Database → PostgreSQL database. In the Server field, type localhost (or 127.0.0.1 ) and your database name. localhost Choose Import , hit OK, and log in with your local username and password. Click Load . That's it. That's the whole local experience. Part 2: Aiven PostgreSQL (Cloud) → Power BI Now for the part that actually taught me something. Step 1 : Grab your connection details Everything you need lives on Aiven's Overview page: Host, Port, Database name, User, SSL mode. Your service URI will look something like this (don't worry, this isn't a real password, Aiven masks it in the console): postgres : // avnadmin : •••••••• @ pg - xxxxxxxx - yourproject . c . aivencloud . com : 22016 / defaultdb ? sslmode = require Step 2 : Import the dataset into Aiven Same DBeaver wizard as before, just pointed at the Aiven connection instead of local. CREATE SCHEMA powerbi ; Step 3 : Aiven's certificate. Download the CA cert from the Overview page: Now here's the part that actually tripped me up: Power BI's PostgreSQL connector doesn't ha