离线AI设备买的是什么?

今天用 Qwen 3.8 27B 写代码的时候，和一个用户聊了一晚上，分享一下我对离线 AI 设备的看法。

成本账：深度用户才划算

深度 AI 用户，7x24 小时地用，跑长线任务，肯定硬件划算，一年就赚钱。但是你平常用线上 API 都不超过 2000 块，确实离线 AI 设备帮不了你。

Mac：Decode 优秀，Prefill 很弱

Mac 的显存带宽和 Decode 能力非常优秀，但是 Mac 的 Prefill 非常差，并发也很差，CUDA 不支持。Mac 从来不说这些，所以买东西要理性，多看多对比，理性选择自己想要的东西。

买设备是买认知

你只用线上 API，你在 AI 上的认知就和所有用线上 API 的人的认知是一样的，而 AI 未来的发展一定会让每家每户都有离线 GPT。你早一天用离线设备，就早一天获得竞争性优势，因为你比别人更懂离线 AI，就跟 20 年前你比别人更早玩电脑编程一个道理，那时候大家都还在犹豫要不要买一台笔记本？

所以，买 AI 设备，不能光看成本，要看你能用自己的设备做出哪些不一样的产品来？离线 AI 设备的目的不是否定在线 AI，而是在在线 AI 也用的情况下，你能通过折腾离线 AI 设备获得哪些未来在社会上的竞争力？

简单来说，买设备从来都是投资，而不是省钱，只比省钱是没法赚钱的。

via https://manateelazycat.github.io/feed.xml

30B 稠密模型就能解决个人编码的需求

我今天针对一个 AI 模型做深入分析，Qwen 3.8 27B xhigh 的速度比 GPT 5.6 sol Max 快 5 倍不止，而且 Qwen 3.8 27B 分析的结论非常严密。

包括今天和英伟达的芯片架构师聊过，他的一个观点：

“30B 的稠密模型就能解决个人编码的需求，以后不需要高显存带宽的更贵机器，因为 AI 模型本身会进化”

这句话就像我今晚做的试验一样，Qwen 3.8 27B 的足够能力，让我觉得，其实 GPT 再强大，它后台的服务器集群再牛逼，也许分到每个用户身上，就是 30B 的算力资源。

via https://manateelazycat.github.io/feed.xml

自由泳最关键的是手臂要伸直

这两天受教练的指导发现：其实自由泳最关键的是手要伸直，手没有伸直的时候，侧身就会扭曲导致身体摇摆，而不是自由泳的流线型。

原来手臂一直是弯的

之前一直以为手臂入水是直的，拍了视频才发现是弯的，如同敬礼的状态。

矫枉过正，以毒攻毒

教练最后说，你这种自学的人，直接来个矫枉过正，以毒攻毒吧，你手臂入水的时候用八字方式入水。

果然，这一下手臂入水直了，身体摆动和游速都快多了。

via https://manateelazycat.github.io/feed.xml

快速入睡技巧：仰卧在床上，做 10 组“4-7-8 呼吸法”（吸气 4 秒，屏息 7 秒，呼气 8 秒）。 然后从 300 开始，以 3 为单位倒数。呼吸能减缓心率，而倒数则能防止思绪纷飞。这种方法效果极佳，简直就像服用了安必恩一样。

— Michael Breus

4-7-8 呼吸法，我感觉有点难做到。Apple Watch 上正念冥想 App 里有这个呼吸的工具，对我来说没什么用。

但是头脑中摸摸倒数对助眠非常有用，我最近一周都在用这个方法。不过我没有用以 3 为单位倒数（今晚可以试一下！），直接倒序 300，299，298 这样对我来说已经很管用了。有的时候我倒数到 1 依然还没睡着，这时我会再开始一轮，第二轮我会从 500 开始，有时第一轮也会直接从 500 开始（当我预测自己还不够困的时候）。

这个助眠方法比我以前用的任何方法都管用。因为我的睡不着，主要原因就是思绪乱飞，强制自己倒数的话，思绪也会乱飞，但是重点是你会意识到，并且继续回到倒数中，直到睡着。

推荐有睡眠问题的朋友试一下。

via Owen - Featured posts

如何摆脱多巴胺文化?

