近期CPO消息汇总解读

先说我自己的结论:这轮所谓“CPO进展超预期”,真实含义是——它从纯概念变成了有交付、有项目、有供应商的导入期。
但另一句也要同时成立:市场把量级讲得太满了,10万台这种叙事水分很大。


1)先把路线说清:现在产业聚焦的是CPO,不是NPO

我更愿意把它拆成两句话记:

  • 英伟达体系:路线定调就是CPO。
  • CSP(云厂商)体系:更现实的是NPO先跑。

这两条并不矛盾:英伟达想要标准和系统能力,云厂商更在意成本/维护/议价权,路线自然分叉。


2)量级别被带节奏:今年更像“3–5万台”,10万台是期权

我对“今年小批量→明年规模化”的理解是这样:

  • 今年:3–5万台这种说法更像“能落地的保守量”。
  • 2027年10万台:要靠良率爬坡硬顶出来,不是口号。

这里的关键点只有一个:良率。CPO一旦良率不够,维护成本会吓退客户,尤其是微软/甲骨文这类更看成本的。


3)谁是真CPO链条、谁只是蹭概念:我会分三档看

第一档:现阶段“真供货/真核心”

  • 天孚通信、罗博特科、腾景、炬光科技
    我认同这四家是当前CPO叙事里标签最清晰、最能被“点名”的参与者。短期市场就认这四个。

第二档:远期期权(能做但还没进链)

  • 源杰科技这类光源头部:我会当成“供应商范围放开后的候选”,但你别指望明年就切入。两年左右才算合理预期。

第三档:关联度偏弱,容易变成纯概念

  • 永鼎股份、德科立这类,被你拿来硬贴CPO,我觉得站不住。
  • 另外,光纤环节不算CPO链条,别混。

4)中际旭创:我不担心业绩,但我承认它的“产业话语权”会被稀释

我对旭创的态度一直比较稳定:

  • 业绩端:短期不至于差,甚至还会增长(可插拔光模块产能还在扩,外加CPO/NPO会带来新增收入)。
  • 估值端:它的“核心角色”可能没以前那么独一份了。
    原因不是被同行干掉,而是CPO这条新路线把产业重心分流。这会让市场愿意给它的“溢价倍数”更摇摆——25倍、30倍、20倍、甚至更低,讨论空间变大。

一句话:我不怕它赚不到钱,我怕的是市场不愿意像以前那样给它“唯一性溢价”。


5)NPO这条线:核心参与者还是旭创、新易盛

我会把NPO理解成“云厂商侧的过渡路线”:

  • 需求主要在谷歌等CSP侧,
  • 参与者以中际旭创、新易盛这类光模块龙头为主。

NPO最大的问题不是“有没有需求”,而是没有统一标准:出了问题往往只能整体换,维护视角看确实糟心;但反过来,标准不统一也给了云厂商通过招投标压价的空间——对他们未必是坏事


6)英伟达 vs 博通:我更相信英伟达把CPO推快,但也更担心它“定价太狠”

这段我理解为:

  • 英伟达:更像纯需求方,推动CPO动力更强,所以进展更快。
  • 博通:自己在ASIC/DSP/EML等环节有既得利益,推进CPO反而利弊纠缠,节奏更曲折,还可能要靠台积电一起解决工艺。

同时,CPO越标准化,越容易变成“少数人定标准、别人交钱”的格局——这就是云厂商天然不舒服的点。


7)我怎么做“交易层面的取舍”

如果只看这份材料,我的取舍会很直接:

  • 要吃CPO能见度提升(短期叙事):优先盯“已经能供货”的四家(天孚/罗博特科/腾景/炬光)。
  • 要吃云厂商侧NPO(过渡路线):旭创、新易盛仍然是主角。
  • 要吃远期期权:源杰这种可以放观察池,但别当近端主线。
  • 纯概念的:我会尽量避开,因为一旦市场情绪退潮,最先被砸的就是它们。

轻量化徒步装备分享:Montbell风暴巡洋舰Storm Cruiser冲锋衣(SUPER DRY-TEC版)

DRY-TEC 版风暴巡洋舰的定位很明确:轻量、可靠防雨、同时尽量把透气做到高,是一件偏“长线徒步/登山通勤都能用”的旗舰雨壳。

优点

1)透气指标很激进,适合“走起来会出汗”的人

官方/渠道给到的透气参数可到 40,000 g/m²/24h(JIS L-1099 B-1),属于硬壳里相当靠前的水平。

2)防水够用且偏稳

防水性能常见标注为 20,000mm 以上,应对大雨和强风雨场景没问题(前提是DWR状态正常)。

3)3层结构 + 30D 高强面料,兼顾耐用与重量

材质信息里明确是 3-layer DRY-TEC / SUPER DRY-TEC,外层为 30D Ballistic nylon ripstop,强调强度与耐磨。

4)版型与细节

官方卖点包含 K-Mono CUT 版型三轴可调帽(Tri-axial Hood)、卷帽固定、Aqua-Tect 防水拉链等,整体是为了在风雨里好用而不是好看。

