观海听涛

金斯瑞 (1548.HK) DNA存储合作深度研究

Tue, 21 Apr 2026 23:46:32 +0800

研究日期: 2026-04-10 股票代码: 1548.HK 当前股价: HKD 12.84

一、核心事件：与Mimulus达成DNA数据存储战略合作

合作概况

公布时间: 2026年4月9日
合作方: Mimulus（分子档案技术先驱）
合作性质: 多年、里程碑式战略合作
目标: 实现DNA数据存储工业化，目标2030年末实现完全超大规模生产

双方角色

角色	Mimulus	GenScript (金斯瑞)
定位	分子档案技术先驱	全球领先CMOS DNA合成技术提供商
提供	Glacier数据存储卡™及架构	大规模高吞吐量DNA合成能力
职责	技术授权 + 架构设计	批量生产 + 制造工艺开发

核心技术：Glacier数据存储卡™

形态: 信用卡大小设备
能耗: 零瓦特 — 无需电力
冷却: 无需冷却系统
维护: 免维护
数据保存: 永不降解，号称"永久档案"
接口: 兼容S3 API

商业逻辑

电力瓶颈: AI扩张导致数据中心电力需求激增，传统存储面临能耗瓶颈
冷存储释放: DNA存储可释放被传统冷存储占用的电网电力
密度优势: 1克DNA可存储215PB数据（是硬盘的100万倍，2025年白皮书数据）

二、股价技术面分析

近期走势

日期	收盘价	成交量	备注
2026-03-22	10.60	12.4M	近期低点
2026-03-31	11.85	17.6M	突破前
2026-04-01	12.36	14.0M	放量大涨
2026-04-07	12.88	21.3M	合作公布前
2026-04-09	12.84	3.4M	合作公布日

均线状态（参考TOPICS记录）

金斯瑞+3.1%（均线多头排列）

GPT-5.4 xhigh、Qwen3.6-Plus、Claude Opus 4.6、Claude Opus 4.7 对比

Tue, 21 Apr 2026 23:28:06 +0800

GPT-5.4 xhigh 指的是：GPT-5.4 + reasoning.effort=xhigh。xhigh 是推理档位，不是单独的底模。
Claude Opus 4.6 截至 2026-04-20 已不是最新 Opus。Anthropic 已在 2026-04-16 发布 Claude Opus 4.7。

一句话结论

要终端式 coding、复杂多步执行、跨工具稳定性：优先看 GPT-5.4 xhigh。
要 GitHub issue 修复、仓库级 bugfix、Claude 生态里的最新主力模型：优先看 Claude Opus 4.7。
要性价比、1M 长上下文、阿里云接入、中文开发环境：优先看 Qwen3.6-Plus。
Claude Opus 4.6 仍然强，尤其在长上下文一致性上有代表性成绩，但从官方定位到最新公开 benchmark，Opus 4.7 已经是 4.6 的直接升级版。

核心规格

维度	GPT-5.4 xhigh	Qwen3.6-Plus	Claude Opus 4.6	Claude Opus 4.7
官方定位	复杂专业工作、agent、coding	通用推理 + agent + 多模态	复杂 agent、coding、长周期任务	Claude 当前最强通用可用模型，主打复杂推理与 agentic coding
推理模式	`none/low/medium/high/xhigh`	默认开启思考模式	`adaptive thinking` / extended thinking	`adaptive thinking` + `effort`，新增 `xhigh`
上下文窗口	1,050,000	1,000,000	1M	1M
最大输出	128,000	65,536	128k	128k
公开价格	$2.50 输入 / $15 输出	阿里云国际区：0-256K 为 3.7471 元输入 / 22.4826 元输出；256K-1M 为 14.9884 元输入 / 44.965 元输出	$5 输入 / $25 输出	$5 输入 / $25 输出
长上下文定价备注	超过标准 272K 窗口后，按更高倍率计费	256K 以上进入更高阶梯	1M 窗口按标准价	1M 窗口按标准价
额外特点	OpenAI 终端 agent 指标强	国内接入和性价比优势明显	长上下文一致性强，4.7 的直接前代	更高分辨率视觉、更长任务预算、直接升级 4.6

Benchmark 速览

注意：下面分数都来自厂商官方，但不完全是同一套 harness、同一套 prompt、同一套推理预算，适合看趋势，不适合把 1 到 2 分的差距当成严格胜负。为便于横向比较，下面统一写成纯数字；若无额外说明，可按百分比口径理解。

JavaScript 模块系统

Tue, 21 Apr 2026 10:00:00 +0800

JavaScript 现在并不缺模块系统，真正的问题是你同时会遇到三层东西：

语言标准里的 ESM: import / export
Node.js 历史遗留的 CommonJS: require / module.exports
浏览器和包管理层的解析规则: type="module"、import map、package.json 的 "exports" / "imports"

如果只记一个结论：

新项目默认优先写 ESM
遇到旧 Node.js 工程、老工具链、历史包袱时才继续用 CommonJS
给 npm 包设计入口时，优先把公开接口写清楚，不要再依赖“随便从包内部路径 import”

1. 先把几个名词分清

CommonJS

Node.js 最早用的是 CommonJS。典型写法如下：

const fs = require('node:fs')

function add(a, b) {
  return a + b
}

module.exports = {add}

它的特点是：

运行时加载
入口 API 是 require
导出核心是 module.exports
对旧 Node.js 生态兼容最好

如果你是这种写法，不要写 exports = xxx，那只是改了局部变量绑定，真正导出的仍然是 module.exports。

ESM

ESM 是 ECMAScript 标准模块格式，现在已经是浏览器和 Node.js 的共同主线：

export function add(a, b) {
  return a + b
}

import {add} from './add.js'

console.log(add(1, 2))

它的特点是：

Linux TCP 服务端调优

Thu, 12 Mar 2020 15:56:28 +0800

很多旧的 TCP 调优文章都带着明显的时代痕迹：

把代理场景、路由转发场景、普通服务端场景混在一起
往 /etc/sysctl.conf 里塞一大堆已经废弃、默认已经合理、或者根本不该全局修改的参数
只给“魔改参数”，不给验证方法

Linux 5.x / 6.x 下，更靠谱的思路是：

先确认瓶颈是在应用、内核、NIC，还是链路本身
只改少量确实相关的参数
每次改动都能用指标或压测结果验证

先看什么

先别急着改 sysctl，先看这些：

# 当前拥塞控制算法和可选项
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_available_congestion_control

# 当前 qdisc
sysctl net.core.default_qdisc
tc qdisc show dev eth0

# TCP 概览
ss -s
ss -lnt

# 协议计数器
nstat -az

# 网卡统计
ethtool -S eth0

如果问题其实是：

进程 ulimit -n 太小
应用监听 backlog 太小
单进程 accept 太慢
用户态线程池、数据库连接池、磁盘 IO 才是瓶颈

那改 TCP 参数通常不会有本质帮助。

关于我

Mon, 29 Feb 2016 16:26:30 +0800

写点什么。

Email: garden.yuen # gmail.com
GitHub: @weaming
RSS: feed.xml