● 有很多人因为无法抗拒划屏的冲动，而放弃了生活中必不可少的事情： ● 那些宁愿刷屏也不愿睡觉的人 ● 那些只顾刷屏而不进行体育锻炼的人 ● 那些只顾刷屏，却不去寻找人生伴侣，也不去与有血有肉的人建立联系的人 ● 那些只顾刷屏，却不去学习技能、找工作或追求职业发展的人
● 担心这些“屏幕僵尸”不读书，听起来几乎有些古板。简单的事实是，由于硅谷强加给他们的技术变革，他们整个生活正日益受到影响。但更令人不安的是，全球最大的企业正投入数十亿资金，以推广和加速人们对其技术工具的这种强迫性使用。
● 以下是我们可以采取的措施，以建立与科技之间更健康的关系。 ● 你不必扔掉手机——但明智的做法是尽量减少对滚动和滑动界面的依赖。 ● 走入世界，重新发现在我们还没有数字应用程序之前，真正的应用程序是什么样子的 ● 我从未加入过童子军（这个故事我改天再讲），也几乎从未为此感到遗憾。不过有一点例外——我很喜欢“功绩徽章”这个概念。要获得一枚徽章，就得走入社会，掌握一些应对现实生活的新技能。 ● 因此，你可以学习钓鱼、攀岩、园艺、急救、摄影、射箭、划船、背包旅行，以及许多其他技能。 ● 那便是我们还没有“应用”之前的“应用”。 ● 这些活动你现在依然都可以参加，每一项都不例外。而且你不需要穿童子军制服。 ● 如果你对户外活动不太感兴趣，也可以选择室内活动——烹饪课、读书会、瑜伽、戏剧，等等。 ● 这就是现实世界。这就是你在现实世界中培养自信和掌握技能的方式。这不仅仅是为了学习技能——做这些事情还能让你与社区以及其他人建立联系。没有任何一款应用程序能比得上这种个人能力的提升。

 ★ 

via Owen - Featured posts

如果你想卖音乐，就必须热爱那些歌曲。如果你想在新闻界取得成功，就必须热爱那些报纸。如果你想在电影界取得成功，就必须热爱电影。

— honest-broker.com

via Owen - Featured posts

如果你不希望自己的孩子接触它，却又靠出售它获利，那你就是在做伦理上自相矛盾的事。Tony 由此主张，产品创造者不能只说“我们是中性平台”，而应明确告诉用户这个在线社会相信什么、禁止什么。餐厅会把骚扰其他客人的人赶出去，技术平台同样可以设定边界、管理私人空间。所谓社会责任，在他看来不是事后加一套公益项目，而是在产品建立时就决定什么值得被鼓励、什么不应该被允许。

— chatgpt.com

via Owen - Featured posts

Firefox 插件注册、检测和自动签名方法

最近给 Firefox 做插件，才发现 Firefox 和 Chrome 的离线插件安装方式完全不一样。

Chrome 可以打开开发者模式，直接加载解压后的插件。Firefox 正式版和 Firefox ESR 安装 XPI 时会强制检查 Mozilla 签名，未签名的 XPI 即使代码完全正常，也会提示插件损坏或者签名无法验证。

about:debugging 虽然可以临时加载未签名插件，但 Firefox 重启以后插件就没了，只适合开发调试，不能用来给用户发布插件。

下面记录一下 Mozilla Firefox 插件的注册、上传检测和获取 API 信息的方法。

注册 Mozilla 开发者账号

先打开 Mozilla 插件开发者中心：

https://addons.mozilla.org/developers/

点击登录，用 Mozilla Account 登录。没有账号就先注册一个，然后同意 Firefox Add-ons 的开发者协议。

Mozilla 不需要提前单独注册一个插件 ID，第一次上传插件以后，开发者中心会自动创建插件项目。但是 manifest 里面一定要写固定的 Gecko ID，例如：

{
  "browser_specific_settings": {
    "gecko": {
      "id": "my-extension@example.com",
      "strict_min_version": "140.0"
    }
  }
}

这个 ID 相当于 Firefox 插件的身份证。后续更新版本必须继续使用同一个 ID，不能每个版本都随机换。

上传插件并进行检测

登录开发者中心以后，点击“提交新附加组件”，Mozilla 会让你选择发布方式：