5)轻

L码连收纳袋,实际称重265g

缺点

1)不是 Gore-Tex:心理溢价和二手认知会吃亏

DRY-TEC 是 montbell 自家膜,性能数据好看,但市场对“Gore-Tex =放心”的认知更强;转手和“品牌安心感”通常不如 GTX。

2)腋下没有拉链

不同地区/年代版本在腋下通风(pit zips)等细节可能不同,买之前最好确认你那件具体配置。

3)轻量壳的通病:更怕长期硬磨与DWR衰减

30D 已经算耐用,但再怎么说仍是轻量雨壳路线;长期重装穿林、背包肩带反复磨,外层泼水会衰减,需要定期清洗与补DWR。

适合谁

  • 走起来会出汗、想要“一件壳覆盖多数雨天徒步”的人
  • 追求轻量化 + 高透气 + 足够防水的平衡,而不是极限抗造硬壳
  • 183cm/78kg,穿L码

Debian 10 + AMH:硬盘占用异常增长,定位到 MySQL Binlog 并彻底解决

最近发现服务器硬盘占用持续上升,而且增长偏快。环境是 Debian 10.5 + AMH 面板 + MySQL 8(mysql-generic-8.0),最终定位到 **MySQL 二进制日志(binlog)**在持续写入并占用空间。本文记录完整排查与解决流程。

现象

  • df -h 显示根分区占用在增长(虽未满,但趋势异常)
  • du 分析目录后发现 /home 占用较大
  • 进一步排查发现 MySQL 目录下存在不断变大的 binlog.* 或 mysql-bin.* 文件

一、定位是哪个目录在增长

先确认哪个挂载点在涨:

df -h
df -i

然后用 du 分层定位大目录(不跨文件系统):

du -x -h --max-depth=1 / | sort -h

这次结果显示 /home 是占用大头,于是继续下钻并找最近变大的大文件:

find /home/usrdata -xdev -type f -mtime -7 -size +50M -printf '%TY-%Tm-%Td %TH:%TM %s %p\n' 2>/dev/null | sort -nr | head -50

输出里直接命中 MySQL 的 binlog 文件(如 binlog.000001、binlog.000002 等)。

二、确认 MySQL 正在写 Binlog

在 phpMyAdmin 里通过 SQL 确认 binlog 状态:

SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'log_bin_basename';
SHOW MASTER STATUS;
SHOW BINARY LOGS;

关键点:

  • log_bin = ON 说明 binlog 开着
  • log_bin_basename 能确认 binlog 前缀(例如 /home/usrdata/mysql-generic-8.0/binlog)
  • SHOW MASTER STATUS 的 File 表示当前正在写的 binlog 文件

三、踩坑记录:不要用 rm 直接删正在被 MySQL 管理的 binlog

这次过程中曾经用 rm 直接删除 binlog.000001~000005,导致后续在 phpMyAdmin 执行 purge 报错:

  • File ‘./binlog.000005’ not found (OS errno 2)

原因是:MySQL 仍保存着 binlog 的索引与状态,但实际文件已被手动删除,导致状态与磁盘不一致。

正确做法应该优先使用:

PURGE BINARY LOGS ...

或用更彻底的方式重建状态(见下文)。

四、最终解决方案:永久关闭 Binlog + 重置状态 + 清理残留文件

对于单机 WordPress(不做主从复制、也不依赖 binlog 做点时间恢复),最省心的方案是永久关闭 binlog

1)在 AMH 配置中强制关闭 binlog

进入 AMH → MySQL → 编辑配置,在 [mysqld] 段加入:

disable_log_bin

保存后重启 MySQL。

2)验证已关闭

phpMyAdmin 执行:

SHOW VARIABLES LIKE 'log_bin';

确认返回 OFF。

3)重建/清空 binlog 状态(修复“删文件导致索引错乱”)

在 phpMyAdmin 执行:

RESET MASTER;

此时 binlog 的索引、状态会被重置,避免后续再出现“引用不存在文件”的报错。

4)删除残留的大 binlog 文件(此时可以 rm)

因为 log_bin=OFF 且已 RESET MASTER,MySQL 不再写也不再依赖这些文件,可以安全删除历史残留(例如 mysql-bin.000001 很大):

cd /home/usrdata/mysql-generic-8.0/
ls -lh | egrep "mysql-bin|binlog"
rm -f mysql-bin.000001 mysql-bin.000002
rm -f binlog.* 2>/dev/null
df -h

五、结果

  • MySQL binlog 不再生成,硬盘占用增长停止
  • 清理残留文件后释放了数百 MB 空间
  • MySQL 状态恢复一致,不再出现 “binlog not found” 类报错

补充建议

  • 如果你确实需要 binlog(主从复制/点时间恢复),不要关闭;应设置自动过期,例如:
SET PERSIST binlog_expire_logs_seconds=259200;
  • (保留 3 天,按需调整)