标签：#qwen

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my...

Yesterday morning my feed exploded with a model release again. But this one was different from the usual frontier drop. Qwen 3.8 27B hit the top of Hacker News and stayed there: at the time I checked, the thread had passed 1,194 points with 713 comments in under a day. That is the kind of heat normally reserved for a $5-per-million-token API announcement. The twist is that this is a dense 27-billion-parameter open model, Apache 2.0 licensed, that people are running on laptops. Simon Willison ran it on an M5 Max MacBook Pro through LM Studio with a 17GB GGUF file and spent 21 minutes watching it think about an SVG ( his comment ). I build production AI systems with Spring Boot and Spring AI, so my first question was not "how smart is it?" It was: can I call this thing from the code I already have, without a second SDK or a cloud account? The answer is yes, and the setup is smaller than the model's license file. Here is what shipped, what the community actually found when they ran it, and the exact Spring Boot wiring for a local Qwen 3.8 27B. What actually shipped Qwen 3.8 is the latest generation of Alibaba's open model family, and 27B is its compact dense member. The model card lists the headline details: A dense 27B vision-language model. A causal language model with a vision encoder, built on the Qwen3.5 architecture. It takes text, images, and video input. 262,144 tokens of native context. The card says it can be extended toward 1 million tokens with RoPE scaling (YaRN), though the card warns static YaRN can hurt performance on shorter inputs. FP8 quantization from the lab. The FP8 repo uses fine-grained fp8 with a block size of 128 and claims "performance metrics are nearly identical to those of the original model." Thinking on by default. Qwen3.8 operates in thinking mode by default, with three reasoning effort levels: xhigh , medium , and low . It also keeps reasoning context from earlier messages ( preserve_thinking ) for multi-step agent work. Multi-token pr

Qwen3.8-2.4T-A95B is a 2.4-trillion-parameter Mixture-of-Experts model with roughly 95B parameters active for each token. If you're planning to self-host it, the first thing to know is that this is a genuinely large distributed model: even the low-precision checkpoints are measured in terabytes. The official open checkpoint is: Qwen/Qwen3.8-2.4T-A95B The model has 512 routed experts and selects 10 of them per token alongside one shared expert. Its 92-layer backbone mixes 69 Gated DeltaNet linear-attention layers with 23 full-attention layers, with full attention appearing every fourth layer. Native context is 262,144 tokens , with an extended configuration available up to roughly 1.01 million tokens . The open checkpoint is text-only and always uses reasoning. This is different from Qwen's hosted Qwen3.8-Max service, which adds features such as vision input and non-thinking mode. For GPU deployment, the main decision is not whether 2.4T parameters will somehow fit. It is which precision format gives you a documented configuration on the hardware you actually have . Start with the checkpoint that matches your GPUs The practical options today are: Your GPUs Checkpoint Documented setup 8× B300 Inferact/Qwen3.8-2.4T-A95B-NVFP4 TP8 8× GB300 Inferact/Qwen3.8-2.4T-A95B-NVFP4 TP8 across two NVL4 trays 16× B300 Qwen/Qwen3.8-2.4T-A95B-FP8 TP16 16× GB300 Qwen/Qwen3.8-2.4T-A95B-FP8 TP16 12× GB300 Qwen/Qwen3.8-2.4T-A95B-FP8 TP4 × PP3 8× MI355X Inferact/Qwen3.8-2.4T-A95B-MXFP4 TP8 The full BF16 checkpoint is roughly 4.45 TiB . The official FP8 version is around 2.27 TiB , while the NVFP4 checkpoint used in the NVIDIA eight-GPU recipe is around 1.32 TiB . That is why NVFP4 is the most approachable NVIDIA deployment if your goal is simply to get Qwen3.8 running without moving immediately to a 16-GPU cluster. H100, H200, A100, B200 and smaller GPU configurations are not included here. Current vLLM material contains sizing information for some of those GPUs, but not equivalent end-to