1. 在 Mozilla Add-ons 上发布：插件会出现在 Firefox 插件商店里，适合公开发布。
2. 自行分发：Mozilla 只负责检测和签名，签名后的 XPI 由开发者自己放到网站上给用户下载。

如果只是想在自己的网站上提供 Firefox 插件下载，就选择“自行分发”，也就是 unlisted 渠道。

然后上传打包好的 XPI。XPI 本质上就是 ZIP 文件，但是要注意 manifest.json 必须直接位于压缩包根目录，不能在外面多套一层文件夹。

上传以后 Mozilla 会自动检测插件。检测失败就按照页面上的错误逐个修改，常见问题有：

1. manifest.json 格式错误，或者使用了 Firefox 不支持的 Chrome 字段。
2. Gecko ID 缺失，或者新版本和旧版本使用了不同的 ID。
3. 上传过相同的版本号。每次上传新版都必须增加 manifest 中的 version。
4. 插件申请了权限，但是没有正确声明数据收集用途。
5. 压缩包中包含源代码、临时文件或者不需要的构建文件。

Firefox 新版对插件数据收集声明检查得比较严格。比如插件需要读取网页活动和登录信息时，可以在 Gecko 配置中声明：

{
  "browser_specific_settings": {
    "gecko": {
      "id": "my-extension@example.com",
      "strict_min_version": "140.0",
      "data_collection_permissions": {
        "required": ["websiteActivity", "authenticationInfo"],
        "has_previous_consent": false
      }
    }
  }
}

具体声明要和插件真正读取的数据保持一致，不要直接照抄上面的权限。检测页面报错时，也要以 Mozilla 当时给出的字段说明为准。

检测通过以后继续提交。自行分发的插件不需要上架商店，Mozilla 处理完成后会生成一个已经签名的 XPI，下载这个文件才可以在正式版 Firefox 和 Firefox ESR 中长期安装。

安装签名 XPI 的方法是打开 about:addons，点击右上角齿轮，选择“从文件安装附加组件”。

获取 Firefox Add-ons API 信息

每次都在开发者中心手工上传和下载太麻烦，Mozilla 提供了 API，可以用 web-ext 自动上传、检测和下载签名后的 XPI。

登录开发者中心后，打开 API 凭据页面：

https://addons.mozilla.org/developers/addon/api/key/

点击生成新的凭据，页面会显示两项信息：

1. JWT issuer：这就是 API Key，一般长得像 user:123456:xxx。
2. JWT secret：这就是 API Secret。

API Key 不是插件的 Gecko ID，也不是 Mozilla 账号。API Secret 相当于账号密码，不要写进源码，不要提交到 Git，也不要放到公开日志里。如果密钥泄漏了，马上回到这个页面重新生成凭据，让旧密钥失效。

我一般把它们分别保存成两个文件：

firefox_addons_api_key.txt
firefox_addons_api_secret.txt

然后限制文件权限，并加入 .gitignore：

chmod 600 firefox_addons_api_key.txt firefox_addons_api_secret.txt

用 web-ext 自动签名

先确保待签名目录中包含 manifest.json 和插件需要的所有文件，然后执行：

export WEB_EXT_API_KEY="$(<firefox_addons_api_key.txt)"
export WEB_EXT_API_SECRET="$(<firefox_addons_api_secret.txt)"

npx --yes web-ext@latest sign \
  --channel unlisted \
  --source-dir ./firefox-extension \
  --artifacts-dir ./artifacts

unlisted 表示自行分发。web-ext 会把插件上传给 Mozilla，等待检测和签名，再把签名后的 XPI 下载到 artifacts 目录。

不要把 API Key 和 Secret 直接写在命令行参数中，否则可能进入 Shell 历史或者被进程列表看到。用环境变量传递会稳妥一些，自动构建程序也应该避免打印这两个变量。

每次生成新版 Firefox 插件前，要先增加 manifest 中的 version。同一个 Gecko ID 和同一个版本号不能重复签名，否则 Mozilla API 会直接拒绝。

怎么确认 XPI 已经签名？

可以解压 XPI，检查里面是否存在 Mozilla 的签名文件：

unzip -l my-extension.xpi | grep META-INF

正常会看到类似下面的文件：

META-INF/mozilla.rsa
META-INF/mozilla.sf
META-INF/cose.sig

