ryan4yin | 二花 (@ryan4yin)

过去一周多，可能以后被证明是AI推理部署史上天翻地覆的一周。 上个周末，我的本地机双5070ti试跑Qwen Flash，只能做到200 prefill，10decode。 今天，在Strata和我自制的PR的支持下，目前可以跑到2200/67，而且只需要一张卡。 即读写速度都提高了近十倍。 更好的消费卡比如4090/5090，当然也有幅度相当大的升级（目前5090在流式处理的支持下，速度已经开始逼近RTX6000，当然显存还是不足）。 这当然带来了消费级硬件的新一轮大涨价。如今，就连曾经无人问津的 32G B70英特尔显卡都卖断货涨价了。 2200/67的速度是什么意思？ 今天除了deepseek，muse等少数模型，大部分API达不到这个速度。 而一个普通的家用游戏电脑就可以达到这个水平。 而这个水平，一周以前，只有5090，DGX spark，M3U这样的机器可以达到。 也就是说，在过去的一周多，全球的普通家用电脑带来了十倍于上周的AI产量。 这个增量，得益于deepseek- Qwen flash这种特殊设计，把智力分成了注意力，专家，和查表， 也得益于Strata这样优秀的架构，把整个处理流水线化，让不同的智力，存储在不同速度的存储设备中，在需要用时刚好抵达。 这对所有愿意拥有本地智力的人，当然是极大的利好。 也许模型层的设计，正在快速收敛到一个目前硬件条件下的最优解？ 然而这对依赖出卖模型算力的生意，尤其是平庸的智力的商业来说，也可能是催命符。

之前问了虚拟网卡 Tun 模式下微信图片加载慢的问题， 大家非常热心的给出了很多诊断的建议，我做了一下复盘： 微信的网络机制本身就极其特殊。@wq268888 提到微信自己有一套优先内置解析、网络嗅探和信息分析，一旦发现流量被虚拟网卡接管，就会不断重试，明确走不了才会降级到常规网络。@giv00257710 踩过更深的坑，发现微信很多图片其实是直接走纯 IP 地址拉取，压根不走域名，导致常规的域名白名单直接失效。加上 @tzhsz 提到的 edns 机制，多媒体 CDN 很容易被国外 DNS 误解析到海外服务器。 第一流派，也是呼声最高、提议人数最多的关停 IPv6 派。 @LeungDeo、@Edison_aware、@BarrySong97、@Ner0sss、@5tran9er 和 @ncle99 都直接给出了一句话诊断：关掉 IPv6。 @Jerry182809 直言用机场的第一步就是关 IPv6。@chrislee_sub 也吐槽微信的 IPv6 兼容问题早就存在好几年了。@0i8up 补充说国内很多家庭路由器和宽带的 IPv6 本身就极其不稳定，像没普及一样，开了徒增玄学断流。 关掉 IPv6 救活的远不止微信。@vireriver 反馈自己只要一开代理，京东和淘宝的商品图片全线崩溃，关了 IPv6 立刻恢复；@ddflj3310 也提到在 Surge 下剪映等抖音系应用完全登不上，同样靠关 IPv6 解决。@HunterRockCat 则提醒飞书等办公协同软件也会遭遇同样的问题。 背后的逻辑被 @grok 和 @MoeDejavu 点透了：绝大多数代理节点根本没有配置 IPv6 出口，但 DNS 偏偏解析出了 AAAA 记录。微信偏偏优先尝试 IPv6 连接，结果掉进路由黑洞死等超时，几秒后才狼狈降级回 IPv4，体感上就是图片一直在死转圈。@MoeDejavu 建议，如果关了 IPv6 还不稳定，记得把代理客户端里的 AAAA 查询解析也一并关停。 第二流派，追求完美双栈的 fake-ip 规则精修派。 很多朋友不想为了微信直接废掉 IPv6，选择对分流配置进行细化。@0xfingeroo 贴出了 GitHub 上 Clash Verge Rev 官方 issue 1762 的长篇排查讨论。 @qtwaiter 给出了教科书级的 fake-ip 原理：在虚拟网卡接管流量时，所有域名都被劫持进了虚拟私有网段。必须在 dns 配置的 fake-ip-filter 加入白名单，强制腾讯的多媒体域名走真实国内 IP 解析。比如针对 QQ 和微信的图片视频，把 放进过滤列表。 @LeonKuo2023 具体给出了两条立竿见影的直连后缀规则： 和 提醒，很多人的微信图片卡死，纯粹是因为分流规则没写全，图片请求被最底下的兜底规则误送到了海外代理。@cnfree8964 补充把严格路由关闭；@LaelLuo 建议排查 QUIC 协议嗅探；@neotuper 建议检查 SNI 分流；@AwesomeYang_com 和 @wooooow_wo 则建议在规则里单独指定微信进程走 DIRECT 直连。 第三流派，干脆放弃虚拟网卡的实用派。 @YanzuWuahh 早就被 Tun 模式的各种玄学搞烦了，选择退回经典架构：系统代理搭配 Proxifier，只对指定的海外开发工具开启强制代理，微信这种国内应用压根碰不到虚拟网卡。 @qg7777 提到，如果没有配置专门的软路由做增强模式，单靠本机跑单一的 Tun 模式极易翻车。@bnxiohi15661429 也吐槽某些客户端内核对 Tun 的处理不够完善，换成小火箭等工具反而没这些毛病。 第四流派，赛博神医 AI 排查流。 @dave33_z 分享了硬核实战：之前买 AWS Lightsail 晚高峰延迟卡死，直接把网络环境和配置丢给 Codex，一通调优把晚高峰延迟压到了六十毫秒。现在遇到各种网络玄学，直接把配置文件丢给 AI 分析。 @tina_sound43105、@neveriwill14294、@xueyu1125、@thePixelsAI、@Silas10m 和 @Lee656233622 全都站这一边。把本地分流规则丢给 Codex 或 DeepSeek，让模型顺着路由跳数检查，几分钟就能自动生成改好的配置。@misaki233q 更是让 Agent 搓出了一套高级双栈规则：国内应用走 IPv6 直连，海外流量走 IPv4 代理，鱼和熊掌全部兼得。 第五流派，反思工具本质的断舍离派。 @WetThinAir 抛出了一个直击本质的问题：我们到底为什么非要开 Tun 模式？像很多写代码的工具，单独配个终端环境或者局部端口就能跑得飞快，根本没必要为了几个工具让全系统的网络流量都从虚拟网卡里冒险淌一遍。 遇到微信转圈的朋友，照着这份清单排查，基本药到病除。