Solo founders and small operators make big, irreversible calls alone. Expand into a new market or not. Kill the product line or keep bleeding on it. A real board of advisors would catch the bad ones, but real boards are expensive and slow, and most people running a 10-person company are never getting one. Steven and I kept circling this problem, so when the Qwen hackathon came around we built FounderOS: an AI board of directors. You bring one decision, eight specialist agents argue about it, and you get a board memo back. The thing we cared about most, and the reason we didn't just build another chatbot wrapper, is that the disagreement survives into the memo. If the board didn't align, you can read who dissented and what would change their mind. Live demo: https://founderos-zeta.vercel.app Repo: https://github.com/VincentJulijanto/FounderOS Video: https://youtu.be/X6x_u6IWHog The board It's a LangGraph state machine underneath. A Scout frames the options first. Market Intelligence pulls cited benchmarks. Four analysts (Trend, Finance, Growth, Capability) run in parallel with asyncio.gather. Then the Skeptic gets everyone's work and attacks the weakest assumption it can find, a debate engine detects the conflicts and runs rebuttal rounds, and the Chair writes the memo. We'd both seen multi-agent demos where five agents produce one suspiciously smooth answer, which means somewhere in the pipeline the disagreement got averaged out. We wanted the opposite. Agents revise their positions when the counterargument is good, and if a conflict doesn't resolve within the round limit it ships in the memo as attributed dissent instead of disappearing. Everything runs on Qwen through the DashScope API. We split by role: qwen-turbo does the fast work (Scout, the analysts, research, the memory index) and qwen-plus does the heavy reasoning (Skeptic, Chair, the debate itself). A full board run comes out to roughly two cents and about two minutes. The two cents part is what makes the

When people demo "agents that automate business workflows," the demo usually ends right where the real problem begins: the moment the agent's output touches the real world. A wrong chatbot answer is annoying. A wrong official violation letter to a restaurant, sent under a county's letterhead, is a lawsuit. For the Qwen Cloud hackathon I built Inspection Autopilot, an agent that does the follow-up paperwork for a county food-safety office, on real public data: 1,333 inspections and 3,579 violation records from Clayton County, Georgia. The interesting part is not the agent. It's the governance around it, and the numbers that prove it works. Start with the receipts Before trusting an agent's judgment, test it against reality. We replayed the county's own history: 350 real (inspection, next-inspection) pairs, each triaged live by qwen-plus using only information available at the time. Facilities the agent flagged URGENT went on to fail their next real inspection 67.6% of the time. Facilities it cleared as ROUTINE failed only 21.1%, against a 48.6% base rate. The tiers are not vibes; the future agreed with them. Three design rules 1. Citations are verified in code, not vibes. The triage agent must justify every risk call by citing violation lines copied verbatim from the inspection record. The backend checks every citation against the source; anything that does not match is dropped and counted. On the committed live eval (50 inspections, 28 of them deliberately dangerous cases), the measured hallucination rate is 0.0% across 126 citations. And because a checker that never fires is indistinguishable from one that does not work, we sabotaged it: 50 forged citations injected, half invented outright, half real violation text lifted from different inspections, the forgery a lazy validator would miss. It caught 50 of 50 and preserved all 75 legitimate citations. We know the tripwire works because we set it off. 2. The log is append-only. Proposals and decisions are insert-only

Most AI assistants forget everything after each session. Memoria remembers, forgets, and evolves—extracting personal facts, resolving contradictions, and reflecting on what it knows. This post shares the journey of building a production‑ready MemoryAgent for the Qwen Cloud Hackathon, Track 1 . Inspiration Every conversation with a typical chatbot starts from zero. You tell it you're allergic to peanuts on Monday, and by Wednesday it recommends pad thai with crushed peanuts. The model doesn't forget; it never had long‑term memory in the first place. Without durable knowledge about who you are, real personalisation is impossible. We built Memoria to solve that problem: a personal AI with human‑like memory that remembers what matters, forgets what fades, resolves contradictions, and evolves its understanding of you over time. Real memory isn't a bigger context window—it's extraction, prioritisation, decay, consolidation, and reflection. The hackathon challenged us to deliver a memory‑efficient, production‑grade MemoryAgent, and we built one from the ground up on Alibaba Cloud. What Memoria does Memoria organises knowledge in three deliberate tiers: Session Memory (Redis) – the last 10 messages of the active chat. Personal Memory (PostgreSQL 16 + pgvector) – user‑centric facts embedded with text-embedding-v3 , ranked by hybrid scoring, and subject to decay, consolidation, and conflict resolution. Context Archive – full transcripts stored for on‑demand search, never polluting routine retrieval. Other key features: Autonomous memory lifecycle : daily decay, weekly consolidation, and background reflection. Personal Intelligence toggle : global memory access vs. session‑only. Memory‑Less incognito mode : no memory reads or writes. MCP skills server : exposes get_core_memories , get_user_preferences , forget_memory , and strengthen_memory to any Qwen agent. Conflict detection & versioning : contradictory facts are automatically flagged and superseded. Persona customisation :