不过最终还是要在正式版 Firefox 或 Firefox ESR 中实际安装一次。能通过 about:addons 正常安装，并且重启 Firefox 后插件仍然存在，才算整个签名和发布流程真正跑通。

简单总结一下：开发阶段用 about:debugging 临时加载，交付用户时走 unlisted 自动签名，想公开推广时再发布到 Firefox 插件商店。三种方式不要混在一起，就不会一直被 Firefox 的签名错误折腾。

via https://manateelazycat.github.io/feed.xml

GPT负责设计，离线27B负责执行：我超高效率但超省钱的工作流

分享我超高效率但是超省钱的工作流方式：

1. 和GPT深入探讨设计和方案
2. GPT在A项目中给出设计方案，我直接让离线的27B去执行
3. 27B执行的时候，我在和GPT讨论B项目的设计方案

和GPT深入探讨设计和方案

设计环节用线上GPT的全局规划能力。如图：我让Codex在全局列一下需求，回答尽量简洁，这样内容少了才好全局思考，把需求收拢成几条清晰的要点。

让离线的27B在后台慢慢用电干活

GPT给出设计方案后，我直接把方案丢给离线的27B执行。如图：Qwen 3.8 27B在AIPod上以vLLM方式运行，在Pi里无审查地执行“生成LPK并安装LPK”任务，23分45秒跑了22条命令，中途遇到本机缺unzip、sudo要密码这类问题也自己补了个node版unzip shim解决掉了。

兼具线上模型的能力与线下模型的省钱

看到了吗？利用线上GPT的全局规划能力，我和GPT在协作设计的时候，27B在后台慢慢用电来干活，而不是用订阅来干活。

这样我兼具了线上GPT模型的能力和线下模型的省钱，因为只要设计好，线下模型现在非常能打了。关键给我节省了90%的订阅费。

via https://manateelazycat.github.io/feed.xml

Invalid media:
image
image

高质量商业软件构建的秘密，这是我 20 年的经验，分享给大家，不一定对，供你们参考。

一、追求简单

越是顶尖的工程师，越要追求用最简单的技术去满足用户的需求。

很多年轻的工程师为了炫技，喜欢构建非常复杂的系统，沉迷于复杂的系统而无法自拔。但是复杂的系统会带来非常大的质量隐患，它却不一定会增加软件的健壮性，甚至有时候会拖慢软件的性能。

二、减少内耗

在 AI 时代，大家都明白，其实我们只是把世界的知识来回搬运，通过一定的信息差和知识差来满足用户的需求赚钱。

但是 AI 时代告诉我们，其实知识就在那里。执行已经不是问题的时候，千万不要沉迷于跟别人抬杠，或者为了证明自己。当你为了证明自己、或者要跟别人比的时候，其实你消耗了大量获取知识的能量，去跟陌生人抬杠，这是毫无意义的。

三、重视用户反馈

很多初级的工程师是很鄙视用户的意见的，但是你知道，这个世界上所有的经济学都建立在相互交换之上。

如果你鄙视付钱给你的客户，其实你就失去了赚钱的商业能力，这是最简单的一个道理。因为世界上没有人愿意把钱给一个鄙视他自己的人。

via https://manateelazycat.github.io/feed.xml

通过 CUDA 缓存技术实现 AI 模型部署加速

分享AI模型部署提速的方法。

这两周都在研究AI模型的移植和优化，昨天晚上认真分析了一下部署模型的耗时，主要是三块：

1. 模型权重加载
2. KV Cache 初始化
3. 编译 CUDA 内核

权重加载和 KV Cache 初始化没有太多优化空间

加载权重和 KV Cache 初始化更多是模型从磁盘到显存的搬运和初始化过程，没有太多优化策略。

编译 CUDA 内核这一步完全没有必要

反而是 CUDA 内核编译却没有必要，所以我先在 T5000 芯片上编译 CUDA 内核，然后把编译好的 cache、triton、nv 等生成目录合成一个 CUDA 缓存包，用户只需要下载缓存包就可以加载 CUDA 内核，而不是每次加载模型都需要重新编译 CUDA 内核。

优化前后的耗时对比

通过这样的方式，我把整个重新部署的时间从 40 分钟，压缩到 16 分钟，大大节省了部署 AI 模型的时间。

via https://manateelazycat.github.io/feed.xml

Invalid media: image

给坦克500Hit4扩油箱

今天来把我的油箱换了，从 68 升换到 140 升 这样加上车上的电池，油电混合可以跑 1500 公里 这样可以轻松穿越中国任何一个无人区😎

坦克这种车，天然有两个加油口，官方就支持安装副油箱，但是安装副油箱的一个问题是，主油箱的油用完了以后，需要用压力泵把油从副油箱抽到主油箱，这种方式在野外极限越野的时候，容易油泵出现问题不泵油，导致你有油却开不动的问题

我这次改装的方式是，原车的油表/油管/电路都不动，直接用140升的新油箱替换原车68升的油箱，这样就不会存在油泵的问题了 看油表的时候，就看车机仪表盘，燃油剩余里程 x 2就是真实的油箱里程

via https://manateelazycat.github.io/feed.xml

Invalid media:
image
image
image
image

分享 Qwen AI 模型移植的经验给大家，避免像我这样踩坑

最近两周移植了 DeepSeek V4 Flash 和 Qwen 3.8 27B 的未审查版本，都没有问题 唯独 Qwen 3.8 Flash Next 的未审查版，5K 以上长输出会遇到“中英韩”的多国语言混合乱码问题

这个首先肯定是 Qwen 3.8 Flash Next 训练不严谨的问题，其他模型都不会乱码

同时需要配置好 AI Agent 的参数，我测试了很多遍，必须按照温度 0.3、top_p 0.95、top_k 20 的设定后，Pi Agent 中输出才不会乱码 另外模型 ID 也要统一，模型 ID、models id、Pi Agent id 都要设置为 qwen3.8-flash-next-uncensored

今天忙了一天，把算力舱的 DeepSeek/GLM/Qwen/MiniMax 全部都更新了一遍，性能更强，显存/磁盘的管理也更加方便了 明天继续优化 Qwen 3.8 Flash Next 和 MiniMax H3，明天下午挑战两台算力舱跑最新的 DeepSeek V4.1！

via https://manateelazycat.github.io/feed.xml

今天跟大家分享一下技术人创业需要补强的几个方面

1. 大方向要对，方向不对，就是勤奋自我感动。大方向来源于读书、交流、晒太阳、散步、深度思考
2. 大错不要犯，一般犯大错的原因就是自己在顺境中获取优势以后，自我膨胀。膨胀才会犯大错。避免犯大错的方法还是读书，多读历史书，看到古人作死的方式，就会时刻反省自己不要膨胀
3. 做事要果断，在 AI 时代，最重要的是你的判断力，执行力不是瓶颈了。判断力培养的方式就是要果断做决定，果断犯小错，也比优柔寡断不做决定好，因为 AI 时代的执行力很强，你犯的小错可以通过快速迭代来解决

via https://manateelazycat.github.io/feed.xml

超大 PDF 的流畅缩放优化

分享一下读书软件的深度优化技巧。

懒猫读书的后端是传输片段到前端去做实时渲染的。这样的好处就是不光传图片，前端可以直接用后端传输的原始数据进行文字标注和文字选中。

但是遇到很多超大的 PDF，传输 PDF 的原始数据就不现实了，因为会超级卡，甚至很多超大的 PDF 会把平板和手机的内存撑爆。

所以这种超大的 PDF 只能传缩略图，但是传缩略图又会导致放大的时候会有一定的模糊。

所以现在懒猫读书的方案是：

● 可编辑的文档传原始数据。
● 不可编辑的文档，像 PDF 扫描版传缩略图。
● 遇到缩放的时候再临时传输 tile 做高清晰渲染层。

这样就可以兼顾流畅性、前端内存的控制，同时针对极限缩放提供无极的清晰度。

今天终于把这个花雕完了，大家可以看一下我们实时放大的效果，还是很不错的。

via https://manateelazycat.github.io/feed.xml

Invalid media: video

模型不同上下文的解码速度

这几天在做精细化的 AI 模型移植，发现一个特别有趣的现象。

Qwen 3.8 Flash Next 的甜品区是 265K 的上下文，它的解码速度最快。

Qwen 3.8 27B 的甜品区，不是 265K，也不是 900K，反而是 512K 的时候，它的解码速度最快。