A new system called Qwen-Image-Agent gives text-to-image models the ability to plan, reason, and revise across multiple steps, closing what its authors call the "context gap." Instead of converting a prompt directly into pixels, the agent wraps a language model around an image generator and runs them in a loop—breaking complex requests into pieces, writing sharper instructions, executing them, and reflecting on what worked. The result is image generation that can handle multi-part, reasoning-heavy tasks that defeat single-shot models. Key facts What: Qwen-Image-Agent wraps planning, reasoning, and memory around a text-to-image model so it can break a hard request into steps - and the local-AI crowd immediately asked whether it runs on a gaming GPU. When: 2026-06-27 Primary source: read the source (arXiv 2606.26907) The architecture follows a four-phase loop. Faced with a complicated request, the agent first plans , breaking the big ask into smaller, manageable pieces. Then it reasons about each piece, pulling in information from its own memory or outside tools and writing tighter instructions. Then it executes , calling the image-generation or image-editing tools to make or modify the picture. Finally it reflects , storing what worked in an episodic memory so the next job goes better. The contrast is direct: a single-shot image model answers in one pass; the agent sketches, steps back, reconsiders, and revises. The paper frames the advantage over ordinary text-to-image the same way a vending machine differs from commissioning a designer—one takes a request and dispenses a result with no conversation, the other asks clarifying questions, works in drafts, keeps notes on your preferences, and iterates toward what you actually meant. The vending machine is faster for a simple request; the designer is who you want for anything with moving parts. This is the same AI agents pattern—plan, act, observe, repeat—that has been reshaping text tasks, now pointed at images. To mea

How to Use Chinese LLMs Without a Chinese Phone Number If you've tried signing up for any Chinese AI service, you've seen the same message: Please enter your phone number (+86) to receive a verification code. This single requirement blocks most overseas developers from accessing some of the best-performing and most cost-effective LLMs on the market. This guide covers every workaround I've found — from least to most practical. The Problem China's major AI labs produce world-class models: DeepSeek — DeepSeek V4-Pro matches GPT-4o within 3-5% on coding benchmarks Qwen (Alibaba) — Qwen 3.7-Max beats GPT-4o on long-context tasks (256K tokens) GLM (ZhipuAI) — GLM-4.5 is competitive with Claude for reasoning tasks Baichuan — Strong for Chinese-language generation But every single one requires: A +86 Chinese phone number for registration Alipay or WeChat Pay for billing Chinese-language documentation Method 1: Virtual Chinese Phone Numbers (Fragile) Services like SMS-activate and 5sim offer temporary Chinese phone numbers for ~$1-2. The problem: Chinese providers have gotten aggressive about flagging virtual numbers. Your account gets banned within days. You lose any balance you've added. ❌ Not recommended — too unreliable for production use. Method 2: Third-Party Gateway Services (Recommended) The most practical solution is a gateway that handles the China-side complexity for you. These services: Maintain their own Chinese accounts and infrastructure Register with real Chinese business entities Handle Alipay/WeChat billing on their end Expose everything through a standard OpenAI-compatible API What this means for you: Sign up with email (no phone number needed) Pay via Stripe or PayPal Get a standard API key Use the OpenAI Python/Node.js SDK as-is Migration example (Python): # Before — can't access Chinese models at all # client = OpenAI(api_key="...") # Only works for OpenAI # After — full access to Chinese models client = OpenAI ( base_url = " https://api.tokenmaster.com