这个测试结果是非常有意思的，分享给大家，赶快去把你的上下文调到最优的值吧😎

via https://manateelazycat.github.io/feed.xml

Invalid media: image

GPT + Qwen 3.8 27B 协作工作流

我还是太爱 Qwen 3.8 27B 了，虽然没有 GPT 那么全能，但是只要是明确的任务，详细说好了，真的是指哪打哪。

很多朋友会问为什么不用解码速度更快的 Qwen 3.8 Flash Next？因为我这两三周都在做 AI 模型移植的工作，我发现 Qwen 3.8 Flash Next 这个模型训练的还是不够严谨，上下文非常长的时候，会出现乱码的情况，只能靠 Pi Agent 温度配置来缓解，而 Qwen 3.8 27B 各种稳定呀。

我现在都用 GPT 做规划，让 27B 去执行，效率杠杠的。

用 Pi Agent 配 Qwen 3.8 27B 修复博客视频问题的过程：

via https://manateelazycat.github.io/feed.xml

Invalid media: image

AI 模型动态 KV Cache 技术分享。这两天我一直在研究上下文和 KV Cache 的动态调节技术，终于被我搞出来了。

现在用户部署的时候，KV Cache 会根据用户输入的上下文动态调节显存占用的值，而不是像原来那样通过 --gpu-memory-utilization 固定的显存分配申请。

KV Cache 按照公式计算：

2 GiB + tokens × 87 KiB

再按 256 MiB 对齐。

改动以后，Qwen 3.8 27B 512K 和 900K 上下文的显存差距可以拉到 30GB 左右，用户可以用多余的 30GB 显存并行跑其他模型。

via https://manateelazycat.github.io/feed.xml

DeepSeek V4 Flash TP2 并发 Prefill 调优实战

DeepSeek 模型调优并发技术分享。最近都在调优 DeepSeek V4 Flash 的 TP2 模型，简单来说就是两台算力舱同时通过 TP2 的技术跑 DeepSeek。因为两台机器的显存总共超过 256 GB，所以即使是非常大的 DeepSeek 也可以提供 1MB 的超大上下文。

最近用户反馈多个并发的时候，第二个 Prefill 会等很久。今天上午研究了一会，发现跟 vLLM 的 --long-prefill-token-threshold 参数有关。

问题定位：long-prefill-token-threshold 参数

--long-prefill-token-threshold 是限制单个 Prefill 请求一次调度迭代中最多处理的 Tokens 数量，默认是 2048，最大可以设置成 4096。

最开始我移植 DeepSeek 的时候，觉得这个值设置为 2048 肯定够了。早上研究才发现，这个值不能设置得很大。因为太大了，vLLM 就会让第一个 Prefill 充分执行；当 Prefill 的值达不到 2048 的时候，后续的 Prefill 就会被排队。

需要调小这个值，给 vLLM 增加调度多个 Prefill 的机会。我测试了一上午，最后发现 1024 这个值最好。

测试结果对比

当设置为 1024 时，8 并发同时请求，后续的 Prefill 可以从最大的 90 秒的等待时间下降到 7 秒左右，而总吞吐只下降了 2.5%。

如果继续下降到 512，虽然后续请求的 TTFT 还会继续下降，但是总吞吐量就会下降到 15% 以上。

https://manateelazycat.github.io/pics/deepseek-tp2-prefill-tuning/prefill-threshold.png

从上面的测试数据可以看出：

● 1024 综合最好：短请求 TTFT 降低 35%~46%，A TTFT 增加约 2.5%，总吞吐下降约 2.5%。
● 512 延迟继续下降，但 A TTFT 增加约 18%，总吞吐下降约 15%，8 并发波动也更大。
● 当前线上已恢复为 2048，部署状态 succeeded/ready，健康检查通过。8 并发下的 waiting 4096-token 是调度预算，不是 KV 内存不足。

结语

今天的 AI 模型调优核心技术就分享到这里。欢迎大家购买懒猫 AI 算力舱 + 懒猫微服套餐，CEO 亲自给你调优 AI 模型性能，把设备的性能压到极限。

via https://manateelazycat.github.io/feed.xml

2026 年江苏万驰国际赛车场一日游

这是走出上海赛道的第一步，来到了江苏万驰赛车场，开启人生中天马以外的第一个房车赛道。

万驰赛车场名义上是一个「AAA 级旅游景区」，入口的大门看上去像是一个高级小区的门口，在进门前左右手边都是居民楼，阳台可以直接看到整个赛道，不知道这个赛景房的居民居住体验是如何的。

价格方面，多亏了江浙沪富哥哥们的努力，万驰赛道在江浙沪地区一再被冷漠，已经开始官方直接出售 399 元一整天的体验票，于是趁着周二去南京████的机会，周三体验了一次一整天只要 399 元的活动（实际上是 434 ： 399 + 5 （手环费？）+ 30 （保险费））。（日常价格依然和天马对齐，是 500 元一节）

从万驰的赛道图可以看到，不像天马只要会踩刹车就行，万驰有大量依赖节奏的连续弯，例如 T4~T7 组合弯，每个弯的入弯和出弯状态会直接影响下一个弯的进弯节奏，需要根据每个车不同的动力，布局和已有的一些特性逐渐掌握一个适合自己车的最佳路线，且许多弯心速度不低，循迹控制不好很容易把车尾甩出去，整体来说比天马有趣/难/危险的多。

此外，不像天马基本只有 T7 高速弯略微有些危险，万驰中著名的「海螺弯」（T8） 需要在 T7 全油出后一路全油到达 T9 走 double apex 或者超晚弯心路线，且 T9 刹车点前全程全油，侧向 G 值几乎一直稳定 > 1G ，非常刺激。

这一次由于到达时间较晚，错过了早上第一节，只跑了 5 节，其中还包括带人上场跑，Racechorno 的记录如下（从早到晚是，从右往左）：

上场第一节开着空调开着 ESP 带人跑出的最快成绩是 1:23:1 ，到了下午稍微熟悉了一些之后，关闭了空调关闭了 ESP 最快单人成绩是 1:21:02 ，不过下午由于 Knock Control 在持续增高（从 0.49 -> 0.70），动力应该有所衰减。

这一次万驰练习下来感觉暴露出我个人对于真车驾驶的一个很大的问题：循迹刹车不够稳定，由于之前模拟器练习基本都是驾驶 GT3 为主，且 ACC 对于循迹刹车只要求做一个刹车的假动作车头就已经可以入弯了，加之之前练习的赛道都是天马，天马似乎只有 T1 和 T4 对于循迹略有要求，导致我在万驰的 T2，T12 非常推头（要么刹车直接松完快速丢方向开始推头，要么刹车晚了一点带着较大的刹车丢方向导致推头），导致即使有 -2 度的前轮外倾角，胎肩磨损依然很大：

右前轮上午跑完两节后的状态：

右后轮上午跑完两节后的状态：

导出了 Racechorno 的数据喂给 ChatGPT 后也有类似的结论：

你现在已经不是“先把车开顺”的阶段了，当前主要瓶颈是中低速连续弯里的减速量与放刹时机，以及几个弯之间的速度连接；重刹能力、快速弯胆量和单圈基本节奏已经相当稳定。

最值得注意的是 T3–T5。在你其他快圈里，T4 曾经以大约 87.7 km/h 通过，相比 80.84 圈高接近 8 km/h；T5 也有大约 77 km/h 的记录，比最快圈高 4 km/h 左右，而且对应小段确实更快。这不像单纯“别人走了不一样的线造成 GPS 误差”，而更像是 80.84 那一圈在这组弯里多减了一点速度。

所以这里下一次不要先想着“把刹车点再延后五米”。更有效的是：同一个刹车点附近保持首次制动强度，然后更早、更连续地释放刹车，让车在入弯阶段保留 3–5 km/h；尤其不要出现已经释放后又二次补刹、重新把前轮压死的情况。 你最快局部数据已经证明车能承受更高速度。

最快圈记录如下：

当天下午还看到了在 T1 末尾小米保留环节：

车载视频

YouTube

iframe (www.youtube.com)

Bilibili

iframe (External Player - 哔哩哔哩嵌入式外链播放器)

整体来说第一次来跑能跑到 1:21 还是比较满意的，详细赛道练习记录放在了 https://fk7.nova.moe/track/logs/2026-09-wantrack/ ，期待下次再来。

via Posts on Nova Kwok's Awesome Blog

Invalid media:
image
image
image
image
image
image
image
image
image
image
image